Discussion :

[shenron666]

Bonjour,

Est-ce que quelqu'un pourrait me dire pourquoi ce code ne fonctionne pas ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
std::ifstream ficInTest("data.dat", std::ios_base::in | std::ios_base::binary);
 
unsigned long nTest;
ficInTest >> nTest;

Le fichier est bien ouvert mais la donnée n'est pas lue
avec la méthode read ça fonctionne

[Arzar]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
std::ifstream ficInTest("data.dat", std::ios_base::in | std::ios_base::binary);

Il me semble que l'opérateur >> est réservé pour la lecture de texte formaté. Pour lire du texte brut, voire du binaire il faut utiliser read.

[shenron666]

C'est bien ce que je pensais, bien que je trouve cela étrange de ne pas avoir implémenté ces opérateurs pour du binaire.

Merci pour ta réponse

[koala01]

Salut, désolé de faire remonter le poste, mais

C'est bien ce que je pensais, bien que je trouve cela étrange de ne pas avoir implémenté ces opérateurs pour du binaire.

Non, c'est tout à fait normal: il est strictement impossible de formater une succession de 1 et de 0 sur laquelle nous n'avons strictement aucune emprise

Finalement, lorsque tu ouvre ton fichier en mode "binaire" (bien que le terme soit particulièrement mal choisi ), il n'y a strictement rien qui t'empêche de lire les bytes d'un entier ou d'un réel "caractères par caractères" (dont certains auront des valeurs non graphiques) ou l'inverse (de lire quatre caractères d'un coup dans un entier, par exemple)...

Evidemment, il faut comprendre le "rien ne t'empêche" dans le sens où la tu n'a aucun moyen de faire la différence dans ton fichier entre ce qui est un byte destiné à un caractère et ce qui en est un destiné à un entier... Il est clair que, pour l'utilisation de la donnée lue, il est largement préférable de la lire dans le type adéquat

[shenron666]

rien n'empêcherait non plus d'avoir un opérateur pour simplement lire/écrire les différents types binaires en série (sbyte, ubyte, sshort, ushort, slong, ulong, ect...) sans formatage, vu que le fichier est ouvert en mode binaire

pour lire 10 <T> on est "obligé" de faire 10 appels de stream.read((cast T)&var, sizeof(T))
je trouve pas ça très propre ni très c++

je trouve dommage que ça n'ai pas été implémenté, ou alors ça l'est et j'aimerai bien trouver
peut-etre dans boost ?

j'ai pas trop eu le temps de chercher, je suis occupé avec boost::iostreams et les archives zip
si quelqu'un a une proposition je suis preneur, sinon je chercherai dès que j'ai un moment

[koala01]

Mais le terme important dans "opérateur d'entrée (de sortie) formatée" est, justement... formaté

Or le formatage ne trouve sa raison d'être que lorsque tu travailles au minimum avec "autre chose qu'une succession sans queue ni tête de 1 et de 0"...

Or, comme je l'ai mal exprimé plus haut, tu ne peux pas considérer les informations qui se trouvent à l'intérieur d'un fichier binaire autrement que comme une succession de 1 et de 0...

En effet, imagine un instant une structure "toute simple" proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct S
{
    int i;
    char c;
    double f;
};

qui, chez moi, correspond à une structure de 16 bytes, et qui, du fait des contraintes d'alignement mémoire se présente en mémoire sous la forme de

• 4 bytes pour i
• 1 byte pour c
• 3 bytes "inutilisés" (d'alignement)
• 8 bytes pour d

Dans un fichier binaire, tu peux, au choix te retrouver soit avec N*16 bytes (d'avoir écrit les trois bits inutilisés), soit avec seulement N*13 bytes.

Tant que tu accédera au données de manière séquentielle, et pour autant que tu suive la même politique lors de la lecture que celle utilisée lors de l'écriture (enlever ou non les trois bits inutilisés), tu n'auras aucun problème: tu lira tes données une à une

Mais si tu décide d'aller à la Xième donnée, et que, marqué pas de bol, tu te trompes dans ta formule pour calculer la position dans le fichier sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

file.seekg(pos*16+1,ios_base::beg); //pas de bol, c'était pos*16 :P

Lorsque tu va essayer de lire les données, tu va lire ton entier, ton caractère, passer trois bytes inutilisés et terminer par la lecture de ton double "comme une lettre à la poste", et il n'y aura strictement rien qui pourra te permettre de remarquer que la lecture est décalée d'un byte:

• Pour ton entier, tu lira les trois derniers bytes de l'entier et le byte normalement dévolu au caractère
• pour le caractère, tu lira en réalité le premier byte inutilisé
• pour le double, tu lira les 7 derniers bytes dévolu au double et le premier byte de l'entier de la structure suivante

Et la lecture s'effectuera de manière tout à fait correcte...

Mais tu obtiendra des données pour le moins incohérentes

Par contre, si tu envisage ton fichier comme un fichier texte, tu n'a pas de problème: ce que tu lis sera d'office un caractère...

Si l'on parle d'entrée formatée pour un fichier texte, c'est entre autre du fait qu'il existe un format clairement défini pour chaque type que l'on peut rencontrer:

• un entier est composé
  
  • d'un signe négatif éventuel
  • d'une succession de chiffres (caractères dont la représentation s'étend entre '0' et '9')
• un double sera composé (s'il n'est pas écrit en notation scientifique)
  
  • d'un signe négatif éventuel
  • d'un certain nombre de chiffres
  • d'une virgule éventuelle
  • d'un certain nombre de chiffres après la virgule
• La plupart des données significatives seront représentées sous la forme de caractères "affichables" (dont la valeur est supérieure ou égale à 32 si tu suis la table ASCII)
• que les données significatives seront séparées, outre utilisation d'un symbole particulier pour respecter un format précis (CSV) par un caractère qui peut être considéré comme un espace (espace, tabulation, retour à la ligne...)