3

I am considering SWIG as a tool for wrapping certain functionalities of a large library into an SDK. I had some success in wrapping some classes from the C++ library into other languages (e.g. Python, C# and D) but I cannot figure out how to do the same with C++.

In other terms, I would like to let SWIG automatically generate a C++ proxy class (see here) for the C++ target, so that I can expose just a single DLL file and some simplified C++ files that use the DLL. Releasing the underlying C++ library is not feasible. Any ideas?

Edit: as suggested by Jens Munk, there is a Google Summe of Code (GSoC) 2008 branch of Swig that allows to set "c" as the target language. There is also another GSoC 2012 version that allows to set Objective-C target. However, all these versions were not merged into the official release, so one needs to build them from scratch and they contain many annoying issues. As far as I know, there is no good option yet to automatically generate proxy C++ classes via Swig.

Additional material:

from-different-compilers

Community
  • 1
  • 1
DoubleChain
  • 251
  • 3
  • 4
  • Hmm, why do you want a proxy class for C++ ? There is already the header system that allows to call functions without knowing their implementation details (i.e. what's in the dll) – brainsandwich Nov 07 '16 at 16:14
  • 2
    A development version of SWIG was develope during Google Summer of Code GSoC, which can do exactly what you want. You tell SWIG that the target language is C. The interface becomes object-oriented C and is compatible with multiple compilers, i..e you can use binaries made using different compilers. I use it myself – Jens Munk Nov 07 '16 at 17:19
  • I've managed to compile and test all these "unofficial" versions of Swig. My question is however not quite resolved because (1) the old GSoC Swig with "c" target contains rough programming errors (void function with return, wrong import instructions, useless chunks of code, swg files that were actually copies of the java target ones, and so on) (2) the result of this tool (even after fixing all these bugs) is a c-style wrapper that still implies that the user of the library needs to make api calls for construction and destruction of classes, while what I need are proxy C++ classes... – DoubleChain Nov 09 '16 at 15:43

0 Answers0