avec les champs de bits C, incertitude sur le padding ?
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut packed à la structure par exemple, sous visual c'est un #pragma
avec les champs de bits C, incertitude sur l'ordre des champs, des bits, des octets, des mots ?
Là encore, c'est connue mais dépend de l'endianness... Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'int ne fait pas 32 bits.
avec les champs de bits C, incertitude sur la taille du type crée ?
Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.
[^] # Re: suckless !! More is less !
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Il n'y a pas vraiment d'incertitude le compilateur alignera les champs sur des frontières de mots. Parce que c'est plus efficace et que la norme ne garanti rien la dessus. Donc sous gcc il faut ajouter l'attribut
packedà la structure par exemple, sous visual c'est un#pragmaLà encore, c'est connue mais dépend de l'endianness... Donc pour faire du code portable, il faut généralement déclarer deux structures, une pour du little endian, l'autre pour du big. Voir d'autre pour le porter sur des CPU où l'
intne fait pas 32 bits.Non, la taille est connue. Soit tu élimines le padding (cf point 1), soit tu le fais pas, mais dans ce cas tu t'en moques.
Ce genre de chose doivent de toutes façon être cantonné au fichier d'interface avec l'extérieur. La structure codée ne doit pas apparaître dans le reste du programme.