January 11, 2013
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
>

January 12, 2013
On 01/09/2013 08:33 AM, Rob T wrote:
> On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>>> Well, you CAN indeed, create a dumbed down language that is memory
>>> safe and don't require a GC.
>>
>>
>> Yeah, that's 1 of my 2 points.
>>
>>
>> The other one you still ignored: the GC doesn't bring much to the
>> table. (Re C# Java etc.)
>
> There is a point being made here that is perfectly valid. There is a
> form of memory leak that a GC can never catch, such as when when memory
> is allocated and simply never deallocated by mistake due to a persistent
> "in use" pointer that should have been nulled but wasn't.
> ...

This is not entirely accurate. A GC does not necessarily have to assume that every reachable pointer will be accessed again. Every memory leak can be caught by some GC, but no GC catches all.

6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »