Que fait le compilateur

Version imprimable

Bonjour tous le monde,
je suis en train de faire un interface pour la gestion des fontes de caractère,
la structure à transmettre pour créer ou changer une fonte est la suivante:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 typedef struct tagLOGFONTA { LONG lfHeight; LONG lfWidth; LONG lfEscapement; LONG lfOrientation; LONG lfWeight; BYTE lfItalic; BYTE lfUnderline; BYTE lfStrikeOut; BYTE lfCharSet; BYTE lfOutPrecision; BYTE lfClipPrecision; BYTE lfQuality; BYTE lfPitchAndFamily; CHAR lfFaceName[LF_FACESIZE]; } LOGFONTA, *PLOGFONTA, *NPLOGFONTA, *LPLOGFONTA;
Ma question:

Que fait le compilateur quand il tombe sur BYTE, est-ce qu'il réserve juste un Byte (Octet) dans la mémoire ou est-ce qu'il réserve
une structure de 4 octets consécutifs ou seul l'octet de poids faible est utilisé. ?

Comme vous savez je ne programme pas en C++, mais j'ai besoin de ces infos pour interfacer mes affaires avec les fonctions Windows, je dois donc
créer une structure similaire à celle crée par le compilateur C++
Jusqu'à lfWeight ça marche impeccable c'est après que ça foire.

Merci pour vos réponses
Cordialement

Ludwig

04/03/2019, 16h47
Bousk

Citation:

Envoyé par Ludwig1

Que fait le compilateur quand il tombe sur BYTE, est-ce qu'il réserve juste un Byte (Octet) dans la mémoire ou est-ce qu'il réserve
une structure de 4 octets consécutifs ou seul l'octet de poids faible est utilisé. ?

Il regarde comment ça a été défini : soit un typedef soit un define.
Si c'est un typedef, le compilateur le considère et traite par son type réel.
Si c'est un define, le pré-processeur remplace par ce qu'il définit avant de passer à l'étape de compilation.

Que fait le compilateur

Bonsoir, Merci pour la réponse- Entre temps j'ai procédé à quelques essais.

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
29
30
typedef struct tagLOGFONTA {
  LONG lfHeight;
  LONG lfWidth;
  LONG lfEscapement;
  LONG lfOrientation;
  LONG lfWeight;
  BYTE lfItalic;
  BYTE lfUnderline;
  BYTE lfStrikeOut;
  BYTE lfCharSet;
  BYTE lfOutPrecision;
  BYTE lfClipPrecision;
  BYTE lfQuality;
  BYTE lfPitchAndFamily;
  CHAR lfFaceName[LF_FACESIZE];
} LOGFONTA, *PLOGFONTA, *NPLOGFONTA, *LPLOGFONTA;
 
Il semblerai que le compilateur construit le structure suivante en mémoire.
hFont est le point d'entré. 
 
Hfont 64 Dump 
  560604 50 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 P...(...........
  560614 64 00 00 00 FF FF 00 0D 00 00 00 40 73 63 72 69 d..........@scri
  560624 70 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 pt..............
  560634 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok
 
 
DONC    
LONG lfHeight;    COMPILE     50 00 00 00 
BYTE  lfItalic;       COMPILE     FF

Comme la structure ci-dessus fonctionne,
j'ai la réponse, BYTE compile des octets les uns à la suite des autres.

Merci à ceux qui se sont donné la peine de lire et/ou de répondre.
Cordialement

Ludwig

04/03/2019, 21h03
Matt_Houston
Je pense que l'OP s'interroge sur la stratégie de packing de l'enregistrement.

En C c'est à vérifier, mais je pense que cela est défini comme en C++, à savoir indéterminé : seuls l'ordre des membres en mémoire et l'adresse du premier membre sont garantis, le padding (la présence d'octets intermédiaires garantissant un alignement optimal) est laissé à la discrétion du compilateur.

Dans le cas particulier de membres consécutifs de type char, tu as peut-être une garantie de contigüité. Faudrait relire la norme pour s'en assurer.

Si tu as besoin d'un layout (disposition mémoire) bien déterminé, par exemple pour faire de l'interopérabilité comme tu l'évoques, alors tu as deux solutions :
- définir tout ou partie du contenu de la structure comme packed avec une directive compilateur, exemple pour gcc (ou encore via un pragma) ;
- utiliser des tableaux en lieu et place de membres consécutifs : c'est portable mais c'est moche et peu lisible.