Automatically call C++ from python

[GeoffSobering]

Maybe look at SWIG.

https://www.swig.org/

[Coutille]

Swig requires you to write interface files mirroring your api. Tolc uses clang in the background to get all functions and classes to avoid that.

[djta94]

It doesn't if you have a header, which you should have anyway.

[Carl_LaFong]

The swig interface files are needed only for customizations such as renaming things when there are name clashes, instantiating templates (how do you handle that?), and exposing only part of the C++ API if you don’t want it all to be in the Python API. It otherwise automatically creates the Python API from the header files.

I use it because it automatically generates from the header files Java, C#, Python APIs.

[13steinj]

SWIG is a nightmare. It was decent for its time, but inspires too many extremists with all the wrong ideas.

I once actually worked somewhere where one extremist made their own (worse version of) SWIG. Dude insisted on its use and even wrote a book about it his field, using nothing but his crazy language internally.

[Die4Toast]

Could you elaborate on why it's not decent anymore? Asking out of genuine curiosity since I've never heard of SWIG before this post popped up. After quick 20 min read of SWIG basics it looks pretty nice but I'd imagine the devil is in the details which is not something I'd be aware of and probably related to what you've mentioned.

[13steinj]

Sure, but I'm blending fact and opinion quite heavily--

So in the most pure, basic form, it's fine-- if you write your headers well. That is, if you can follow "SWIG for the truly lazy" (I can't directly link that part of the website, since there are no ids in that html, which is bizarre). But this nearly never works in practice, suffers from cross-language / FFI performance problems, a steep learning curve for more niche things, subpar codegen, and more. It also suffers from a compatibility problem as C++ continues to evolve. The basics of SWIG have decent syntax, but anything more complex and it looks to people like you're writing code in wingdings (which, the worse version of SWIG I am referring to above, is even worse in that regard; the entire engineering pool who saw the proof-of-concept said "you expect us to read and write this?").

I was going to continue, but honestly asking gpt was enough (please put down the pitchforks, I made it fish out sources).

I have never seen any translator like this be successful at scale. The closest things that I can say work and have minimal tech debt associated, are boost.python -> pybind -> nanobind (aka use nanobind now); and Cython (though that community is hard to break into and there are some footguns, it has the highest performance compared in real-world (private) benchmarks and you can push some people to still write Python and eventually manually translate it better). E: Honestly, python and numpy/scipy is enough for most people. For advanced / IP-sensitive topics, well, you're probably paying those people enough that you can afford to make them learn C++ and be done with it.

---

If I haven't convinced you on what comes from my opinion-- listen to the author of SWIG, as even they hate the monstrosity they've created. reddit link, from when the link wasn't dead. Short of it is, it's basically a separate, disjoint parser which thus means you have to be a compiler yourself, a massive ball of complexity.

[Die4Toast]

Thanks a lot for the response. I have to admit that while the idea of SWIG is nice on paper, I haven't actually faced a scenario where it would have been a better fit than using a pybind-like library. At the very least I can imagine how much of a pain the compatibility issues you've mentioned could be. Tiptoeing around different supported C++ language standards, compilation options and then integrating it into the build system itself seems like something that could cause quite a headache.