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

[rikki cattermole via Digitalmars-d-learn]

On 01/06/2016 7:59 PM, Anthony Monterrosa wrote:
> 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.

They get called once memory has been allocated and before it is deallocated.

>  - 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).

No. core.memory provides an interface to the GC, not malloc and friends.

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

Not all arrays. Slices are not required to use the GC, just don't go 
appending to it.

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

GCAllocator uses the GC yes. It is the default one for theAllocator() 
and processAllocator().
However there are others such as Mallocator which do not use the GC but 
directly call malloc and friends.

>  - 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.

Oh but you can!
https://github.com/dlang/druntime/blob/master/src/gcstub/gc.d

Now imagine replacing all those useful little function implementations 
with assert(0); Then you can never use 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?

People view the GC as a bad thing. Most of the time it is only ever a 
good thing.
You're not writing a AAA game here and even then you might be able to 
get away with it by just being a little bit careful and disabling it.

If you have some code that needs to be speed up? Sure preallocate memory 
will always give you speed boosts. But the GC generally won't cause that 
many problems especially if its disabled for the hot places.