• Matt Kline (32/32) Apr 09 2015 I have a bit of confusion about the D memory model when it comes
• H. S. Teoh via Digitalmars-d (7/42) Apr 09 2015 The compiler detects when a variable is being closed over by a nested
• Matt Kline (6/9) Apr 09 2015 Is there somewhere I can read more about this (besides the
• Steven Schveighoffer (10/18) Apr 09 2015 It's called a closure. It's not specific to voldemort types, it's done
• Kagamin (5/8) Apr 10 2015 Closures may or may not be destroyed by GC. Such scenario used to

"Matt Kline" <matt bitbashing.io> writes:

I have a bit of confusion about the D memory model when it comes 
to returning nested classes (i.e. "Voldemort types") and am 
hoping someone can take a minute to clear it up. Consider the 
following short program:

auto foo()
{
     import std.random;
     import std.conv;

     auto i = dice(0.5, 0.5);
     string s = "Hello, scopes";

     class Bar {
         string what() { return s ~ " " ~ i.to!string; }
     }

     return new Bar;
}

void main()
{
     import std.stdio;

     auto b = foo();
     writeln(b.what());
}

I was under the impression that nested classes captured their 
context via a pointer to the current stack frame. But if that 
were the case, reading i and s when b.what() is called would 
cause invalid reads below the current stack pointer, and this 
data could be thrashed by inserting any calls between the call to 
foo() and the call to b.what(). Running the above program through 
valgrind also indicates no foul play.

So what is actually going on here? Do nested classes capture 
their context some other way? Does the compiler do semantic 
analysis and capture local variables by value if an instance of 
the Voldemort type is going to get returned out of the function?

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Thu, Apr 09, 2015 at 06:08:17PM +0000, Matt Kline via Digitalmars-d wrote:
[...]
 auto foo()
 {
     import std.random;
     import std.conv;
 
     auto i = dice(0.5, 0.5);
     string s = "Hello, scopes";
 
     class Bar {
         string what() { return s ~ " " ~ i.to!string; }
     }
 
     return new Bar;
 }
 
 void main()
 {
     import std.stdio;
 
     auto b = foo();
     writeln(b.what());
 }
 
 I was under the impression that nested classes captured their context
 via a pointer to the current stack frame. But if that were the case,
 reading i and s when b.what() is called would cause invalid reads
 below the current stack pointer, and this data could be thrashed by
 inserting any calls between the call to foo() and the call to
 b.what(). Running the above program through valgrind also indicates no
 foul play.
 
 So what is actually going on here? Do nested classes capture their
 context some other way? Does the compiler do semantic analysis and
 capture local variables by value if an instance of the Voldemort type
 is going to get returned out of the function?

The compiler detects when a variable is being closed over by a nested
function, and allocates them on the heap instead of the stack.


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases. 
He/She has prejudices. -- Gene Wirchenko

"Matt Kline" <matt bitbashing.io> writes:

On Thursday, 9 April 2015 at 18:15:16 UTC, H. S. Teoh wrote:

 The compiler detects when a variable is being closed over by a 
 nested
 function, and allocates them on the heap instead of the stack.

Is there somewhere I can read more about this (besides the 
compiler source code)? What ramifications are there for local 
variables being closed over that have destructors? Does the 
Voldemort object then get implicit destructor code that destroys 
the closed-over variables when it falls out of scope?

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 4/9/15 2:23 PM, Matt Kline wrote:
 On Thursday, 9 April 2015 at 18:15:16 UTC, H. S. Teoh wrote:

 The compiler detects when a variable is being closed over by a nested
 function, and allocates them on the heap instead of the stack.

 Is there somewhere I can read more about this (besides the compiler
 source code)? What ramifications are there for local variables being
 closed over that have destructors? Does the Voldemort object then get
 implicit destructor code that destroys the closed-over variables when it
 falls out of scope?

It's called a closure. It's not specific to voldemort types, it's done 
whenever you take a delegate that needs the context pointer to the stack.

I believe destruction is performed on the stack frame data when the GC 
collects the stack frame.

See here: http://dlang.org/function.html#closures

In regards to voldemort types triggering a heap allocation of the stack 
frame, I can't find specific documentation on this, probably a good idea 
to add it.

-Steve

"Kagamin" <spam here.lot> writes:

On Thursday, 9 April 2015 at 18:23:31 UTC, Matt Kline wrote:
 Does the Voldemort object then get implicit destructor code 
 that destroys the closed-over variables when it falls out of 
 scope?

Closures may or may not be destroyed by GC. Such scenario used to 
be problematic, but there was some progress on it recently wrt 
support of struct destructors allocated on heap, though I don't 
know whether it affects closures.