automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

[Atila Neves via Digitalmars-d-announce]

Using std.experimental.allocator? Tired of writing `scope(exit) 
allocator.dispose(foo);` in a language with RAII? Me too:



http://code.dlang.org/packages/automem

Example:

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 
different allocators.
. 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.
. RefCounted only increments/decrements the ref count atomically 
if the contained type is `shared`
. 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)!

I benchmarked RefCounted against C++'s std::shared_ptr comparing 
ldc to clang using both shared and non-shared payloads in D. 
std::shared_ptr is faster (I've never written a smart pointer 
before), but the advantage of non-atomic operations makes my D 
implementation just a bit faster when non-shared. I think with 
some work it can be significantly faster without any loss of 
thread safety.

Atila