dotgnu-general
[Top][All Lists]
Advanced

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

Re: [DotGNU]Overriding C++ virtual methods in C#


From: Adam Treat
Subject: Re: [DotGNU]Overriding C++ virtual methods in C#
Date: Fri, 6 Dec 2002 13:27:01 -0500
User-agent: KMail/1.4.7

What you've described is easy to overcome.  I'll post later with a sample ;)

Adam

On Friday 06 December 2002 01:17 pm, Gopal V wrote:
> If memory serves me right, Marcus wrote:
> > I've come up with one way to achieve this goal in effect.
>
> Nope ... you haven't ... at least you haven't made it far enough ..
>
> Let me explain ...
>
> I have
>
> QWidget which inherits from QObject , and QObject has a virtual method
> `vmethod' declared for it ...
>
> So I create QWidgetBridge and QObjectBridge to wrap these ... so here
> QWidgetBridge inherits from QObjectBridge to inherit bridging (which
> seems to be the obvious plan here, correct me if I'm wrong).
>
> So the inheritance pattern looks like this
>
> QObject
>
>  |     \__ QObjectBridge
>
> QWidget         |
>        \__ QWidgetBridge
>
> (which is the Multiple Inheritance diamond drawn in ASCII art :-)
>
> Since QWidgetBridge should inherit QObjectBridge *and* QWidget to be
> useful for the purpose ....
>
> Now if I call QWidgetBridge.vmethod() which one will get called ?,
> the options are
>
> 1) QWidget::vmethod           (inherited via QWidget)
> 2) QObjectBridge::vmethod     (inherited via QWidgetBridge)
>
> Since QWidgetBridge does not override vmethod, we really cannot be sure.
>
> (DISCLAIMER: I don't know if there's a way in C++ to avoid this)
>
> Naming the bridge function differently doesn't work either (that was almost
> too obvious,right ?) ..
>
> So all bridge classes must override *all* the previous methods in their
> wrapped class and not use inheritance from the bridge of their parent class
> to do avoid this ambiguity ....
>
> Which means you cannot override methods in parent bridges or cast them to
> parent bridges, and thus the system breaks down....
>
> What this really needs is a way to allow PInvoke to check for C# functions
> like they do in JNI , delegates need to be stored in C++ wrappers to be
> accessible , causing all the problems I have described so far ...
>
> Hope that makes it clear,
> Gopal



reply via email to

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