This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strategy for dealing with C++ virtual functions in a managed binding.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]