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

[Rene Zwanenburg via Digitalmars-d-learn]

> I was wondering: what's the preferred method for deterministic 
> memory management?

You may be interested in RefCounted. It only works for structs, 
not classes, but it's still useful.

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

malloc() and free() operate on a lower level, they only care 
about raw memory. When you malloc() some space, you can construct 
an object there using emplace(), and it can be destructed by 
using detroy().

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

It's important to differentiate static arrays, and slices with 
static storage. For example:

class C
{
   static int[] someSlice; // This is a slice with static storage. 
The memory it is referring to may be GC allocated, but it doesn't 
have to (this is true for all slices btw).

   int[4] someStaticArray; // This is a static array, i.e. an 
array with a fixed length. In D static arrays are value types, so 
it's allocated in its enclosing scope and copied when you pass it 
around.
}

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

I don't know of any dangling pointer issues with Array. It's 
possible to create cycles resulting in a leak, but that's only 
likely to happen if you heavily rely on refcounting everything.

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

Like Rikki said, if you really want to the GC can be replaced 
with an asserting stub. This isn't as hard as it sounds, just add 
something like the file he linked to to your project. Since all 
declarations are extern(C) there is no name mangling, and the 
linker will prefer your own definitions over the ones in 
druntime. I don't recommend you do this though unless you really 
know what you're doing.

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

You can annotate your functions as @nogc. The compiler will 
disallow any potential GC use, including calling other functions 
that are not @nogc.

P0nce is doing real time audio stuff, iirc he's using a thread 
with a @nogc entry point for the strictly real-time parts, and 
regular GC-using code in another thread for everything else.