Swig and C++11

[John Ralls]

> On Dec 30, 2014, at 3:56 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Wednesday 24 December 2014 08:38:06 John Ralls
> > ... although the SWIG folks still have some work
> > to do to fully assimilate C++11 [1].
> > 
> > 
> > [1] http://www.swig.org/Doc3.0/CPlusPlus11.html <http://www.swig.org/Doc3.0/CPlusPlus11.html>
>  
> I'm taking this line out of its wider context of the python wrapper discussion because it may be more important than only the python wrappers.
>  
> We also depend on swig for our interaction between current c(++) and guile code.
>  
> If we rewrite the engine in c++11, and want to export these new objects to guile, swig's capability to handle c++11 code becomes important.
>  
> I don't know that much about swig's internals. I do know it has a generic core and each supported language has its own module for language specific implementation. The python one is currently the most actively developed one.
>  
> The guile module on the other hand has no active maintainer and hasn't had one for years. (I had to implement the guile 2 compatibility myself for that reason).
>  
> So it may well be possible that swig's c++11 support for guile is quite broken. I don't think it gets tested other than "it builds". It is lacking lots of run time tests.

I don’t think that that will be much of a problem. In the near term we need to maintain C wrappers anyway so that the engine remains accessible to the GUI. SWIG can just wrap those wrappers for Guile. What will be more interesting will be moving the core functionality that’s currently in Scheme (e.g. business options) into C++11 because those classes will presumably interface directly to Guile via SWIG. The abilities of SWIG to do that might affect the way we program the interaction, but we won’t know until we start on it.

In my weak understanding of SWIG’s internals it parses the wrapped API into an intermediate representation and uses that to generate the wrapper API in various  languages. If that’s right, then only changes in the internal representation will affect the Guile API. I don’t think there will be many.

There was one section that caught my attention, about lambdas:
"The lambda functions are removed from the wrappers for now, because of the lack of support for closures (scope of the lambda functions) in the target languages.”
Clearly they weren’t thinking about Scheme when they wrote that! Since SWIG does support functors (a.k.a. function objects, classes which have only a constructor and which do their useful work in the constructor), which is in large part what lambdas are intended to make simpler, I imagine that it’s the capture feature that they’re having trouble with. I see that as more of an implementation detail rather than something we’d want to wrap.

Regards,
John Ralls