www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1760] New: Closures - Variable unnecessarily allocated on heap

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


--
Jan 01 2008
next sibling parent 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





-------
Not a bug, but a limitation.


--
Jan 01 2008
prev sibling parent reply 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
Jan 01 2008
parent reply 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.
Jan 02 2008
parent reply 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
Jan 02 2008
parent 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.


 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...
Jan 03 2008