47 votes

Les octets de remplissage d'un type de POD sont-ils copiés?

Supposons que j'ai un type POD comme ceci:

struct A {
    char a;
    int b;
};

Sur mon système, sizeof(A) == 8, même si sizeof(char) == 1 et sizeof(b) == 4. Cela signifie que la structure de données a 3 octets inutilisés.

Maintenant, supposons que nous ne

A x = ...;
A y =x;

Question:

Est-il garanti que tous les 8 octets de x et y sera identique, même ceux 3 inutilisés?

De manière équivalente, si je transfert le sous-jacent octets de certains A des objets à un autre programme qui ne permet pas d'en comprendre la signification ou de la structure, et les traite comme un tableau de 8 octets, peut que d'autres programmes en toute sécurité de comparer les deux As pour l'égalité?

Remarque: Dans une expérience avec gcc 7, il apparaît que ces octets ne sont copiés. Je voudrais savoir si cela est garanti.

43voto

Baum mit Augen Points 3571

Le constructeur de copie / déplacement défini implicitement pour une classe X non syndiquée effectue une copie / un déplacement membre par membre de ses bases et de ses membres.

12.8 / 15 [class.copy] dans N4141

Le motif de bits dans les octets de remplissage est donc autorisé à différer.

7voto

Tristan Brindle Points 5234

Ce n'est pas autorisée, mais cppreference entrée pour l » std::memcmp suggère que les octets de remplissage peuvent varier:

memcmp() entre deux objets de type struct{char c; int n;} comparera les octets de remplissage dont les valeurs peuvent différer lorsque les valeurs de c et n sont identiques

6voto

Massimiliano Janes Points 5021

étant donné que vous avez demandé à propos d'un type POD ( donc y compris les syndicats ), il convient de mentionner que, selon [la classe.copier]

La implicitement défini par copier/déplacer constructeur pour une union X copies de la représentation d'objet (6.9) de X

que pour trivialement copiable types comprennent le remplissage des bits ainsi. Aussi, il pourrait être juste une question de remplacement d'Un avec

union A{ struct {
    char a;
    int b;
}; };

(en fait, les utilisations ci-dessus non standard anonyme struct, mais vous obtenez le point ... )

4voto

Jodocus Points 5413

Pour répondre à votre deuxième question:

De manière équivalente, si je transfert le sous-jacent octets de certains objets à un autre programme qui ne permet pas d'en comprendre la signification ou de la structure, et les traite comme un tableau de 8 octets, peut que d'autres programmes en toute sécurité de comparer les deux pour l'égalité?

Comme un objet de votre type peut contenir des octets de remplissage, un autre programme ne peut pas comparer deux objets pour l'égalité:

Sachant que les bits des octets qui font l'objet de la sémantique est la clé pour la définition de sa valeur de représentation. Toutefois, dans ce scénario, le programme cible ne connaît que la représentation d'objet, c'est à dire la séquence d' octets représentant un objet en mémoire, y compris les octets de remplissage. Une fonction memcmp ne peut comparer ces objets dont la valeur de la représentation est identique à son objet la représentation d'une manière significative. Si vous l'utiliser pour comparer des objets de valeur-sage, même si ils ont de la marge, il peut ne pas donner les résultats de la droite comme on ne peut pas dire les bits dans la représentation des objets ne sont pas pertinents pour la valeur des représentations de deux objets à l'égalité.

Voir http://en.cppreference.com/w/cpp/language/object

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X