On Jun 6, 2013 4:58 PM, "Sylvestre Ledru" <sylvestre.ledru@scilab-enterprises.com> wrote:
>
> Hello William,
>
> We are in the process of finishing the SWIG / Scilab support.
>
> Simon, as C/C, is currently working on fixing the tests.
> However, the STL tests are failing. They require quite some works and we
> don't think they will be used by the SWIG/Scilab users (too complex in
> term of usage).
>
> Would you agree on the merge even if the STL support is not there ?
>
I'm not sure I entirely agree. The main strengths of Swig compared to other wrapping tools are the c++ support including STL and multiple target language support that is fairly consistent. By omitting the STL in new target languages, it will degrade the overall Swig experience disappointing users.

Most c++ users will also use string and vector, probably more than half of projects. If there is any compromise, then these two must be supported at a minimum. If this is difficult then there is something wrong because it should be a simple adaptation of C strings and arrays. It should take in the order of a few days at most if the rest of the module is up to scratch. There are also lots of runtime tests in other languages which greatly eases the implementation as translating these from another language is quick compared to the usual considerable time it takes to write the tests.

If you want to avoid the whole UTL approach for providing STL support take a look at the earlier STL wrappers for the scripting languages or even the simple Java approach.

Before merging I would like to review the module and would encourage others to also do so.

It is good to hear that this module is maturing and I have cc'd swig-devel for further discussion.

William


Hello William,

STL support in SWIG seems to be like a never ending task, but I think I've finished the work that you required for Scilab.

Now we can -in a generic way- manipulate and pass to C++ functions, STL "simple containers" (like vectors, sets, lists). For this, I mostly based my work on what has been done in Python on that topic, and adapted it to the case of Scilab.

You probably know that we mostly use matrices in Scilab. Matrices of the four primitive types in Scilab (int, double, string, bool) are mapped in input/output to an equivalent STL container.
As Scilab knows also pointers (which can be stored not in a matrix but in a list), you can also manipulate (through pointers) STL containers of more complex types, and pass them to C++ functions.

I could give some other details (for example on STL map, for which there is no equivalent type in Scilab, so it is used through pointers only), but all elements about STL support will be documented soon.

I would have liked to add remaining containers (like deque, ...), to complete unit tests, to fix things about iterators, to reorganize some sources.... There is still some work to do, but I think it can be done in a further step.

To illustrate this, I've successfully used SWIG Scilab to integrate a big and and real C++ library, containing about a thousand of functions using STL.

Could you review our work ? And if you accept this, could you explain me what has to be done to integrate this in the master branch ? I've already fixed the Scilab test suite, it should be run without crash or compilation issue.

Best regards.

Simon Marchetto
Scilab Enterprises