Disable GC entirely

[Johannes Pfau]

Am Mon, 08 Apr 2013 11:57:08 +0100
schrieb "Regan Heath" <regan at netmail.co.nz>:

> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman at gmail.com> wrote:
> > I suspect Andrei for one knows this, and that's why the D
> > containers are so... barely existing. The language is not yet ready
> > to say with confidence
> > how they should look.
> 
> That, and before you can design the containers you need a concrete  
> allocator interface design.  Actually, this is likely the same
> blocker for GC-free D as well.
> 
> D should have a set of global allocator hooks.  If it did, you could  
> easily catch unexpected allocations in tight loops and realtime
> code.  If it did, GC-free D would be trivial - just replace the
> default GC based allocator with a malloc/free one, or any other
> scheme you like.
> 

IIRC stuff like closures and dynamic array appending rely on a gc and
it wouldn't be trivial to change that to a normal alloc/free allocator.

A good & simple start would be a -vgc switch, similar to -vtls which
prints out all hidden memory allocations. Custom allocators are still
important for the library (toString etc). Apart from that I would just
stay away from language features which allocate. For example instead of
using the concatenate operators I'd just use something like appender
(which should then support custom allocators).