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

Adam Treat manyoso at yahoo.com
Tue Dec 3 05:47:29 GMT 2002

On Tuesday 03 December 2002 12:09 am, James Michael DuPont wrote:
> --- Adam Treat <manyoso at yahoo.com> wrote:
> > 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.
> /me ears pick up something interesting
> > 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.
> I would like too see this code. /me thinks you can use libiberty and
> the   introspector or gcc_xml for this.

Oh, we already have a strategy for mangling the names.  A script and 
nm+cppfilt works nicely.  I can produce this script for you tomorrow (it's 
late ;)  We looked at libiberty for this, but it only provides a mechanism 
for 'demangling' and does not provide a way to 'mangle' given a string 
representing a function prototype.

> >  The
> > idea is
> > to use an instance pointer as an invisible first parameter and then,
> > using
> > the mangled name, call libqt directly.
> like the gnu libjava

Oh?  libjava uses this method?  Is this part of gcj then?

> >  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 ;)
> yes, let us see the basic axioms, we can build this in a standard
> process.
> at this point, I would like to know why cannot you use the internal
> call system? that has a binding generator as well, no?

The binding generator is pretty flexible and easy to extend to other C++ 
API's.  We use a custom C++ header parser written in C# to produce an XML 
file representing the C++ API.  This XML file is then processed through our 
binding generator called 'binge'.  What do you mean by 'use the internal call 
system' ??  I have no idea what you are referring to nor do I understand 'has 
a binding generator as well, no' ... what has a binding generator as well?

> >  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.
> you can grab pointers to virtual function entries,
> and given an object and a vf pointer call the object.
> please send me more info,
> I just might be able to help.

Awesome!  I don't know what kind of info would be helpful ... Our ideal 
solution would allow us to associate a delegate with a C# virtual function 
... when the virtual function is implemented the binding would pass the 
delegate to a C glue method as a function pointer ... the C glue method could 
then do some magic with the virtual table in libqt.so and install the 
delegate in place of the existing function pointer.  I know how to do all of 
this except play with the Qt vtable in native code ...

Hope this info helps,


More information about the kde-core-devel mailing list