I can has @nogc and throw Exceptions?

[Adam Sansier via Digitalmars-d-learn]

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.