Deterministic Memory Management With Standard Library Progress

[cym13 via Digitalmars-d]

On Saturday, 4 March 2017 at 18:09:10 UTC, Anthony wrote:
> I've been having difficulty finding an up-to-date answer to 
> this question, so I figured I'd ask the forum: can 
> deterministic memory management be done in D, without losing 
> any main features? I ask this because I know it's technically 
> possible, but the methods that are suggested in the answers 
> I've read always suggest the avoidance of most of the standard 
> library. I know that there is an effort to reverse the reliance 
> on the GC, but I don't know how far that's gotten in the last 
> six months. Would anyone be able to give me more information?
>
> To give context to my question, I don't have a problem with 
> GCs, and this question isn't stemming from a C++ background. 
> I've been told to learn C++ though, due to its efficiency and 
> power.
>
> It feels like D is a better choice for me to learn than C++; 
> it's ostensibly C++ but with various amounts of baggage or 
> unfavorable quirks removed. But I'm wary to learn if one of the 
> major proponents for C++ usage, deterministic memory 
> management, isn't directly supported. I check back here every 
> few months or so, but now I just can't find anything new.

Well, you said it, the key point is "without losing main 
features".

There's quite a chunk of the standard library that is @nogc, 
almost everything in std.algorithm for example (to the exception 
of one function IIRC, minor enough I can't remember which). Aside 
from that most modules providing some form of reading or encoding 
also provide two sets of methods: one that asks for an external 
buffer which you can use, the other that automatically allocates 
a buffer to alleviate the need to manually manage it (GC-ed).

The other problem with the GC in the standard library is the 
exception one: as we have GC-ed exceptions by default (to avoid 
having to manually free them) no function using exceptions can be 
@nogc. However one should realistically note that allocation of 
exceptions is and should stay exceptional so there are cases 
where you could decide to use a cast to force an exception-using 
function into a @nogc scope.

Finally GC problems are completely exagerated. It only runs when 
used so having it to manage exceptions only for example is 
completely viable, and it is possible to dereference threads if 
you don't want them to be seen by the GC. Using GC globally and 
avoiding it locally on heat points has proved to be a successful 
strategy within the community. So I wouldn't worry too much, 
giving it a try is paramount.