manual memory management

[Timon Gehr]

On 01/08/2013 06:30 AM, H. S. Teoh wrote:
> ...
>
> I don't know if I know them all, but certainly the following are
> GC-dependent:
>
> - Slicing/appending arrays (which includes a number of string
>    operations), .dup, .idup;

Slicing is not GC-dependent.

> - Delegates & anything requiring access to local variables after the
>    containing scope has exited;

Yes, but this does not make delegate literals useless without a GC. 
scope delegate literals do not allocate but instead point directly to 
the stack.

> - Built-in AA's;
> - Classes (though I believe it's possible to manually manage memory for
>    classes via Phobos' emplace), including exceptions (IIRC);

Classes are not GC-dependent at all. 'new'-expressions are GC-dependent. 
(though I think DMD still allows overloading them.)

> - std.container (IIRC Andrei was supposed to work on an allocator model
>    for it so that it's usable without a GC)
>
> AFAIK, the range-related code in Phobos has been under scrutiny to
> contain no hidden allocations (hence the use of structs instead of
> classes for various range constructs). So unless there are bugs,
> std.range and std.algorithm should be safe to use without involving the
> GC.
>

The choice of structs vs classes is kind of necessary. I do not always 
want to write 'save' in order to not consume other copies of the range.
(InputRangeObject notably gets this wrong, this is why it is not used.)

> Static arrays are GC-free, and so are array literals (I *think*) as long
> as you don't do any memory-related operation on them like appending or
> .dup'ing.

Currently, with DMD, array literals always allocate if they are not 
static. (Even if they are directly assigned to a static array variable!)

> So strings should be still somewhat usable, though quite
> limited. I don't know if std.format (including writefln & friends)
> invoke the GC -- I think they do,  under the hood. So writefln may not be
> usable, or maybe it's just certain format strings that can't be used,
> and if you're careful you may be able to pull it off without touching
> the GC.
>

I think they use output ranges under the hood. The main issue is 
toString(), which inherently requires GC allocation.

> AA literals are NOT safe, though -- anything to do with built-in AA's
> will involve the GC. (I have an idea that may make AA literals usable
> without runtime allocation -- but CTFE is still somewhat limited right
> now so my implementation doesn't quite work yet.)
>

I think the fact that it is not possible to save away arbitrary data 
structures at compile time for runtime use is just a limitation of the 
current implementation. Anyways mutable literals require allocation 
because of aliasing concerns.

> But yeah, it would be nice if the official docs can indicate which
> features are GC-dependent.
>
>
> T
>