Comparaison dans une lecture binaire (cas particulier)

Version imprimable

Salut à tous,

Dans le cadre d'une importation de fichier propriétaire, je dois lire en mode binaire puis tester les valeurs pour savoir ou je me trouve dans la structure de celui ci (il est organisé en "chunks").

Alors j'ai un code source qui fait cette importation, mais j'aurais souhaité le refaire pour déja m'améliorer mais également changer le mode d'acces (il passe par des memcpy...)

Donc vaillant gaillard que je suis, je fais mes recherches, determine qu'apparement, au vu des topics du forums et de la FAQ il faut passer par ifstream.

Donc je balance un petit bout de code pour voir si au moins j'arrive à lire le premier noeud composé comme suit :

ID : 2 octets
longueur_chunk : 4 octets.

voici mon code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #define MAIN_3DS 0x4d4d unsigned char buff; //buffer de lecture ifstream filein(filename.c_str(),ios::binary); //ouverture du fichier if(filein) // si l'ouverture a réussi { filein.read(reinterpret_cast<char*>(&buff),2); //on lit les deux premiers octets -> Id if(buff==MAIN_3DS) printf("reussi"); filein.read(reinterpret_cast<char*>(&buff),4); //on lit les 4 octets suivants } filein.close();
Donc voici mes deux questions :

1) filein.read deplace bien le curseur ? c'est à dire qu'apres un read de 2 octets, le prochain read commencera au troisieme ? (je prefere etre sur car j'ai un petit doute)

2) Mon test ne fonctionne pas...
Si je fais afficher le contenu de mon buff, il m'affiche "M", je suppose qu'il faut que je fasse quelque chose à ce buff pour pouvoir le tester avec la valeur de ma constante non ?Comment faire pour que ça passe ? Sincerement, je ne vois pas trop comment faire là.

Merci d'avance et désolé pour la récurrence du sujet ^^ apparement c'est un probleme mystique qui touche pas mal de monde :P
@++

10/01/2006, 09h07
Laurent Gomila

1) Oui

2) Tu ne pourras jamais mettre 2 ou 4 octets dans un unsigned char... Tu peux créer un tableau de N char, ou directement utiliser des types ayant la bonne taille, pour peu que tu sois sûr de ceux-ci selon ton système.

Tu peux aussi regarder comment font les autres chargeurs de 3DS, il y en a pas mal en open-source sur le net.
10/01/2006, 13h47
zax-tfh

[Fausse manip de Loulou24, pas pu récupérer le message original, vraiment désolé :oops:]
10/01/2006, 13h54
Laurent Gomila

Désolé pour ton message, j'ai fait "éditer" au lieu de "citer" :oops: http://djforum.free.fr/smileysmileys...com.stupid.gif

Bref, voilà tout de même ma réponse :

Citation:

Maintenant cela fonctionne en utilisant unsigned short et unsignet int ;)

La taille et le codage interne des types pouvant varier d'un système à l'autre, ne compte sur cette solution que si tu ne vises que ta configuration.

Ahhh, alors là tu fais bien de m'en parler... car ce n'est pas le cas, je cherche à porter mon soft (dev sous Mac Os) vers une platerforme autre (win32 voire linux si j'ai le courage de l'installer un jour :D)

Alors je me doutais bien que les types ne sont pas les memes sous diverses platerformes (enfin pas définies de la meme taille). Mais voila ce que je pense et que j'aimerai bien que tu valides stp :

J'ai un fichier que je lis en binaire. Les données dans ce fichier suivent une structure fixe (pour un unsigned int, on lit 4 octets et on les place dans une variable en unsigned int, pour un short on lit 2 octets...).
Donc grosso modo, la lecture ne se fait pas selon le sizeof(mon type que je veux) mais selon un nombre d'octets que je donne dans mon source.
De cette maniere cela devrait etre portable non ?

Voici le code en question :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 #define MAIN_3DS 0x4D4D void parse3ds(string filename) { unsigned short Id; unsigned int longueur,index; ifstream filein(filename.c_str(),ios::binary); if(filein) { index=0; //lecture du premier noeud. filein.read((char*)(&Id),2); index+=2; filein.read((char*)&longueur,4); index+=4; if (Id!=MAIN_3DS) return; } else printf("erreur de lecture de fichier"); }
Je pense (enfin j'espere) que cela devrait passer sur toute plateforme non ?

Merci d'avance
ps : pas grave pour le message ^^ c'etait surtout adressé à toi pour te remercier donc comme tu l'as vu c'est good ;)

10/01/2006, 14h58
Laurent Gomila

Citation:

J'ai un fichier que je lis en binaire. Les données dans ce fichier suivent une structure fixe (pour un unsigned int, on lit 4 octets et on les place dans une variable en unsigned int, pour un short on lit 2 octets...).
Donc grosso modo, la lecture ne se fait pas selon le sizeof(mon type que je veux) mais selon un nombre d'octets que je donne dans mon source.
De cette maniere cela devrait etre portable non ?

Et si tu mets 2 octets dans un unsigned short qui en fait 4 par exemple, il va se passer quoi à ton avis ?

En fait il y a deux solutions :

- Définir des types de taille fixe, càd tout un tas de directives préprocesseurs pour gérer chaque système... C'est plutôt lourd. De plus il faudra encore gérer l'endianess par dessus ça.

- Utiliser des buffers de caractères pour récupérer tes données, puis reconstituer les entiers à partir de ses éléments. Avec les fonctions qui vont bien c'est vite géré. Et plus de problème d'endianess, non plus (normalement).

En effet, j'avais pas pensé à ça...
J'ai fait un truc, mais comme je patauge un peu sur les cast, sur ce qu'il se passe dans la machine et tout le tintouin, je ne suis pas ultra sur de mon coup. Voici le code :

Classe noeud :
Code:

1 2 3 4 5 6 7 8 9 class noeud { public: char Idchar; char longueurchar; unsigned short Id; unsigned int longueur; void noeud::caster(void); };
Sa méthode pour caster les données en type souhaité (donc c'est ici que j'ai mis ma pseudo solution au probleme que tu as soulevé (ou ma solution tout court si elle est bonne ^^)
Code:

1 2 3 4 5 6 void noeud::caster(void) { this->Id = (unsigned short)this->Idchar; this->longueur = (unsigned int)this->longueurchar; }
Enfin, la fonction qui lit un noeud.
Code:

1 2 3 4 5 6 7 8 9 10 11 noeud lirenoeud(ifstream &fichier, int &index) { noeud node; fichier.read((char*)&node.Idchar,2); index+=2; fichier.read((char*)&node.longueurchar,4); index+=4; node.caster(); return node; }
Merci d'avance
++

ps : j'espere que ce cast fait le taf ;)

10/01/2006, 15h13
zax-tfh

J'ai été un peu vite là... :(
Ca ne fonctionne pas... je repart à la peche voir ce qui debloque...

Je pense avoir trouvé une solution, mais je n'en suis pas sur, ne sachant pas ce que fait réellement le reinterpret_cast au niveau du langage machine (s'il convertit bien proprement ou s'il pourrait merder selon les archis des machines).
Voici le code, qu'en penses tu ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class noeud { public: unsigned char Idchar[2]; unsigned char longueurchar[4]; unsigned short Id; unsigned int longueur; void noeud::caster(void); }; void noeud::caster(void) { this->Id = *(reinterpret_cast<unsigned short *>(this->Idchar)); this->longueur = *(reinterpret_cast<unsigned int *>(this->longueurchar)); }
Donc pour lire mes noeuds j'utilise ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 noeud lirenoeud(ifstream &fichier, int &index) { noeud node; fichier.read(reinterpret_cast<char*>(&node.Idchar),2); index+=2; fichier.read(reinterpret_cast<char*>(&node.longueurchar),4); index+=4; node.caster(); return node; }
Penses tu donc que je ne risque pas d'avoir de probleme en terme de portabilité ?
Merci d'avance
++

Il ne faut pas employer de cast, il suffit de recoller correctement les morceaux de ton entier :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
unsigned long Read2Bytes(std::istream& Stream)
{
    unsigned char Buffer[2];
    Stream.read(reinterpret_cast<char*>(Buffer), 2);
 
    if (LITTLE_ENDIAN) // macro à définir selon le système (PC : little endian ; MAC : big endian)
    {
        return Buffer[0] + (Buffer[1] << 8);
    }
    else
    {
        return Buffer[1] + (Buffer[0] << 8);
    }
}
 
unsigned long Read4Bytes(std::istream& Stream)
{
    unsigned long Buffer[] = {Read2Bytes(), Read2Bytes()};
 
    if (LITTLE_ENDIAN)
    {
        return Buffer[0] + (Buffer[1] << 16);
    }
    else
    {
        return Buffer[1] + (Buffer[0] << 16);
    }
}

Un truc dans le genre, modulo les erreurs d'endianess (l'ordre est peut-être inversé).

Et assure-toi bien que le type de retour (ici unsigned long) est toujours suffisamment grand pour contenir le nombre d'octets que tu lis.

10/01/2006, 16h25
zax-tfh

Arf, là je pleure un peu...
J'etais parti pour m'amuser avec opengl et j'en arrive à m'enerver sur des Bytes ^^

Tes fonctions, c'est bien mais sincerement, je ne calcule pas grand chose, du moins, je crois peut etre voir ce que tu fais mais je ne suis pas certain...

Tu recuperes tes deux octets dans un tableau de char, tu renvoie le char[1]+le car[2] decalé à gauche de 8

Mais je ne sais pas vraiment ce que c'est censé faire du style, le decalage, ou meme le symbole +

Je suis vraiment rouillé de chez rouillé sur les bases du C c'est grave ! lol.

Pour revenir à mon probleme, n'existe-t-il pas de solution toute faite ? enfin une gestion bien implémentée quoi.
Car bon, moi j'ai juste envie de recuperer des octets et de les mettres dans des variables typées correctement, c'est tout ^^ pas de réinventer le systeme :D

Et pourquoi le cast ne fonctionne-t-il pas dans mon cas ? c'est ça que je ne comprend pas en fait.
Je vais t'expliquer ma logique, tu comprendras peut etre mieux pourquoi je ne comprend pas ^^

Dans le descriptif du fichier, on me dit, à telle adresse, tu dois recuperer tant d'octets et ces octets representent un int.
Donc bon, la partie recuperation d'octets, c'est pas bien compliqué, je lui dit d'aller lire le fichier au bon endroit et de recuperer mes N octets.
Ensuite si je caste, logiquement, il devrait me traduire mes N octets (qui representent d'apres le descriptif un int - et ce, quelque soit la machine) en un type au format de la machine non ?

Je ne comprend pas à quel endroit c'est censé coincer en faisant ça (bon certes c'est une vision pas très profonde des choses, mais je m'adapte ^^)

voilou
++

ps : j'avais meme pas grillé que tu etais de Metz, on est à 60 bornes l'un de l'autre ^^ je suis sur nancy ;)
10/01/2006, 16h44
Laurent Gomila

Citation:

Tes fonctions, c'est bien mais sincerement, je ne calcule pas grand chose, du moins, je crois peut etre voir ce que tu fais mais je ne suis pas certain...

Ok, j'explique :)

Le but est de récupérer les octets individuellement, puisqu'on ne sait pas dans quel ordre le système les veut. Donc, dans un tableau d'octets (unsigned char). Ensuite, si le système est en big endian (octet de poids fort en premier ou dernier -- me rappelle jamais), il faut recoller les deux morceaux de ton entier dans un certain ordre, si le système est en little endian, l'inverse. Le recollage est effectué en additionnant (on aurait aussi pu utiliser un OU bit à bit, mais l'addition est équivalente puisqu'il n'y a aucun recoupement) les deux octets, mais il faut décaler un octet de 8 bits afin qu'il se place devant l'autre, et non par dessus. Et voilà, tu as formé un entier de 16 bits avec 2 octets. Pour 4, 8, ... c'est pareil, sauf qu'on utilise la fonction qui récupère n/2 octets plutôt que de tout refaire à partir d'un tableau d'octets.

Citation:

Dans le descriptif du fichier, on me dit, à telle adresse, tu dois recuperer tant d'octets et ces octets representent un int.
Donc bon, la partie recuperation d'octets, c'est pas bien compliqué, je lui dit d'aller lire le fichier au bon endroit et de recuperer mes N octets.
Ensuite si je caste, logiquement, il devrait me traduire mes N octets (qui representent d'apres le descriptif un int - et ce, quelque soit la machine) en un type au format de la machine non ?

L'erreur est dans

Citation:

il devrait me traduire mes N octets (qui representent d'apres le descriptif un int - et ce, quelque soit la machine)

Le fichier a été enregistré sur une machine bien précise, l'encodage des entiers qui y sont écrits sont donc soumis à la règle d'endianess et de taille propre à cette machine. Comme le logiciel n'est pas con, il a procédé (certainement) de la même manière que moi afin que ceci ne dépende plus de la machine, c'est pourquoi l'ordre et la taille des entiers est donnée explicitement dans la documentation du format.
De plus reinterpret_cast n'effectue aucune conversion physique, il change juste la manière dont le compilo va interpréter ce qui est pointé.
10/01/2006, 16h56
zax-tfh

Limipide comme de l'eau de vie :D

Je comprend dix fois mieux là ! merci pour tes explications ! vraiment c'est sympa !
Donc si j'ai bien saisi, le probleme d'endianess ne se situe pas sur la machine qui execute mon soft mais au niveau du fichier 3ds en question.

Donc admettons que je trouve dans le descritpif qu'il s'agisse de l'un ou de l'autre, je pourrais me servir de tes fonctions sans devoir faire le test de l'endianess.

Si je sais que c'est dans un certain sens, j'ai juste à renvoyer mes octets composés dans le bon sens et c'est tout quoi ?

En gros, si je voulais pouvoir utiliser ma méthode que j'ai decrit plus bas, il faudrait que mes octets soient décrits à l'endroit.

Par exemple (et schematiquement):
J'ai 2 octets A et B
A et B collés comme ceci AB forment un nombre unsigned short.
Si dans mon fichier 3ds il sont décrit de poids faible à poids fort ça sera décrit comme ceci :

XXXXXBAXXXXX (X etant les autres octets contigües)
Or quand je vais lire, je vais prendre de gauche à droite, donc au final je vais avoir BA dans ma variable de recuperation, ce qui n'est pas bon.
Par contre, si les octets sont décrit de poids fort à poids faible, j'aurais ça : XXXXXABXXXXX
je vais donc recuperer AB dans ma variable et alors je pourrais caster tranquille pepere.

Donc pour résumer, la gestion des endianess dependent du fichier 3ds et non de la machine executant le programme ?

Si j'ai tout faux, désolé pour l'abberation ^^
10/01/2006, 17h28
Laurent Gomila

En fait, la façon dont sont stockés les entiers dans le fichier est figée (et devrait être documentée normalement), c'est par contre bien le système qui va lire ces entiers qui ne vas pas avoir le même système d'endianess. Donc il faut bien adapter les fonctions selon la plateforme sur laquelle tourne le programme.
10/01/2006, 17h32
zax-tfh

Ca y est je viens de piger !
Effectivement, si tu es sur un systeme ou c'est poids fort -> poids faible et que tu envoies dans cet ordre AB à chaque recuperation, ca ne sera pas pareil sur un systeme ou c'est dans l'ordre inverse.

Je saisis mieux la subtilité ^^
Merci beaucoup !

N'empeche que ça me fait halluciner le nombre de trucs comme ça dont on ne soupsconne meme pas l'existance et qui peuvent tout faire foirer !!!

Encore merci !
10/01/2006, 22h12
Jean-Marc.Bourguet

Citation:

Envoyé par Loulou24

En fait, la façon dont sont stockés les entiers dans le fichier est figée (et devrait être documentée normalement), c'est par contre bien le système qui va lire ces entiers qui ne vas pas avoir le même système d'endianess. Donc il faut bien adapter les fonctions selon la plateforme sur laquelle tourne le programme.

Si tu les recomposes comme tu l'as fait, tu n'as pas à tenir compte de la boutitude de ta machine. C'est bien là l'avantage de la méthode: le fichier a un format bien fixé et le code bien écrit ne dépend pas de la correspondance ou non de ce format avec la représentation utilisée par la machine.
10/01/2006, 22h34
Laurent Gomila

Citation:

Envoyé par Jean-Marc.Bourguet

Si tu les recomposes comme tu l'as fait, tu n'as pas à tenir compte de la boutitude de ta machine. C'est bien là l'avantage de la méthode: le fichier a un format bien fixé et le code bien écrit ne dépend pas de la correspondance ou non de ce format avec la représentation utilisée par la machine.

Exact j'avais même pas pensé à ça :koi:

Bon ben finalement tout ça devient très simple :wink:
10/01/2006, 23h58
Médinoc

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...
11/01/2006, 02h01
zax-tfh

Citation:

Envoyé par Jean-Marc.Bourguet

Citation:

Envoyé par Loulou24

En fait, la façon dont sont stockés les entiers dans le fichier est figée (et devrait être documentée normalement), c'est par contre bien le système qui va lire ces entiers qui ne vas pas avoir le même système d'endianess. Donc il faut bien adapter les fonctions selon la plateforme sur laquelle tourne le programme.

Si tu les recomposes comme tu l'as fait, tu n'as pas à tenir compte de la boutitude de ta machine. C'est bien là l'avantage de la méthode: le fichier a un format bien fixé et le code bien écrit ne dépend pas de la correspondance ou non de ce format avec la représentation utilisée par la machine.

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 ^^

Merci ;)

Je pense comprendre ce qui me pose probleme : les pointeurs !!!
Je connais grosso modo le principe de base, un pointeur est une sorte de variable qui contient l'adresse memoire d'une valeur que l'on a stocké ou d'une variable.
Le soucis, c'est que là je n'y comprend rien avec cette histoire de buffer et compagnie, c'est une horreur...

Je voulais donc savoir si quelqu'un pouvait me filer un petit coup de pate en me donnant juste le code de ce que je vais décrire plus bas, comme ça je pourrais au moins savoir vers quoi me diriger et ensuite chercher dans ce sens pour comprendre pourquoi ce code et pas un autre.

Voila ce que je veux faire pour le moment (pour pouvoir comprendre) :

Ma fonction principale :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void parseFichier3ds(string filename) { ifstream fichier(filename.c_str(),ios_base::binary); if (fichier) { fichier.seekg(0,ios_base::end); long fsize = fichier.tellg(); unsigned char buffer[fsize]; fichier.seekg(0,ios_base::beg); fichier.read(reinterpret_cast<char*>(buffer), fsize); fichier.close(); liredonnees(?????); } }
ma fonction liredonnees :
Code:

1 2 3 4 5 6 7 8 9 10 void liredonnees(???????? buffer) { unsigned short ref = 0x4d4d; unsigned short id; unsigned int longueur; id = buffer[1]+(buffer[0]<<8); printf("id : %d \n",id); printf("reference %d \n",ref); }
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 ?

Merci d'avance, ça me permettra de me rafraichir un peu sur les pointeurs et tout le tintouin, malgré mon allergie perpetuelle ^^
++

Citation:

Envoyé par Médinoc

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:

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:

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.

11/01/2006, 09h25
Laurent Gomila
Citation:

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.
Citation:
Code:

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

Citation:

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:

void liredonnees(const unsigned char * buffer)

:?:
11/01/2006, 22h33
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
12/01/2006, 00h26
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 !
++
12/01/2006, 10h03
Laurent Gomila
Citation:

Envoyé par 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 ?
Code:

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

Citation:

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.
12/01/2006, 10h33
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 :D
12/01/2006, 10h59
Laurent Gomila

Citation:

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.
12/01/2006, 11h04
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 ;)

Fuseau horaire GMT +2. Il est actuellement 07h42.