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

scott douglass sdouglass at arm.com
Mon Sep 30 09:21:46 UTC 2002


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).  The only reference to D0 will be in the vtable for S.  If I'm producing the vtable for S I can just substitute NULL (or some such).  I see now that since I don't know what compiler is producing the S vtable I can't know if D0 is referenced so I do need to produce the D0 symbol if I'm producing D2 -- but I can rely on D0 never actually being called (by legal code).

Or do you mean that other compilers are free to refer to D0 in ways that I don't understand?

>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?  I think that these language restrictions mean that constructing/destructing a complete object (i.e. calling C1/D1/D0) of abstract type has no meaning.

>You can, however, assign both symbols to one address, which means the only
>penalty you pay is a few bytes in object files.
For C1/C2 and D1/D2 in the absence of virtual bases, yes.  I'd also like to remove the object code for D0 of abstract classes.





More information about the cxx-abi-dev mailing list