I am thinking about how FLTK v2 might developed in a way that would lighten the load for people wishing to wrap FLTK using SWIG. So here is a little story about how I used SWIG recently:
I recently used SWIG to wrap a closed-source third-party API that was coded in C. This API is to be used by a server that I want to move from C++ to java. I wrote a C wrapper for two reasons: first, the original API really needed higher level abstractions, and secondly it enabled me to have functions where the arguments and return values were compatible with java. This enables the C code to be tested via a standalone C program. I was able to test it, profile it, valgrind it etc etc. Once that was done I was able to move onto the java knowing I had a solid foundation. I admit that this was C, not C++. But I have seen SWIG used to wrap C++ as well. The C++ was designed with the awareness that SWIG was going to be used to create a java wrapper. It worked very well. The ".i" files merely included the C++ headers. No extra hacks were required. I wonder, is there any interest in changing FLTK v2 to make it so the header files can be parsed by SWIG without the kind of hacks in pyFltk? This may involve more separation in the headers than FLTK currently has. It might also mean changing some types behind the scenes to make them compatible between C++ and java. Regards, Andrew Marlow _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
