Thanks for your reply. In my view, the difference seems not affect the
behavior. As we store the pointer of the C++ object, when we call a C++
virtual function in Go and the object itself is an instance of child class,
calling the parent's function or the child's function are the same --
finally they will call the child's function in C++. For example,
```
// Example swig source file
%module test5
%inline %{
class A {
public:
virtual int test() {return 0;};
};
class B: public A {
public:
int test() {return 1;}
};
%}
// Example Go wrapper code if we use anonymous field
type A struct {
SwigcptrA uintptr
}
func (p A)test() int {
return (int)(C.wrap_A_test(p.Swigcptr()))
}
type B struct {
SwigcptrB uintptr // It is the same as A.SwigcptrA
A
}
func (p B)test() int {
return (int)(C.wrap_B_test(p.Swigcptr()))
}
// C++ wrapper code
int wrap_A_test(A* a) {
return a->test(); // If we passed a child's pointer here, it will also
call the B::test
}
int wrap_B_test(B* a) {
return b->test();
}
```
If we have a B object `b` in Go, calling `b.A.Test` will call `wrap_A_test`
in C++ wrapper code, and finally call the `B::test`. It will be the same as
call `b.Test` in Go.
在 2016年10月4日星期二 UTC+8上午3:01:24，Ian Lance Taylor写道：
>
> On Sun, Oct 2, 2016 at 2:03 AM, Shengqiu Li <[email protected]
> <javascript:>> wrote:
> >
> > I'm making a binding of a C++ library for go, and I'm wondering why the
> > anonymous field inheritance isn't used in the go wrapper code.
> >
> > I have found a piece of comment in the go backend of SWIG, saying:
> >
> >> // For each method defined in a base class but not defined in
> >> // this class, we need to define the method in this class. We
> >> // can't use anonymous field inheritance because it works
> >> // differently in Go and in C++.
> >
> >
> > I have also found this old topic:
> > https://groups.google.com/d/msg/golang-nuts/0YJJKHGSRMY/gR6I1-mbU2AJ
> >
> > What I think about the "difference" is that the anonymous field is more
> like
> > a delegation. However I still don't get the point how the "difference"
> takes
> > effect. Could anyone give an explanation, or an example where the
> anonymous
> > field doesn't work?
>
> In C++ a virtual method inherited from a parent class is passed a
> pointer to the child class. If that method, implemented in the parent
> classn, calls any virtual methods on the `this` pointer, it will call
> the methods implemented by the child class (which may of course be
> inherited from the parent class).
>
> In Go an embedded method inherited from an embedded type is passed the
> embedded value. If that method, implemented in the embedded types,
> calls any methods on the receiver, it will call the methods
> implemented by the embedded type, not the methods implemented by the
> child type.
>
> 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.
