[cxx-abi-dev] Deleted virtual functions

[Dennis Handly]

>From: David Vandevoorde <daveed at edg.com>
>Maybe if a pure virtual function has an  
>implementation one could call that implementation?

Yes but only in the sources that have a key function or if that implementation
is defined everywhere.

>> void __cxa_pure_virtual (void *this_ptr)

>But would that break backward compatibility?
	Daveed

Not on my implementation where C and C++ calling conventions are the same.
Perhaps for the ABI document.
Though it could be added as an engineering note. :-)

But it would be a good idea for this new function.

>From: Sean Perry <perry at ca.ibm.com>
>The C linkage would be a problem on platforms that use a different calling.

It won't be any worse than now.  And that function will abort anyway
and already has the wrong number of parms.

>The compiler is going to generate code that assumes the functions pointed
>to by the virtual function table have C++ linkage.  These functions should
>have C++ linkage too.
Sean Perry

>From: Mark Mitchell <mark at codesourcery.com>
>I do not think it would be a good idea to require that a compiler put
>__cxa_pure_virtual into the virtual table.  For code-size optimization,
>having a simple NULL pointer is better.

Ok.  And NULL is constant, a function pointer/descriptor isn't.

>(Note that some implementations of __cxa_pure_virtual call fprintf, and
>thereby drag in the whole I/O library; it's not just the cost of the
>__cxa_pure_virtual function itself.)

I don't see this as an issue.  If there is a __cxa_pure_virtual that
calls fprintf the cost is already paid?  At least in a shared lib
implementation.

>I view __cxa_pure_virtual as a requirement on a conforming library, not
>on a conforming compiler.

Ok.

>One advantage of that is that a compiler that
>wants to work with an older run-time library (i.e., one that does not
>contain __cxa_deleted_virtual) can use a NULL pointer.
Mark Mitchell

I assume the Standard says that if you manage to call that function, it's
your tough luck?  ;-)

Are we going to explain that "may" in detail in the ABI so we don't have to
have this mail exchange again?

>From: David Vandevoorde <daveed at edg.com>
>That thought crossed my mind, and then I dismissed it because  
>__cxa_pure_virtual is already that way.

Yes.

>I think the API functions should keep C linkage, but the vtable should  
>be allowed to point to a wrapper for these functions with C++ linkage.
>Does that work?
	Daveed

Sure.

>From: Mark Mitchell <mark at codesourcery.com>
>Yes -- provided you accept my view that the requirements on these
>functions are merely that the run-time library must provide them.  Then,
>the compiler is free to put whatever it wants into the virtual table --
>including, if necessary, a reference to a wrapper.

Sure.

>From: Lawrence Crowl <crowl at google.com>
>Why is this a concern?  The tables are in .rodata and bounded by
>the number of distinct classes, which is generally quite reasonable.

No they aren't always for my implementation.  You can only put vtables
in .rodata by using advanced AI technology and getting the user to promise
where the functions are.
I.e. in the current executable and not in some other shlibs.
One bad external function blows the whole vtable.

Note we use function descriptors and not plabels.  The later could
use a pointer to read/write data.

>Explaining when it can and cannot use an old library often causes more
>problems than it fixes.
Lawrence Crowl

I assume you are talking about all of the other new incompatible features
in the new Standard.

>From: Lawrence Crowl <crowl at google.com>
>I do not object to the flexibility.  However, I would prefer the
>choice to require the __cxa_deleted_virtual be available to the
>programmer.  Admittedly, this is quality-of-implementation.

And that's why I want to be able to print the class name in the error
message.  Rather than getting a signal.