www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Stupid scope destruction question

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
Is there any guaranties that `ScopeTemp` will not be destroyed before 
`f` call because it isn't used?
---
struct ScopeTemp
{
     ...
     // allocates value
     this(...) { ... }

      property void* value() { ... }

     // destroys value
     ~this() { ... }
}

void f(void* ptr) { ... }

void main()
{
     f(ScopeTemp(...).value);
}
---
According to http://dlang.org/struct.html#StructDestructor
"Destructors are called when an object goes out of scope."
So I understand it as "it will not be destroyed before scope exit even 
if not used". Is it correct?

So the question is if `ScopeTemp`'s scope is `main` scope, not some 
possibly generated "temp scope" (don't now what documentation statements 
prohibit compiler from doing so).


Working code:
---
import std.exception;
import std.c.stdlib;

struct ScopeTemp
{
     private int* p;
     // allocates value
     this(int i)
     in { assert(i); }
     body { *(p = cast(int*) enforce(malloc(int.sizeof))) = i; }

      disable this(this);

      property int* value() { return p; }

     // destroys value
     ~this() { *p = 0; p = null; /*free(p);*/ }
}

void f(int* ptr)
{
     assert(*ptr == 1);
}

void main()
{
     f(ScopeTemp(1).value);
}
---
-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Sep 20 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
20.09.2012 13:27, Denis Shelomovskij пишет:
 Is there any guaranties that `ScopeTemp` will not be destroyed before
 `f` call because it isn't used?
 ---
 struct ScopeTemp
 {
      ...
      // allocates value
      this(...) { ... }

       property void* value() { ... }

      // destroys value
      ~this() { ... }
 }

 void f(void* ptr) { ... }

 void main()
 {
      f(ScopeTemp(...).value);
 }
 ---
 According to http://dlang.org/struct.html#StructDestructor
 "Destructors are called when an object goes out of scope."
 So I understand it as "it will not be destroyed before scope exit even
 if not used". Is it correct?

 So the question is if `ScopeTemp`'s scope is `main` scope, not some
 possibly generated "temp scope" (don't now what documentation statements
 prohibit compiler from doing so).


 Working code:
 ---
 import std.exception;
 import std.c.stdlib;

 struct ScopeTemp
 {
      private int* p;
      // allocates value
      this(int i)
      in { assert(i); }
      body { *(p = cast(int*) enforce(malloc(int.sizeof))) = i; }

       disable this(this);

       property int* value() { return p; }

      // destroys value
      ~this() { *p = 0; p = null; /*free(p);*/ }
 }

 void f(int* ptr)
 {
      assert(*ptr == 1);
 }

 void main()
 {
      f(ScopeTemp(1).value);
 }
 ---

Wow, this `main` works fine too: --- // same ScopeTemp definition as above int* gptr; void f(int* ptr) { assert(*ptr == 1); gptr = ptr; } void g() { assert(*gptr == 0); } void main() { f(ScopeTemp(1).value); // Here `ScopeTemp` value is already destroyed g(); } --- So `ScopeTemp`'s scope definitely isn't a `main` scope. So the question: what do we know about this "temp scope"? -- Денис В. Шеломовский Denis V. Shelomovskij
Sep 20 2012
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 20 September 2012 at 09:31:45 UTC, Denis 
Shelomovskij wrote:
 20.09.2012 13:27, Denis Shelomovskij пишет:
 Is there any guaranties that `ScopeTemp` will not be destroyed 
 before
 `f` call because it isn't used?
 ---
 struct ScopeTemp
 {
     ...
     // allocates value
     this(...) { ... }

      property void* value() { ... }

     // destroys value
     ~this() { ... }
 }

 void f(void* ptr) { ... }

 void main()
 {
     f(ScopeTemp(...).value);
 }
 ---
 According to http://dlang.org/struct.html#StructDestructor
 "Destructors are called when an object goes out of scope."
 So I understand it as "it will not be destroyed before scope 
 exit even
 if not used". Is it correct?

 So the question is if `ScopeTemp`'s scope is `main` scope, not 
 some
 possibly generated "temp scope" (don't now what documentation 
 statements
 prohibit compiler from doing so).


 Working code:
 ---
 import std.exception;
 import std.c.stdlib;

 struct ScopeTemp
 {
     private int* p;
     // allocates value
     this(int i)
     in { assert(i); }
     body { *(p = cast(int*) enforce(malloc(int.sizeof))) = i; }

      disable this(this);

      property int* value() { return p; }

     // destroys value
     ~this() { *p = 0; p = null; /*free(p);*/ }
 }

 void f(int* ptr)
 {
     assert(*ptr == 1);
 }

 void main()
 {
     f(ScopeTemp(1).value);
 }
 ---

Wow, this `main` works fine too: --- // same ScopeTemp definition as above int* gptr; void f(int* ptr) { assert(*ptr == 1); gptr = ptr; } void g() { assert(*gptr == 0); } void main() { f(ScopeTemp(1).value); // Here `ScopeTemp` value is already destroyed g(); } --- So `ScopeTemp`'s scope definitely isn't a `main` scope. So the question: what do we know about this "temp scope"?

AFAIK, if the rules are the same in C++ (which they probably are), then: "Any object constructed during argument passing will remain valid for the duration of the call. It will go out of scope once the function has finished returning, and after the return value has itself gone out of scope and been destroyed." The two catches are: *"The implementation is allowed to elide the copy for pass by value, even if it has visible side effects, and construct directly into the function's stack." *"If the function is able to use "(Named) Return Value Optimization" "(N)RVA" (invented by Walter himself), the returned value's destruction will not be observable (as it won't happen)." Try running this: C++ ---- #include <iostream> struct S { int i; S(int i) : i(i) {::std::cout << "C:" << i << ::std::endl;} S(const S&){::std::cout << "CC:" << i << ::std::endl;} ~S(){::std::cout << "D~:" << i << ::std::endl;} }; S foo(S) { ::std::cout << "foo(S)" << ::std::endl; return S(2); } S foo(int) { ::std::cout << "foo(int)" << ::std::endl; return S(6); } int main() { foo(S(1)); foo(S(5).i); } ---- C:1 foo(S) C:2 D~:2 D~:1 C:5 foo(int) C:6 D~:6 D~:5 ---- D: ---- import std.stdio; struct S { int i; this(int j){i = j;writeln("C",i);} this(this){writeln("PB",i);} ~this(){writeln("D~",i);} }; S foo(S) { writeln("foo(S)"); return S(2); } S foo(int) { writeln("foo(int)"); return S(6); } void main() { S a = foo(S(1)); S a = foo(S(5).i); } ---- C1 foo(S) C2 D~1 D~2 C5 foo(int) C6 D~6 D~5 ---- I haven't seen any difference between C++ and D, including the argument pass by value elision, as well as (N)RVA
Sep 20 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
20.09.2012 15:35, monarch_dodra пишет:
 On Thursday, 20 September 2012 at 09:31:45 UTC, Denis Shelomovskij wrote:
 20.09.2012 13:27, Denis Shelomovskij пишет:
 Is there any guaranties that `ScopeTemp` will not be destroyed before
 `f` call because it isn't used?
 ---
 ...
     f(ScopeTemp(...).value);
 }
 ---
 According to http://dlang.org/struct.html#StructDestructor
 "Destructors are called when an object goes out of scope."
 So I understand it as "it will not be destroyed before scope exit even
 if not used". Is it correct?

 So the question is if `ScopeTemp`'s scope is `main` scope, not some
 possibly generated "temp scope" (don't now what documentation statements
 prohibit compiler from doing so).


AFAIK, if the rules are the same in C++ (which they probably are), then: "Any object constructed during argument passing will remain valid for the duration of the call. It will go out of scope once the function has finished returning, and after the return value has itself gone out of scope and been destroyed."

Thanks, looks like D does have C++ behaviour here. But your last statement about return value is incorrect. More than that function call doesn't change anything. Correct answers are here: * `12.2 Temporary objects [class.temporary]` section of C++ standard * http://stackoverflow.com/questions/2506793/c-life-span-of-temporary-arguments * http://stackoverflow.com/questions/5459759/full-expression-boundaries-and-lifetime-of-temporaries -- Денис В. Шеломовский Denis V. Shelomovskij
Sep 24 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 09/24/2012 12:49 AM, monarch_dodra wrote:
 On Monday, 24 September 2012 at 07:25:28 UTC, Denis Shelomovskij wrote:
 20.09.2012 15:35, monarch_dodra пишет:
 AFAIK, if the rules are the same in C++ (which they probably are), 



 "Any object constructed during argument passing will remain valid for
 the duration of the call. It will go out of scope once the function has
 finished returning, and after the return value has itself gone out of
 scope and been destroyed."



That sounds like you are saying that the temporary S() is destroyed after 'r' below: // C++ code R r = foo(S());
 How is my statement incorrect? The "function call" itself doesn't change
 anything sure, since it is more generally a "full expression": The
 return value itself is created *during* that full expression, but after
 the creation of the arguments. Last in, first out, it is destroyed
 before the passed in arguments.

That is not correct. The temporary S() is destroyed at the end of the assignment expression (at the semicolon), while 'r' will live until the end of the current scope. Ali
Sep 24 2012
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 24 September 2012 at 07:25:28 UTC, Denis Shelomovskij 
wrote:
 20.09.2012 15:35, monarch_dodra пишет:
 AFAIK, if the rules are the same in C++ (which they probably 
 are), then:
 "Any object constructed during argument passing will remain 
 valid for
 the duration of the call. It will go out of scope once the 
 function has
 finished returning, and after the return value has itself gone 
 out of
 scope and been destroyed."

Thanks, looks like D does have C++ behaviour here. But your last statement about return value is incorrect. More than that function call doesn't change anything. Correct answers are here: * `12.2 Temporary objects [class.temporary]` section of C++ standard * http://stackoverflow.com/questions/2506793/c-life-span-of-temporary-arguments * http://stackoverflow.com/questions/5459759/full-expression-boundaries-and-lifetime-of-temporaries

How is my statement incorrect? The "function call" itself doesn't change anything sure, since it is more generally a "full expression": The return value itself is created *during* that full expression, but after the creation of the arguments. Last in, first out, it is destroyed before the passed in arguments. Unless you were playing on the words "gone out of scope" (which is indeed not the 100% correct), I don't see how my statement is incorrect.
Sep 24 2012
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 24 September 2012 at 17:49:22 UTC, Ali Çehreli wrote:
 On 09/24/2012 12:49 AM, monarch_dodra wrote:
 On Monday, 24 September 2012 at 07:25:28 UTC, Denis

 20.09.2012 15:35, monarch_dodra пишет:
 AFAIK, if the rules are the same in C++ (which they



 "Any object constructed during argument passing will remain



 the duration of the call. It will go out of scope once the



 finished returning, and after the return value has itself



 scope and been destroyed."



That sounds like you are saying that the temporary S() is destroyed after 'r' below: // C++ code R r = foo(S());
 How is my statement incorrect? The "function call" itself

 anything sure, since it is more generally a "full

 return value itself is created *during* that full expression,

 the creation of the arguments. Last in, first out, it is

 before the passed in arguments.

That is not correct. The temporary S() is destroyed at the end of the assignment expression (at the semicolon), while 'r' will live until the end of the current scope. Ali

Ah... but see, "s" is *not* the temporary returned value. It is a normal stack variable to which the the return value is copied. Also, as I said, in this situation, the compiler will elide the return completely by constructing the returned value directly into s, so you won't see the destroyer. Try this though: -------- void main() { S s; foo(S(1)); } -------- D: C++ ---- ---- C0 C:0 C1 C:1 foo(S) foo(S) C2 C:2 D~1 D~:2 D~2 D~:1 D~0 D~:0 ---- ---- As you can see, three destructors. It would appear that D, contrary to C++, actually destroys the return value before the passed in arguments. Interesting. A valid behavior like any other I guess, but doesn't change much. I'll admit I was wrong regarding that (regarding D), but it stays right for C++ :p Not your example you ask? HERE is the *money* example: -------- void main() { S s; s = foo(S(1)); } -------- D: C++ ---- ---- C0 C:0 C1 C:1 foo(S) foo(S) C2 C:2 D~1 D~:2 D~0 D~:1 D~2 D~:2 ---- ---- Again 3 destroyers. Again, C++, again works as I said. Regarding D, WTF is D~0 ? That is D's "return value move" into action! First time I observe it myself! Exciting! * First, the passed in argument is destroyed: D~1. * Then it gets interesting: * D first calls a destroyer on s (but doesn't actually remove it from the stack): D~0. * Then D does a memcpy from the returned value, onto s (the move). * Finally, the actual return value is then removed from the stack, but no destructor ever called on it. * Finally, at the end of the program, s is destroyed (D~2). Neat-o!
Sep 24 2012