Deterministic Memory Management With Standard Library Progress

[Anthony via Digitalmars-d]

On Sunday, 5 March 2017 at 13:32:04 UTC, Moritz Maxeiner wrote:
>> I was referring to phobos. I feel intimidated by the idea of 
>> trying to code some of the functions of phobos myself in a 
>> no-gc manner. I'm sure I'd run into things way out of my 
>> knowledge domain.
>
> I get that, though usually Phobos code is fairly readable if 
> you've got a firm grasp of D templates.

Hmm. This is encouraging news to here, given that templates were 
the most recent topic I've learned in D. Maybe I'll just have to 
give GC-reliant areas a read. Although I don't know what those 
areas would be; AFAIK I'd have to look for @nogc tags, which 
sounds tedious.

As for Guillaume Piolat's Advice:
> - Use struct RAII wrappers and destructors to release 
> resources. Typically structs with disabled postblit. However 
> very often resources are classes objects because they feature 
> virtual dispatch.

>- In destructors, call .destroy on members that are class 
>objects (reverse order of their creation if possible). Also on 
>heap allocated struct but those are rare. The idea is that when 
>the GC kicks in, unreachable objects on the heap should already 
>have already been destroyed.

>- Don't let the GC release resources, with the "GC-proof 
>resource class idiom". I remember Andrei pushing for the GC not 
>to call destructors, to no avail. So the GC is calling 
>destructors and you should use it as a _warning that something 
>is wrong_ and determinisim wasn't respected, not as a safety 
>measure and a way to actually release resources (because it's 
>wrong thread, wrong timing, unreliable).

>- Like in C++, if your ownership is in the case where it's 
>shared, you can introduce artificial owners (eg: arena pool owns 
>arena pool items).

>- The resources that are only memory need no owner and can be 
>managed by the GC.         (eg: strings, a ubyte[] array...)

>When you have deterministic destruction, it's simple to offload 
>work from GC to manual memory management. You don't loose ANY 
>main feature.

>The GC is an efficient way to call free(), and a global owner 
>not a way to release resources.

This is also encouraging! Thanks for the concrete advice. But, I 
think due to my inexperience, to don't really understand some of 
your advice. Specifically, the only-memory recourses like strings 
and arrays can be managed by the GC, and arena pools. I can just 
look these things up, but I figured it'd be easy to ask first.