Fragile virtual functions

[Michel Fortin]

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/