Structure + DWORD + WORD => sizeof bizarre

Bonjour à tous ceux qui me liront,

Je n'ai pas l'habitude de poster des questions, je connais très bien le C/C++ mais aujourd'hui, je tombe sur un os :mouarf::

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

typedef unsigned long int DWORD; // 32bit typedef unsigned short int WORD; // 16bit   struct test1 { WORD word; }; struct test2 { DWORD dword; }; struct test3 { WORD word; DWORD dword; };   ...   cout << sizeof(test1); // => 2 : OK cout << sizeof(test2); // => 4 : OK cout << sizeof(test3); // => 8 : ARRGHH

---

Ma kes ki space ???? 8O
Je suis sous ubuntu 10.4, je dev avec eclipse galileo et je compile avec g++ (the last version normalement).

Je veux faire quelque chose du style :

Code:

---

1 2 3 4

struct mystruct { ... } ex; // plein de BYTE(char), WORD, DWORD... ifstream in; in.read((BYTE*) &ex, sizeof(mystruct));

---

Et donc c'est la cata :cry:

Pourquoi lorsque l'on a une structure mélangeant des types 16bit et 32bit il nous met des 32bit à la place des 16bit ? :cfou:
There is something qui m'echappe.

Si un expert de l'implémentation de C++ et qui connait g++ à fond peut donc m'aider à comprendre...

Merci d'avance

Salut

Ton code est du C++.

Pour répondre à ton interrogation, c'est une question d'alignement des données en mémoire, pour des questions de performances. Il y a des explications ici : http://fr.wikipedia.org/wiki/Alignement_de_donn%C3%A9es

Salut,

Merci pour l'info :ccool:

Je vais devoir remplir ma structure champ par champ.
Je dois écrire un peu plus qu'une seule ligne :mouarf:

Il doit exister des implémentations de C qui ne font pas d'alignement à mon avis, peut être pour les applis embarquées : optimisation mémoire oblige ;).
Ça dépend de ce que l'on veut.

Bonjour,

Citation:

---

Envoyé par hargn

Je vais devoir remplir ma structure champ par champ.
Je dois écrire un peu plus qu'une seule ligne :mouarf:

Il doit exister des implémentations de C qui ne font pas d'alignement à mon avis, peut être pour les applis embarquées : optimisation mémoire oblige ;).
Ça dépend de ce que l'on veut.

---

Ce n'est pas trop une histoire d'implémentation, mais de compilateur et de programmeur.
IL y avait cette entrée dans la FAQ: http://c.developpez.com/faq/?page=st...#STRUCT_sizeof
Sinon on peut forcé le compilateur à mettre les données dans la plus petite structure (soit un WORD et un DWORD) avec des commandes pour le précompilateur: http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx

Le mieux pour être portable, serait de lire un chaque champ un octet à la fois (à cause des problèmes d'endianness). Mais si tu veux te limiter aux x86, __attribute__((packed)) pour gcc et #include<pshpack1.h> #include<poppack.h> pour Visual suffisent.

Citation:

---

Le mieux pour être portable, serait de lire un chaque champ un octet à la fois (à cause des problèmes d'endianness)

---

Là j'ai pas ce problème vu que le fichier que je veut lire est en petit-boutiste.
D'ailleurs s'il n'y avait pas ce problème d'alignement, j'aurai juste à charger le fichier en mémoire, et mon parser aurait juste eu besoin de mettre les valeurs des pointeurs de mes structure à la bonne adresse.
Ça aurait été la solution la plus simple pour moi et optimale en coût proc/mem.

Citation:

---

Ce n'est pas trop une histoire d'implémentation, mais de compilateur et de programmeur.

---

Et si car c'est le compilateur qui définit l'implémentation du langage (c'est le sujet de mon cours sur l'implémentation des langages objets), on peut dire que c'est le compilo qui implémente le langage.
Et donc on modifie l'implémentation en filant des params au compilo.
Après c'est au programmeur de ce débrouiller avec la façon dont c'est implémenté (et donc de se débrouiller quand ça colle pas comme il voudrait : par exemple ces fichus structures ne fonctionnant pas comme ça devrait à cause de question d'optimisation) :mouarf: