reinterpret_cast création d'un objet trivialement constructible par défaut

Question

Référence cpp † déclare que :

Les objets avec des constructeurs par défaut triviaux peuvent être créés en utilisant la fonction reinterpret_cast sur n'importe quelle mémoire alignée de manière appropriée, par exemple sur une mémoire allouée avec l'option std::malloc .

Cela implique que le code suivant est bien défini :

struct X { int x; };
alignas(X) char buffer[sizeof(X)];    // (A)
reinterpret_cast<X*>(buffer)->x = 42; // (B)

Trois questions suivent :

1. Cette citation est-elle correcte ?
2. Si oui, à quel moment la durée de vie de la X commencer ? Si en ligne (B) Est-ce que c'est le plâtre lui-même qui est considéré comme un stockage d'acquisition ? Si c'est en ligne (A) et s'il y avait une branche entre (A) y (B) qui construirait conditionnellement un X ou une autre capsule, Y ?
3. Y a-t-il des changements entre C++11 et C++1z à cet égard ?

---

† Notez qu'il s'agit d'un ancien lien. Le libellé a été modifié en réponse à cette question. Il se lit maintenant comme suit :

Contrairement au C, cependant, les objets avec des constructeurs par défaut triviaux ne peuvent pas être créés en réinterprétant simplement un stockage correctement aligné, tel que la mémoire allouée avec std::malloc : placement-new est nécessaire pour introduire formellement un nouvel objet et éviter un comportement potentiel non défini.

Answer 1

Il n'y a pas X objet, vivant ou non, donc prétendre qu'il en existe un entraîne un comportement non défini.

[intro.objet]/1 énonce de manière exhaustive le moment où les objets sont créés :

Un site objet est créé par une définition ([basic.def]), par un fichier nouvelle-expression ([expr.new]), lorsque l'on change implicitement le membre actif membre actif d'une union ([class.union]), ou quand un objet temporaire est temporaire ([conv.rval], [class.temporary]).

Avec l'adoption de P0137R1 La définition du terme "objet" se trouve dans ce paragraphe.

Existe-t-il une définition d'un X objet ? Non. Y a-t-il un nouvelle-expression ? Non. Y a-t-il une union ? Non. Y a-t-il une construction de langage dans votre code qui crée un objet temporaire X objet ? Non.

Ce que [basic.life] dit sur la durée de vie d'un objet avec une initialisation vide n'est pas pertinent. Pour que cela s'applique, vous devez avoir un objet en premier lieu. Vous n'en avez pas.

C++11 a à peu près le même paragraphe, mais ne l'utilise pas comme définition d'"objet". Néanmoins, l'interprétation est la même. L'autre interprétation - traiter [basic.life] comme créant un objet dès qu'un stockage approprié est obtenu - signifie que vous créez des objets de Schrödinger. * ce qui contredit N3337 [intro.objet]/6 :

Deux objets qui ne sont pas des champs de bits peuvent avoir la même adresse si un est un sous-objet de l'autre, ou si au moins l'un d'entre eux est un sous-objet de classe de base de taille nulle et que l'autre est un objet de classe de base. sous-objet de taille nulle et qu'ils sont de types différents ; sinon ils doivent avoir des adresses distinctes.

---

_{^*Stockage avec l'alignement et la taille appropriés pour un type <code>T</code> est par définition un stockage avec l'alignement et la taille appropriés pour <em>tout autre type </em>dont les exigences de taille et d'alignement sont égales ou inférieures à celles des <code>T</code> . Ainsi, cette interprétation signifie que l'obtention du stockage crée simultanément un ensemble infini d'objets de types différents dans ledit stockage, ayant tous la même adresse.}

Answer 2

Sur la base de p0593r6 Je pense que le code figurant dans le PO est valable et doit être bien défini. Le nouveau libellé, basé sur le DR appliqué rétroactivement à toutes les versions à partir de C++98 inclus, permet de création implicite d'objets pour autant que l'objet créé soit bien défini ( tautologie est parfois le secours pour les définitions compliquées), voir § 6.7.2.11 Modèle d'objet [intro.objet] ) :

objets créés implicitement dont l'adresse est celle du début de la région de de la région de stockage, et produire une valeur de pointeur qui pointe sur cet objet, si cette valeur permet au programme d'avoir un comportement défini. comportement [...]

Voir aussi : https://stackoverflow.com/a/61999151/2085626

Answer 3

Cette analyse est basée sur n4567, et utilise les numéros de section de celui-ci.

§5.2.10/7 : Quand une valeur prvalue v de type pointeur d'objet est converti en pointeur d'objet de type "pointeur vers cv T", le résultat est static_cast<cv T*>(static_cast<cv void*>(v)) .

Donc, dans ce cas, le reinterpret_cast<X*>(buffer) est la même chose que static_cast<X *>(static_cast<void *>(buffer)) . Cela nous amène à examiner les parties pertinentes concernant static_cast :

§5.2.9/13 : Une valeur prval de type "pointeur vers cv1 void" peut être converti en une valeur prval de type "pointeur vers cv2 T", où T est un type d'objet et cv2 est identique à, ou supérieur à, cv-qualification, cv1 . La valeur du pointeur nul est convertie en la valeur du pointeur nul du type de destination. Si la valeur du pointeur d'origine représente l'adresse A d'un octet en mémoire et A satisfait à l'exigence d'alignement de T alors la valeur du pointeur résultant représente la même adresse que la valeur du pointeur d'origine, c'est-à-dire, A .

Je crois que c'est suffisant pour dire que la citation originale est en quelque sorte correcte - cette conversion donne des résultats définis.

Quant à la durée de vie, elle dépend de ce dont vous parlez. Le cast crée un nouvel objet de type pointeur - un temporaire, dont la durée de vie commence à la ligne où se trouve le cast et se termine lorsqu'il sort de la portée. Si vous avez deux conversions différentes qui se produisent de manière conditionnelle, chaque pointeur a une durée de vie qui commence à l'emplacement du cast qui l'a créé.

Ni l'un ni l'autre n'affecte la durée de vie de l'objet fournissant le stockage sous-jacent, qui est toujours buffer et a exactement la même durée de vie, que vous créiez ou non un pointeur (de type identique ou converti) vers ce stockage.