This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strategy for dealing with C++ virtual functions in a managed binding.
- From: Adam Treat <manyoso at yahoo dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 2 Dec 2002 21:40:23 -0500
- Subject: Re: Strategy for dealing with C++ virtual functions in a managed binding.
- References: <200212022124.27498.manyoso@yahoo.com>
- Reply-to: manyoso at yahoo dot com
On Monday 02 December 2002 09:24 pm, Adam Treat 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.
>
> 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.
I wanted to add that the way we could forward the call to the managed C#
function is through a C# delegate. A 'delegate' is like a super-enhanced
strongly typed function pointer. This 'delegate' can be passed through
PInvoke (this is how C# calls native methods) as a function pointer. The idea
would be to somehow install the delegate/function_ptr into the vtable in such
a way as to override the existing bottom most virtual function in Qt/C++.
Any
> ideas? Is this a pipe dream?
>
> Cheers,
>
> Adam