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
