"We should try to setup a platform that generates automatic interface wrapping code based on code parsing."Interesting! BTW, isn't some of that what SWIG does?

dbl

QuoteBoost has very good documentation,This is a very sweeping statement. Some are well-documeted, many not, unfortunately.Ask the average C++ developer..

QuoteOriginally posted by: Polter"We should try to setup a platform that generates automatic interface wrapping code based on code parsing."Interesting! BTW, isn't some of that what SWIG does?Is this a kind of IDL what you have in mind?

"Something like IDL."The goal is the Foreign Function Interface (FFI) generation: http://www.c2.com/cgi/wiki?ForeignFunctionInterfaceSome criticism: http://autocad.xarch.at/lisp/ffis.html#swig

Quote@Cuch: boost math doc = 500 pages! Those guys are great. Now for the other 99 libraries in the same way

QuoteOriginally posted by: Polter"Something like IDL."The goal is the Foreign Function Interface (FFI) generation: http://www.c2.com/cgi/wiki?ForeignFunctionInterfaceSome criticism: http://autocad.xarch.at/lisp/ffis.html#swigexcept IDL is OMG, Microsoft and de-facto standard.

Some more examples, for a case of Python: http://wiki.cython.org/WrappingCorCppWith some more criticism:"SWIG is one of the oldest and most mature methods of wrapping C or C++ code into Python (SWIG works for other target languages as well). It can wrap almost any C and C++ code, including complex templated C++ code. If you have a large (so that hand wrapping is prohibitive) and coarse-grained API, SWIG will likely be your best choice. However, SWIG does have a number or disadvantages compared with Cython. First, SWIG produces a C file, which gets compiled to a .so, but then it also produces a Python wrapper on top of this .so file. For fine grained APIs (where not much is done in each C/C++ call), the overhead of this additional Python wrapper can be significant. Second, with SWIG, the Python wrappers are written for you, so if their design is not exactly what you want, you end up doing more work to create your final Python API."However, I am not aware of anything else cross-platform & cross-target-langs:"Code GenerationSWIG currently generates wrapper code for nineteen different target languages: Allegro CL C# CFFI CLISP Chicken D Go Guile Java Lua Modula-3 Mzscheme OCAML Octave Perl PHP Python R Ruby Tcl UFFI In addition to this, the parse tree can be exported as XML and Lisp s-expressions. Experimental work is also available for a Pike module. "Note the missing ones: Mathematica, MATLAB, Excel/VBA.However, there's PHP, so that could cover the websites availability.

Agreed, I'm a big SWIG supporter. I usually test my libs in python using a SWIG generated interface, and I find it very natural and easy to mantain. I happened to find very few things not supported, and I'm sure I could have found ways to get round the problem each time.My vote for it.

QuoteOriginally posted by: outrun- "except IDL is OMG, Microsoft and de-facto standard. "@Cuch, are you saying that we should do IDL? SWIG can probable generate IDL?Now if we could do the same with docs If SWIG can do the job, then fine. We need to determine what the interop requirements are (C# and Matlab for my part).

Regarding MATLAB -- I've found "nr3matlab.h" (NR as in "Numerical Recipes") very helpful -- it offers a C++ API (as opposed to C API when you use MEX directly) -- here's a nice tutorial:http://www.nr.com/nr3_matlab.htmlUnfortunately, the copyright status is unknown.NR describes it thusly: "You can use Numerical Recipes to extend MATLAB(R), sometimes giving huge speed increases. A tutorial with examples is here. A free interface file is here."Note, that this header file (only -- no need to build anything) is completely independent of the NR (the book) code and is solely a wrapper for C API that you get the access to when you use the official MATLAB-provided "mex.h".// There's also Rcpp for R, but since this is already covered by SWIG...