Bon, vu la rapidité avec laquelle mon problème sur les dlls a été réglé, je tente une deuxième question
Je voudrais lire des en-têtes de fichiers, à l'aide de flux (ifstream machin (lefichier),  machin.read (lehader))
Et bien sur en binaire hein.
Bon mais je sais que y a pleins de trucs compliqué à l'échelle des bits, du genre les words dans les dwords sont inversé (0xAB CD devient 0xCD AB ou un truc comme ça), et pis est-ce que read lis bien dans l'ordre (j'espere qd même ), et enfin est-ce qu'il y a un moyen que si je crée :

Machin soit bien le 1er en mem, suivit de bidule et de truc, histoire de pouvoir faire un read (&Header), si jamais read remet bien les bits dans l'ordre bien sur ...
 
Oula je crois que j'ai rarement posté un truc aussi peu clair ... Mais bon les gens d'ici sont tellemet bon ... nan, si vous avez des précisions à demander j'expliquerai

Bonne question, ça m'intéresse aussi

big endian / little endian. ça dépend de ton proc : intel, mac, etc.
 

en théorie, oui. en théorie, car le compilateur peut décider d'aligner tes variables (sur word, sur dword). relis le fichier avec d'autres options de compilation, tu l'as dans l'os.

ben moi j'ai souvent fait ce genre de manip, et je n'ai eu aucun problème, les zones de mémoire étaient bien contigues
 
je suppose que quand on déclare une structure, le compilo se débrouille pour allouer une zone de RAM suffisamment large...

Vaut mieux éviter de faire un read/write bestiale de structure, par contre pour les types atomique de plus d'un octets (int, double...) Tant que tu écrit et que tu lis sur des machines qui ont le même type de processeur c bon.

euh ... bon pour le truc qui dépend du proc, j'ose espérer que c'est qd même pareil pour tout ce qui se trouve sur PC (intel, amd, cyrix (:D)), non ? Sinon je suis pas dans la merde ...
 
Ensuite pour l'alignement en mem, est-ce que ça veut dire que le seul moyen de ne pas avoir de problème c'est de lire les infos par petits bouts du genre read(&Header.machin), puis read(&Header.bidule) puis read(&Header.truc) ... ? Si c le cas ça tue un peu (bcp) l'intérêt d'avoir une struct ...
 
 

 
Ha mon avis tu peux avoir des problèmes si tu utilise pas le même compilo pour faire le prog qui lit et celui qui écrit (je sais ça peut paraitre stupide mais on sait jamais ) d'autant plus si tu utilise des int.

freewol a écrit a écrit : euh ... bon pour le truc qui dépend du proc, j'ose espérer que c'est qd même pareil pour tout ce qui se trouve sur PC (intel, amd, cyrix (:D)), non ? Sinon je suis pas dans la merde ...

 
Tant que tu reste sur une plateforme Pc ça doit être bon.
 

freewol a écrit a écrit :   Ensuite pour l'alignement en mem, est-ce que ça veut dire que le seul moyen de ne pas avoir de problème c'est de lire les infos par petits bouts du genre read(&Header.machin), puis read(&Header.bidule) puis read(&Header.truc) ... ? Si c le cas ça tue un peu (bcp) l'intérêt d'avoir une struct ...

 
Normalement ça doit passer, sauf si tu cherche les enuis avec des truc exotiques

freewol a écrit a écrit : euh ... bon pour le truc qui dépend du proc, j'ose espérer que c'est qd même pareil pour tout ce qui se trouve sur PC (intel, amd, cyrix (:D)), non ? Sinon je suis pas dans la merde ...

à partir du moment ou tu ne codes pas pour des procs motorola... tous les processeurs intel ou compatibles codent leurs octets en little endian.
 

freewol a écrit a écrit :   Ensuite pour l'alignement en mem, est-ce que ça veut dire que le seul moyen de ne pas avoir de problème c'est de lire les infos par petits bouts du genre read(&Header.machin), puis read(&Header.bidule) puis read(&Header.truc) ... ? Si c le cas ça tue un peu (bcp) l'intérêt d'avoir une struct ...

franchement, vu le nombre de fois ou j'ai lu ou écrit une structure en bloc sans aucun pb, je me demande vraiment si c'est source d'emmerdement
 
 
 

 
Pour avoir des problèmes faut vraiment les chercher à mon avis

ce n'est pas une source d'emmerdements, c'est un design qui dit : c'est CETTE structure qu'on utilise, on ne la changera JAMAIS (en gros). si tu veux faire évoluer ta structure, tu as intérêt à sauvegarder chaque variable avec son nom, un peu comme les attributs d'une balise html. _là_ tu n'auras jamais d'emmerdes, tu ne te prendras moins la tête avec des numéros de version, etc.

un exemple de soft que j'ai fait et qui écrit une structure en bloc :
 
http://harko.free.fr/soft/ID3_2_CSV.exe
 
c'est un prog qui exporte les tags ID3 de fichiers mp3 en CSV. je déclare une structure correspondant au tag et je fais un read sauvage dans &structure. aucun pb.
 
vérifieé, vous verrez !

ah mais la je suis d'accord !  
si la structure n'évolue pas, cette manip est sans danger, la c'est clair !

Harkonnen a écrit a écrit : un exemple de soft que j'ai fait et qui écrit une structure en bloc :   http://harko.free.fr/soft/id3_2_csv.exe   c'est un prog qui exporte les tags ID3 de fichiers mp3 en CSV. je déclare une structure correspondant au tag et je fais un read sauvage dans &structure. aucun pb.   vérifieé, vous verrez !

 
On a jamais dit que ça marchait pas, je l'ai souvent fais moi aussi

bon ok donc si je résume, étant donné que je ne code que pour PC (euh ... windows c bien que pour PC non ? ), je me pose pas de question sur les bits écris sur le DD. Ensuite si je joue pas de malchance j'aurai pas de problème avec un read sauvage de structure.
 
Bon tout ça c très bien, mais (et oui il y a un mais) :
est-ce qu'il faut que je tienne compte de ce petit ou grand indien, je ne sais même pas si ça correspond à ce que je disais (inversion des dwords) ?????
Et pkoi, oui pkoi, qd je tente ce que j'ai dis avec un fichier bmp, non seulement ça foire, puisque j'ai que qques champs qui sont bons, mais en plus suivant si je read la structure d'un coup d'un seul ou par ptits bouts j'ai certains champs qui sont bons ou non ? Bon mais là pour cette dernière question il est encore possible que ça vienne de mon code, que je n'ai pas totalement vérifié, svp répondez surtout à celles plus théoriques.
 
En tout cas merci pour vos réponses

C littleEndian (un truc comme ça), ça veut dire que les octets de poid faibles sont en premier, pour écrire 0xFF00 le proc met 00 FF (dans la mémoir ou sur le disque) Et tant que tu code pour le même type de proc c bon.

sur les procs intel, la suite d'octets suivante :

 
sera codée comme ça en mémoire :

 
mais en mémoire uniquement ! après, le compilateur se débrouille à remettre ça dans l'ordre (à confirmer néanmoins).
 
donc à mon avis, je pense que tu n'as meme pas à te casser le c.. à remettre tout ça en ordre
 

 
Effectivement le compilo fait ce qu'il faut et tu n'as pas à t'en occuper lorsque tu écrit ton code. Attention cependant avec les images, tu peux avoir des surprises en ce qui concerne l'écriture des couleurs (j'ai eu le problème).

ok bon j'essaie tout ça, et je vous tiens au courant.
merci à tous

Bon ben les ennuis commence, je suis dsl mais je risque de poser encore une question stupide ...
C parti :  
J'essaie de lire le header d'un bête BMP, et ça foire déjà. Bon ce BMP ouvert avec Hex Workshop se révèle commencer par 42 4D C4 0D 02 00. 42 et 4D ça c l'identifiant, 2 chars : 'BM', et C4 0D 02 00, qui sont donc inversés et signifient donc 00 02 0D C4, soit 134596 comme le confirment la calculatrice et Hex Worshop lui même, c'est la taille. Bon ensuite le prog qui tente de lire ça (oui juste ça ) :

Bon ben ça ça marche pas puisque j'obtient :
Identifier : 'BM'
FileSize : 2

Par contre (!!), si je fais le read comme ça :

et bien j'obtiens bien :
Identifier : 'BM'
FileSize : 134596
 
...

 
Pourquoi tu castes ???

ben parce que le prototype de read c read (unsigned char *, ...)

Essaie plutot :

 
Hum, non, pareil (encore heureux).

C quoi ta variable BMP comme type?

au fait, t'utilises quoi comme compilo ?
si c'est GCC, c'est normal

Bon contre toute attente j'ai compris d'où venait le problème ... et ça montre que tout n'est pas tjs aussi simple que les posts précédant pouvaient laisser penser. Je pense que c un problème du à read de ifstream, mais la cause elle-même du problème de read est l'inversion des octets due aux indiens.
 
Le truc, c'est que ça marche très bien qd les dwords à lire sont alignés en mem, mais ça ne marche plus du tout quand des words ou des bytes seuls viennent tout déranger.
 
Un exemple : si on a  

et qu'ensuite on fait un read (&Exemple), et bien le word1 sera bon, mais les dwords1 et dword2 ne le seront pas, tandis que dword3 le sera à nouveau !! (word2 j'en sais rien)
Et si on fait ça :

ou ça :

et bien ça marche ...
Bon j'ai un peu écrit un roman, dsl.
J'espere avoir été clair, parce que j'y connais rien à ça, je décris juste le résulat d'expériences extrapolé ...

Tu l'as bien ouvert en binaire ton ifstream?

as tu ouvert ton ifstream en binary ?
 
edit : grilled

 
Grillé

ouiouiouiouiouiouiouiouiouiouiouiouiouiouioui

Eh oui faut de la mémoire Dsl

t'utilises GCC ou pas ?

On sait jamais.
2eme explication: ton compilo fait un allignement de la mémoir à la con et te rajoute 2 octets à la suite de ton tableau.
Vérifie la taille de ta structure.

consulte ça éventuellement :
 
http://www.phim.unibe.ch/comp_doc/ [...] izeof.html
http://www.delorie.com/djgpp/v2faq/faq22_11.html

bon déjà non j'[/cpp]utilise VC++6 sous win98
 
ensuite je sais ce qu'il se passe exactement pour ma structure de BMP :  

Ensuite mon fichier commence par : 42 4D C4 0D 02 00 00 00 00 00 36 00 00 00 28 00(oui ça fait bcp de chiffres )
Eh bien si je lis tout d'un coup, 42 et 4D sont bien convertis en char : 'B' et 'M'. Ensuite C4 0D sont oubliés ! Puis on inverse : 02 00 00 00 devient 00 00 00 02 d'où la taille de 2, puis 00 00 36 00 devient 00 36 00 00 et 00 00 28 00 devient 00 28 00 00. Hum bon j'en ai fait un peu trop, tant pis je laisse. Enfin bref, si le lis en 1er les 2 chars, 42 et 4D ne sont plus oubliés. Le truc c'est read aligne tout suivant les multiples de 4 à partir du début où on lis apparemment. Par contre ensuite dans l'en-tête il y a 2 words de suite et ça passe très bien (ils sont pas inversés entre eux).

 
Par ce que les donnée doivent être allignée sur 32 bits par ton compilo. T'as essayé de reagrdé ce que te renvoi sizeof sur ta structure?

ah ok ... ok ça y est je viens de comprendre le rapport avec les trucs sur sizeof de tout à l'heure. Au temps pour moi. Je regarderai ça. Mais ça expliquerai bien les choses. Ce qui est bien c'est que je comprends vite. Ce qui l'est moins, c qu'il faut m'expliquer longtps
Merci

je voudrais savoir si tu le fais exprès