Connaissez vous un site qui proposent des exemples de lecture et écriture
dans un fichier
- texte
- typé.
Autrement, j'ai récupéré du code et j'ai une erreur sur la première ligne
quand je compile.
#include fstream.h
C:\Dev-Cpp\include\c++\3.4.2\backward\fstream.h:31, from
D:\EcritureFichier.cpp
Excusez moi pour cette question un peu simpliste, mais je débute en C++.
Si la question est trop simpliste, indiquez moi un forum où je pourrai la
poser.
Bref, tu prends un POD à taille fixe et sans pointeur au milieu (les chaines sont dans des tableaux statiques dimensionnés à tout jamais), et tu conclues tes écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un format de fichier, puis on crée un POD qui, avec le compilateur qu'on utilise, permet une lecture "directe" du disque vers la RAM.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo sous Windows, je peux copier directement 40 octets du fichier vers ce POD, et ça marche.
Si je veux faire du code portable, en revanche, je vais plutôt lire un entier non signé de 32 bits, puis un entier signé de 32 bits, etc., le tout en petit-boutiste.
On 14 Feb 2006 00:27:21 -0800, "kanze" <kanze@gabi-soft.fr>:
Bref, tu prends un POD à taille fixe et sans pointeur au
milieu (les chaines sont dans des tableaux statiques
dimensionnés à tout jamais), et tu conclues tes
écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à
jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un format de
fichier, puis on crée un POD qui, avec le compilateur qu'on utilise,
permet une lecture "directe" du disque vers la RAM.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo sous
Windows, je peux copier directement 40 octets du fichier vers ce POD,
et ça marche.
Si je veux faire du code portable, en revanche, je vais plutôt lire un
entier non signé de 32 bits, puis un entier signé de 32 bits, etc., le
tout en petit-boutiste.
Bref, tu prends un POD à taille fixe et sans pointeur au milieu (les chaines sont dans des tableaux statiques dimensionnés à tout jamais), et tu conclues tes écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un format de fichier, puis on crée un POD qui, avec le compilateur qu'on utilise, permet une lecture "directe" du disque vers la RAM.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo sous Windows, je peux copier directement 40 octets du fichier vers ce POD, et ça marche.
Si je veux faire du code portable, en revanche, je vais plutôt lire un entier non signé de 32 bits, puis un entier signé de 32 bits, etc., le tout en petit-boutiste.
kanze
Fabien LE LEZ wrote:
On 14 Feb 2006 00:27:21 -0800, "kanze" :
Bref, tu prends un POD à taille fixe et sans pointeur au milieu (les chaines sont dans des tableaux statiques dimensionnés à tout jamais), et tu conclues tes écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un format de fichier, puis on crée un POD qui, avec le compilateur qu'on utilise, permet une lecture "directe" du disque vers la RAM.
En supposant qu'on peut. Si tu définis un format « Internet », avec des entiers de quatres octets, octet de poids fort d'abord, comment définir un POD qui marche avec VC++ sous Windows sur un PC.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo sous Windows, je peux copier directement 40 octets du fichier vers ce POD, et ça marche.
Sous Windows. Avec la version actuelle du compilateur. En supposant que les DWORD, LONG, etc. ont la même représentation en externe qu'en interne.
Note bien que c'est sous MS-DOS que la représentation interne des long a changé d'une version du compilateur à l'autre. Sous Solaris, il dépend des options de la compilation.
Enfin, tu ne fais que différer le problème. (Mais au moins, le format est connu et documenté.)
Si je veux faire du code portable, en revanche, je vais plutôt lire un entier non signé de 32 bits, puis un entier signé de 32 bits, etc., le tout en petit-boutiste.
En somme, tu comptes sur le fait que la représentation dans le format qui t'intéresse est la même que la représentation interne. Et que cette représentation interne ne va pas réelement changer -- que si long passe à 64 bits, il te restera un autre type entier avec exactement la même représentation qu'a long aujourd'hui.
J'avoue que je n'ai pas cette liberté. Les Linux sur PC et les Solaris sur Sparc monte les mêmes fichiers disque -- il faut que ce qu'il y a sur le disque soit lisible aux deux. (Sur d'autres sous-reseaux, il y a aussi des PC sous Windows. Ce qui ne va pas sans poser de problèmes pour les fins de lignes, même dans les fichiers texte.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 14 Feb 2006 00:27:21 -0800, "kanze" <kanze@gabi-soft.fr>:
Bref, tu prends un POD à taille fixe et sans pointeur au
milieu (les chaines sont dans des tableaux statiques
dimensionnés à tout jamais), et tu conclues tes
écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à
jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un
format de fichier, puis on crée un POD qui, avec le
compilateur qu'on utilise, permet une lecture "directe" du
disque vers la RAM.
En supposant qu'on peut. Si tu définis un format « Internet »,
avec des entiers de quatres octets, octet de poids fort d'abord,
comment définir un POD qui marche avec VC++ sous Windows sur un
PC.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo
sous Windows, je peux copier directement 40 octets du fichier
vers ce POD, et ça marche.
Sous Windows. Avec la version actuelle du compilateur. En
supposant que les DWORD, LONG, etc. ont la même représentation
en externe qu'en interne.
Note bien que c'est sous MS-DOS que la représentation interne
des long a changé d'une version du compilateur à l'autre. Sous
Solaris, il dépend des options de la compilation.
Enfin, tu ne fais que différer le problème. (Mais au moins, le
format est connu et documenté.)
Si je veux faire du code portable, en revanche, je vais plutôt
lire un entier non signé de 32 bits, puis un entier signé de
32 bits, etc., le tout en petit-boutiste.
En somme, tu comptes sur le fait que la représentation dans le
format qui t'intéresse est la même que la représentation
interne. Et que cette représentation interne ne va pas réelement
changer -- que si long passe à 64 bits, il te restera un autre
type entier avec exactement la même représentation qu'a long
aujourd'hui.
J'avoue que je n'ai pas cette liberté. Les Linux sur PC et les
Solaris sur Sparc monte les mêmes fichiers disque -- il faut
que ce qu'il y a sur le disque soit lisible aux deux. (Sur
d'autres sous-reseaux, il y a aussi des PC sous Windows. Ce qui
ne va pas sans poser de problèmes pour les fins de lignes, même
dans les fichiers texte.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bref, tu prends un POD à taille fixe et sans pointeur au milieu (les chaines sont dans des tableaux statiques dimensionnés à tout jamais), et tu conclues tes écritures/lectures à coup de std::write + reinterpret_cast.
Et tu n'est plus capable de lire les données après une mise à jour du compilateur.
Généralement, on fait l'inverse : on définit précisément un format de fichier, puis on crée un POD qui, avec le compilateur qu'on utilise, permet une lecture "directe" du disque vers la RAM.
En supposant qu'on peut. Si tu définis un format « Internet », avec des entiers de quatres octets, octet de poids fort d'abord, comment définir un POD qui marche avec VC++ sous Windows sur un PC.
Par exemple, on trouve ceci dans <windows.h> :
typedef struct tagBITMAPINFOHEADER{ // bmih DWORD biSize; LONG biWidth; LONG biHeight; WORD biPlanes; WORD biBitCount DWORD biCompression; DWORD biSizeImage; LONG biXPelsPerMeter; LONG biYPelsPerMeter; DWORD biClrUsed; DWORD biClrImportant; } BITMAPINFOHEADER;
Si je suis au bon endroit dans un fichier, avec mon compilo sous Windows, je peux copier directement 40 octets du fichier vers ce POD, et ça marche.
Sous Windows. Avec la version actuelle du compilateur. En supposant que les DWORD, LONG, etc. ont la même représentation en externe qu'en interne.
Note bien que c'est sous MS-DOS que la représentation interne des long a changé d'une version du compilateur à l'autre. Sous Solaris, il dépend des options de la compilation.
Enfin, tu ne fais que différer le problème. (Mais au moins, le format est connu et documenté.)
Si je veux faire du code portable, en revanche, je vais plutôt lire un entier non signé de 32 bits, puis un entier signé de 32 bits, etc., le tout en petit-boutiste.
En somme, tu comptes sur le fait que la représentation dans le format qui t'intéresse est la même que la représentation interne. Et que cette représentation interne ne va pas réelement changer -- que si long passe à 64 bits, il te restera un autre type entier avec exactement la même représentation qu'a long aujourd'hui.
J'avoue que je n'ai pas cette liberté. Les Linux sur PC et les Solaris sur Sparc monte les mêmes fichiers disque -- il faut que ce qu'il y a sur le disque soit lisible aux deux. (Sur d'autres sous-reseaux, il y a aussi des PC sous Windows. Ce qui ne va pas sans poser de problèmes pour les fins de lignes, même dans les fichiers texte.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 16 Feb 2006 00:20:10 -0800, "kanze" :
En somme, tu comptes sur le fait que la représentation dans le format qui t'intéresse est la même que la représentation interne.
Et surtout, je compte sur le fait que Microsoft a encouragé cette façon de faire, et qu'elle est donc raisonnablement sûre tant qu'on fait du code spécifique-Windows.
On 16 Feb 2006 00:20:10 -0800, "kanze" <kanze@gabi-soft.fr>:
En somme, tu comptes sur le fait que la représentation dans le
format qui t'intéresse est la même que la représentation
interne.
Et surtout, je compte sur le fait que Microsoft a encouragé cette
façon de faire, et qu'elle est donc raisonnablement sûre tant qu'on
fait du code spécifique-Windows.
En somme, tu comptes sur le fait que la représentation dans le format qui t'intéresse est la même que la représentation interne.
Et surtout, je compte sur le fait que Microsoft a encouragé cette façon de faire, et qu'elle est donc raisonnablement sûre tant qu'on fait du code spécifique-Windows.
