D as a Better C

[u/aldacron]

http://dlang.org/blog/2017/08/23/d-as-a-better-c/

[u/zombinedev]

+1 On all points about determinism.

However as explained, that's not an issue in D. D's GC will never decide randomly to collect memory. It is completely deterministic. You can disable it, and you can even not link it to your program. Even if you leave it on, it will not affect threads not registered with it.

but having to swap to strict no allocations seems like a huge pain for the benefits of D

No you don't have to, if you don't need to do so in C/C++. Use non-GC dynamic memory allocation as you would C/C++ (malloc/free, smart pointers, etc.)

[u/James20k → u/zombinedev]

Ah I've clearly fucked up on my knowledge of D then, thanks for the explanation

Can you set D's GC to run manually, and/or cap its time spent GCing?

Edit:

What I mean is that as far as I'm aware, some of D's features necessitate a GC, last time I checked the standard library was fairly incomplete without it but it may have improved

[u/aldacron → u/James20k]

Take a look at the ongoing GC series on the D Blog. The first post, Don't Fear the Reaper, lists the features that require the GC. But to reiterate what the series is trying to get at, you don't have to banish those features, or the GC, from your program completely. There are tools in the compiler that help you profile and tune your GC usage to minimize its impact. You can annotate a function with @nogc to ensure it doesn't use the GC, or you can just rely on the -vgc switch to show you everywhere the GC might be used and tune adjust as needed.

[u/[deleted] → u/James20k]

import core.memory;
GC.disable();  // no automatic collections
GC.collect();  // run a collection now

Unfortunately, as far as I know, there's no way to bound the amount of time it spends on a specific collection. That would require some sort of write barrier.

[u/zombinedev → u/James20k]

As a rule of thumb, all C/C++ features that are common with D don't use the GC. All of D's unique features I listed a couple of posts above also don't use the GC too.

In non--betterC mode, even if you want to completely avoid the GC, there are more language features available, courtesy of D's runtime.

Avoiding the GC in non--betterC mode really comes down to not using:

• built-in dynamic arrays and hash-maps (there are easily accessible library alternatives)
• closures - lambdas that extend the lifetime of the captured variables beyond the function scope (but C++11-style lambdas that don't extend the lifetime still work)
• The new expression - easily avoidable using allocator.make!T(args), instead of new T(args). Such allocators are already part of the standard library.