Deterministic Memory Management With Standard Library Progress

[Guillaume Piolat via Digitalmars-d]

On Monday, 6 March 2017 at 16:10:51 UTC, Anthony wrote:
> 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.

(Arena pools are an allocator type, unrelated to your question 
(though they are used to lessen GC usage) ).


When I speak about "only-memory" resources I mean resources that 
only hold memory transitively.


class MyClass
{
     string a;
     ubyte[] arr;
     float p;
}

There is not much reason to destroy - or release the memory of - 
a MyClass deterministically since it only references memory. A 
global owner like the GC will do.

In C++ you would find an owner for each std::string, but in D you 
can rely on the GC for releaseing them.

But you shalt not rely on the GC for closing files, releasing 
mutexes, closing sockets... etc. Any object that would hold such 
a resource (or holds an object that holds such a resource) is 
better handled in a manual/RAII way instead. Memory allocated 
with malloc is such a resource too.

In my mind, D programs use a hybrid style of ownership, GC + 
manual/RAII(aka "scoped ownership"). So it's more complex that 
just "scoped ownership" like in C++.