On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu
On 4/9/17 4:56 AM, Atila Neves wrote:
Using std.experimental.allocator? Tired of writing
`scope(exit) allocator.dispose(foo);` in a language with RAII?
I think the code in the README should be enough to understand
what's going on. Alpha stuff here but I think the main things
missing are weak pointers and a ref counted array. Given that
I've never had to use std::weak_ptr in C++, I'm not in a hurry
to implement the former.
Notable design decisions / features:
. The smart pointers are responsible for allocating the memory
for the container object using the allocator of choice. This
is to guarantee that one can't allocate and deallocate using
. The allocator has to be specified as part of the type: this
means the user can choose how to store it in the smart
pointer, which for singletons (e.g. Mallocator) or stateless
allocators means they can take up zero space. If a singleton
(or the default theAllocator), the allocator doesn't need to
be passed in to the constructor, otherwise it does.
Specifying, e.g. Mallocator also means the relevant code can
be marked @nogc.
After extensively studying how C++ allocator framework works, I
got to the notion that making the allocator part of the type is
I was aware of this, but here we have a crucial workaround -
theAllocator, which is the default anyway. It's probably the best
of both worlds, since you can still specify the type if needed,
which also means the guarantee of @nogc if needed.
. RefCounted only increments/decrements the ref count
atomically if the contained type is `shared`
Great. Can RefCounted itself be shared? I learned this is
important for composition, i.e. you want to make a RefCounted a
field in another object that is itself shared, immutable etc.
Since it has a destructor, no:
The only way to do that would be to split it into two. Which I
guess I could with a template mixin implementing the guts.
. RefCounted!(shared T) can be sent to other threads.
. UniqueArray behaves nearly like a normal array. You can even
append to it, but it won't use GC memory (unless, of course,
you chose to use GCAllocator)!
This may be a great candidate for the standard library.
I think this needs to be used in production first, and having it
as a dub package makes it easy for people to do so.