I can has @nogc and throw Exceptions?

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 13 July 2016 at 20:44:52 UTC, Adam Sansier wrote:
> On Wednesday, 13 July 2016 at 16:28:23 UTC, Lodovico Giaretta 
> wrote:
>>
>> It's actually quite easy. Here's the code (untested):
>>
>> ================================================================
>>
>> import std.experimental.allocator.building_blocks.region;
>> import std.experimental.allocator.mallocator;
>> import std.experimental.allocator;
>>
>>
>> Region(shared(Mallocator)) exception_allocator;
>> enum EXCEPTION_MEM_SIZE = 256*1024;
>> static this()
>> {
>>     exception_allocator = 
>> typeof(exception_allocator)(EXCEPTION_MEM_SIZE);
>> }
>>
>> ================================================================
>>
>> And here is an usage example (untested, too):
>>
>> ================================================================
>>
>> void throwingFunction()
>> {
>>     // try to do something, but fail
>>     throw exception_allocator.make!Exception("my wonderful 
>> error message");
>> }
>>
>> void throwingThrowingFunction()
>> {
>>     try
>>     {
>>         // try to call function, which fails
>>         throwingFunction;
>>     }
>>     catch (Exception exc)
>>     {
>>         // try to recover from failure, but generate other 
>> exception (just to show chaining)
>>         throw exception_allocator.make!Exception("I love 
>> exception chaining");
>>     }
>> }
>>
>> void main()
>> {
>>     try
>>     {
>>         // try to call function, which fails
>>         throwingThrowingFunction;
>>     }
>>     catch (Exception exc)
>>     {
>>         // recover from failure, then deallocate the 
>> exceptions no longer needed
>>         exception_allocator.deallocateAll;
>>     }
>> }
>> ================================================================
>
> Doesn't work. identifier expected on shared.
>
> What's the difference of simply using malloc to allocate the 
> memory and creating the exceptions their? Seems like a long and 
> winded way go about it or is there some benefit to using the 
> experimental allocators?

`Region(shared(Mallocator))` shall be `Region!(shared 
Mallocator)` (again, I'm just looking at the code, didn't test 
it).

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;
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;
3) the Region allocator has the added value of working even if 
there's no more memory available (because it preallocated it).

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...