Pourquoi n'est-ce pas sizeof pour une struct égale à la somme de sizeof de chaque membre?

L'emballage et l'alignement d'octets, comme décrit dans la FAQ C ici:

C'est pour l'alignement. De nombreux processeurs ne peuvent pas accéder de 2 et de 4 octets
quantités (par ex. ints et long ints) si ils sont entassés dans des
chaque-qui-chemin.

Supposons que vous avez cette structure:

struct {
    char a[3];
    short int b;
    long int c;
    char d[3];
};

Maintenant, vous pourriez penser qu'il devrait être possible de ce pack
structure en mémoire comme ceci:

+-------+-------+-------+-------+
|           a           |   b   |
+-------+-------+-------+-------+
|   b   |           c           |
+-------+-------+-------+-------+
|   c   |           d           |
+-------+-------+-------+-------+

Mais il est beaucoup, beaucoup plus facile sur le processeur, si le compilateur arrange
comme ceci:

+-------+-------+-------+
|           a           |
+-------+-------+-------+
|       b       |
+-------+-------+-------+-------+
|               c               |
+-------+-------+-------+-------+
|           d           |
+-------+-------+-------+

Dans la version compressée, remarquez comment il est au moins un peu dur pour
vous et moi, pour voir comment le b et c des champs enrouler autour? En un mot,
il est difficile pour le processeur, trop. Par conséquent, la plupart des compilateurs pad
la structure (comme si extra, champs invisibles) comme ceci:

+-------+-------+-------+-------+
|           a           | pad1  |
+-------+-------+-------+-------+
|       b       |     pad2      |
+-------+-------+-------+-------+
|               c               |
+-------+-------+-------+-------+
|           d           | pad3  |
+-------+-------+-------+-------+

Cela peut être dû à l'alignement d'octets et de rembourrage de telle manière que la structure sort pour un même nombre d'octets (ou des mots) sur votre plate-forme. Par exemple en C sur Linux, les 3 structures:

#include "stdio.h"


struct oneInt {
  int x;
};

struct twoInts {
  int x;
  int y;
};

struct someBits {
  int x:2;
  int y:6;
};


int main (int argc, char** argv) {
  printf("oneInt=%zu\n",sizeof(struct oneInt));
  printf("twoInts=%zu\n",sizeof(struct twoInts));
  printf("someBits=%zu\n",sizeof(struct someBits));
  return 0;
}

Les membres de la taille (en octets) de 4 octets (32 bits), 8 octets (2x 32 bits) et 1 octet (2+6 bits), respectivement. Le programme ci-dessus (sur Linux avec gcc) imprime les tailles 4, 8, et 4 - où la dernière structure est matelassée pour qu'il est un seul mot (4 x 8 bits des octets sur ma plate-forme 32 bits).

oneInt=4
twoInts=8
someBits=4

La taille d'une structure est plus grand que la somme de ses parties, en raison de ce qui est appelé l'emballage. Un processeur particulier a préféré la taille des données qu'il fonctionne avec. La plupart des processeurs modernes préféré de taille de 32 bits (4 octets). Accéder à la mémoire lorsque les données sont sur ce type de limite est plus efficace que des choses qui dépassent cette limite de taille.

Par exemple. Examiner la structure simple:

struct myStruct
{
   int a;
   char b;
   int c;
} data;

Si la machine est une machine 32 bits de données et est aligné sur une frontière de 32 bits, nous voyons un problème immédiat (en supposant qu'aucune structure d'alignement). Dans cet exemple, nous supposons que la structure de données commence à l'adresse 1024 (0x400 - à noter que le plus faible de 2 bits sont à zéro, de sorte que les données sont alignées par rapport à la limite de 32 bits). L'accès aux données.une fonctionneront bien parce qu'il démarre sur une frontière - 0x400. L'accès aux données.b fonctionne également très bien, car il est à l'adresse 0x404 - une autre limite de 32 bits. Mais un non alignés structure de placer des données.c à l'adresse 0x405. Les 4 octets de données.c sont à 0x405, 0x406, 0x407, 0x408. Sur une machine 32 bits, le système serait de lire les données.c pendant un cycle de la mémoire, mais seulement obtenir 3 des 4 octets (le 4e octet est sur la prochaine frontière). Ainsi, le système de aurait à faire un deuxième accès à la mémoire pour obtenir le 4e octet,

Maintenant, si au lieu de mettre des données.c à l'adresse 0x405, le compilateur collier de la structure par 3 octets et mettre les données.c à l'adresse 0x408, le système aurait besoin que de 1 cycle pour lire les données, la coupe de temps d'accès à cet élément de données de 50%. Rembourrage swaps de mémoire de l'efficacité pour l'efficacité du traitement. Étant donné que les ordinateurs peuvent avoir d'énormes quantités de mémoire (plusieurs gigaoctets), les auteurs estiment que le swap (vitesse au-dessus de la taille) est raisonnable.

Malheureusement, ce problème devient un tueur lorsque vous tentez d'envoyer des structures sur un réseau ou même écrire des données binaires dans un fichier binaire. Le rembourrage inséré entre les éléments d'une structure ou une classe qui peuvent perturber les données envoyées vers le fichier ou le réseau. Afin d'écrire du code portable (celui qui va aller à plusieurs différents compilateurs), vous aurez probablement à accéder à chaque élément de la structure séparément pour assurer le bon "emballage".

D'autre part, les différents compilateurs ont des capacités différentes pour gérer les données de la structure de l'emballage. Par exemple, dans Visual C/C++ le compilateur prend en charge la directive #pragma pack de commande. Cela vous permettra d'ajuster les données de l'emballage et de l'alignement.

Par exemple:

#pragma pack 1
struct MyStruct
{
    int a;
    char b;
    int c;
    short d;
} myData;

I = sizeof(myData);

Je devrais maintenant avoir la longueur de 11. Sans le pragma, je pourrais être n'importe quoi à partir de 11 à 14 ans (et pour certains systèmes, 32), en fonction du défaut d'emballage du compilateur.

C99 N1256 projet de norme

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

6.5.3.4 L'opérateur sizeof:

3 Lorsqu'il est appliqué à un opérande dont la structure ou le type d'union,
le résultat est le nombre total d'octets dans un tel objet,
y compris à l'intérieur et le remplissage à droite.

6.7.2.1 de la Structure et de l'union des prescripteurs:

13 ... Il y a peut être sans nom
rembourrage à l'intérieur d'une structure de l'objet, mais pas au début de son.

et:

15 Il peut être sans nom rembourrage à la fin d'une structure ou d'une union.

La nouvelle C99 souple tableau caractéristique de l' (struct S {int is[];};) peuvent aussi affecter padding:

16 Comme un cas particulier, le dernier élément d'une structure avec plus d'un nommé membre peut
ont incomplète de type tableau, ce qu'on appelle un flexible de membre du groupe. Dans la plupart des situations,
le flexible de membre du groupe est ignoré. En particulier, la taille de la structure est comme si l'
flexible membre du groupe ont été omis, à l'exception qu'il peut avoir plus de remplissage à droite de
l'omission impliquerait.

L'annexe J des Problèmes de Portabilité réitère:

Suivants sont non spécifié: ...

• La valeur des octets de remplissage lors de stocker des valeurs dans des structures ou des syndicats (6.2.6.1)

C++11 N3337 projet de norme

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf

5.3.3 Sizeof:

2 Lorsqu'il est appliqué
pour une classe, le résultat est le nombre d'octets dans un objet de cette classe, y compris toute rembourrage nécessaire pour
placer les objets de ce type dans un tableau.

9.2 les membres de la Classe:

Un pointeur vers un modèle de mise en page struct objet, convenablement converti à l'aide d'un reinterpret_cast, les points d'
membre initial (ou si le membre est un peu de champ, puis à l'unité dans laquelle il se trouve), et vice-versa. [ Note:
Il pourrait donc être sans nom rembourrage à l'intérieur d'un standard-layout struct objet, mais pas à son début,
que nécessaire afin d'obtenir l'alignement. — fin de la remarque ]

Je sais seulement assez de C++ pour comprendre la remarque 🙂

Langage C feuilles compilateur d'une certaine liberté quant à l'emplacement des éléments de structure dans la mémoire:

• la mémoire des trous peuvent apparaître entre deux composants, et après le dernier élément. C'était dû au fait que certains types d'objets sur l'ordinateur cible peut être limitée par les frontières de l'adressage
• "trous de mémoire" taille inclus dans le résultat de l'opérateur sizeof. Le sizeof seulement ne comprennent pas la taille de la baie flexible, qui est disponible en C/C++
• Certaines implémentations de la langue pour vous permettre de contrôler la disposition de la mémoire de structures à travers le réseau et les options du compilateur

Le langage C fournit l'assurance pour le programmeur d'éléments de mise en page dans la structure:

• compilateurs nécessaires pour affecter une séquence de composants augmentation des adresses de mémoire
• L'adresse du premier élément coïncide avec le début de l'adresse de la structure
• sans nom champs de bits peuvent être inclus dans la structure de l'adresse requise alignements des éléments adjacents

Problèmes liés aux éléments d'alignement:

• Différents ordinateurs de la ligne sur les bords des objets de différentes façons
• Différentes restrictions sur la largeur du champ de bits
• Ordinateurs différents sur la façon de stocker les octets dans un mot (Intel 80x86 et Motorola 68000)

Comment l'alignement des œuvres:

• Le volume occupé par la structure est calculée comme la taille de la aligné seul élément d'un tableau de ces structures. La structure doit
  fin de sorte que le premier élément de la prochaine structure n'est pas la violer les exigences d'alignement

p.s infos Plus détaillées sont disponibles ici: "Samuel P. Harbison, Guy L. Steele C Une Référence, (5.6.2 - 5.6.7)"