On Wednesday, 13 July 2016 at 21:12:29 UTC, Adam Sansier wrote:
The advantages over a simple malloc are:
1) You can change between GC allocation, malloc, mmap and
other allocators by changing a single line, instead of
changing every throw;
Ok, I like!
2) you can use very fast allocators, based on your needs; this
example uses the Region allocator, which is way faster than a
call to malloc;
I like too! But I'll have to assume you are right since I have
no proof.
3) the Region allocator has the added value of working even if
there's no more memory available (because it preallocated it).
Well, one could do this with malloc because one can
pre-allocate it too. I figure this is why you stated 2 though
because it is pre-allocated? So, really only point 1 stands,
but that is probably not even valid since one can wrap the
allocator in a template. This is probably exactly what is being
done..
So, ultimately no real benefit except the implementation
details have been removed. That's not a bad thing as long as it
works ;)
In general, the allocators library provides facilities that
may seem overkill for simple tasks (and in fact they are), but
prove very flexible and useful for advanced uses, or to write
generic highly customizable code.
Of course, being experimental, this library has still some
issues...
Well, I will try out the code and see. You've provided an
example and if it works then it should be good enough in my
case. If it doesn't limit what I need to do then I'm happy ;)
How is phobo's going to deal with such things when it is trying
to get off the GC? It surely has to throw exceptions. Similar
method or something entirely different?
Thanks.
At the end, all memory comes from one of these: GC heap, malloc,
mmap, sbrk. All other allocators build on top of these (or on top
of user supplied buffers, which come from these as well). What
those "wrapper" allocators do is managing the given memory,
either using different allocations strategies for different
allocation sizes, or keeping lists of free blocks instead of
returning them using "free", or other things (have a look at the
docs). So at the end they do what you would manually do in C/C++
to "personalize" the allocations, with the aim of reducing waste
and/or being faster. They are also arbitrarily composable on top
of each other.
I don't know how Phobos will handle exceptions. Maybe use
reference counting (coming soon in D, maybe)? Maybe algorithms
that already have to allocate will switch from using the GC to
using a user-supplied custom allocator, and will use it for
exceptions too.
Currently I'm working on a replacement for std.xml and I'm making
every component take a template parameter to specify the
allocator. Initially the allocators look like a real mess, but
after a couple of days playing with them, you start understanding
the mechanics and at the end you really enjoy them. Changing a
single parameters allows to switch between @safe gc code and
@nogc code in the unittests, without changing the implementation.
