Calling virtual function from destructor

2019-01-04 11:55发布

Is this safe ?

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;

This code crases sometimes with IP in a bad address.

That is not a good idea to call a virtual function on constructor is clear for everyone.

From articles like http://www.artima.com/cppsource/nevercall.html I understand that destructor is also a not so good place to call a virtual function.

My question is "Is this true ?" I have tested with VS2010 and VS2005 and PrivateBase::FunctionCall is called. Is undefined behavior ?

标签: c++ virtual
4条回答
男人必须洒脱
2楼-- · 2019-01-04 12:23

In general, it is not a good idea to call a virtual function, unless the object of the class it might get dispatched to (i.e., the "full" object of the most-derived class) is fully-constructed. And this is not the case

  • until all the constructors finish execution
  • after any destructor finishes execution
查看更多
你好瞎i
3楼-- · 2019-01-04 12:34

Is this safe ?

Yes. Calling a virtual function from a constructor or destructor dispatches the function as if the object's dynamic type were that currently being constructed or destroyed. In this case, it's called from the destructor of Derived, so it's dispatched to Derived::FunctionCall (which, in your case, calls PrivateBase::FunctionCall non-virtually). All of this is well defined.

It's "not a good idea" to call virtual functions from a constructor or destructor for three reasons:

  • It will cause unexpected behaviour if you call it from a base class and (erroneously) expect it to be dispatched to an override in a derived class;
  • It will cause undefined behaviour if it is pure virtual;
  • You'll keep having to explain your decision to people who believe that it's always wrong to that.
查看更多
走好不送
4楼-- · 2019-01-04 12:34

It is a very bad idea according to scott: link

This is what i have compiled and run to help myself gain a better understanding of the destruction process, you might also find it helpful

#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;

}
查看更多
【Aperson】
5楼-- · 2019-01-04 12:41

I am going to go against the flow here... but first, I must assume that your PublicBase destructor is virtual, as otherwise the Derived destructor will never be called.

It is usually not a good idea to call a virtual function from a constructor/destructor

The reason for this is that dynamic dispatch is strange during these two operations. The actual type of the object changes during construction and it changes again during destruction. When a destructor is being executed, the object is of exactly that type, and never a type derived from it. Dynamic dispatch is in effect at all time, but the final overrider of the virtual function will change depending where in the hierarchy you are.

That is, you should never expect a call to a virtual function in a constructor/destructor to be executed in any type that derived from the type of the constructor/destructor being executed.

But

In your particular case, the final overrider (at least for this part of the hierarchy) is above your level. Moreover, you are not using dynamic dispatch at all. The call PrivateBase::FunctionCall(); is statically resolved, and effectively equivalent to a call to any non-virtual function. The fact that the function is virtual or not does not affect this call.

So yes it is fine doing as you are doing, although you will be forced to explain this in code reviews as most people learn the mantra of the rule rather than the reason for it.

查看更多
登录 后发表回答