On Friday, 18 September 2020 at 12:32:49 UTC, Andrey Zherikov
wrote:
======
The output is:
======
-> void test.main()
-> test.do_lazy(lazy S s)
-> test.create()
1 S test.S.this(int n)
<- test.create()
1 void test.S.~this()
===-1 (2)
<- test.do_lazy(lazy S s)
-> 1703096 test.do_something(S s)
<- 1703096 test.do_something(S s)
<- void test.main()
======
As you can see, dtor is called before writeln on (1) and s1.i
is -1 (2)
Indeed. As we can see from the output, first do_lazy() is called
from test.main, then create() is called (this happens inside
do_lazy, as s is lazy). When create() returns, the scoped!S you
created goes out of scope and is destroyed. scoped's destructor
overwrites the memory with S.init, which is why s.i is -1 at that
point. Then the memory is overwritten by subsequent function
calls, as that stack space is now considered vacant. That's why
the output changes from -1 to 1703096.
A bit interesting is the fact that <- test.create() is printed
before ~this(). I expected the order to be opposite, but there
may be sensible reasons why it's not.
scoped!S is only valid inside the scope its variable exists in,
and when that scope is exited, it refers to random stack data.
It's a lot like this code:
int* fun() {
int a;
int* p = &a;
return p;
}
Note that return &a; does not compile, with a warning about
escaping a reference to a local variable. That's exactly the same
thing that's happening with scoped!S, but since scoped is more
complex, the compiler has a hard time keeping track of things,
and code that in a perfect world would not compile, does. It may
be that D's scope tracking functionality has become good enough
to catch this error now, if the functions are properly marked.
Even if this is the case, then they are obviously not properly
marked. :p
Now, this begets the question: *when* should I use scoped!T?
Short answer: Basically never.
Longer answer:
1) When the lifetime of one object needs to be a strict subset of
another. That is, the class instance you created only exists as
long as the function create() is on the stack. When scoped!T is a
member of another class or struct, it continues to live as long
as that object exists. In most cases, you don't mind that it
stays around for longer, and can let the GC handle the cleanup.
If you really do care, you can use scoped!T, or explicitly
destroy the object when you're done with it.
2) scoped!T may be used as a performance hack, letting you avoid
the GC. If you have instrumented your code and found that this is
the culprit, scoped!T might help. Even if GC is the problem,
you'll still need #1 to be true.
There may be other cases, but I believe those are the main two
reasons to use scoped!T.
--
Simen
