www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct constructors and destructors.

reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
Is there a reason that the following code

struct Foo
{
    this (string name)
    { do_something(name); }

    ~this()
    { undo_something(); }
}

Foo foo = void;

void open()
{
    foo = Foo("test"); // <- this line
}

tries to OpAssign foo to itself then calls foo's destructor?
Jul 19
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
 Is there a reason that the following code

 struct Foo
 {
     this (string name)
     { do_something(name); }

     ~this()
     { undo_something(); }
 }

 Foo foo = void;

 void open()
 {
     foo = Foo("test"); // <- this line
 }

 tries to OpAssign foo to itself then calls foo's destructor?
What happens is this. void open() { foo = () { Foo _tmp = Foo.__ctor("test"); return _tmp; } (); }
Jul 19
next sibling parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, Jul 19, 2017 at 7:09 PM, Stefan Koch via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 What happens is this.

 void open()
 {
   foo = () {
   Foo _tmp = Foo.__ctor("test");
   return _tmp;
   } ();
 }


 Error: need 'this' for 'this' of type 'ref Foo(string s)'
Jul 19
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 19 July 2017 at 12:23:06 UTC, Danni Coy wrote:
 On Wed, Jul 19, 2017 at 7:09 PM, Stefan Koch via Digitalmars-d 
 < digitalmars-d puremagic.com> wrote:

 What happens is this.

 void open()
 {
   foo = () {
   Foo _tmp = Foo.__ctor("test");
   return _tmp;
   } ();
 }


 Error: need 'this' for 'this' of type 'ref Foo(string s)'
I posted pseudo code to show you that you are creating a temporary. Which leaves the scope after assigning. And therefore triggers the destructor.
Jul 19
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 July 2017 at 12:34:50 UTC, Stefan Koch wrote:
 Which leaves the scope after assigning.
 And therefore triggers the destructor.
No, that's not the case. There is a temporary, but its destructor is not called. The existing object in `foo` is destroyed, so the new one can be moved (and indeed moved, not copied, so no postblit, no dtor call, though it might or might not invalidate internal pointers - that's why the spec bans those) into its place.
Jul 19
prev sibling parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
Yeah somehow I read that as a question -- must be getting tired.

That makes more sense.

is there any way to

On Wed, Jul 19, 2017 at 10:34 PM, Stefan Koch via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Wednesday, 19 July 2017 at 12:23:06 UTC, Danni Coy wrote:

 On Wed, Jul 19, 2017 at 7:09 PM, Stefan Koch via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 What happens is this.

 void open()
 {
   foo = () {
   Foo _tmp = Foo.__ctor("test");
   return _tmp;
   } ();
 }


 Error: need 'this' for 'this' of type 'ref Foo(string s)'
I posted pseudo code to show you that you are creating a temporary. Which leaves the scope after assigning. And therefore triggers the destructor.
Jul 19
prev sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:
 On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
 Is there a reason that the following code

 struct Foo
 {
     this (string name)
     { do_something(name); }

     ~this()
     { undo_something(); }
 }

 Foo foo = void;

 void open()
 {
     foo = Foo("test"); // <- this line
 }

 tries to OpAssign foo to itself then calls foo's destructor?
What happens is this. void open() { foo = () { Foo _tmp = Foo.__ctor("test"); return _tmp; } (); }
Hm, isnt that wrong? If I destroy resources on the dtor, wouldn't it invalidate the resource on the copy? Also, C++ behaves differently
Jul 19
next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Wednesday, 19 July 2017 at 14:09:32 UTC, SrMordred wrote:
 On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:
 On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
 Is there a reason that the following code

 struct Foo
 {
     this (string name)
     { do_something(name); }

     ~this()
     { undo_something(); }
 }

 Foo foo = void;

 void open()
 {
     foo = Foo("test"); // <- this line
 }

 tries to OpAssign foo to itself then calls foo's destructor?
What happens is this. void open() { foo = () { Foo _tmp = Foo.__ctor("test"); return _tmp; } (); }
Hm, isnt that wrong? If I destroy resources on the dtor, wouldn't it invalidate the resource on the copy? Also, C++ behaves differently
No Sorry, it behaves almost the same. just in D ctor and dtor are not called on declaration even if you drop " = void".
Jul 19
parent reply Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, Jul 20, 2017 at 12:19 AM, SrMordred via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Wednesday, 19 July 2017 at 14:09:32 UTC, SrMordred wrote:

 On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:

 On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:

 Is there a reason that the following code

 struct Foo
 {
     this (string name)
     { do_something(name); }

     ~this()
     { undo_something(); }
 }

 Foo foo = void;

 void open()
 {
     foo = Foo("test"); // <- this line
 }

 tries to OpAssign foo to itself then calls foo's destructor?
What happens is this. void open() { foo = () { Foo _tmp = Foo.__ctor("test"); return _tmp; } (); }
Hm, isnt that wrong? If I destroy resources on the dtor, wouldn't it invalidate the resource on the copy? Also, C++ behaves differently
No Sorry, it behaves almost the same. just in D ctor and dtor are not called on declaration even if you drop " = void".
Is there a way to delay the initialisation of a struct?
Jul 20
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 20 July 2017 at 09:09:42 UTC, Danni Coy wrote:
 On Thu, Jul 20, 2017 at 12:19 AM, SrMordred via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Wednesday, 19 July 2017 at 14:09:32 UTC, SrMordred wrote:

 On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:

 On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:

 Is there a reason that the following code

 struct Foo
 {
     this (string name)
     { do_something(name); }

     ~this()
     { undo_something(); }
 }

 Foo foo = void;

 void open()
 {
     foo = Foo("test"); // <- this line
 }

 tries to OpAssign foo to itself then calls foo's destructor?
What happens is this. void open() { foo = () { Foo _tmp = Foo.__ctor("test"); return _tmp; } (); }
Hm, isnt that wrong? If I destroy resources on the dtor, wouldn't it invalidate the resource on the copy? Also, C++ behaves differently
No Sorry, it behaves almost the same. just in D ctor and dtor are not called on declaration even if you drop " = void".
Is there a way to delay the initialisation of a struct?
void initialization + emplace: struct Foo { this (string name) { create_count++; } ~this() { destroy_count--; } } int create_count; int destroy_count; Foo foo = void; void main() { import std.stdio; import std.conv : emplace; writefln("this(string) ran %s times.", create_count); writefln("~this() ran %s times.", destroy_count); emplace(&foo, "test"); writeln("--- emplace ---"); writefln("this(string) ran %s times.", create_count); writefln("~this() ran %s times.", destroy_count); } this(string) ran 0 times. ~this() ran 0 times. --- emplace --- this(string) ran 1 times. ~this() ran 0 times. https://is.gd/G06GvK
Jul 20
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 July 2017 at 14:09:32 UTC, SrMordred wrote:
 Hm, isnt that wrong?
Did my post even go through? http://forum.dlang.org/post/udaxeyujrafklzpwwftf forum.dlang.org What's going on here is actually pretty simple. Though calling a destructor on a default-initialized struct should always be valid anyway.
Jul 20
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
 tries to OpAssign foo to itself then calls foo's destructor?
Are you sure that's what's actually happening? What should be happening there is: 1) it calls Foo's constructor on a temporary location 2) it destroys the old contents of `foo` 3) it moves the Foo from (1) into the variable freshly destroyed from (2) It is void initialized, so you might think there are no old contents of foo, but the compiler doesn't know this for certain (consider you called `open` twice. would be true the first time, but not the second time. the compiler needs to generate the function so it works both times). There is a function which the compiler knows will only be called once though: a static constructor. --- shared static this() { foo = Foo("test"); } --- That only runs once, and the compiler will skip the destruction of old `foo`.... as long as it isn't already initialized. Ironically, removing the `= void` from it causes the compiler to realize this and only use the ctor initialization. Otherwise, it tries to destroy the existing item, apparently not realizing it was void.... arguably a small compiler bug there.
Jul 19