Discussion :

[hargn]

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 :

Code :

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

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 ????
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 :

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

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

Pourquoi lorsque l'on a une structure mélangeant des types 16bit et 32bit il nous met des 32bit à la place des 16bit ?
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

[jeroman]

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

[hargn]

Salut,

Merci pour l'info

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

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.

[LittleWhite]

Bonjour,

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

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

[Médinoc]

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.

[hargn]

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.

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)