NairodDorian
Messages postés130Date d'inscriptionlundi 26 juin 2006StatutMembreDernière intervention18 août 2008
-
25 août 2006 à 11:47
hibakusha
Messages postés25Date d'inscriptionvendredi 4 août 2006StatutMembreDernière intervention23 mai 2007
-
8 oct. 2006 à 18:50
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 août 2006 à 14:21
C'est ton compilo qui ajoutera le reste, ce que j'appelle le 'cadrage', pour que le sizeof soit en conformité avec son réglage (normalement 8) de taille de structure.
Si donc tes membres sont correctement alignés comme dans mon exemple au dessus, le compilo ajoutera 3 octets en bas de la struct.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 août 2006 à 12:14
char c[1];
s'écrit: char c;
Pour un alignement correct sans occupation de mémoire inutile, suffit de mettre par ordre décroissant des tailles de variables.
ex:
typedef struct _ELEM {
double d; // 8 octets
int *pval; // 4 octets sur system 32 ou 8 sur system 64
int v;
short si;
char szbuf[10]; // serie de 1 octet
char c;
} ELEM, *LPELEM;
NairodDorian
Messages postés130Date d'inscriptionlundi 26 juin 2006StatutMembreDernière intervention18 août 2008 30 août 2006 à 11:30
J'ai une toute derniere question pour completer ce post, j'aligne du plus grand (double) au plus petit (char) dans ma structure c'est donc une representation big endian mais les processeurs pentium travaillent en little endian.
Donc logiquement je devrai commencer du plus petit au plus grand.
Pourquoi developper a l'inverse du fonctionnement des pentium ?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 30 août 2006 à 12:03
big ou little endian n'a rien à voir avec l'alignement de structure, c'est l'ordre dans lequel le cpu traite les octets par rapport à un mot (WORD) ou DWORD.
hibakusha
Messages postés25Date d'inscriptionvendredi 4 août 2006StatutMembreDernière intervention23 mai 20071 8 oct. 2006 à 18:50
Les membres seront toujours correctement alignés, quoi que tu fasse : c'est le compilateur qui fait ce boulot, peu importe l'ordre dans le quel tu declarera les membres, le compilo les alignera sur la frontiere "naturel" du micro, et ajoutera les octets de padding en consequence (multiple de 8 octets dans ton cas) ...
... Sauf bien sûr si tu utilise les mots clefs specifiques de ton compilo pour forcer un désalignement : c'est la qu'il faudra penser aux eventuels problemes si tu passe un structure/class en parametre .... (par exemple sous Windows, et pour des micro type ARM, avec le mot clef __unaligned tu peut forcer un membre à être à une adresse non alignée. Mais si tu doit faire ce genre de connerie, c'est bien souvent parce que le type avant toi n'as pas reflechi plus loin que son nez, ou bien que tu doit te trimbaler un passif dont on tu peut pas te debarraser...j'en sait quelque chose :( )
La bonne question c'est plutot : est ce que j'ai vraiment une tres tres bonne raison de passer du temps à reflechir aux deux octets de padding que je pourrait eviter ? si tu bosse sur une machine à l'aise dans sa ram, la réponse est non. Maintenant si tu doit embarquer ton soft sur des cibles toute petite avec de la memoire que se fait rare (raison de cout avant tout), plus surement la reponse sera oui.
si tu veut optimiser, utilise le plus souvent possible des membres int/unsigned int : dans ce cas le compilo fera toujours un meilleur boulot que toi, et les accès memoire seront eux aussi optimisés. Evite les raisonnement du genre "j'ai besoin d'un compteur de 0 a 200, alors je prend un unsigned char" Dans ce cas le micro ira plus vite a incrementer un unsigned int qu'un unsigned char (pas d'operation "masquée", un seul acces bus etc...)