sécurité de static_cast à pointer-à-classe dérivée de la base destructor

Question

Ceci est une variante des questions Downcasting using the Static_cast in C++ et Safety of invalid downcast using static_cast (or reinterpret_cast) for inheritance without added members

Je ne suis pas clair sur l'expression dans la norme « B qui est en fait un sous-objet d'un objet de type D, le pointeur résultant pointe vers l'objet englobant de type D "par rapport au comportement dans ~ B. Si vous lancez D dans ~ B, est-ce encore un sous-objet à ce moment-là? L'exemple simple suivant montre la question:

void f(B* b); 

class B { 
public: 
    B() {} 
    ~B() { f(this); } 
}; 

class D : public B { public: D() {} }; 

std::set<D*> ds; 

void f(B* b) { 
    D* d = static_cast<D*>(b); // UB or subobject of type D? 
    ds.erase(d); 
} 

Je sais que le casting est une porte ouverte à la catastrophe, et de faire quelque chose comme ça du dtor est une mauvaise idée, mais une revendication collègue « Le code est valide et fonctionne correctement.Cette distribution est parfaitement valide.Le commentaire indique clairement qu'il ne devrait pas être déréférencé ". J'ai souligné que la distribution est inutile et nous devrions préférer la protection fournie par le système de type aux commentaires. Le plus triste, c'est qu'il est l'un des principaux développeurs/développeurs et un "expert" supposé C++. Puis-je lui dire que la distribution est UB?

Answer 1

[expr.static.cast]/p11:

Un prvalue de type « pointeur vers CV1B, » où B est un type de classe, peut être converti en un prvalue de type « pointeur vers CV2D », où D est un dérivé classe (article 10) de B, si une conversion de type valide de « pointeur vers D » à « pointeur vers B » existe (4.10), CV2 est le même cv-qualification, ou plus cv-qualification que, CV1 et B est ni une classe de base virtuelle de D ni une classe de base d'une base virtuelle classe de D. La valeur null pointeur (4.10) est convertie à la valeur de pointeur null du type de destination. Si le prvalue de de type « pointeur vers CV1B » points à un B qui est en fait un sous-objet d'un objet de type D, les points de pointeur résultant de l'objet enfermant de type D. Sinon, le comportement n'est pas défini.

La question est donc de savoir si, au moment de la static_cast, le pointeur indique en fait à « une B qui est en fait un sous-objet d'un objet de type D ». Si oui, il n'y a pas d'UB; sinon, le comportement est indéfini que le pointeur résultant soit déréférencé ou non.

[class.dtor]/p15 dit que (Souligné par l'auteur)

Une fois qu'un destructor est invoqué pour un objet, l'objet ne existe

et [base. vie]/p1 dit que

La durée de vie d'un objet de type T se termine lorsque:

• si T est un type de classe avec un destructor non négligeable (12,4), le début d'appel destructor, ou
• [...]

De là, alors, la D La durée de vie de l'objet a pris fin dès que son destructeur est appelé, et certainement au moment où le destructeur de B a commencé à s'exécuter - ce qui est après que le corps destructeur de D a terminé son exécution. À ce stade, il n'y a pas "objet de type D" à gauche que ce B peut être un sous-objet de - il "n'existe plus". Ainsi, vous avez UB.

Clang avec UBsan sera report an error sur ce code si B est rendu polymorphe (donné une fonction virtuelle), qui prend en charge cette lecture.

Answer 2

Vous devez absolument lui dire que c'est UB! !

Pourquoi?

12,4/7: bases et les membres sont détruits dans l'ordre inverse de l'achèvement de leur constructeur Les objets sont detroyed dans l'ordre inverse de leur constuction.

12.6.2/10: Première (...) classes de base virtuelles sont initialisés (...) puis, classes de base directes sont initialisés

Alors, quand un destructing D, d'abord le D Les membres sont détruits, puis le sous-objet D, et alors seulement B sera détruit.

Ce code fait en sorte que f() est appelée lorsque l'objet B est détruit:

~B() { f(this); } 

Alors, quand un objet D est détruit, le D suboject est détruit d'abord, puis ~ B() est exécutée, appeler f().

En f() vous lancez le pointeur sur un B comme pointeur vers un D. Ce est UB:

3,8/5: (...) après la durée de vie d'un objet a pris fin et avant que le stockage que l'objet occupé est réutilisé ou libéré, tout pointeur qui fait référence à l'emplacement de stockage où l'objet sera ou a été localisé peut être utilisé mais seulement de façon limitée. (...) Le programme a comportement indéfini si le pointeur est utilisé pour accéder à un membre de données non statique ou appeler une fonction membre non statique de l'objet , ou (...) le pointeur est utilisé comme l'opérande d'un static_cast.

Answer 3

Apparemment, votre collègue a l'impression que tant que vous ne dérérez pas un pointeur invalide, tout va bien. Il est incorrect.

L'évaluation simple d'un tel pointeur a un comportement indéfini. Ce code est évidemment cassé.