Discussion :

[radlabo94]

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 :

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

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 !

[foetus]

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"

Sinon tu as les solutions de bourrins

Code :

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

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);

[Iradrille]

Hello,

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

Code :

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

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

Mais pourquoi lire des char ?

Code :

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

1
2
3
int16_t buffer;
flux >> buffer;
int data = buffer;

[radlabo94]

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 !

[radlabo94]

Bonsoir,

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

A bientôt sur Developpez.

[therwald]

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.

[Médinoc]

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

[therwald]

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

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

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

[radlabo94]

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 :

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

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 !

[Médinoc]

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.

[therwald]

Code :

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

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).