fun avec des bitmap - Page 1

(char*)(&(h2.filesize)) à la même valeur que (char*)(&(h2.id[4 ]))

alors que:

typedef struct {
char id[ 2 ];
long filesize;
[..]
} BMPHEAD;


C'est normal ?
ça devrait pas être qlqchose comme:
(char*)(&(h2.filesize)) = (char*)(&(h2.id[3 ])) ?

-

c'est ce que je voulais dire.

bon, il semblerait que le compilo s'amuse à ne pas mettre les variables à la queueleuleu. Ça va être super pratique de lire les données contenu dans le header

C'est normal, le compilateur aligne les données pour optimiser les accès.
Selon le compilateur, tu peux désactiver cette optimisation.
Avec GCC => __attribute__((packed))
Avec visal c => #pragma pack(push,1) puis #pragma pack(pop) si mes souvenirs sont bons

ok merci beaucoup. Je m'en suis passé en utilisant une structure avec que des char, puis des fonctions qui réalignent. Si ça devient trop lourd je passe à __attribute__((packed))

Ton char fait 2 tandis que ton long fait 4. Or le bus est en 32bits, donc il est plus rapide pour lui de lire les 32bits d'un coup, donc il aligne. D'ailleurs si tu comptes sur l'alignement du compilateur pour lire tes données, ton code est très sale, pas portable et il fera n'importe quoi avec un autre compilo. En un mot, arrête de compter là-dessus.

-

C'est très sale comme manière de faire. Selon les optimisations, le résultat ne sera pas identique.
Perso, le mieux, c'est d'écrire exactement ce quon veut, ou encore mieux, rajouter une couche d'abstraction sur la structure - XML par ex -

(J'ai l'impression que personne n'a lut mon ./6 )


ex-Miles>
1. déja, un char c'est 1 octet (sur tous les compilo C dont j'ai entendu parler en tout cas).

2. Je ne comprends pas ce que tu essayes de dire

"D'ailleurs si tu comptes sur l'alignement du compilateur pour lire tes données, ton code est très sale, pas portable et il fera n'importe quoi avec un autre compilo. En un mot, arrête de compter là-dessus."
Comment est-ce que je peux "compter sur l'alignement du compilateur" quand j'utilise des char ?

Orion_>
effectivement je fais a peu près:
BMPHEADER bmp;
fread(&bmp, sizeof(BMPHEADER), 1, file);

avec:

typedef struc {
char a[UN_NOMBRE];
}BMPHEADER;

Zallez pas me dire que le compilo va insérer des octets au milleux de mon array quand même

Orion_ :
et si on veut faire un
BMPHEADER bmp;
fread(&bmp, sizeof(BMPHEADER), 1, file);

comment il fait le compilo si il modifie la structure ??
on va ce retrouver avec n'importe koi dans les champs :/

c'est plus ou moins la méthode utilisé par windows pour lire l'entete d'un bmp hein, sauf que la structure bitmap est prédéfinie ^^

pour les pbm d'alignement, passage low/big endian les structures se retrouvent inversé (j'en ai fait les frais sur un de mes projets)

jfg :
(J'ai l'impression que personne n'a lut mon ./6 )


ex-Miles>
1. déja, un char c'est 1 octet (sur tous les compilo C dont j'ai entendu parler en tout cas).

2. Je ne comprends pas ce que tu essayes de dire

"D'ailleurs si tu comptes sur l'alignement du compilateur pour lire tes données, ton code est très sale, pas portable et il fera n'importe quoi avec un autre compilo. En un mot, arrête de compter là-dessus."
Comment est-ce que je peux "compter sur l'alignement du compilateur" quand j'utilise des char ?

Orion_>
effectivement je fais a peu près:
BMPHEADER bmp;
fread(&bmp, sizeof(BMPHEADER), 1, file);

avec:

typedef struc {
char a[UN_NOMBRE];
}BMPHEADER;

Zallez pas me dire que le compilo va insérer des octets au milleux de mon array quand même

Non, mais si tu utilises d'autres types de données la taille peut dépendre de la plateforme et du compilo... Hmm sinon si tu veux faire du code portable évite au maximum les "char" tout court, ca peut etre signé ou non signé... (et sur les nombres signés, les opérations style shift et tout ca sont pas tres bien définies sur les machines qui ne sont pas en complément a 2 ) "unsigned char" cay mieux

ok. unsigned char powa.

-

ben c la seule maniere portable... et oui, le C c'est relou (mais tu peux passer par des macros pour que ca soit un peu moins relou)

-

bah écoute si tu veux faire un programme spécifique a une plateforme et un compilo c'est ton choix...

sur les machines qui ne sont pas en complément a 2

Peut-être que je suis mal renseigné mais toutes les machines de moins de 20ans est pas trop folklorique sont en complément a 2 non?

Godzil
:

Orion_ :
et si on veut faire un
BMPHEADER bmp;
fread(&bmp, sizeof(BMPHEADER), 1, file);

comment il fait le compilo si il modifie la structure ??
on va ce retrouver avec n'importe koi dans les champs :/

c'est plus ou moins la méthode utilisé par windows pour lire l'entete d'un bmp hein, sauf que la structure bitmap est prédéfinie ^^

pour les pbm d'alignement, passage low/big endian les structures se retrouvent inversé (j'en ai fait les frais sur un de mes projets)

tiens, moi aussi. t'as essayé sur ton iBook ?

Uther
:

sur les machines qui ne sont pas en complément a 2

Peut-être que je suis mal renseigné mais toutes les machines de moins de 20ans est pas trop folklorique sont en complément a 2 non?

peu importe, le standard C a été concu dans l'optique de machines pas forcément en complément a 2, donc il impose plus de limites sur les programmes, donc les compilos meme sur machines en complément a 2 s'en servent pour mieux optimiser et donc il vaut mieux utiliser des unsigned meme dans ce cas...

Flanker
:

Godzil
:

Orion_ :
et si on veut faire un
BMPHEADER bmp;
fread(&bmp, sizeof(BMPHEADER), 1, file);

comment il fait le compilo si il modifie la structure ??
on va ce retrouver avec n'importe koi dans les champs :/

c'est plus ou moins la méthode utilisé par windows pour lire l'entete d'un bmp hein, sauf que la structure bitmap est prédéfinie ^^

pour les pbm d'alignement, passage low/big endian les structures se retrouvent inversé (j'en ai fait les frais sur un de mes projets)

tiens, moi aussi. t'as essayé sur ton iBook ?

Ben en l'occurence c'est mon emulateur (que j'ai test sur 3 plateforme largement différente, Windows MSVC, TI68K tigcc, et Mac PPC gcc ^^)

jfg > 2 char = 2 octets.

ah ok

./22> c'est pas forcément vrai. Ca dépend de la plateforme.

2 chars = 2 "octets", meme s'ils ne font pas 8 bits...

et comme un octet ça fait a 99.9999% des cas 8 bits

Pollux> Si ça fait pas 8 bits ça s'appelle pas un octet.

je sais pas si c'est un octet, en tout cas c'est un "octet", c'est-a-dire la traduction francaise de "byte" :

http://dictionary.reference.com/search?q=byte :

byte n. A sequence of adjacent bits, usually eight, operated on as a unit by a computer.

Oui et rien n'empecherait de faire une machine ou la valeur de base fait 10Bits

Apres tout les PC avant des octets de 9Bits ya qq année en arrieres (le 9ème bit etait utilisé pour la parité)

-