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.
