Bonjour,
j'ai un prb de compréhension des relation et équivalence entre des codes
utilisant des fstream et ceux utilisant des fopen ....
en bref, j'ai une routine qui parse un fichier via un code du type :
fstream fs;
fs.open(nomfichier, ios_base::in)
fs.seekg(i);//i un offset qui est donnée par la dll qui a écrit le fichier
puis une boucle jusqu'à la fin avec des getline...
L'existence de ce fichier est temporaire et sera + tard remplacer par
une mémoire partagée entre la DLL et mon application. Donc pour préparer
le terrain, je veux parser mon ficher après l'avoir intégralement chargé
en memoire via :
FILE* pf = fopen(monfichier, "rt")
struct _stat file_info = _stat(monfichier);
allocation(Buffer, file_info.size);
fread(Buffer, 1, file_info.size, pf);
puis parser Buffer en ce décalant de l'offset...
cependant l'offset i ne semble pas avoir de sens, ou en tout pas le sens
d'un offset en octet à partir du debut de fichier ... Je suspose que si
le fichier est ecris via un fstream, puis lu via un fstream tout est
cohérent, mais dans le cas contraire, comme assurer la conversion de
l'offset pour un fs.seekg en un offset octet pour positionner le
pointeur de debut de parsing dans mon buffer ?
Auriez vous des infos sur ce sujet.
merci d'avance
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
kanze
Bernie wrote:
j'ai un prb de compréhension des relation et équivalence entre des codes utilisant des fstream et ceux utilisant des fopen ....
Il doit y avoir équivalence exacte, parce que tous les comportements des fstream sont définis en termes des FILE*.
en bref, j'ai une routine qui parse un fichier via un code du type : fstream fs; fs.open(nomfichier, ios_base::in) fs.seekg(i);//i un offset qui est donnée par la dll qui a écrit le fi chier puis une boucle jusqu'à la fin avec des getline...
Attention, déjà : un seekg à une position arbitraire n'est garanti que si la position provient du résultat d'un tellg précédant. C'est assez limité, ce qu'on peut faire avec les accès aléatoire sur les flux (que ce soit les flux de C++ ou les flux de C, d'ailleurs).
L'existence de ce fichier est temporaire et sera + tard remplacer par une mémoire partagée entre la DLL et mon application. Donc pour préparer le terrain, je veux parser mon ficher après l'avoir intégralement chargé en memoire via :
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
struct _stat file_info = _stat(monfichier); allocation(Buffer, file_info.size); fread(Buffer, 1, file_info.size, pf); puis parser Buffer en ce décalant de l'offset...
cependant l'offset i ne semble pas avoir de sens, ou en tout pas le sens d'un offset en octet à partir du debut de fichier ...
Puisque tu parles des DLL, et _stat, je supposerais une plateforme Windows. Alors : d'où vient réelement cette valeur i ? Parce que de toute façon, si le fichier n'est pas ouvert en binaire, la notion de « offset en octet » n'a pas de sens. Si le DLL a fait un tellg lors qu'il a écrit, et que c'est cette valeur-là qu'elle indique, il y a des chances que ça marche de ton côté, toujours à condition d'ouvrir le fichier avec la même mode.
Dans la mesure où tu veux te rapprocher de mmap autant que possible, je conseillerai d'ouvrir des deux côtés en mode binaire. Comme ça, tu as une image. Et si tu n'as pas d'influence sur la DLL, et elle écrit en texte, il est peut probable que tu puisses réelement utiliser mmap ; au moins, tu n'y verras pas les mêmes octets que l'autre a écrit.
Je suspose que si le fichier est ecris via un fstream, puis lu via un fstream tout est cohérent, mais dans le cas contraire, comme assurer la conversion de l'offset pour un fs.seekg en un offset octet pour positionner le pointeur de debut de parsing dans mon buffer ?
Ce qu'on peut faire avec les offsets est assez limité, au moins en ce qui concerne la norme. Mais typiquement, si tu travailles en mode binaire des deux côtés, tu as des chances de pouvoir t'en sortir.
Ce qui vaut aussi bien pour les flux iostream que pour les flux FILE*.
-- 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
Bernie wrote:
j'ai un prb de compréhension des relation et équivalence entre
des codes utilisant des fstream et ceux utilisant des fopen
....
Il doit y avoir équivalence exacte, parce que tous les
comportements des fstream sont définis en termes des FILE*.
en bref, j'ai une routine qui parse un fichier via un code du type :
fstream fs;
fs.open(nomfichier, ios_base::in)
fs.seekg(i);//i un offset qui est donnée par la dll qui a écrit le fi chier
puis une boucle jusqu'à la fin avec des getline...
Attention, déjà : un seekg à une position arbitraire n'est
garanti que si la position provient du résultat d'un tellg
précédant. C'est assez limité, ce qu'on peut faire avec les
accès aléatoire sur les flux (que ce soit les flux de C++ ou les
flux de C, d'ailleurs).
L'existence de ce fichier est temporaire et sera + tard
remplacer par une mémoire partagée entre la DLL et mon
application. Donc pour préparer le terrain, je veux parser mon
ficher après l'avoir intégralement chargé en memoire via :
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C,
et je ne l'ai jamais vu.
struct _stat file_info = _stat(monfichier);
allocation(Buffer, file_info.size);
fread(Buffer, 1, file_info.size, pf);
puis parser Buffer en ce décalant de l'offset...
cependant l'offset i ne semble pas avoir de sens, ou en tout
pas le sens d'un offset en octet à partir du debut de fichier
...
Puisque tu parles des DLL, et _stat, je supposerais une
plateforme Windows. Alors : d'où vient réelement cette valeur
i ? Parce que de toute façon, si le fichier n'est pas ouvert en
binaire, la notion de « offset en octet » n'a pas de sens.
Si le DLL a fait un tellg lors qu'il a écrit, et que c'est cette
valeur-là qu'elle indique, il y a des chances que ça marche de
ton côté, toujours à condition d'ouvrir le fichier avec la même
mode.
Dans la mesure où tu veux te rapprocher de mmap autant que
possible, je conseillerai d'ouvrir des deux côtés en mode
binaire. Comme ça, tu as une image. Et si tu n'as pas
d'influence sur la DLL, et elle écrit en texte, il est peut
probable que tu puisses réelement utiliser mmap ; au moins, tu
n'y verras pas les mêmes octets que l'autre a écrit.
Je suspose que si le fichier est ecris via un fstream, puis lu
via un fstream tout est cohérent, mais dans le cas contraire,
comme assurer la conversion de l'offset pour un fs.seekg en un
offset octet pour positionner le pointeur de debut de parsing
dans mon buffer ?
Ce qu'on peut faire avec les offsets est assez limité, au moins
en ce qui concerne la norme. Mais typiquement, si tu travailles
en mode binaire des deux côtés, tu as des chances de pouvoir
t'en sortir.
Ce qui vaut aussi bien pour les flux iostream que pour les flux
FILE*.
--
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
j'ai un prb de compréhension des relation et équivalence entre des codes utilisant des fstream et ceux utilisant des fopen ....
Il doit y avoir équivalence exacte, parce que tous les comportements des fstream sont définis en termes des FILE*.
en bref, j'ai une routine qui parse un fichier via un code du type : fstream fs; fs.open(nomfichier, ios_base::in) fs.seekg(i);//i un offset qui est donnée par la dll qui a écrit le fi chier puis une boucle jusqu'à la fin avec des getline...
Attention, déjà : un seekg à une position arbitraire n'est garanti que si la position provient du résultat d'un tellg précédant. C'est assez limité, ce qu'on peut faire avec les accès aléatoire sur les flux (que ce soit les flux de C++ ou les flux de C, d'ailleurs).
L'existence de ce fichier est temporaire et sera + tard remplacer par une mémoire partagée entre la DLL et mon application. Donc pour préparer le terrain, je veux parser mon ficher après l'avoir intégralement chargé en memoire via :
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
struct _stat file_info = _stat(monfichier); allocation(Buffer, file_info.size); fread(Buffer, 1, file_info.size, pf); puis parser Buffer en ce décalant de l'offset...
cependant l'offset i ne semble pas avoir de sens, ou en tout pas le sens d'un offset en octet à partir du debut de fichier ...
Puisque tu parles des DLL, et _stat, je supposerais une plateforme Windows. Alors : d'où vient réelement cette valeur i ? Parce que de toute façon, si le fichier n'est pas ouvert en binaire, la notion de « offset en octet » n'a pas de sens. Si le DLL a fait un tellg lors qu'il a écrit, et que c'est cette valeur-là qu'elle indique, il y a des chances que ça marche de ton côté, toujours à condition d'ouvrir le fichier avec la même mode.
Dans la mesure où tu veux te rapprocher de mmap autant que possible, je conseillerai d'ouvrir des deux côtés en mode binaire. Comme ça, tu as une image. Et si tu n'as pas d'influence sur la DLL, et elle écrit en texte, il est peut probable que tu puisses réelement utiliser mmap ; au moins, tu n'y verras pas les mêmes octets que l'autre a écrit.
Je suspose que si le fichier est ecris via un fstream, puis lu via un fstream tout est cohérent, mais dans le cas contraire, comme assurer la conversion de l'offset pour un fs.seekg en un offset octet pour positionner le pointeur de debut de parsing dans mon buffer ?
Ce qu'on peut faire avec les offsets est assez limité, au moins en ce qui concerne la norme. Mais typiquement, si tu travailles en mode binaire des deux côtés, tu as des chances de pouvoir t'en sortir.
Ce qui vaut aussi bien pour les flux iostream que pour les flux FILE*.
-- 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
Alexandre
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
j'avais vu ça sur les compilos borland (et je suppose, la plupart des compilos pour DOS/Win) : mode texte (à opposer à 'b' pour mode binaire), ce qui ne change que les ajout de r après les n (ou l'inverse, d'ailleurs). ça ne doit pas exister sous unix (donc pas dans la norme je suppose)
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C,
et je ne l'ai jamais vu.
j'avais vu ça sur les compilos borland (et je suppose, la plupart des
compilos pour DOS/Win) : mode texte (à opposer à 'b' pour mode binaire), ce
qui ne change que les ajout de r après les n (ou l'inverse, d'ailleurs).
ça ne doit pas exister sous unix (donc pas dans la norme je suppose)
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
j'avais vu ça sur les compilos borland (et je suppose, la plupart des compilos pour DOS/Win) : mode texte (à opposer à 'b' pour mode binaire), ce qui ne change que les ajout de r après les n (ou l'inverse, d'ailleurs). ça ne doit pas exister sous unix (donc pas dans la norme je suppose)
Fabien LE LEZ
On 24 Jun 2005 09:13:05 -0700, :
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
Elle indique que le fichier est ouvert en mode texte. Et comme c'est de toutes façons le mode par défaut, c'est une no-op.
On 24 Jun 2005 09:13:05 -0700, kanze@gabi-soft.fr:
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C,
et je ne l'ai jamais vu.
Elle indique que le fichier est ouvert en mode texte. Et comme c'est
de toutes façons le mode par défaut, c'est une no-op.
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
Elle indique que le fichier est ouvert en mode texte. Et comme c'est de toutes façons le mode par défaut, c'est une no-op.
Horst Kraemer
wrote:
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
C'est une extension (très inutile ;-) inventée probablement par Borland ou Microsoft. Sous Turbo C et successeurs on avait l'option de définir (par une variable publique de la bibliothèque) "binaire" comme défaut. Alors il fallait "rt" pour indiquer qu'on veut ouvrir le fichier en mode texte.
-- Horst
kanze@gabi-soft.fr wrote:
FILE* pf = fopen(monfichier, "rt")
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C,
et je ne l'ai jamais vu.
C'est une extension (très inutile ;-) inventée probablement par
Borland ou Microsoft. Sous Turbo C et successeurs on avait l'option de
définir (par une variable publique de la bibliothèque) "binaire" comme
défaut. Alors il fallait "rt" pour indiquer qu'on veut ouvrir le
fichier en mode texte.
C'est quoi, cette option 't'. Elle n'existe pas dans la norme C, et je ne l'ai jamais vu.
C'est une extension (très inutile ;-) inventée probablement par Borland ou Microsoft. Sous Turbo C et successeurs on avait l'option de définir (par une variable publique de la bibliothèque) "binaire" comme défaut. Alors il fallait "rt" pour indiquer qu'on veut ouvrir le fichier en mode texte.
