Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
As the author of the WinSafe lib, I wholeheartedly agree.
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.
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.
In that case you want to keep most of the unsafe in the HAL crate, and expose an interface as safe as possible. To give you an idea, is it since 2018 that a "generic" DMA safe implementation is in discussion https://github.com/rust-embedded/embedded-hal/issues/37
You mean the legacy symbol naming scheme? A new mangling scheme that includes full type information and avoids compiler-internal junk like that hash was merged four years ago. Granted, TIL it's not the default yet, but it's been available with -C symbol-mangling-scheme=v0 since v1.59 from Feb 2022. That indicates to me moving towards ABI stability, not away from it.
More info here: https://rust-analyzer.github.io/ and here: https://rust-analyzer.github.io/manual.html#installation