[DotGNU]Strategy for dealing with C++ virtual functions in a managed binding.
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
> 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