wg-allocators VS dpp

Tracking issue for Storages, and a TLDR on what it is

I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7

Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.

It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7

do you know dpp ? https://github.com/atilaneves/dpp

give https://github.com/atilaneves/dpp a try ... I made it work and I'm not very literate in C

Which is capable of directly linking + invoking most C++ things (except constructors/destructors, it can't handle those, you need a function which calls the constructor from within C++) just given a type definition.

Then you have "d++", which lets you "#include" C/C++ headers. Under the hood tries to run an automatic syntax conversion. It can't handle but for simple code it works and can spit out the equivalent D.

https://github.com/atilaneves/dpp

Also you've got "dstep", which is "A tool for converting C and Objective-C headers to D modules"

https://github.com/jacob-carlborg/dstep

And finally you have the somewhat abandoned (but as far as I know mostly functional) Calypso, which is a fork of the LLVM-based D compiler that supports direct interop with C++. It's a pain to build though, haven't gotten around to trying to build it, but it does look wicked cool:

https://github.com/Syniurge/Calypso

    pragma (cppmap, "cppheader.h");  // tells Clang to parse cppheader.h but do not import anything

dpp* can't do function definitions yet but for declarations it's as easy as #including a C header file natively.

* https://github.com/atilaneves/dpp