[cxx-abi-dev] comlpete object 'structors for abstract classes (was deleting destructors)

Mark Mitchell mark at codesourcery.com
Mon Sep 30 15:41:10 UTC 2002



--On Monday, September 30, 2002 10:21:46 AM +0100 scott douglass 
<sdouglass at arm.com> wrote:

> At 30-09-02 01:33 AM -0700, Mark Mitchell wrote:
>> --On Monday, September 30, 2002 09:00:23 AM +0100 scott douglass
>> <sdouglass at arm.com> wrote:
>>
>>> Hello,
>>>
>>> I've noticed that it's probably reasonable to not produce C1/D1/D0
>>> 'structors for abstract classes -- the language rules prevent ever
>>> needing to construct or destruct a complete object of abstract type.
>>
>> You certinaly need D0:
>>
>> struct S { virtual void f () = 0; ~S (); };
>>
>> void g (S* sp) {
>>   delete sp;
>> }
>
> I don't follow that.  We know that sp must point to some class derived
> from S (because S is abstract).

Note that ~S is not virtual.  There is nothing that says that an abstract
class must have a virtual destructor, even though many style guidelines
suggest that.

>> You may need D1 and C1 too; this is the flip side of your question
>> about whether you need D2/C2 when there are no virtual bases.  The
>> ABI doesn't clearly say which version(s) of these functions derived
>> classes can call, so you can't eliminate any of them.
>
> I am relying on the language restrictions that you can never
> create/destroy a complete object of abstract type.  What does calling the
> C1 of an abstract class do?

The ABI specifies the behavior of C1 in that case just fine.  You construct
the bases classes, fill in the vtable, and run the code the user wrote in
the constructor.

You observed earlier that for a class with no virtual bases a derived
class can choose to call C1 instead of C2 -- after all, they do the same
thing.  I think you're right -- we didn't preclude that.  We certainly
didn't preclude a derived class from calling C1 if the base class is
abstract.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com



More information about the cxx-abi-dev mailing list