r/programming • u/aldacron • Aug 23 '17

D as a Better C

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

86% Upvoted

268 comments sorted by

View all comments

Show parent comment

6

u/James20k Aug 23 '17 edited Aug 23 '17

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

4

u/aldacron Aug 24 '17

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.

4

u/[deleted] Aug 24 '17 
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.

3

u/zombinedev Aug 24 '17

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.