rust-cpp VS derive_more

I am the current passive maintainer of the cpp crate: https://github.com/mystor/rust-cpp

I would like to utilize OMPL's functionality in Rust code, so I want to call into OMPL C++ code somehow in Rust. I've seen two (non-mutually-exclusive) options so far: - rust-cpp, which allows you to write C++ code in Rust within the cpp!() macro. - cxx, which allows you to define both sides of the FFI boundary manually (as opposed to bindgen's automatic generation).

There's also the cpp and cxx crates for doing C++/Rust interop, but they probably aren't appropriate to use in all cases. The C ABI is definitely the safest way to go unless you're really trying to marry Rust and C++ code bases, not just writing library bindings.

https://github.com/mystor/rust-cpp <- not a transpiler, but almost as good

Otherwise, C would never have achieved success in MS-DOS when all the stuff it was binding to at the time required blocks of inline assembly. (Crates like rust-cpp do exist, which allow "inline C++" in the same way that C++ allows inline assembly.)

Actually, you can make inline C++ macro in Rust. Similar unholy monstrosities exist for inline python, inline C, inline SQL, inline HTML,...

Here is a more serious project that allows to embed C++ code directly in your Rust code: https://github.com/mystor/rust-cpp

Don't underestimate the power of procedural macros: https://github.com/mystor/rust-cpp

Alright, thanks for all your ideas! I also found this mystor/rust-cpp, which apparently allows inline c++ as opposed to cxx. Having yet to try out any of these, I like the idea of inline code more. Thought now I feel I need to brush up my skills a bit more to try this stuff out.

Is there a way to use derive_more to handle the generation of binary operators with one or both referenced operands? For example, avoiding having to do this macro dance for every combination of MyVal and &MyVal, for every operator needed:

This fails to compile. Looking at the implementation for that macro I don't see a way to use it that would work: https://github.com/JelteF/derive_more/blob/master/impl/src/from.rs

tl;dr you can put commit hashes in the place where the parent comment put tags.

The PR interface actually exposes this for force-pushes, but the UI discovery for this is horrible. It turns out that the "force-pushed" part in the little message in the github UI is actually a link. This link points to the diff between the old and the new HEAD of the branch.

As an example you can look at this PR:

It has this little message somewhere down the page:

Monadic-Cat force-pushed the add-unwrap branch from e130dbe to 25235aa 4 months ago

If you then click that link you go to the "compare" page, which shows the diff between the two commits:

https://github.com/JelteF/derive_more/compare/e130dbe6b2a429...

Disclaimer: I'm a Micrsoft employe, but don't work on Github. I'm a daily user of Github though.