Hacker News Reader

Comment by progbits | Hacker News Reader

I've used Swig for C++ to Python interop and let me warn you it is a nightmare. The syntax is absurdly terse and convoluted, documentation sucks and good luck trying to search the web for constructs made only of special characters.

CLIF is way nicer for C++/Python. If you need other languages then best of luck (Zig, Rust and D are easier than Java and Go at least).

View on HN

SWIG was created 27 years ago. I've used it when it was the only game in town and I'm grateful for it. Now there are many other options, at least for Python. Use the one that suits you best.

Right, I'm sure the project achieved great things and I didn't mean to belittle that.

But today I would not recommend anyone start using it if they have a choice, and it seemed prudent to post that warning on a submission of Swig's homepage without context.

The GNU Radio project dumped Swig and replaced it with pybind11 for the same reason. Just a nightmare when things go wrong.

I’ve only ever used pybind11 for C++ -> Python interface and must say, it seems pretty good.

That was exactly my experience writing custom GNU Radio blocks for my master's thesis: swig mangling my C++ variables. I have nothing positive to say about it.

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/... (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

> 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

I 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.

I'd recommend pybind11 for c/c++ <--> python bridge. Though you have to compile your wheel for every minor python version separately.

cibuildwheel (https://cibuildwheel.readthedocs.io/en/stable/) makes this fairly straightforward.

pffffffffffffff yea right. maybe if you're building some tiny project one like 1 platform. anything serious and you're immediately diving through github issues for solutions to problems and poring over the source of both cibuildwheel and pip.

I don't know if it's a feature of Swig, but Swig C++ modules are also hard to use from Python, because they're missing reflection, docstrings, etc. I don't know if it was a shortcoming of the Swig module I was working with (e.g. author didn't bother to add docstrings) or the Swig itself, but it was pretty uncomfortable working with module that provides zero runtime documentation and incomplete documentation.

Also, structure of the resulting module, classes, methods was kind of unpythonic.

CLIF is nice but not under public development and not really getting feature improvements. It's direct connection to LLVM is both a very big strength--it gets industrial-grade C++ parsing from a standards-compliant C++ parser--and it's biggest weakness--building and using it requires sticking with its favored version of llvm sources.

All of that works, especially for Google internally, which uses CLIF quite extensively, but that makes it not so great for external projects.

I’ve used pybind11 to expose C++ to Python. Worked well for me after the initial hurdle of learning what needed to be done.

Cython is pretty good for C interop. Numpy is implemented in it

What about PyBind? I've heard great things about the simplicity of using PyBind for this sort of thing.

For Java (JNI), using SWIG was a very pleasant experience for me. It allowed me to abstract away shared logic to C++ that would otherwise have to be implemented in both Java and Objective-C.

I deeply appreciate comments like this. It's frustrating when a tool sounds like the perfect tool for a job, you sink a bunch of time into it, only to discover this kind of scenario. Sometimes there are early indications, but often not. Thanks for sharing your lived experience.

I've been extremely impressed by pybind11 for c++/python interop.

More than a nightmare, just look at their website.

What's wrong with the website? Seems fine at a glance?

Reply on news.ycombinator.com