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

[Gopal V]

If memory serves me right, Adam Treat wrote:
> Our new strategy is then to call the libqt.so directly using mangled method 
> names in our DllImport attributes.  

IMHO, this is a bad idea ... because eventhough g++ name mangling is 
standardized, it's likely to change without much notice .. gcc 2.53
had a switch, IIRC..

> 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 

http://www.delorie.com/gnu/docs/gcc/gxxint_15.html

has the name mangling docs ... but I wouldn't like someone depending 
on that for production code ....

> most of the advantages gained from calling libqt directly. 

There are no advantages in calling libqt directly ... the native thunk in
calling 1 function and passing through another to get there is practically
neglible (if well written) .... But this does remove the QtC dependencies
and make it more compact ... Other than that , there seem to be no runtime
or speed advantages in this ...

> 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.  Any ideas? 

This will be hard to write , hard to debug and unpredictable .... and
the virtual table was not really meant to be done like this ... A C
stub to call the orginal C++ remains the true, tried and tested method.

> Is this a pipe dream?

__C7QStringii ? ... *yummy* ..

It's possible , because you already know the attributes of the classes
in Qt , the names of classes and functions ... But my personal opinion
is "It will always be a hack" .

Gopal
-- 
The difference between insanity and genius is measured by success
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<