On 06/17/2012 01:45 AM, Era Scarecrow wrote:
On Saturday, 16 June 2012 at 22:13:44 UTC, Timon Gehr wrote:
On 06/16/2012 11:19 PM, Era Scarecrow wrote:
On Saturday, 16 June 2012 at 20:16:52 UTC, Denis Shelomovskij wrote:
Just want to mention again that Issue 7965 is a really nasty
wrong-code bug that is difficult to find unless you know about it.
I face this Issue in almost every my D program with non-trivial
std.algorithm usage and I suppose I'm not alone.
If there is no plans to fix it in near future this _must_ be
mentioned in std.algorithm Page and in other places in docs because
it's really possible to avoid it every time you use std.algorithm.
It's not a joke! Such things must be mentioned in docs or D is
unusable for non-experienced D developers.
http://d.puremagic.com/issues/show_bug.cgi?id=7965
Looks to me like a frame pointer bug for the delegate (Or lack of
it?)...
Based on the setup, it should also be illegal to pass the struct
outside of the scope it's in due to the delegate in the struct
(Unless the variable(s) in question are static).
Passing the struct outside of the scope it is in must be legal and
create a heap frame if it references any of the stack variables.
What delegates are you talking about?
I had the impression that a function referencing the outer frame
automatically was a delegate; Maybe I just messed up on the terms..
void func(){
int x;
void y(){x++;};
//equal to??
auto y = delegate void(){x++;};
}
I see. What actually happens looks more like this:
struct StackContext{
int x;
}
StackContext x;
static void y(StackContext* context){ context.x++; }
No delegate is created until the address of the nested function is
taken. If such a delegate is suspected to escape the frame, the
StackContext is allocated on the heap instead.
