GNU GCC (g ++): Pourquoi génère-t-il plusieurs dtors?

Environnement de développement: GNU GCC (g ++) 4.1.2

Alors que j'essaie d'étudier comment augmenter la `` couverture du code - en particulier la couverture des fonctions '' dans les tests unitaires, j'ai constaté qu'une partie de la classe dtor semble être générée plusieurs fois. Certains d'entre vous ont-ils une idée de pourquoi, s'il vous plaît?

J'ai essayé et observé ce que j'ai mentionné ci-dessus en utilisant le code suivant.

Dans "test.h"

class BaseClass
{
public:
    ~BaseClass();
    void someMethod();
};

class DerivedClass : public BaseClass
{
public:
    virtual ~DerivedClass();
    virtual void someMethod();
};

Dans "test.cpp"

#include <iostream>
#include "test.h"

BaseClass::~BaseClass()
{
    std::cout << "BaseClass dtor invoked" << std::endl;
}

void BaseClass::someMethod()
{
    std::cout << "Base class method" << std::endl;
}

DerivedClass::~DerivedClass()
{
    std::cout << "DerivedClass dtor invoked" << std::endl;
}

void DerivedClass::someMethod()
{
    std::cout << "Derived class method" << std::endl;
}

int main()
{
    BaseClass* b_ptr = new BaseClass;
    b_ptr->someMethod();
    delete b_ptr;
}

Quand j'ai construit le code ci-dessus (g ++ test.cpp -o test) et que j'ai vu le type de symboles générés comme suit,

nm - test de démangle

Je pouvais voir la sortie suivante.

==== following is partial output ====
08048816 T DerivedClass::someMethod()
08048922 T DerivedClass::~DerivedClass()
080489aa T DerivedClass::~DerivedClass()
08048a32 T DerivedClass::~DerivedClass()
08048842 T BaseClass::someMethod()
0804886e T BaseClass::~BaseClass()
080488f6 T BaseClass::~BaseClass()

Mes questions sont les suivantes.

1) Pourquoi plusieurs dtors ont-ils été générés (BaseClass - 2, DerivedClass - 3)?

2) Quelle est la différence entre ces dtors? Comment ces multiples détecteurs seront-ils utilisés de manière sélective?

J'ai maintenant le sentiment que pour atteindre une couverture de fonctions à 100% pour le projet C ++, nous aurions besoin de comprendre cela afin que je puisse invoquer tous ces dtors dans mes tests unitaires.

J'apprécierais beaucoup si quelqu'un pouvait me donner la réponse sur ce qui précède.

Tout d'abord, les objectifs de ces fonctions sont décrits dans l' ABI Itanium C ++ ; voir les définitions sous "destructeur d'objet de base", "destructeur d'objet complet" et "suppression du destructeur". La correspondance avec les noms mutilés est donnée en 5.1.4.

Fondamentalement:

• D2 est le "destructeur d'objet de base". Il détruit l'objet lui-même, ainsi que les membres de données et les classes de base non virtuelles.
• D1 est le "destructeur d'objets complet". Il détruit en outre les classes de base virtuelles.
• D0 est le "destructeur d'objet de suppression". Il fait tout ce que fait le destructeur d'objets complet, en plus d'appeler operator deleteà libérer la mémoire.

Si vous n'avez pas de classes de base virtuelles, D2 et D1 sont identiques; GCC, à des niveaux d'optimisation suffisants, alias les symboles sur le même code pour les deux.

Il existe généralement deux variantes du constructeur ( non-responsable / responsable ) et trois du destructeur ( suppression non-responsable / responsable / responsable ).

Les ctor et dtor non en charge sont utilisés lors de la gestion d'un objet d'une classe qui hérite d'une autre classe à l'aide du virtualmot - clé, lorsque l'objet n'est pas l'objet complet (donc l'objet actuel n'est "pas chargé" de la construction ou de la destruction l'objet de base virtuel). Ce ctor reçoit un pointeur vers l'objet de base virtuel et le stocke.

Le en charge sont pour tous les autres cas, par exemple , s'il n'y a pas d' héritage virtuel impliqué cteur et dtors; si la classe a un destructeur virtuel, le pointeur dtor de suppression en charge va dans le slot vtable, tandis qu'un scope qui connaît le type dynamique de l'objet (c'est-à-dire pour les objets avec une durée de stockage automatique ou statique) utilisera le dtor en charge (car cette mémoire ne doit pas être libérée).

Exemple de code:

struct foo {
    foo(int);
    virtual ~foo(void);
    int bar;
};

struct baz : virtual foo {
    baz(void);
    virtual ~baz(void);
};

struct quux : baz {
    quux(void);
    virtual ~quux(void);
};

foo::foo(int i) { bar = i; }
foo::~foo(void) { return; }

baz::baz(void) : foo(1) { return; }
baz::~baz(void) { return; }

quux::quux(void) : foo(2), baz() { return; }
quux::~quux(void) { return; }

baz b1;
std::auto_ptr<foo> b2(new baz);
quux q1;
std::auto_ptr<foo> q2(new quux);

Résultats:

• L'entrée de dtor dans chacune des vtables pour foo, bazet quuxpoint respectif de suppression en charge dtor.
• b1et b2sont construits par le baz() responsable , qui appelle le foo(1) responsable
• q1et q2sont construits par le quux() responsable , qui tombe foo(2) en charge et baz() non en charge avec un pointeur vers l' fooobjet qu'il a construit précédemment
• q2est détruit par ~auto_ptr() in-charge , qui appelle le dtor virtuel ~quux() en charge la suppression , qui appelle ~baz() non-responsable , ~foo() responsable et operator delete.
• q1est détruit par le ~quux() responsable , qui appelle ~baz() non-responsable et ~foo() responsable
• b2est détruit par le ~auto_ptr() responsable , qui appelle le dtor virtuel ~baz() en charge la suppression , qui appelle le ~foo() responsable etoperator delete
• b1est détruit par le ~baz() responsable , qui appelle le ~foo() responsable

Toute personne dérivant de quuxutiliserait son ctor et dtor non-en charge et prendrait la responsabilité de créer l' fooobjet.

En principe, la variante sans charge n'est jamais nécessaire pour une classe qui n'a pas de bases virtuelles; dans ce cas, la variante en charge est alors parfois appelée unifiée , et / ou les symboles à la fois en charge et non en charge sont aliasés sur une seule implémentation.