Version imprimable
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?
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.
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 ;)
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...
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)Citation:
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)
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?
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.Citation:
Envoyé par Médinoc
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).
Merci.