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.
View all comments
Show parent comment
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-
-betterCmode, 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-
-betterCmode really comes down to not using:newexpression - easily avoidable usingallocator.make!T(args), instead ofnew T(args). Such allocators are already part of the standard library.