dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Strategy for dealing with C++ virtual functions in a managed


From: James Michael DuPont
Subject: Re: [DotGNU]Strategy for dealing with C++ virtual functions in a managed binding.
Date: Mon, 2 Dec 2002 21:09:47 -0800 (PST)

--- Adam Treat <address@hidden> 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.

>  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, 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 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.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


reply via email to

[Prev in Thread] Current Thread [Next in Thread]