I can has @nogc and throw Exceptions?

[Lodovico Giaretta via Digitalmars-d-learn]

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.