Discussion :

[camboui]

Je cherche des exemples ou du code pour comprendre l'usage de ce trio de fonctions de l'API:
CreateFile()
CreateFileMapping()
MapViewOfFile()

J'imagine par exemple un fichier de plusieurs dizaines de gigas à lire par paquets de 1Mb. Il me parait bien plus simple de faire quelque chose comme ceci:
f=CreateFile()
ptr=GlobalAlloc(1Mb)
ReadFile(f,ptr,1Mb)

Quel est l'avantage du couple CreateFileMapping/MapViewOfFile lorsqu'on ne cherche qu'à lire ou écrire dans un fichier ? (pas de partage mémoire entre process)
Merci.

[Médinoc]

J'ai entendu mentionner comme un avantage le fait de pouvoir manipuler un fichier binaire de longueur assez arbitraire sans prendre autant de mémoire. Par exemple, un fichier de plusieurs centaines de Mo auquel on accèderait bloc par bloc dans un ordre bizarroïde (genre, un téléchargement en P2P).

En clair, mapper le fichier en mémoire éviterait de faire des fseek() ou SetFilePointer() dans tous les sens, et permettrait de le faire depuis plusieurs threads (il n'y a qu'un seul "file pointer", alors qu'il peut y avoir plusieurs vues).

[Mac LAK]

Pour l'exemple de code, tu en as pas mal sur MSDN.

L'intérêt direct d'un FileMapping, c'est le côté multitâche : chaque processus / thread peut créer "le sien" sans ruiner les autres, et le contenu du fichier est alors accessible comme un simple tableau depuis le code. Autre avantage, c'est extrêmement bien mis en cache, bien plus efficacement que tu ne pourras le faire avec des I/O classiques, et c'est également bien plus rapide (pas mal de copies en moins, ça compte sur des gros fichiers).

Deuxième point d'intérêt, c'est la création de mémoire partagée : c'est d'ailleurs ainsi que l'on procède de façon normale sous Windows pour créer une zone de mémoire partagée entre processus.

[camboui]

Sur msdn je n'ai trouvé qu'un seul exemple, le plus simple, celui de mémoire partagée. Mais beaucoup de blabla qui incite à la plus grande prudence tant la gestion d'erreurs semble complexe (map sur fichier compressé dans une partition ntfs par exemple).

Ce qui m'intéresse c'est un cas pratique, du "vécu", d'un (très) gros fichier qui tirerait parti de ces fonctions. Rien qu'en lecture se serait déjà pas mal.

En fait je ne comprend pas comment on pourrait accèder à un fichier de 8Gb avec un mapview de 100Mb (et encore, il semble qu'on ne puisse pas choisir la taile du mapview ?) sans s'amuser à refaire des mapview, morceau par morceau, pour parcourir tout le fichier.
En clair, si on a un mapview qui commence à l'offest X sur un fichier donné, comment faire pour le déplacer à l'offset X+N, puis X+2N, X+3N, etc ?

[Mac LAK]

Sur msdn je n'ai trouvé qu'un seul exemple, le plus simple, celui de mémoire partagée. Mais beaucoup de blabla qui incite à la plus grande prudence tant la gestion d'erreurs semble complexe (map sur fichier compressé dans une partition ntfs par exemple).

Tu as regardé cette page ?

En fait je ne comprend pas comment on pourrait accèder à un fichier de 8Gb avec un mapview de 100Mb (et encore, il semble qu'on ne puisse pas choisir la taile du mapview ?) sans s'amuser à refaire des mapview, morceau par morceau, pour parcourir tout le fichier.

C'est pourtant ça qui va remplacer ReadFile, en fait. La seule différence, c'est que la granularité (=la taille de la fenêtre) n'est pas 100% libre, il faut faire avec les contraintes du système.

En clair, si on a un mapview qui commence à l'offest X sur un fichier donné, comment faire pour le déplacer à l'offset X+N, puis X+2N, X+3N, etc ?

Via MapViewOfFile, tout simplement. Le UnmapViewOfFile va libérer le mapping courant : cela ne fait RIEN de concret si le fichier est en lecture seule, et cela va commiter les changements si tu es en écriture. Pour le reste, ce sont les paramètres dwFileOffsetHigh, dwFileOffsetLow et dwNumberOfBytesToMap de MapViewOfFile qui indiquent quelle zone du fichier doit être mappée.