Je suis entrain de convertir mes vieilles sources de g++296 pour un g++=20
un peu plus r=E9cent et, horreur, mes entr=E9es sorties binaires ne march=
ent=20
plus !
Exit le fp.read( (char *) ptr, sizeof( double ) * n ) ????
Quelle est l'=E9quivalent =E9l=E9gant sur une version de gcc 3.4.3 ? Ne m=
e=20
dites pas qu'il faille revenir au fread() du C ?? Dans ce cas, comment=20
passe-t-on d'un ifstream =E0 un FILE * sans avoir =E0 tout r=E9=E9crire ?=
??
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
A priori, jusqu'à ce qu'on change la norme ; c'est un comportement exigé par la norme. Et d'après ce que j'ai compris, personne dans le comité a envie de toucher aux flux.
Ceci dit... je me suis effectivement basé sur des requêtes système de plus bas niveau (open, read, write, close de Posix) chaque fois que j'ai eu besoin de faire des entrées/sorties binaires. Mais c'est en partie lié à mes applications -- il y a beaucoup de chose (comme des écritures synchronisées, ou la gestion des grands fichiers) qui ne sont pas supportés par les flux. Je crois qu'un flux du XDR, par exemple, ne serait pas mal, et qu'il pourrait bien se baser sur au moins les streambuf. (Dans ce cas-ci, il ne supportera pas imbue au niveau de flux, et il s'arrangera lui-même pour faire l'imbue du streambuf au bon moment.)
-- 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
Gregoire Mercier wrote:
Pour finir, j'ai eu plus ou moins confirmation sur
comp.lang.c++ que les flux d'entrées sorties étaient
essentiellement orientés vers le formattage du texte. Le
flux.imbue( std::locale::classic() ) resout effectivement les
choses mais jusqu'à quelle version ???
A priori, jusqu'à ce qu'on change la norme ; c'est un
comportement exigé par la norme. Et d'après ce que j'ai compris,
personne dans le comité a envie de toucher aux flux.
Ceci dit... je me suis effectivement basé sur des requêtes
système de plus bas niveau (open, read, write, close de Posix)
chaque fois que j'ai eu besoin de faire des entrées/sorties
binaires. Mais c'est en partie lié à mes applications -- il y a
beaucoup de chose (comme des écritures synchronisées, ou la
gestion des grands fichiers) qui ne sont pas supportés par les
flux. Je crois qu'un flux du XDR, par exemple, ne serait pas
mal, et qu'il pourrait bien se baser sur au moins les streambuf.
(Dans ce cas-ci, il ne supportera pas imbue au niveau de flux,
et il s'arrangera lui-même pour faire l'imbue du streambuf au
bon moment.)
--
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
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
A priori, jusqu'à ce qu'on change la norme ; c'est un comportement exigé par la norme. Et d'après ce que j'ai compris, personne dans le comité a envie de toucher aux flux.
Ceci dit... je me suis effectivement basé sur des requêtes système de plus bas niveau (open, read, write, close de Posix) chaque fois que j'ai eu besoin de faire des entrées/sorties binaires. Mais c'est en partie lié à mes applications -- il y a beaucoup de chose (comme des écritures synchronisées, ou la gestion des grands fichiers) qui ne sont pas supportés par les flux. Je crois qu'un flux du XDR, par exemple, ne serait pas mal, et qu'il pourrait bien se baser sur au moins les streambuf. (Dans ce cas-ci, il ne supportera pas imbue au niveau de flux, et il s'arrangera lui-même pour faire l'imbue du streambuf au bon moment.)
-- 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
kanze
Gregoire Mercier wrote:
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Qui comporte exactement les mêmes problèmes que iostream, au moins pour la plupart.
-- 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
Gregoire Mercier wrote:
Pour finir, j'ai eu plus ou moins confirmation sur
comp.lang.c++ que les flux d'entrées sorties étaient
essentiellement orientés vers le formattage du texte. Le
flux.imbue( std::locale::classic() ) resout effectivement les
choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl
;-) je suis repassé au bon view fwrite et fread...
Qui comporte exactement les mêmes problèmes que iostream, au
moins pour la plupart.
--
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
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Qui comporte exactement les mêmes problèmes que iostream, au moins pour la plupart.
-- 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
Jean-Marc Bourguet
Gregoire Mercier writes:
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple minimum compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne soit pas la transformation identite pour char->char me semble etre d'utiliser son propre char_trait car std::char_traits<char> a pour state_type std::mbstate_t (21.1.3.1) et std::codecvt<char, char, std::mbstate_t> est une conversion degeneree (22.2.1.5/3).
Un petit essai sur les machines que j'ai sous la main avec une locale UTF-8 disponible (linux, solaris) me confirme que - avec des streams sur char, j'ai la transformation identite - avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les
flux d'entrées sorties étaient essentiellement orientés vers le formattage
du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les
choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis
repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple minimum
compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne soit
pas la transformation identite pour char->char me semble etre
d'utiliser son propre char_trait car std::char_traits<char> a pour
state_type std::mbstate_t (21.1.3.1) et std::codecvt<char, char,
std::mbstate_t> est une conversion degeneree (22.2.1.5/3).
Un petit essai sur les machines que j'ai sous la main avec une locale
UTF-8 disponible (linux, solaris) me confirme que
- avec des streams sur char, j'ai la transformation identite
- avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple minimum compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne soit pas la transformation identite pour char->char me semble etre d'utiliser son propre char_trait car std::char_traits<char> a pour state_type std::mbstate_t (21.1.3.1) et std::codecvt<char, char, std::mbstate_t> est une conversion degeneree (22.2.1.5/3).
Un petit essai sur les machines que j'ai sous la main avec une locale UTF-8 disponible (linux, solaris) me confirme que - avec des streams sur char, j'ai la transformation identite - avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
Jean-Marc Bourguet wrote:
Gregoire Mercier writes:
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple minimum compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne soit pas la transformation identite pour char->char me semble etre d'utiliser son propre char_trait car std::char_traits<char> a pour state_type std::mbstate_t (21.1.3.1) et std::codecvt<char, char, std::mbstate_t> est une conversion degeneree (22.2.1.5/3).
Je crois que la norme est assez flou en ce qui concerne les codecvt que peuvent voir le flux. D'une part, elle dit clairement que «@codecvt< char, char, mbstate_t > » implemnts a degenerate conversion. » Mais telle que je le comprend (et ici, j'avoue que j'ai beaucoup de mal à comprendre quoique ce soit), cette exigence ne s'applique pas à codecvt_byname, ni à d'autres classes qui peuvent dérivées de codecvt. Et (encore, tel que je le comprend), la fonction use_facet< codecvt<...> > peut très bien renvoyer une référence à une de ces classes dérivées.
Mais je peux bien me tromper.
Il me semble, d'ailleurs, que Plauger a dit une fois que dans leurs codecvt, ils en avaient bien un qui convertissait de l'EBCDIC à l'ASCII.
Encore que, franchement, je doute très fort que ce soit le problème du posteur initial.
Un petit essai sur les machines que j'ai sous la main avec une locale UTF-8 disponible (linux, solaris) me confirme que - avec des streams sur char, j'ai la transformation identite - avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
Je crois que tu pourrais prèsque laisser tomber les trois derniers mots. Je me démande si personne a réelement compris la section (y compris l'auteur). Parmi ceux qui le connaissent le mieux, je ne vois pas de francophones. Si tu as une question concrète, il vaudrait mieux le poster dans un groupe anglophone (ou éventuellement germanophone -- avec Josuttis, KÜhl et Lang, les allemands semblent assez spécialisés dans la bibliothèque).
-- 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
Pour finir, j'ai eu plus ou moins confirmation sur
comp.lang.c++ que les flux d'entrées sorties étaient
essentiellement orientés vers le formattage du texte. Le
flux.imbue( std::locale::classic() ) resout effectivement
les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl
;-) je suis repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple
minimum compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne
soit pas la transformation identite pour char->char me semble
etre d'utiliser son propre char_trait car
std::char_traits<char> a pour state_type std::mbstate_t
(21.1.3.1) et std::codecvt<char, char, std::mbstate_t> est une
conversion degeneree (22.2.1.5/3).
Je crois que la norme est assez flou en ce qui concerne les
codecvt que peuvent voir le flux. D'une part, elle dit
clairement que «@codecvt< char, char, mbstate_t > » implemnts a
degenerate conversion. » Mais telle que je le comprend (et ici,
j'avoue que j'ai beaucoup de mal à comprendre quoique ce soit),
cette exigence ne s'applique pas à codecvt_byname, ni à d'autres
classes qui peuvent dérivées de codecvt. Et (encore, tel que je
le comprend), la fonction use_facet< codecvt<...> > peut très
bien renvoyer une référence à une de ces classes dérivées.
Mais je peux bien me tromper.
Il me semble, d'ailleurs, que Plauger a dit une fois que dans
leurs codecvt, ils en avaient bien un qui convertissait de
l'EBCDIC à l'ASCII.
Encore que, franchement, je doute très fort que ce soit le
problème du posteur initial.
Un petit essai sur les machines que j'ai sous la main avec une
locale UTF-8 disponible (linux, solaris) me confirme que
- avec des streams sur char, j'ai la transformation identite
- avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
Je crois que tu pourrais prèsque laisser tomber les trois
derniers mots. Je me démande si personne a réelement compris la
section (y compris l'auteur). Parmi ceux qui le connaissent le
mieux, je ne vois pas de francophones. Si tu as une question
concrète, il vaudrait mieux le poster dans un groupe anglophone
(ou éventuellement germanophone -- avec Josuttis, KÜhl et Lang,
les allemands semblent assez spécialisés dans la bibliothèque).
--
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
Pour finir, j'ai eu plus ou moins confirmation sur comp.lang.c++ que les flux d'entrées sorties étaient essentiellement orientés vers le formattage du texte. Le flux.imbue( std::locale::classic() ) resout effectivement les choses mais jusqu'à quelle version ???
Pour ma part (et pour une part importante de RegExp en perl ;-) je suis repassé au bon view fwrite et fread...
Reflechissant a nouveau, j'aimerais bien avoir un exemple minimum compilable qui reproduit le probleme.
Il me semble que la seule maniere pour avoir un codecvt qui ne soit pas la transformation identite pour char->char me semble etre d'utiliser son propre char_trait car std::char_traits<char> a pour state_type std::mbstate_t (21.1.3.1) et std::codecvt<char, char, std::mbstate_t> est une conversion degeneree (22.2.1.5/3).
Je crois que la norme est assez flou en ce qui concerne les codecvt que peuvent voir le flux. D'une part, elle dit clairement que «@codecvt< char, char, mbstate_t > » implemnts a degenerate conversion. » Mais telle que je le comprend (et ici, j'avoue que j'ai beaucoup de mal à comprendre quoique ce soit), cette exigence ne s'applique pas à codecvt_byname, ni à d'autres classes qui peuvent dérivées de codecvt. Et (encore, tel que je le comprend), la fonction use_facet< codecvt<...> > peut très bien renvoyer une référence à une de ces classes dérivées.
Mais je peux bien me tromper.
Il me semble, d'ailleurs, que Plauger a dit une fois que dans leurs codecvt, ils en avaient bien un qui convertissait de l'EBCDIC à l'ASCII.
Encore que, franchement, je doute très fort que ce soit le problème du posteur initial.
Un petit essai sur les machines que j'ai sous la main avec une locale UTF-8 disponible (linux, solaris) me confirme que - avec des streams sur char, j'ai la transformation identite - avec des streams sur wchar_t, j'ai de l'UTF-8 interprete correctement
Il y a-t'il un specialiste des locale qui nous lis?
Je crois que tu pourrais prèsque laisser tomber les trois derniers mots. Je me démande si personne a réelement compris la section (y compris l'auteur). Parmi ceux qui le connaissent le mieux, je ne vois pas de francophones. Si tu as une question concrète, il vaudrait mieux le poster dans un groupe anglophone (ou éventuellement germanophone -- avec Josuttis, KÜhl et Lang, les allemands semblent assez spécialisés dans la bibliothèque).
-- 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
