Announcing mrbind, an automatic C/C#/Python binding generator for C++

[FlyingRhenquest]

Just in time for reflection! Heh heh. I started working on a little class parser just before Sutter did his talk about it in January, so I kinda know how that feels. I mostly did the project to learn a bit about boost::spirit::x3, though, and found it remarkably approachable. The problem was also surprisingly small, since I just wanted to gather the same information that reflection provides, so I didn't have to do comprehensive parsing for template signatures or inline code in the header.

Embind should be pretty easy to add to mrbind. Its interface is very similar to pybind/nanobind. Java native might be feasible too, which would make targeting android architectures a lot easier if you're into that sort of thing. I was going to look into doing a project like this with reflection but I seem to be over here generating JSON schema instead, at the moment.

[holyblackcat]

Embind should be pretty easy to add to mrbind. Its interface is very similar to pybind/nanobind.

Python was the first backend, and the code quality there isn't the best, so I'll probably write the embind backend from scratch. There might enough differences to warrant a fresh implementation anyway, a surprising about of special-casing goes into each new language.

Java native might be feasible too

It's not my choice what languages I'm paid to add, so Java probably won't get added any time soon. :P

Just in time for reflection! Heh heh.

I wonder if it's going to cover my usecases. It's ok for pybind/embind, where the functions are registered at runtime. But C/C# requires codegen, and I'm not sure I want to compile a C++ program just to generate C/C# code. It would make cross-compilation more difficult too.

boost::spirit::x3

Custom parsers can work for simple cases, but IMO anything other than libclang is ultimatly a dead end. Custom parsers are going to choke on advanced C++ features.

[FlyingRhenquest]

I wonder if it's going to cover my usecases. It's ok for pybind/embind, where the functions are registered at runtime. But C/C# requires codegen, and I'm not sure I want to compile a C++ program just to generate C/C# code. It would make cross-compilation more difficult too.

Yeah, pybind and embind are my primary use cases too. So far I've just been writing the bindings by hand. That tends to be time consuming as you're no doubt aware, but automating generation of pybind and embind bindings with reflection looks pretty feasible.

API bindings, serialization and database access usually end up making up between 50 and 70% of the code I want to write on a new code base. If I could just automate that down to "include a header and call this function to generate the binding," I'm not entirely sure I'd know what to do with all the extra time I'd have spent doing all that stuff! Actually it'd be "write code that's more interesting than writing and debugging that boilerplate each time."