[K42-discussion] virtual destructors

[Bryan S Rosenburg]

Maria Butrico wrote on 07/10/2006 05:36:56 PM:
> It is not clear to me that anyone is actually invoking this method.  We
> could define such method to panic, to catch any actual invocations.
> 
> Also Donour told us that he needed to add a destructor becuase
> 
> "C++ requires that classes with virtual methods define a virtual
> destructor. Older versions of gcc allow you to get away without it, but
> gcc4 enforces it."
> 
> and that he added one such to the VAllocServices class.

Let's stop mixing up virtual destructors with delete operators.  Operators 
new and delete have to do with dynamic allocation.  Constructors and 
destructors have to do with object initialization and finalization.  The 
presence of constructors/destructors, virtual or otherwise, should in no 
way imply the use of dynamic allocation and deletion.

The statement that "C++ requires classes with virtual methods to define a 
virtual destructor" does not state that the class must also have a delete 
operator.

With that said, however, it seems that g++ imposes such a requirement. 
(The requirement is not new with gcc4.)  I've checked a small test 
program, and it seems the compiler generates destructor code that also 
conditionally calls delete.  If the class and none of its base classes 
provide a delete, the call is to our friend _ZdlPv.

The result is that any class that has virtual methods has to provide a 
delete operator, and in K42, that means it or one of its superclasses must 
include a DEFINE_XXX_NEW(<class_name>) macro invocation.  It turns out 
that we have a DEFINE_NOOP_NEW() macro for exactly this purpose.  It 
defines new() and delete() operators that simply panic, as Maria has 
suggested.

Donour, can you try inserting a DEFINE_NOOP_NEW() invocation into 
VAllocServices() (and anywhere else you've had to define virtual 
destructors), and see if that clears up the undefined symbol?

- Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060711/d5864a1d/attachment.htm