Fragile virtual functions

[Craig Black]

"Michel Fortin" <michel.fortin at michelf.com> wrote in message 
news:fqtuqt$nfd$1 at digitalmars.com...
> If I understand well the virtual function dispatching mechanism, if you 
> have a library with some class, such class having virtual functions, 
> adding a new virtual function to that class will make the ABI incompatible 
> with already-compiled subclasses having more virtual functions, and if you 
> don't add your function at the end of a class definition, with already 
> compiled code calling virtual functions for your class. Am I the only one 
> seeing that as a weakness for object-oriented libraries?
>
> I've seen a recommendation somewhere (for C++) suggesting that virtual 
> functions should be made protected and that public functions should be 
> created for calling the protected virtual functions. This doesn't protect 
> the subclasser from this problem, but it protects the caller of a virtual 
> function which is liberated from having to perform the virtual dispatching 
> by itself (and thus from having knowleadge of the virtual table layout).
>
> I was wondering if the D compiler couldn't do that by itself: create a 
> "trampoline" function for every virtual call which would do the 
> dispatching for you by loading the actual function address and branching 
> directly to it (without really adding a function on the stack). Then a 
> client of your library would be shielded from you adding more functions to 
> your class.
>
> Thoughts? I'm particularly wondering about the speed penalty it could 
> incur.

I am the primary author of an API that is used by other programmers.  It 
uses plugin libraries.  Adding new virtual functions does change the ABI and 
it's very annoying.  Developers that use this API will usually complain if 
there is an ABI change, because it means that everyone's plugins have to be 
recompiled for compatibility.  This somewhat cripples development when ABI 
compatibility is required.

So I concur with your observation that this is a problem.  However, I would 
consider your suggestion to be an incomplete solution.  Because, as you say, 
it doesn't solve the problem for subclasses.  Does anyone have an idea that 
would be a full solution?  Of course, we are not talking about modifying or 
removing existing virtual functions.  Just adding them.

-Craig