L'appel de fonction virtuelle de destructeur

Est-il sécuritaire ?

class Derived:  public PublicBase, private PrivateBase
{
 ... 

   ~Derived()
   {
      FunctionCall();
   }

   virtual void FunctionCall()
   {
      PrivateBase::FunctionCall();
   }
}

class PublicBase
{
   virtual ~PublicBase(){};
   virtual void FunctionCall() = 0;
}

class PrivateBase
{
   virtual ~PrivateBase(){};
   virtual void FunctionCall()
   {
    ....
   }
}


PublicBase* ptrBase = new Derived();
delete ptrBase;

Ce code crases parfois avec la propriété intellectuelle dans une mauvaise adresse.

Qui n'est pas une bonne idée d'appeler une fonction virtuelle sur le constructeur est clair pour tout le monde.

Des articles comme http://www.artima.com/cppsource/nevercall.html je comprends que le destructeur est aussi un bon endroit pour appeler une fonction virtuelle.

Ma question est "Est-ce vrai ?" J'ai testé avec VS2010 et VS2005 et PrivateBase::FunctionCall est appelé. Est un comportement indéfini ?

Vous obtenez un comportement indéterminé de la suppression d'un pointeur vers la base où le destructeur n'est pas marquée virtual. Aussi, vous devriez avoir une ambiguïté entre les deux bases, puisque les deux fonctions ont la même signature - qui êtes-vous impérieuses? OIE, postez votre code réel, celui-ci n'a même pas compiler.
Désolé pour la confusion: le code réel est trop complexe, Dérivé n'est pas un destructeur virtuel, Les classes de Base n'ont.
Une fois qu'une classe est un destructeur virtuel, tous les objets qui héritent de il virtuel destructeurs, si le code de la montre ou pas. Personnellement, je préfère tapant l' virtual mot-clé, mais il est entièrement facultatif (il en va de même pour toute autre fonction virtuelle: les remplacements de la fonction virtuelle sera virtuels, qui se sont déclarées comme telles ou non dans le code).
Essayez primordial FunctionCall dans un TooDerived : pulic Derived classe. Qui ne sera pas appelé.
-1 Ce code ne compile pas en raison du manque de points-virgules. Ce n'est pas important en soi, mais cela signifie que c'est le code. Aussi, l'exemple est incomplètes, et, sur cette base, je vais voter pour fermer.
Qui semble exagérée. "Le code réel" n'est pas l'objectif sous-jacent; l'objectif est "de code qui sont sans ambiguïté illustre bien le coeur du problème" - dont ce code n'a clairement.
une bonne référence: wiki.sei.cmu.edu/confluence/display/cplusplus/...

InformationsquelleAutor cprogrammer | 2012-08-23

c++virtual

64

Je vais aller à contre-courant ici... mais d'abord, je dois supposer que votre PublicBase destructeur est virtuel, car sinon, le Derived destructeur ne sera jamais appelé.

Il n'est généralement pas une bonne idée d'appeler une fonction virtuelle à partir d'un constructeur/destructeur

La raison pour cela est que la dynamique de l'expédition est étrange au cours de ces deux opérations. Le type réel de l'objet changements cours de construction et il changements de nouveau lors de la destruction. Quand un destructeur est en cours d'exécution, l'objet est exactement de ce type, et jamais un type qui en découlent. Répartition dynamique est en effet à tous les temps, mais le final overrider de la fonction virtuelle va changer en fonction de l'endroit dans la hiérarchie sont.

Qui est, vous ne devriez jamais s'attendre à un appel à une fonction virtuelle dans un constructeur/destructeur pour être exécuté dans n'importe quel type dérivé du type du constructeur/destructeur en cours d'exécution.

Mais

Dans votre cas particulier, la final overrider (au moins pour cette partie de la hiérarchie) est ci-dessus votre niveau. En outre, vous êtes pas à l'aide de dynamic dispatch à tous. L'appel PrivateBase::FunctionCall(); est résolu statiquement, et en fait l'équivalent d'un appel à une fonction non virtuelle. Le fait que la fonction est virtuel ou non n'a pas d'incidence sur cet appel.

Donc oui c'est bien de faire comme vous le faites, même si vous serez obligé de l'expliquer dans des revues de code, comme la plupart des gens apprennent le mantra de la règle plutôt que la raison.
- L'appel de supprimer appellera Derived::~Derived() (parce que nous avons destructeur virtuel) qui va appeler FunctionCall (lors de la destruction est de ce type: PublicBase); il faudra donc se résoudre à PublicBase::FunctionCall() qui est virtuelle pure. C'est que corect ?
- Jusqu'à l'accolade de fermeture de ~Derived, le type de l'objet est Derived (et, par extension, aussi PublicBase et PrivateBase) C'est quel que soit le type statique de l'pointeur à travers lequel vous supprimez (acquis que le destructeur de ce type est virtuel, comme c'est le cas). Lors de l'exécution de ~Derived, l'appel à PrivateBase::FunctionCall() est pas répartition dynamique, c'est un appel direct à la fonction (en raison de la qualification PrivateBase::)
- Donc, l'appel à FunctionCall dans Derived::~Derived() est résolu à Derived::FunctionCall ou PublicBase::FunctionCall (l'objet est exactement de ce type) ? Je comprends que PrivateBase::FunctionCall() n'est pas une répartition dynamique en raison de la qualification, mais cet appel est à l'étape suivante.
- Je suis un peu confus avec votre question. Lorsque delete est appelé, ~Derived sera appelée par le biais de la distribution dynamique, comme ~PublicBase est virtuel. À ce stade, l'objet est de type Derived et c'est à ce moment que le destructeur corps est exécutée et PrivateBase::FunctionCall est appelé.
- est dynamique de l'expédition, mais par l'intermédiaire de la VFT de la classe de l'exécution en cours de constructeur, pas la VFT de this.
- est statique de l'expédition, qualifié appels de fonction ne jamais utiliser de répartition dynamique.
InformationsquelleAutor David Rodríguez - dribeas
20

Est-il sécuritaire ?

Oui. L'appel d'une fonction virtuelle à partir d'un constructeur ou un destructeur, les dépêches de la fonction comme si l'objet est de type dynamique ont été actuellement en cours de construction ou de destruction. Dans ce cas, il est appelé à partir du destructeur de Derived, il est donc envoyé à Derived::FunctionCall (ce qui, dans votre cas, les appels PrivateBase::FunctionCall non virtuellement). Tout cela est bien définie.

C'est "pas une bonne idée" pour appeler des fonctions virtuelles à partir d'un constructeur ou un destructeur pour trois raisons:
- Il va provoquer un comportement inattendu si vous appelez à partir d'une classe de base et (à tort) s'attendent à être distribué à une substitution dans une classe dérivée;
- Il va provoquer un comportement indéterminé si elle est virtuelle pure;
- Vous allez continuer à avoir à expliquer votre décision de gens qui croient que c'est toujours mal à cela.
InformationsquelleAutor Mike Seymour
2

En général, il n'est pas une bonne idée d'appeler une fonction virtuelle, sauf si l'objet de la classe il peut être distribué (par exemple, le "plein" de l'objet de la plupart de la classe dérivée) est entièrement construit. Et ce n'est pas le cas
- jusqu'à ce que tous les constructeurs de terminer l'exécution
- après tout destructeur fin de l'exécution de
- Il y a virtuel destructeurs dans le code, de sorte que le premier destructeur appelé est Dérivé qui appelle une fonction de base. La deuxième condition est de répondre ?
- Si le code a été correctement écrit (virtuel dtors, sans ambiguïté primordial de baseclass méthodes), les balles ne s'applique pas et le code devrait être l'un des rares cas qui est "bien". Les problèmes proviennent de l'appel des fonctions virtuelles à partir de la de la classe de base ctor / dtor.
- Non, le "plein" de l'objet n'est pas impliqué dans le constructeur et le destructeur de la sémantique. La fonction virtuelle appels de constructeurs et destructeurs aller à la version de la fonction pour le type dont le constructeur ou le destructeur est en cours d'exécution, pas nécessairement la plus type dérivé.
- vous êtes en droit-le type de l'objet (y compris ses vtable) devrait changer au cours de la construction/destruction, comme l'a souligné David. Je me souviens d'avoir des problèmes avec qui il y a quelques temps mais -- mais peut-être que le vieux compilateur a été brisé, à la fois moderne gcc et clang obtenir la droite (je viens de vérifier pour être sûr).
InformationsquelleAutor Grzegorz Herman
1

C'est une très mauvaise idée selon scott: lien

C'est ce que j'ai compilé et exécuté pour m'aider à acquérir une meilleure compréhension du processus de destruction, vous pouvez également trouver utile
```
#include <iostream>
using namespace std;


class A {
public:
  virtual void method() {
    cout << "A::method" << endl;
  }

  void otherMethod() {
    method();
  }

  virtual ~A() {
    cout << "A::destructor" << endl;
    otherMethod();
  }

};

class B : public A {
public:
  virtual void method() {
    cout << "B::method" << endl;
  }

  virtual ~B() {
    cout << "B::destructor" << endl;
  }
};

int main() {

  A* a = new B();

  a->method();

  delete a;

}
```
- Non, les membres de données ne sont pas détruits jusqu'à ce que après le corps du destructeur. Il n'y a pas de danger dans l'accès à ces membres de l'destructeur, même par le biais d'un appel de fonction, et même par le biais d'un appel virtuel.
- J'étais sous l'impression que le corps de ~Derived a été exécuté avant l'appel à ~Base.
- c'est le droit. Le corps de ~Derived s'exécute en premier, puis les membres de données de Derived sont détruits, alors ~Base est exécutée.
- soooo .... si Base appels Derived.Somthing() ensuite, nous avons de gros problèmes depuis Derived a déjà appelé delete important_pointer sûrement
- si ~Base() appelle une fonction virtuelle à l'appel va à la version définie pour ~Base(). Il n'appelle pas de versions dérivées.
- Je comprends mon erreur, va éditer la question
- laissez-nous continuer cette discussion dans le chat
InformationsquelleAutor sji

Vous devez vous connecter pour publier un commentaire.