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

Adam Treat manyoso at
Mon Dec 2 21:10:56 GMT 2002

Hello All,

I would like to pick the brains of the collective intelligence and come up 
with a good solid strategy for dealing with C++ virtual functions in a 

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.  We would like to minimize the 
overhead the C library requires plus the nasty issues related to 
generating/maintaining and keeing the C binding in sync with our own binding.  
Our new strategy is then to call the directly using mangled method 
names in our DllImport attributes.  This is accomplished by using a 
combination of 'nm' and 'cppfilt' during Qt# binding creation.  The idea is 
to use an instance pointer as an invisible first parameter and then, using 
the mangled name, call libqt directly.  We plan on getting the instance 
pointers by providing a minimal C glue library which will return instance 
pointers for every ctor in libqt.  The benefits, if this works, are: speed, 
memory, maintainability.  Portability shouldn't be a problem because we hope 
to have people compile libqt with GCC.  Oh, and our binding generator is also 
capable of an easy extension to bind any C++ lib in case anyone is interested 
in binding other C++ libraries ;)

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?



More information about the kde-core-devel mailing list