www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Presence of struct destructor makes lvalue?

reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
The following program has two assignments from two rvalues:

import std.stdio;
import std.string;

// version = destructor_defined;

struct S
{
     int i;

     string info() const
     {
         return format("%s(%s)", &i, i);
     }

     void opAssign(S rhs)
     {
         writefln("%s from Rvalue %s", this.info(), rhs.info());
     }

     void opAssign(ref S rhs)
     {
         writefln("%s from Lvalue %s", this.info(), rhs.info());
     }

     version (destructor_defined)
     {
         ~this()
         {
             writefln("destroying %s", this.info());
         }
     }
}

S foo(int i)
{
     return S(i);
}

void main()
{
     auto s = S(1);

     // Assignment from two kinds of rvalues
     s = foo(2);
     s = S(3);
}

The output indicates that the two assignments go to the "rvalue 
assignment operator":

7FFF36AA0B20(1) from Rvalue 7FFF36AA0B24(2)
7FFF36AA0B20(1) from Rvalue 7FFF36AA0B28(3)

However, when S.~this() is defined (by e.g. uncommenting the 'version =' 
line), the second assignment involves an lvalue:

7FFF9571E7F8(1) from Rvalue 7FFF9571E750(2)
destroying 7FFF9571E750(2)
7FFF9571E7F8(1) from Lvalue 7FFF9571E804(3)  <-- HERE
destroying 7FFF9571E804(3)
destroying 7FFF9571E7F8(1)

I suspect this has something to do with the compiler generated 
assignment logic:

   http://dlang.org/struct.html

[quote]
Struct assignment t=s is defined to be semantically equivalent to:

t.opAssign(s);

where opAssign is a member function of S:

S* opAssign(ref const S s)
{   ... bitcopy *this into tmp ...
     ... bitcopy s into *this ...
     ... call destructor on tmp ...
     return this;
}
[/quote]

It is not clear how the presence of ~this() changes the semantics. Bug?

Thank you,
Ali
Apr 08 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
DMD often inserts temporaries when they are unexpected (or users 
do not expect when they should).

D main function in destructor case is rewritten as:

    S s = S(1);
    s.opAssign(foo(2));
    s.opAssign((S __sl1779 = S(3); , __sl1779))

Hence, ref version is taken in account because '__sl1779' is a 
good lvalue.

Troubles seems to come from 
https://github.com/D-Programming-Language/dmd/blob/master/src/expression.c#L4203
Apr 08 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/08/2013 12:24 PM, Maxim Fomin wrote:


 DMD often inserts temporaries when they are unexpected (or users do not
 expect when they should).

 D main function in destructor case is rewritten as:

     S s = S(1);
     s.opAssign(foo(2));
     s.opAssign((S __sl1779 = S(3); , __sl1779))


Have you manually typed those lines or is there a tool that outputs that 
"preprocessor" ;) output?


 Hence, ref version is taken in account because '__sl1779' is a good 


lvalue.

 Troubles seems to come from
 


https://github.com/D-Programming-Language/dmd/blob/master/sr
/expression.c#L4203 



Thank you very much for finding the related line. :) Quoting:

Expression *StructLiteralExp::semantic(Scope *sc)
{ Expression *e;

// ...

     /* If struct requires a destructor, rewrite as:
      * (S tmp = S()),tmp
      * so that the destructor can be hung on tmp.
      */
     if (sd->dtor && sc->func)
     {
         Identifier *idtmp = Lexer::uniqueId("__sl");
         VarDeclaration *tmp = new VarDeclaration(loc, type, idtmp, new 
ExpInitializer(0, this));
         tmp->storage_class |= STCctfe;
         Expression *ae = new DeclarationExp(loc, tmp);
         Expression *e = new CommaExp(loc, ae, new VarExp(loc, tmp));
         e = e->semantic(sc);
         return e;
     }

     return this;
}

Is it because destructors cannot be "hung" on literals?

It is inconsistent that function-returned rvalues do not behave the same 
as literal-rvalues.

Ali



 Apr 08 2013



  parent reply kenji hara <k.hara.pg gmail.com>  writes:


This is definitely a bug.

http://d.puremagic.com/issues/show_bug.cgi?id=3D9907

Kenji Hara

2013/4/9 Ali =C3=87ehreli <acehreli yahoo.com>


 On 04/08/2013 12:24 PM, Maxim Fomin wrote:


 DMD often inserts temporaries when they are unexpected (or users do not
 expect when they should).

 D main function in destructor case is rewritten as:

     S s =3D S(1);
     s.opAssign(foo(2));
     s.opAssign((S __sl1779 =3D S(3); , __sl1779))


 Have you manually typed those lines or is there a tool that outputs that
 "preprocessor" ;) output?



 Hence, ref version is taken in account because '__sl1779' is a good


 lvalue.

 Troubles seems to come from
 https://github.com/D-**Programming-Language/dmd/blob/**


 master/src/expression.c#L4203<https://github.com/D-Programming-Language/d=


md/blob/master/src/expression.c#L4203>


 Thank you very much for finding the related line. :) Quoting:

 Expression *StructLiteralExp::semantic(**Scope *sc)
 { Expression *e;

 // ...

     /* If struct requires a destructor, rewrite as:
      * (S tmp =3D S()),tmp
      * so that the destructor can be hung on tmp.
      */
     if (sd->dtor && sc->func)
     {
         Identifier *idtmp =3D Lexer::uniqueId("__sl");
         VarDeclaration *tmp =3D new VarDeclaration(loc, type, idtmp, new
 ExpInitializer(0, this));
         tmp->storage_class |=3D STCctfe;
         Expression *ae =3D new DeclarationExp(loc, tmp);
         Expression *e =3D new CommaExp(loc, ae, new VarExp(loc, tmp));
         e =3D e->semantic(sc);
         return e;
     }

     return this;
 }

 Is it because destructors cannot be "hung" on literals?

 It is inconsistent that function-returned rvalues do not behave the same
 as literal-rvalues.

 Ali





 Apr 08 2013



  parent  =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


On 04/08/2013 07:13 PM, kenji hara wrote:> This is definitely a bug.

 http://d.puremagic.com/issues/show_bug.cgi?id=9907

 Kenji Hara


Thank you! :) You've already fixed it!  (Pending merge...)

Ali



 Apr 08 2013