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
m
>
> Does it pass the SWIG testsuite?
>
No. I have only done some initial works. The other parts, for example the
director feature are not modified yet.
I think one of the biggest advantages is that it can shorten the wrapper
code. When C++ inheritance hierarchy is large and deep, the wrapper
On Tue, Oct 4, 2016 at 7:07 AM, Shengqiu Li 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
I have made a preliminary demo using the anonymous field feature
github.com/dontpanic92/swig
After wrapping your example C++ code, the following Go code acts the same
as C++ code:
package main
import "test5"
func test(a test5.A) {
a.M1()
}
func main() {
b := test5.NewB()
test(b)
What I mean is that the difference doesn't affect the wrapper. Your example
shows the situation of purely go code, but the wrapper code doesn't purely
go code -- although the "path" are different, the destination is the same.
If your code acts as a wrapper -- let's say that A.m2 will call test_A
On Tue, Oct 4, 2016 at 6:33 AM, Shengqiu Li wrote:
> 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
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 --
finall
On Sun, Oct 2, 2016 at 2:03 AM, Shengqiu Li 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 defin
Hi all,
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 c
