Utilisation fonction "read"

Bonjour à tous,

Après recherches je ne trouves toujours pas de réponse à mes interrogations. Je me tourne donc vers vous.
J'ai des doutes sur la fonction qui extrait un bloc d' au plus n octets d'un flux et les place à l'adresse ch c'est à dire la fonction :

istream & read(char *ch, int n);


J'illustrerai mon problème par un exemple simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

// Je déclare un flux d'entré que j'associe à mon fichier physique "toto.xyz" (fichier binaire) ifstream flux; flux.open("toto.xyz", ios::in|ios::binary);   // Déclaration d'un buffer de 2 octets char* buff = new char[2];   // Lecture de 2 octets flux.read(buff, 2);   // Convertir le contenu de mon buffer int conv = *buff;

---

Je voudrais faire ça ! Or je ne suis pas convaincu de la méthode pour lire le contenu de mon buffer, ainsi que pour celle concernant la conversion de char en int.

Merci pour vos corrections ! :aie:

La seul broutille est le fait que le char est signé.
Lorsqu'on prend 2 octets dans un fichier je ne pense pas que ce soit important, puisque que cela doit être un "nombre magique" :mrgreen:

Sinon tu as les solutions de bourrins :mouarf: :mouarf:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

char buf[2] = {2, 7};   unsigned short temp_1 = ((buf[0] & 1) | (buf[0] & 2) | (buf[0] & 4) | (buf[0] & 8) | (buf[0] & 16) | (buf[0] & 32) | (buf[0] & 64) /*| (buf[0] & 128)*/); unsigned short temp_2 = ((buf[1] & 1) | (buf[1] & 2) | (buf[1] & 4) | (buf[1] & 8) | (buf[1] & 16) | (buf[1] & 32) | (buf[1] & 64) /*| (buf[0] & 128)*/);   unsigned int result_1 = (temp_2 + (temp_1 << 8));   // or unsigned short temp_3 = buf[0]; unsigned short temp_4 = buf[1];   unsigned int result_2 = (temp_4 + (temp_3 << 8));   // or unsigned int result_3 = (((unsigned short) buf[1]) + (((unsigned short) buf[0]) << 8));   printf("%d %d %d\n", result_1, result_2, result_3);

---

Hello,

Ou avec un reinterpret_cast (éventuel problème d'endianess à la clef).

Code:

---

1 2	char buffer[2]; int data = int(*reinterpret_cast<int16_t*>(buffer));

---

Mais pourquoi lire des char ?

Code:

---

1 2 3

int16_t buffer; flux >> buffer; int data = buffer;

---

J'avais à l'idée de m'y prendre aussi comme ça, à la bourin :).

J'ai besoin de faire de tests d'intégrité de fichier, il m'est donc indispensable de connaitre la valeur de lu et rangé dans le buffer. J'avais aussi vu les conversions explicites ;)

J'ai vais essayer vos méthodes, merci de vos réponse. Je reviendrai surement vers vous pour informer.

A plus !

Bonsoir,

après essai la seconde solution fonctionne très bien.
Merci pour votre aide.

A bientôt sur Developpez.

PS: si le fichier n'est pas produit sur la même machine, le problème d'endianness se pose à mon avis. En effet, le code de l'opérateur >> n'a aucun moyen de savoir que les octets ne sont pas dans l'ordre qu'il attend.
Le seul moyen d'être sûr dans ce cas est d'utiliser à l'écriture les fonction type htons()/htonl(), et à la lecture les fonction type ntohl(), ntohl() de manière à maitriser le problème du byte ordering.

L'opérateur >> se moque bien de l'endianness, vu qu'il lit le nombre sous forme de texte.

Citation:

---

Envoyé par Médinoc

L'opérateur >> se moque bien de l'endianness, vu qu'il lit le nombre sous forme de texte.

---

:aie:

my mistake...mais dans ce cas on ne peut pas lire le même fichier qu'un truc a base de

Citation:

---

// Je déclare un flux d'entré que j'associe à mon fichier physique "toto.xyz" (fichier binaire)

---

Le reinterpret_cast est parait-il à éviter le plus possible.
Voici donc la méthode par excellence pour répondre à la problématique que j'évoquais à l'ouverture de cette conversation.

Code:

---

1 2 3

int var; flux.read((char *) &var, 4);

---

La valeur lue est automatiquement affecté à var.
ET C'EST TOUT ! ELLE EST PAS BELLE LA VIE ?!

A bientôt ! 8-)

Le C-style cast est encore plus à éviter que le reinterpret_cast!

Ton code est un parfait exemple de comment suivre la lettre d'une "règle" sans comprendre son esprit. Un C-style cast sur un pointeur, c'est une combinaison de reinterpret_cast et const_cast, le tout dans un emballage qui échappe à la recherche textuelle. À ne surtout pas faire.

Citation:

---

Envoyé par radlabo94

Code:

---

1 2 3

int var; flux.read((char *) &var, 4);

---

---

Comme le soulignait Medinoc, si c'est pour faire ça autant faire un reinterpret_cast, c'est plus propre! La raison pour éviter le réinterpret_cast n'est pas une question d'esthétique, mais brutalement une question de validité du traitement.
Le code ci-dessus fait l'hypothèse que ton fichier a été produit par une machine identique à celle qui lit. A savoir:

• même taille pour stocker les int (diffère selon les plateformes)
• même ordre pour stocker les bytes d'une valeur multibyte (diffère selon les plateformes <=> endianness)

Si ton fichier a été produit par une machine qui stocke les int sur 8 bytes, ou qui les stocke dans l'autre sens, tu vas obtenir une valeur aberrante à la sortie.
Par contre, si tu fais l'hypothèse producteur du fichier = consommateur du fichier, alors le reinterpret_cast est une solution valable (bien que fermée à des besoins comme le transfert de données vers une machine de caractéristiques différentes), et autant documenter la limitation et utiliser le reinterpret_cast.
EDIT: ton code ne fait pas seulement l'hypothèse que producteur=consommateur, mais aussi celle que la plateforme sur laquelle tu es déployé stocke les intsur 4 bytes (aucune garantie).