Strategy for dealing with C++ virtual functions in a managed binding.
Adam Treat
manyoso at yahoo.com
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
binding.
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 libqt.so 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?
Cheers,
Adam
More information about the kde-core-devel
mailing list