Ctor Initializer: l'auto-initialisation provoque un crash?

Question

J'ai eu du mal à déboguer un crash sur la production. Je voulais juste confirmer avec les gens ici la sémantique. Nous avons une classe comme ...

class Test { 
public: 
    Test() 
    { 
    // members initialized ... 
    m_str = m_str; 
    } 
    ~Test() {} 
private: 
    // other members ... 
    std::string m_str; 
}; 

Quelqu'un a modifié l'initialisation d'utiliser des listes d'initialisation-ctor qui est raisonnablement correct dans notre sémantique de code. L'ordre d'initialisation et leur valeur initiale est correcte entre autres. Donc la classe ressemble à ...

class Test { 
public: 
    Test() 
    : /*other inits ,,, */ m_str(m_str) 
    { 
    } 
    ~Test() {} 
private: 
    // other members ... 
    std::string m_str; 
}; 

Mais le code a soudainement commencé à planter! J'ai isolé la longue liste d'inits à ce morceau de code m_str(m_str). Je l'ai confirmé via link text.

Faut-il tomber en panne? Que dit la norme à ce sujet? (Est-ce un comportement indéfini?)

Answer 1

Le premier constructeur est équivalent à

Test() 
    : m_str() 
    { 
    // members initialized ... 
    m_str = m_str; 
    } 

qui est, au moment où vous arrivez à la mission dans le constructeur, m_stra déjà été initialisé implicitement à une chaîne vide. Ainsi, l'affectation à soi-même, bien que totalement dénuée de sens et superflu, ne pose aucun problème (puisque std::string::operator=(), comme tout opérateur d'assignation bien écrit devrait, vérifie l'auto-affectation et ne fait rien dans ce cas).

Cependant, dans le deuxième constructeur, vous essayez d'initialiser m_str avec lui-même dans la liste des initialiseur - à quel point il est pas encore initialisé. Le résultat est donc un comportement indéfini.

Mise à jour: Pour les types primitifs, cela est encore un comportement non défini (résultant dans un champ avec la valeur des déchets), mais il ne tombe pas en panne (en général - voir les commentaires ci-dessous pour les exceptions) parce que les types primitifs est, par définition constructeurs , destructeurs et ne contiennent aucun pointeur vers d'autres objets.

La même chose est vraie pour tout type qui ne contient pas de membres de pointeur avec la sémantique de propriété. std::string est démontré comme n'étant pas l'un de ceux-ci :-)

Answer 2

m_str est construit dans la liste d'initialisation. Par conséquent, au moment où vous l'attribuez à lui-même, il n'est pas entièrement construit. Par conséquent, un comportement indéfini.

(Qu'est-ce que l'auto-affectation censé faire de toute façon?)

Answer 3

comportement non défini ne doit pas conduire à un accident - il peut faire à peu près tout, de continuer à travailler comme s'il n'y avait pas problème du tout, de s'écraser immédiatement, de faire quelque chose de vraiment étrange qui provoque des problèmes apparemment sans rapport plus tard. La revendication canonique est que cela fait "voler les démons de votre nez" (aka, "provoque des démons nasaux"). À un moment donné, l'inventeur de la phase avait un site Web (plutôt cool) racontant la guerre nucléaire qui a commencé à partir de quelqu'un causant un comportement indéfini dans le "DeathStation 9000".

Edit: Le libellé exact de la norme est (§: 1.3.12):

1.3.12 comportement non défini [defns.undefined]

comportement, comme pourraient résulter d'une utilisation de une construction de programme erronée ou des données erronées, pour lesquelles cette Norme internationale n'impose aucune exigence. Un comportement indéfini peut également être attendu lorsque cette norme internationale omet la description de toute définition explicite du comportement. [Note: le comportement non défini va de l'ignorance complète de la situation avec des résultats imprévisibles à la traduction ou à l'exécution de programme de façon documentée caractéristique de l'environnement (avec ou sans l'émission d'un message de diagnostic), à la fin d'une traduction ou exécution (avec l'émission d'un message de diagnostic ).

Answer 4

Ceci est la même différence entre

std::string str; 
str = str; 

et

std::string str(str); 

Les travaux antérieurs (bien que ce soit un non-sens), ce dernier n'a pas, car il essaie de copier-construction un objet d'un objet non encore construit.

Bien sûr, la voie à suivre serait

Test() : m_str() {} 

Answer 5

L'initialisation d'origine par affectation est complètement superflu.

Cela n'a causé aucun dommage, hormis le gaspillage des cycles du processeur, car au moment de l'affectation, le membre m_str avait déjà été initialisé, par défaut.

Dans le deuxième extrait de code, l'initialisation par défaut est substituée pour utiliser le membre non encore initialisé pour s'initialiser. C'est un comportement indéfini. Et c'est complètement inutile: il suffit de supprimer cela (et ne pas réintroduire le time-waster d'origine, juste, supprimer).

En augmentant le niveau d'avertissement de votre compilateur, vous pourriez être en mesure d'obtenir des avertissements à propos de ce code trivial trivial similaire.

Malheureusement, le problème que vous rencontrez n'est pas technique, c'est beaucoup plus fondamental. C'est comme si un travailleur dans une usine automobile posait une question sur les roues carrées qu'ils mettent sur la nouvelle marque de voiture. Ensuite, le problème n'est pas que les roues carrées ne fonctionnent pas, c'est que beaucoup d'ingénieurs et de managers ont été impliqués dans la décision d'utiliser les jantes carrées fantaisie et aucun d'entre eux ne s'y est opposé - certains d'entre eux ne l'ont pas fait Je comprends que les roues carrées ne fonctionnent pas, mais la plupart d'entre elles, je suppose, avaient simplement peur de dire de quoi elles étaient sûres à 100%. C'est donc probablement un problème de gestion. Je suis désolé, mais je ne connais pas de solution pour cela ...