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 <lisheng...@gmail.com 
> <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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to