http://d.puremagic.com/issues/show_bug.cgi?id=1760

           Summary: Closures - Variable unnecessarily allocated on heap
           Product: D
           Version: 2.009
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: trivial
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: xnknet@gmail.com


Using this sample code:

int delegate() three(){
        int a = 35;
        int b = 60;
        int c = 75;

        int geta(){ return a; }
        int getb(){ return b; }

        writeln(&a);
        writeln(&b);
        writeln(&c);

        return &geta;
}

void main(){
        three();
}


Prints:
892FF4
892FF8
12FF28

This means that 'int b' is allocated on the heap, even though the function 'int getb()' is never referenced.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1760


matti.niemenmaa+dbugzilla@iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|trivial                     |enhancement




------- Comment #1 from matti.niemenmaa+dbugzilla@iki.fi  2008-01-01 11:19 -------
Not a bug, but a limitation.


-- 

d-bugmail@puremagic.com wrote:

> is means that 'int b' is allocated on the heap, even though the function 'int getb()' is never referenced.

As Matti says, sort of a limitation, but not really one it is possible to solve because the compiler can never know if an object referencing it is linked in later on.

-- 
Lars Ivar Igesund

Lars Ivar Igesund wrote:
> d-bugmail@puremagic.com wrote:
> 
>> is means that 'int b' is allocated on the heap, even though the function
>> 'int getb()' is never referenced.
> 
> As Matti says, sort of a limitation, but not really one it is possible to
> solve because the compiler can never know if an object referencing it is
> linked in later on.

I disagree. In the example, no delegate pointing to three.getb() is ever created inside three(), and no other code can get to the symbol since it isn't in scope anywhere else. So the compiler could tell getb() doesn't even need to be emitted and 'b' can be stack-allocated, if only it would try to determine that fact.

Frits van Bommel wrote:

> Lars Ivar Igesund wrote:
>> d-bugmail@puremagic.com wrote:
>> 
>>> is means that 'int b' is allocated on the heap, even though the function 'int getb()' is never referenced.
>> 
>> As Matti says, sort of a limitation, but not really one it is possible to solve because the compiler can never know if an object referencing it is linked in later on.
> 
> I disagree. In the example, no delegate pointing to three.getb() is ever created inside three(), and no other code can get to the symbol since it isn't in scope anywhere else. So the compiler could tell getb() doesn't even need to be emitted and 'b' can be stack-allocated, if only it would try to determine that fact.

Good point, didn't look to the top to see that it's all inside a delegate.

-- 
Lars Ivar Igesund

Lars Ivar Igesund wrote:
> Frits van Bommel wrote:
> 
>> Lars Ivar Igesund wrote:
>>> d-bugmail@puremagic.com wrote:
>>>
>>>> is means that 'int b' is allocated on the heap, even though the function
>>>> 'int getb()' is never referenced.
>>> As Matti says, sort of a limitation, but not really one it is possible to
>>> solve because the compiler can never know if an object referencing it is
>>> linked in later on.
>> I disagree. In the example, no delegate pointing to three.getb() is ever
>> created inside three(), and no other code can get to the symbol since it
>> isn't in scope anywhere else. So the compiler could tell getb() doesn't
>> even need to be emitted and 'b' can be stack-allocated, if only it would
>> try to determine that fact.
> 
> Good point, didn't look to the top to see that it's all inside a delegate.

Small correction: It's not all in a delegate. It's all in a function (that happens to return a delegate).
Not that it matters here...