Quantcast

Golang - Another way to organize the go wrapper code?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Golang - Another way to organize the go wrapper code?

Shengqiu Li
Hi all,

For now, the go backend doesn't utilize the anonymous field feature. Every C++ class will generate a new `uintptr` type with all functions it has, including the functions inherited from parent. For example, the following code

```
class A {
public:
void a() {}
};

class B : public A{
public:
void b(){}
};
```

Will generate there member functions in total, one for A, and two for B. This may cause the wrapper code to bloat, especially when the inheritance hierarchy is very large or many classes have a same "big" ancestor. As a result the compilation can be very slow and the final executable file size will be larger. What's more, it may(?) need more memory to compile -- on some machines, the compilation may fail.

How about making use of the anonymous field feature? Then we have no need to generate a `func a` for B. Does it have any drawbacks?

------------------------------------------------------------------------------

_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Golang - Another way to organize the go wrapper code?

Shengqiu Li
I found a comment in the source code of Go backend:

      // 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++.

Could anyone explain about how the difference take effect? 


2016-09-29 21:34 GMT+08:00 Shengqiu Li <[hidden email]>:
Hi all,

For now, the go backend doesn't utilize the anonymous field feature. Every C++ class will generate a new `uintptr` type with all functions it has, including the functions inherited from parent. For example, the following code

```
class A {
public:
void a() {}
};

class B : public A{
public:
void b(){}
};
```

Will generate there member functions in total, one for A, and two for B. This may cause the wrapper code to bloat, especially when the inheritance hierarchy is very large or many classes have a same "big" ancestor. As a result the compilation can be very slow and the final executable file size will be larger. What's more, it may(?) need more memory to compile -- on some machines, the compilation may fail.

How about making use of the anonymous field feature? Then we have no need to generate a `func a` for B. Does it have any drawbacks?


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Loading...