Preferred method of creating objects, structs, and arrays with deterministic memory management

Anthony Monterrosa via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Jun 1 00:59:50 PDT 2016


I've recently been trying to convince a friend of mine that D has 
at least the functionality of C++, and have been learning the 
language over C++ for a few months. Memory management is pretty 
important to him, and a subject I'm honestly curious about as 
well. I was wondering: what's the preferred method for 
deterministic memory management?

I don't know much about this topic relative to most (Java 
background), but this is what I've found:

  - Classes/Structs have constructors and destructors. I am 
unconfident with my knowledge as to how this works with malloc 
and free.

  - core.memory can be used to call malloc and its buddies. It 
allows determined management, but will still use the GC if 
something isn't collected (presumably for leaks).

- Many features and types use the GC such as exceptions, the new 
keyword, and all arrays except statics.

  - Allocators in "std.experimental.allocators" still use the GC, 
but give more control for class/struct objects.

  - std.container.array can be used for deterministic arrays, but 
has the issue of dangling pointers. There is probably a good 
solution to this, but I don't know it.

  - There seems to be no way to completely turn off the GC. That 
is, never have the runtime allocate the memory used by the GC.

  - Andreau had a discussion in 2009 about how this issue might be 
handled, but there didn't seem to be an obvious consensus 
(http://forum.dlang.org/thread/hafpjn$1cu8$1@digitalmars.com?page=1)

This are the pieces I've gathered, but I don't really know what's 
true or how to use this knowledge. Some ideas I've gleaned may 
also be outdated. Does anyone know the "correct" way one would go 
about a non-GC program, and if a program can be ran without ever 
instantiating a GC? Has there been any progress on reducing the 
std library's usage of the GC?


More information about the Digitalmars-d-learn mailing list