Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

virtual method calls in constructors and destructors

25 views
Skip to first unread message

Lynn McGuire

unread,
Mar 18, 2016, 6:56:00 PM3/18/16
to
Well, I just got educated on virtual method calls in constructors and destructors. None will be executed as you think so that
functionality will not work. It would be nice if the compiler would warn a person.
http://stackoverflow.com/questions/12092933/calling-virtual-function-from-destructor
and
http://stackoverflow.com/questions/9114982/calling-virtual-method-from-destructor-workaround

I devised a way to get around the virtual method call in the constructor by adding an argument to my base constructor which fixed
that issue. But getting around the virtual method call in my destructor is painful.

Lynn

Paavo Helde

unread,
Mar 18, 2016, 7:32:38 PM3/18/16
to
On 19.03.2016 0:55, Lynn McGuire wrote:
> Well, I just got educated on virtual method calls in constructors and
> destructors. None will be executed as you think so that functionality
> will not work. It would be nice if the compiler would warn a person.

In C++ the virtual method call from ctor/dtor works exactly like I am
expecting (unlike in some other language). It would not make sense to
call a function on an object which is not yet constructed or is already
destroyed, would it?

The point is, both the construction and destruction already behave
pretty polymorphically, all the inheritance chain is traversed and all
the ctors/dtors called on the way. That's about the same behavior which
can be achieved by virtual functions, so there should be no real need to
call virtual functions from ctors/dtors.

Alf P. Steinbach

unread,
Mar 19, 2016, 2:01:15 AM3/19/16
to
On 18.03.2016 23:55, Lynn McGuire wrote:
> Well, I just got educated on virtual method calls in constructors and
> destructors. None will be executed as you think so that functionality
> will not work.

On the contrary, in C++ virtual functions are executed in the same way
from constructors and destructors as from elsewhere.

And unlike Java and C#, in C++ it's safe.

So, generally, it Just Works™, in C++.


> It would be nice if the compiler would warn a person.
>
> http://stackoverflow.com/questions/12092933/calling-virtual-function-from-destructor

That answer is a bit of FUD: Fear, Uncertainty and Doubt. Silly in a
technical context. But good for harvesting some rep points at SO, which,
after all, is the absolutely greatest extant Herb Schildt area on the
Internets :)


> and
>
> http://stackoverflow.com/questions/9114982/calling-virtual-method-from-destructor-workaround

Uhm, too long didn't read, but it's a typical X/Y-question: wanting to
do X, envisioning solution Y, finding that Y is impossible or
impractical (usually complete nonsense), asking about Y only.


> I devised a way to get around the virtual method call in the constructor
> by adding an argument to my base constructor which fixed that issue.

I guess you want to do derived class specific initialization WITHIN the
base class constructor, e.g. creating a Button API-level widget in the
constructor of a general Widget base class constructor.

Hurray, the FAQ is there for you!

https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctor-idiom

Re terminology: AFAIK the “Dynamic Binding During Initialization” term
is just something Marshall Cline invented, it wasn't there in my
original FAQ suggestion, and I've never seen it anywhere else.


> But getting around the virtual method call in my destructor is painful.

That's the Y of an X/Y problem. ;-)

What is the /real/ problem, that you try to solve that way?


Cheers & hth.,

- Alf

Bo Persson

unread,
Mar 19, 2016, 6:35:58 AM3/19/16
to
It works exactly the way it was designed.

When the base class destructor runs, the derived class' destructor has
already been executed, and that part of the object is gone. Calling a
function of the derived class is the same as calling a function of a
deleted object.

C++ protects you from that. A good thing!

To me, the very obvious "workaround" is for the derived class'
destructor to call its own function as needed. That way the base class
doesn't have to.


Bo Persson


0 new messages