|
Boost : |
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2008-05-03 15:50:23
Simonson, Lucanus J wrote:
> Hartmut wrote:
>> What's the problem with making the destructor virtual in the first
> place?
>> Since the class already has other virtual functions this won't generate
> any
>> (significant) additional overhead (the only thing what's added is
> another
>> function pointer to the already existing virtual function table, barely
>> something to worry about).
>
> This is not true. In this case, the destructor is a no-op. Virtual
> functions incur significant overhead over non-virtual functions in the
> case that the non-virtual would be inlined, where-as the virtual must
> have a symbol for the pointer in the virtual function table to point to,
> and cannot be called inline unless the exact type is known at compile
> time (defeating the purpose of polymorphism.)
Do you realize that you just made an argument why it is important for
the destructor to be virtual ?
If the compiler doesn't know the exact type (and thus can't inline the
call), there is a serious risk that any derived destructor might need to
be executed, but the compiler doesn't know that (and neither does the
runtime, as there is no entry for the destructor in the vtable).
It doesn't matter whether the base-class destructor is a no-op. What
matters is what is in the derived class destructor, which you (or the
base class implementor) does not have any control over.
Regards,
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk