On Wednesday, 13 July 2016 at 21:27:16 UTC, Lodovico Giaretta
wrote:
On Wednesday, 13 July 2016 at 21:12:29 UTC, Adam Sansier wrote:
[...]
Ok, I like!
[...]
I like too! But I'll have to assume you are right since I have
no proof.
[...]
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 ;)
[...]
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.
Ok. Is there a way to bundle allocations so that one free will
work?
For example, your exception handling looks good but I need to
supply custom messges. If I use sformat I have to create the
array for the buffer to create the message in. This means I would
have to free both the exception and the string. It would be nice
to be able to do this in one go.
Also, could one create a struct or class for the exception so
that it is automatically free'ed at the end of a catch block, if
caught? Probably not without language help?
Sometimes it's nice to include runtime info in an error message
such as an OS error code.
