Another advantage is when we use multiple inheritance. Currently we can
only use SwigGetTheSecondBase() method to manually convert an object into a
parent other than the first one, however if we use the embedded field, it
means we can store the bases' pointers in the struct and we don't need
manually convert it.
For example,
type ClassA struct {
SwigcptrA uintptr
}
type ClassB struct {
SwigcptrB uintptr
}
type ClassC struct {
SwigcptrC uintptr
A // A.SwigcptrA is the same as SwigcptrC
B // B.SwigcptrB should be obtained from C++ function, and it can be
done only once -- in the `NewC()`
}
Then when we call B's function, they will pass the SwigcptrB to the C++
functions -- which is correct.
在 2016年10月4日星期二 UTC+8下午10:22:34，Ian Lance Taylor写道：
>
> On Tue, Oct 4, 2016 at 7:07 AM, Shengqiu Li <[email protected]
> <javascript:>> wrote:
> > I have made a preliminary demo using the anonymous field feature
> > github.com/dontpanic92/swig
>
> This is written in a way that I find hard to understand--I can't
> easily see the differences between the old code and the new.
>
> Does it pass the SWIG testsuite?
>
> Perhaps you are right that SWIG could have implemented using Go
> embedded types. Ultimately SWIG deals with interface types, as I
> think it must, and perhaps that lets it hide the differences between
> the languages.
>
> Is there any advantage to having SWIG generate embedded types?
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
