I can has @nogc and throw Exceptions?

[Adam Sansier via Digitalmars-d-learn]

On Wednesday, 13 July 2016 at 20:57:49 UTC, Lodovico Giaretta 
wrote:
> 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;

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.