Discussion :

[Jean-Marc.Bourguet]

Pour ce genre de choses, il peut être interessant d'utiliser les fonctions htons/ntohs/htonl/ntohl, qui permettent d'enregistrer toujours sur le même format (dit "format réseau", c'est du BigEndian), et de lire correctement selon l'hote qui exécute la lecture...

Dommage, sous Windows, il faut lier avec Winsock et tout, c'est parfois assez fastidieux...

Moi, si la spec me dit qu'il faut ecrire un entier non signe en 4 octets represente chacun par un caractere en big endian je fais (en coupant la verification des erreurs):

Code :

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

1
2
3
4
5
6
void writeWord(std::istream& is, unsigned long w) {
   is.put((w / 0x1000000) % 0x100);
   is.put((w /   0x10000) % 0x100);
   is.put((w /     0x100) % 0x100);
   is.put((w            ) % 0x100);
}

et ce code fonctionne sur du big endian, du little endian, ... n'importe quoi et il me semble qu'en plus le code correspond clairement a la spec. Pour lire, je fais (en coupant a nouveau la verification des erreurs)

Code :

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

1
2
3
4
5
6
unsigned long readWord(std::istream& is) {
    unsigned long result = is.get();
    result = result * 0x100 + is.get();
    result = result * 0x100 + is.get();
    return result * 0x100 + is.get();
}

et a nouveau il me semble qu'il y a une bonne correspondance avec la spec et que le code est correct partout. Je n'utilise les htonX et ntohX qu'avec les fonctions des sockets puisque la spec dans ce cas c'est d'utiliser le resultat de ces fonctions.

[Laurent Gomila]

Pourrais tu expliquer un peu plus ce que tu dis stp ?
De quelle methodes parles tu ?
Qu'appelles tu "le code bien écrit" ?
Enfin précises un peu car je ne suis pas sur de comprendre de quoi tu parles en fait ^^

Ce que voulait dire Jean-Marc, c'est que l'utilisation de décalages de bits et d'additions pour reconstituer un entier rendait cette opération indépendante de l'endianess. Ainsi en procédant de la sorte (-> "le code bien écrit") c'est bien le système qui va gérer l'ordre des bits et non toi.

Code :

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

1
2
long fsize = fichier.tellg();
unsigned char buffer[fsize];

Il s'agit d'une extension du C tolérée par certains compilos, mais bien invalide en C++. Si la taille n'est pas connue à la compilation il faut utiliser un tableau dynamique (std::vector).

Je voulais juste savoir comment vous feriez pour pouvoir acceder au buffer via la fonction ? cet a dire comment passer ce buffer de ma fonction principale à l'autre pour pouvoir y acceder du meme genre que je le fais actuellement ?

Code :

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

void liredonnees(const unsigned char * buffer)

:

[zax-tfh]

Salut,

J'y vois déjà un peu plus clair avec vos explications !
Pour ce qui est du décalage des bits, j'ai bien pigé ce qu'à dit Jean Marc, impec merci

Par contre pour ce qui est d'utiliser les vectors ok, mais je pense que je vais revenir un peu sur mon histoire de tout bufferiser... en fait je ne suis pas trop sur de la méthode que je souhaite utiliser. Une chose est sure, c'est qu'il faut que je puisse lire ce fichier et en recuperer les données...

Par contre, là ou je ne pige pas c'est que je dois récuperer des données via la fonction read. A partir de cette fonction, je dois lui specifier combien d'octets je souhaite recuperer.
Or vu que le nombre est variable, je dois déclarer la variable ou sont stockés ces octets en unsigned char * buffer.
Et c'est ce * qui me gene, car je lutte toujours autant pour m'en servir ^^

Si je ne dis pas de bétises, je déclare un tableau de pointeurs vers des char, non ?

Et donc c'est là que je coince un peu pour récuperer mes caracteres pour les retravailler en BIG ou LITTLE endian, mais j'espere trouver avec le temps... ^^

EDIT : bon, je suis quand meme pas mal à coté de la plaque, lol... Donc le char * toto c'est un pointeur vers un caractere... je ne sais pas pourquoi je me suis mis en tete que c'etait un tableau de pointeurs... Surement à cause de l'analogie que j'ai fait sur le code source du parseur que j'ai trouvé...
Bon pour faire plus simple (ou peut etre plus compliqué...) je tente avec un vector de char vu que je ne connais pas par avance le nombre d'octets que je vais lire dans le fichier. Par contre, nouveau probleme : comment stocker dans un vector<char> ce que je vais lire avec la fonction read, ou plutot comment passer en parametre mon vecteur dans la fonction read... je fais mes recherches ^^

Merci à vous

[zax-tfh]

Je crois que j'ai trouvé mon bonheur !!!!! Merci les gars !!!! vraiment nickel chrome !!!
Bon par contre pour remplir mon vecteur, je suis obligé de faire une boucle while(i<fsize) qui va faire un read d'un octet et le stocker dans mon vecteur en faisant un push_back. n'y aurait-il pas une methode plus simple pour le remplir d'un coup ?

encore merci en tout cas !
++

[Laurent Gomila]

Je crois que j'ai trouvé mon bonheur !!!!! Merci les gars !!!! vraiment nickel chrome !!!
Bon par contre pour remplir mon vecteur, je suis obligé de faire une boucle while(i<fsize) qui va faire un read d'un octet et le stocker dans mon vecteur en faisant un push_back. n'y aurait-il pas une methode plus simple pour le remplir d'un coup ?

Code :

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

1
2
3
std::vector<unsigned char> buffer(size);
 
fichier.read(reinterpret_cast<char*>(&buffer[0]), size);

C'est expliqué ici :

http://c.developpez.com/faq/cpp/?pag...teneurs_avec_c

Et donc c'est là que je coince un peu pour récuperer mes caracteres pour les retravailler en BIG ou LITTLE endian, mais j'espere trouver avec le temps... ^^

Comme te l'a expliqué Jean-Marc, tu n'auras pas à te soucier de l'endianess.

[zax-tfh]

Merci pour le vector j'ai fouillé cette nuit mais avec les yeux que je devais avoir, c'etait difficile ^^

Pour ce qui est du endianess, j'ai compris le truc au moment ou j'etais dans mon plumard vers 2-3h du mat ^^
En gros, l'operation * 0x100 se fait selon l'endian de la machine donc du coup selon l'endian, la multiplication va decaler de huit bits soit à gauche soit à droite (enfin si j'ai bien compris ^^ mais je pense que oui vu que ma fonction recursive fonctionne).

Encore plein de merci à vous ! j'ai appris plein de bonnes choses

[Laurent Gomila]

Pour ce qui est du endianess, j'ai compris le truc au moment ou j'etais dans mon plumard vers 2-3h du mat ^^
En gros, l'operation * 0x100 se fait selon l'endian de la machine donc du coup selon l'endian, la multiplication va decaler de huit bits soit à gauche soit à droite (enfin si j'ai bien compris ^^ mais je pense que oui vu que ma fonction recursive fonctionne).

Oui, la machine va faire ses décalages de bits directement dans le sens correspondant à son endianess. Par contre inutile d'embrouiller un décalage de 8 bits au fin fond d'une multiplication par 0x100, à part rendre ton code moins compréhensible, ça ne sera pas mieux qu'un bon vieux << 8.

[zax-tfh]

J'y ai pensé aussi, mais je me suis demandé si l'opérateur << ne risquait pas de changer de comportement selon les machines, ou alors qu'il y aurait encore un truc bizarre qui change selon les machines vis à vis de ça... c'est pour ça que je ne l'ai pas changé ^^.
Je vais le faire, merci pour la précision