4 ms·

Are you familiar with this? https://github.com/rust-lang-nursery/rust-bindgen https://github.com/rust-lang-nursery/rust-bindgen It will translate a C header i

Are you familiar with this? https://github.com/rust-lang-nursery/rust-bindgen https://github.com/rust-lang-nursery/rust-bindgen It will translate a C header into Rust for all your bindings. Something could probably be built to do this more on the fly. If it doesn't already exist. edit: docs link https://docs.rs/bindgen/0.30.0/bindgen/ https://docs.rs/bindgen/0.30.0/bindgen/ edit2: and I should mention the inverse, Rust to C bindings, https://github.com/eqrion/cbindgen https://github.com/eqrion/cbindgen https://docs.rs/cbindgen/0.1.23/cbindgen/ https://docs.rs/cbindgen/0.1.23/cbindgen/

johncolanduoni 9y ago
Bindgen is excellent with C APIs but what I've found really impressive is that it can handle C++ pretty well too. Most of my issues with using C++ code via bindgen are due to deviations in calling conventions that are hard to solve at that level.
JoshTriplett 9y ago
And as soon as procedural macros are stabilized, I'm sure that someone will provide a bindgen macro that would let you do something like bindgen!("somelib.h").
chubot 9y ago
Yeah that is part of it, but I also like the lighter design philosophy I see Zig. It's the difference between thinking about compatibility up front vs. clean-slate design + compatibility. If you look at the Python vs. Lua C API you can see that difference. Lua was designed to interoperate with C (albeit after breaking the language 4+ times); Python just took whatever their implementation happened to be, and then exposed that API to users. With thousands of functions and macros and GIL and whatnot. Then a bunch of people came along later and wrote 5 different binding generators, and all of them solved some the problem, but not all of the problem. And some of them created new problems (SWIG). Also (to child comment), is it really possible to do bindgen as a macro rather than as a separate code generating tool? Because I assume bindgen has to invoke a C++ parser like Clang. I looked at Zig and it indeed uses libclang to parse C. I don't know about Rust's macro system but it would be somewhat surprising if it can invoke external tools or run C++ code at compile time.
- bluejekyll 9y ago
  Procedural macros aren't the macro_rules and custom derives that are currently in stable. They allow you to do much more. You can see this put to use in the Rocket project quite heavily. I believe it should be possible to link against bindgen as described and generate the bindings inline. The caveat here is that it would be fairly opaque to the user as you wouldn't see the generated bindings in code. For situations like that I rely on 'cargo doc' to generate the documentation such that I can see the actual interface generated. Rocket codegen for example: https://github.com/SergioBenitez/Rocket/tree/master/codegen https://github.com/SergioBenitez/Rocket/tree/master/codegen
- simias 9y ago
  You also have to take into account that Rust has a borrow checker that makes opaque C calls 2nd class citizens anyway. Zig doesn't have that as far as I can tell. So it means that even if Rust had a standard C header include directive it still wouldn't be completely transparent because most of the time you want to wrap around C APIs in Rust to provide safe, borrow checked and pointer-free alternatives. There's a different philosophy I think.
- steveklabnik 9y ago
  > I looked at Zig and it indeed uses libclang to parse C. I don't know about Rust's macro system but it would be somewhat surprising if it can invoke external tools or run C++ code at compile time. Bindgen is often invoked in a "build script", which Cargo runs before building your project. So not exactly, but basically.

johncolanduoni 9y ago

Bindgen is excellent with C APIs but what I've found really impressive is that it can handle C++ pretty well too. Most of my issues with using C++ code via bindgen are due to deviations in calling conventions that are hard to solve at that level.

JoshTriplett 9y ago

And as soon as procedural macros are stabilized, I'm sure that someone will provide a bindgen macro that would let you do something like bindgen!("somelib.h").

chubot 9y ago

Yeah that is part of it, but I also like the lighter design philosophy I see Zig. It's the difference between thinking about compatibility up front vs. clean-slate design + compatibility. If you look at the Python vs. Lua C API you can see that difference. Lua was designed to interoperate with C (albeit after breaking the language 4+ times); Python just took whatever their implementation happened to be, and then exposed that API to users. With thousands of functions and macros and GIL and whatnot. Then a bunch of people came along later and wrote 5 different binding generators, and all of them solved some the problem, but not all of the problem. And some of them created new problems (SWIG). Also (to child comment), is it really possible to do bindgen as a macro rather than as a separate code generating tool? Because I assume bindgen has to invoke a C++ parser like Clang. I looked at Zig and it indeed uses libclang to parse C. I don't know about Rust's macro system but it would be somewhat surprising if it can invoke external tools or run C++ code at compile time.

bluejekyll 9y ago
Procedural macros aren't the macro_rules and custom derives that are currently in stable. They allow you to do much more. You can see this put to use in the Rocket project quite heavily. I believe it should be possible to link against bindgen as described and generate the bindings inline. The caveat here is that it would be fairly opaque to the user as you wouldn't see the generated bindings in code. For situations like that I rely on 'cargo doc' to generate the documentation such that I can see the actual interface generated. Rocket codegen for example: https://github.com/SergioBenitez/Rocket/tree/master/codegen https://github.com/SergioBenitez/Rocket/tree/master/codegen
simias 9y ago
You also have to take into account that Rust has a borrow checker that makes opaque C calls 2nd class citizens anyway. Zig doesn't have that as far as I can tell. So it means that even if Rust had a standard C header include directive it still wouldn't be completely transparent because most of the time you want to wrap around C APIs in Rust to provide safe, borrow checked and pointer-free alternatives. There's a different philosophy I think.
steveklabnik 9y ago
> I looked at Zig and it indeed uses libclang to parse C. I don't know about Rust's macro system but it would be somewhat surprising if it can invoke external tools or run C++ code at compile time. Bindgen is often invoked in a "build script", which Cargo runs before building your project. So not exactly, but basically.