Re: Strategy for dealing with C++ virtual functions in a managed binding.

[Joe Buck <jbuck at synopsys dot com>]

> First, let me tell you a little about our upcoming method for binding Qt# to 
> Qt/C++.  Essentially, we are looking to get rid of the intermediate QtC (see: 
> C binding for Qt) as much as possible...
...

> Now, that you understand the idea ... one area we are having a hard time 
> trying to solve is C++ virtual functions.  The only way I can figure to 
> handle this is to provide a C glue method for every virtual function in libqt 
> :(  This is nasty and eliminates most of the advantages gained from calling 
> libqt directly. So, that's why I am wondering if anyone has a genius idea for 
> how to handle this in an elegant way.  The preferred solution would be to 
> somehow override the virtual table to call a managed function directly and 
> then somehow forward this to the appropriate C# virtual function.  Any ideas?  
> Is this a pipe dream?

It's a pipe dream.  When there is a virtual call, you can't override the
virtual function table because it is fundamental; you don't know the true
type of the object, only some base type.  You must somehow dereference
the virtual function table to find the real address of the function.
Worse, if you want to be portable, some GCC targets use thunks and others
don't, so you'll have difficulties with multiple inheritance if you try
to generate virtual calls directly instead of using the compiler.

The only way to do things cleanly and portably is, as you say, to provide
a glue function for every virtual call in the library.  A tool could
be written to generate these calls cleanly and mechanically.
For example, the C-callable name might be something like

__PREFIX_MANGLE

where PREFIX is some fixed prefix, and MANGLE is the mangled name.
It would call the virtual function on the first argument using the
remaining arguments.

I suppose GCC could be extended to auto-generate such things in a more
efficient manner, as direct jumps, getting rid of the extra call and
stack-copying (or this may not be needed depending on how well sibling
call optimization can be made to work).  I'm not volunteering.