Data-Flow (Escape) Analysis to Aid in Avoiding GC

[Tobias Pankrath via Digitalmars-d-learn]

On Friday, 13 February 2015 at 12:40:57 UTC, Per Nordlöw wrote:
> On Friday, 13 February 2015 at 11:52:50 UTC, Tobias Pankrath 
> wrote:
>> On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote:
>>> On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
>>>> Whether s.front uses GC is determined by s.front 
>>>> implementation, caller can't affect it.
>>>
>>> Compiling
>>>
>>> https://github.com/nordlow/justd/blob/master/t_splitter.d
>>>
>>> with -vgc on dmd git master gives no warnings about GC 
>>> allocations!
>>>
>>> Is this really true!?
>>
>> Why should splitter.front allocate?
>
> Ahh, I think I understand now. I thought that slice creations 
> ment GC-allocation but it doesn't right? It just increases a 
> reference counter somewhere and creates a stack context for the 
> slice right?

There are no reference counts involved, just simple arithmetic.

string a = "abc";
string b = a[1 .. $];

struct Slice(T) { T* ptr; size_t length };

Slice!char a = { <ptr_to_constant, 3 }
Slice!char b = { a.ptr + 1, 2 }



> But what about to!string in
>
>     auto x = line.strip.splitter!isWhite.joiner("_").to!string;
>
> ?

That needs to allocate.

Probably -vgc only lists GC allocation inside the current scope 
and doesn't look inside called functions. For this, there is 
@nogc.