Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
fichiers binaires et char*
Bonjour,
J'ai remarqué qu'en C++ les fonctions d'accès aux fichiers typiquement utilisées pour les fichiers binaires (en gros, basic_istream::read et basic_ostream::write) forcent l'emploi du type caractère (char* ou wchar_t *), contrairement aux fonctions C.
Pourquoi? Est-ce pour forcer le programmeur à prendre en compte la sérialisation vers un buffer de char? Ou juste à cause d'un favoritisme pour les fichiers texte?
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Bonjour,
Je vais surement dire faux, mais ce ne serait pas parce que le char est l'unité la plus petite (point de vue taille) en mémoire. Du coup, si vous voulez traiter un fichier binaire, vous ne pouvez pas faire mieux (en dessous) du char.
Si je ne dis pas de bêtise, en C, c'est du void* ... et comme nous le savons tous (du moins en C++) le void* est très très moche.
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
Salut,
Je ne suis pas beaucoup plus sur que white_tentacle, mais je dirais volontiers que la notion importante n'est pas tant le caractère en tant que tel que le byte.
En effet, le résultat de sizeof correspond au nombre de byte nécessaires pour représenter le type en question (du moins pour les primitifs), et il semble donc "logique" de se baser sur la taille du byte pour déterminer toutes les autres
A méditer: La solution la plus simple est toujours la moins compliquée
Mais dans ce cas, pourquoi la version "wide" basée sur wchar_t?
Les deux méthodes "binaires" devraient au moins traiter des char (voire des unsigned char) plutôt qu'un des type clairement réservés au texte, et dont la taille n'est même pas garantie...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je ne sais pas si c'est la raison (elle est peut-etre perdue dans le design de la 1ere version de IOStream -- sachant que ce qui est normalise est le resultat de la 3ieme refonte), mais ca ne fait pas d'IO binaire, la locale va transcoder avec format externe. Pour faire des IO binaires, il faut utiliser la version char en etant sur d'avoir imbué une locale dont la facette codecvt ne fait rien dans in et out ("C" p.e.) et d'avoir ouvert le stream en binaire si besoin est pour que rien ne se passe (transformation CR-LF vers LF)Envoyé par Médinoc
A noter qu'il faut faire attention aux memes choses en C (et vu que la locale est globale, ca peut etre penible)
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Tu veux dire que les locales peuvent affecter plus que les conversions entre valeurs et texte (séparateur décimal, etc.), et qu'en plus ouvrir un fichier en mode binaire ne suffit pas à neutraliser ça?
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Oui. Il faut pour sur rester sur des IO en char et non en wchar_t, et en plus utiliser une locale qui ne fait pas de conversion. Ma recommandation est donc de s'assurer qu'on est bien dans la locale "C" (soit en ne changeant pas la locale globale -- mais certaines lib de GUI le font -- , soit en imbuant explicitement std::locale::classic() en plus d'ouvrir en binaire.
C'est à moitié un problème théorique. D'une part aucune des locales que j'ai regardé ne faisait quelque chose dans ce cas bien que ma lecture est que seule la locale "C" est garantie ne pas le faire. D'autre part, j'ai l'impression que c'est obligatoire si on veut faire une locale qui supporte l'EBCDIC dans un systeme POSIX (les machines sous AIX auxquelles j'avais acces quand j'ai regarde n'avaient pas de telles locales installees, mais elles n'avaient pas beaucoup de locales de disponibles) et j'ai déjà écrit des facettes codecvt qui faisaient effectivement quelque chose (utiliser de l'utf8 en interne pour char, mais ecrire les fichiers en latin-9; ce qui est genant c'est devoir utiliser mbstate_t; si j'ai bonne mémoire j'avais fait quelque chose de non portable pour ça).
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Merci.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager