• d-bugmail puremagic.com Jan 01 2008
• d-bugmail puremagic.com Jan 01 2008
• Lars Ivar Igesund <larsivar igesund.net> Jan 01 2008
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Jan 02 2008
• Lars Ivar Igesund <larsivar igesund.net> Jan 02 2008
• Frits van Bommel <fvbommel REMwOVExCAPSs.nl> Jan 03 2008

d-bugmail puremagic.com writes:

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.


-- 

d-bugmail puremagic.com writes:

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.


-- 

Lars Ivar Igesund <larsivar igesund.net> writes:

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

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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.

Lars Ivar Igesund <larsivar igesund.net> writes:

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

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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.


 solve because the compiler can never know if an object referencing it is
 linked in later on.


 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...