Bonjour,
 
Voila, je dois creer un programme en c++ qui doit ecrire un fichier en memoire virtuelle. Le probleme c est que j ai aucune idee comment creer une memoire virtuelle et ecrire dedans. Est ce quelqu un peut me donner des info ou me dire ou je peux trouver ces info?
Merci de votre aide

sais tu au moins ce qu'est la mémoire virtuelle ? si tu le savais, tu t'apercevrais de l'énormité de ce que tu écris
http://aumha.org/win5/a/xpvm.php

ça a pas vraiment de sens pratique ce que tu veux faire.
 
par contre tu peux utiliser un fichier mappé en mémoire, c'est peut être ce qu'il faut que tu fasse.
 
ça permet plus ou moins de réutiliser le moteur de pagination vers disque de l'os de manière eplicite.

Desole si je sais pas ce qu est une memoire virtuelle. Je suis en stage et on ma dit qu il fallait voir si c etait possible d ecrire mon fichier texte en utilisant une memoire virtuelle car une des contraintes de mon projet est justement de ne pas ecrire sur le disque dur.

ah, tu veux écrire sur un disque virtuel ! en mémoire quoi ! donc tu fais le malloc() qui va bien et puis voila

donc meme si mon fichier est vraiment gros (genre 2Mega) ca marche ou est ce que le malloc est limite en taille?

sauf si t'utilises un compilo datant de 1987, non malloc n'as pas ce genre de limitation

Merci beaucoup a tous. Je vais en parler a mon chef. Ca devrait resoudre nos problemes.

bin heu oué okay, mais bon si c'est pour un fichier de log ou je ne sais trop rien, le malloc aidera pas..

c est pour un fichier texte. En fait, c juste une tres longue chaine de caracteres, non?  
Et apres comme je veux l envoyer par internet, j ai juste a lire la chaine.

bin heu ça veux rien dire, contexte trop large.
 
si c'est pour la manipuler dans le code C++, autant utiliser un ostringstream, si c'est pour la manipuler a l'extérieur du binaire avec d'autres outils qui ne touchent que des fichiers (client FTP), alors oui il faudra passer par un disque virtuel.

Tu peux peut-être même l'envoyer sur internet à mesure que tu le fabriques, ton fichier... à moins que sa construction prenne beaucoup de temps ou bien qu'elle ne soit pas "triviale"...

ou puis-je trouver des info sur les disques virtuels? et comment je peux en creer et m en servir?

non mais on s'en fout du disque virtuel ! c'est de la ram c'est tout !

si tu veux je peux t'en vendre un, de disque virtuel

ouai on est d'accord, mais si il doit utiliser un client ftpeux, et qu'il a pas de disque, faut bien qu'il puisse lui faire plaisir...

pas cher mon fils

Exact. Une énorme chaîne de caractères parsemée de petits "CTRL-M" si t'es sur Unix, et de petits "CTRL-J+CTRL-M" si t'es sur Windows. Chaque fois que l'éditeur trouve un de ces caractères, il passe à la ligne lors de l'affichage.
 

Ben en fait, si t'as la chaîne en mémoire, il te suffit de placer un pointeur en début de chaîne et d'envoyer sur ta socket "n" octets à partir de ce pointeur. Puis tu décales ce pointeur de "n" octets tant que t'es pas arrivé au bout (avec un petit contrôle intelligent du dépassement).
Tu pourrais tenter d'envoyer toute la chaîne d'un coup mais je sais pas si la commande "send" n'est pas limitée en taille...

 
bien entendu on a pas a savoir que sous windows une ligne se termine par "\r\n" (ce sont des détails d'implementation qui ne font que diminuer la portabilité du programme si on en tient compte). En C++ une ligne se termine toujours et uniquement par '\n', comme ca ca reste simple

ok bon bah je vais en parler avec mes chefs et voir si ca leur va.
Merci.

Exact. Si on veut écrire une ligne, il suffit de la faire terminer par '\n'. Et si on veut la lire, il suffit d'utiliser "fgets()" ou "getline()" qui s'arrêtent à la fin de la ligne quelle que soit cette fin...
 

En fait, on ne sait toujours pas trop quel est ton besoin.
Si c'est de créer un fichier en mémoire, alors un simple malloc et basta. Même si le malloc fait 200Mo, le système s'amusera avec sa swap mais il te donnera ton allocation.
Si c'est de créer un fichier sur un disque virtuel, le C++ ne peut pas t'aider car la notion de "disque virtuel" est hors de son concept. Tout ce qu'il sait faire, c'est créer des fichiers sur un périphérique et c'est à toi de faire en sorte que ce périphérique soit virtuel (par exemple monter un répertoire en swap sur Unix et écrire un fichier dans ce répertoire; ou utiliser "ramDisk" (http://www.arsoft-online.com) sour Windows et écrire sur le lecteur virtuel créé par "ramDisk" )...

Ok bon je donne plus de detail sur mon projet:
Je dois faire une interface entre 2 logiciels. Cette interface devra lire des donnees ds les queues d un des logiciels puis les envoyer sous un certain format a l autre logiciel via le net.
Pourquoi je veux obligatoirement ecrire un fichier? en fait il existe deja des dll que je peux utiliser qui ecrivent le fichier sous le bon format et qui l envoyent au 2eme logiciel. Le probleme est que ces dll ecrivent le fichier sur le disque dur et mon chef ne veut pas de ca (probleme de crash du disque qui est important ds l environnement ou le produit est utilise). C est pourquoi on m a demande de me renseigner pour voir si je pouvais pas ecrire le fichier sur un disque (memeoire) vituel.
Dans mon cas je pense pas que je puisse utiliser "ramDisk" comme le suggere Sve@r, car mon programme ne sera pas utilise que sur ma machine mais sera vendu a d autres compagnies et il faut que tout soit simple a utiliser. Si je commence a dire que d avord il faut installer tel truc, puis faire telle manip, on est pas sorti.
Pour l instant, mon chef est en deplacement pour la semaine donc je lui en parlerai la semaine prochaine.

As-tu regarde ce que peux faire ta bibliotheque ? Si elle peut envoyer le contenu d'un fichier a une autre appli, elle doit certainement pouvoir envoyer un bourdel pointe    
 
(Je m'imagine trop la scene : Hey boss ! J'ai trouve la solution, new !   )

en fait pour l instant j ai pas encore les bibli donc je sais pas exactement comment elles font. Pour l instant c est que de la recherche de solution que je dois faire.

Euh... a mon avis, si le disque crashe pendant que l'appli est exécutée, ça m'étonnerait fort que l'appli continue même si tout se fait en mémoire. Et même si elle continue, ceux qui utilisent l'appli auront d'autres soucis à gérer que de récupérer les infos de l'appli. Et comme la mémoire utilise quand-même le disque pour ses swap je pense que l'argument de ton chef "tout faire en mémoire de peur du crash" risque de ne pas tenir face à la réalité...
 

Evidemment... et puis il y a aussi des pb de licences...
 

J'espère qu'il est assez intelligent pour comprendre tes arguments