I have a plan.. I really DO

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jul 6 16:46:33 UTC 2018


On Friday, 6 July 2018 at 16:10:04 UTC, Ecstatic Coder wrote:
[...]
> With D, I CAN'T use the language and its standard library as 
> usual, just because of the GC "phobia".
>
> Which would be the #1 problem for me, because "standard" D is 
> perfect to me, as much as "standard" C++ is nice to me.
>
> That's my point.

Uhm... have you actually *tried* to do this in D?

I have a project where, for various reasons, I need to control 
exactly when the GC runs a collection cycle.  The code is not 
@nogc; in fact there are array allocations and AA allocations all 
over the place. And it's idiomatic D code with heavy Phobos use. 
But all I need to do is:

import core.memory;
GC.disable();
... // tons of code, including allocating code, Phobos calls, etc.
if (okToCollect)
    GC.collect();
... // more allocating code
GC.enable();

No collection cycles will run in the code marked "...", because 
the GC has been disabled. That means you can happily allocate 
stuff away and there will NOT be any GC stop-the-world pauses.  
Of course, I don't want memory to leak away freely either, so at 
strategic points in the code, I call GC.collect() to clean up. 
IOW, I can predict, and *control*, when exactly I want to spend 
time to clean up my memory.

Then when I'm in a less-critical part of the code, I just 
re-enable the GC and let it do its job.

I know what you're going to say next.  There are cases where this 
level of control is not fine enough.  That's true, and that's 
where things like @nogc will help you.  But the blanket statement 
that you "can't use the language and its standard library as 
usual" just because of GC-phobia is, at best, inaccurate.


More information about the Digitalmars-d-announce mailing list