3 ms·
The syntax is terse if you need to do arbitrary stuff with an arbitrary interface. But if you start off keeping SWIG in mind from the beginning and avoid funky
by meta-level 3y ago
The syntax is terse if you need to do arbitrary stuff with an arbitrary interface. But if you start off keeping SWIG in mind from the beginning and avoid funky features at API level you might be fine by just "importing" your header files in the SWIG-definition file.
See https://projects.om-office.de/frans/swig_demo/-/tree/master/cpp-src https://projects.om-office.de/frans/swig_demo/-/tree/master/... (disclaimer: very old and special exception handling)
IMHO this is a good practice anyway, because this way you make sure, your API looks the same in every binding.
And this way you get a binding for Python, Java, JavaScript, C#, Lua, and much more
- tvaughan 3y ago> But if you start off keeping SWIG in mind from the beginning and avoid funky features at API level you might be fine by just "importing" your header files in the SWIG-definition file. This has been my experience as well. Just like I would argue that code which has been written to be testable is better than code which hasn’t, a “public API” which has been written to be consumed by another tool is better than one that hasn’t
- progbits 3y agoI don't fully agree. Returning unique_ptr, optional or some error sumtype (absl::Status) is perfectly fine non-funky API, but it will require special Swig handling to rewrap.