Am Mon, 08 Apr 2013 11:57:08 +0100 schrieb "Regan Heath" <[email protected]>:
> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <[email protected]> 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).
