www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - struct template constructors

reply Boris-Barboris <ismailsiege gmail.com> writes:
Hi

https://dpaste.dzfl.pl/0def4e286564

Is there a cleaner way to go than the one on the line 26? And why 
is the constructor

/d475/f781.d(37): f781.UniquePtr!(A).UniquePtr.__ctor(DT)(ref 
scope UniquePtr!DT rhs)

unfit for line 51?
Is it because the expression " = UniquePtr!B.make()" cannot be 
interpreted as "scope ref"? It must release ownership of a 
pointer it holds, and looks like it cannot do it in this form.
Jun 22 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/22/2017 12:06 PM, Boris-Barboris wrote:

 Hi

 https://dpaste.dzfl.pl/0def4e286564

 Is there a cleaner way to go than the one on the line 26? And why is the
 constructor

 /d475/f781.d(37): f781.UniquePtr!(A).UniquePtr.__ctor(DT)(ref scope
 UniquePtr!DT rhs)

 unfit for line 51?
 Is it because the expression " = UniquePtr!B.make()" cannot be
 interpreted as "scope ref"? It must release ownership of a pointer it
 holds, and looks like it cannot do it in this form.


(Going pedantic, you mean "struct constructor templates" or "templated 
struct constructors".)

No time to think about the rest of the design but just to get the code 
compiled, replace 'ref' with 'auto ref' like so:

     this(DT)(scope auto ref UniquePtr!DT rhs)
     {
         // ...
     }

Ali
Jun 22 2017
next sibling parent Boris-Barboris <ismailsiege gmail.com> writes:
On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:

 No time to think about the rest of the design but just to get 
 the code compiled, replace 'ref' with 'auto ref' like so:

     this(DT)(scope auto ref UniquePtr!DT rhs)
     {
         // ...
     }

 Ali


i added this static variable:

static int destcalls = 0;

changed constructor to:

     this(DT)(scope auto ref UniquePtr!DT rhs)
     {
         // here rhs releases pointer
         pragma(msg, typeof(rhs));
     }

wich prints "UniquePtr!(B)" on my machine,
and destructor:

     ~this() { destcalls++; }

Following code compiles and runs ok:

     class A {}
     class B: A {}
     UniquePtr!A a = UniquePtr!A.make();
     assert(destcalls == 0);
     UniquePtr!A b = UniquePtr!B.make();
     assert(destcalls == 1);

Destructor is called for the result of "UniquePtr!B.make();", and 
if it actually was passed by value (wich is indicated by pragma's 
output), b's internal pointer would refer to freed heap block.
Jun 22 2017
prev sibling parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:

 No time to think about the rest of the design but just to get 
 the code compiled, replace 'ref' with 'auto ref' like so:


Ok, looks like this indeed passes rhs by reference, thank you.

destcalls - number of times UniquePtr destructor was called
deallocs - number of times internal pointer was freed.

unittest
{
     deallocs = destcalls = 0;

     class A {}
     class B: A {}

     {
         UniquePtr!B b = UniquePtr!B.make();
         assert(b.owner);
         {
             UniquePtr!A a = b;
             assert(!b.owner);
             assert(a.owner);
             assert(destcalls == 0);
             assert(deallocs == 0);
         }
         assert(destcalls == 1);
         assert(deallocs == 1);
     }
     assert(destcalls == 2);
     assert(deallocs == 1);
}
Jun 22 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/22/2017 12:57 PM, Boris-Barboris wrote:

 On Thursday, 22 June 2017 at 19:17:13 UTC, Ali Çehreli wrote:

 No time to think about the rest of the design but just to get the code
 compiled, replace 'ref' with 'auto ref' like so:


 Ok, looks like this indeed passes rhs by reference, thank you.


To be complete, 'auto ref' passes lvalues by reference and rvalues by 
value, which you can detect with __traits(isRef):

struct S{
}

void foo()(auto ref S s) {
     static if (__traits(isRef, s)) {
         pragma(msg, "lvalue");
     } else {
         pragma(msg, "rvalue");
     }
}

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

     foo(S());
}

Ali
Jun 22 2017
parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Thursday, 22 June 2017 at 20:05:46 UTC, Ali Çehreli wrote:

 To be complete, 'auto ref' passes lvalues by reference and 
 rvalues by value, which you can detect with __traits(isRef):

 struct S{
 }

 void foo()(auto ref S s) {
     static if (__traits(isRef, s)) {
         pragma(msg, "lvalue");
     } else {
         pragma(msg, "rvalue");
     }
 }

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

     foo(S());
 }

 Ali


Thank you very much! And the last question:
Is it guaranteed an all compilers, that:
1). destructor for said rvalue is called only once.
2). function taking auto ref parameter gets that exact 
(memory-wise) rvalue, for example:

struct S {}

S produce() { return S(); }

consume(produce());

void consume(auto ref S s)
{
   // s passed by value, but is exactly that struct returned by 
produce, as if it
   // was RVO'd inside consume's stack frame.
   // and S destructor called only once on consume's scope escape?
}
Jun 22 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/22/2017 02:08 PM, Boris-Barboris wrote:

 On Thursday, 22 June 2017 at 20:05:46 UTC, Ali Çehreli wrote:

 To be complete, 'auto ref' passes lvalues by reference and rvalues by
 value, which you can detect with __traits(isRef):

 struct S{
 }

 void foo()(auto ref S s) {
     static if (__traits(isRef, s)) {
         pragma(msg, "lvalue");
     } else {
         pragma(msg, "rvalue");
     }
 }

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

     foo(S());
 }

 Ali


 Thank you very much! And the last question:
 Is it guaranteed an all compilers, that:
 1). destructor for said rvalue is called only once.
 2). function taking auto ref parameter gets that exact (memory-wise)
 rvalue, for example:

 struct S {}

 S produce() { return S(); }

 consume(produce());

 void consume(auto ref S s)
 {
   // s passed by value, but is exactly that struct returned by produce,
 as if it
   // was RVO'd inside consume's stack frame.
   // and S destructor called only once on consume's scope escape?
 }


I'm not sure whether it's RVO or moving in what condition, but yes, 
there will be no copy. You will get the bit representation of the 
constructed object.

And yes, there should be one destructor, which may be a no-op if you 
grab its resource and set it to null.

On all compilers...

Ali
Jun 22 2017
parent reply Boris-Barboris <ismailsiege gmail.com> writes:
On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:

 And yes, there should be one destructor, which may be a no-op 
 if you grab its resource and set it to null.

 On all compilers...


That's a relief, thank you for your help.
Jun 22 2017
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 22 June 2017 at 21:19:43 UTC, Boris-Barboris wrote:

 On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:

 And yes, there should be one destructor, which may be a no-op 
 if you grab its resource and set it to null.

 On all compilers...


 That's a relief, thank you for your help.



 On all compilers...


... modulo bugs.

Closely Related: https://github.com/dlang/dmd/pull/6852
Jun 22 2017
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 23 June 2017 at 00:54:36 UTC, Petar Kirov [ZombineDev] 
wrote:

 On Thursday, 22 June 2017 at 21:19:43 UTC, Boris-Barboris wrote:

 On Thursday, 22 June 2017 at 21:16:40 UTC, Ali Çehreli wrote:

 And yes, there should be one destructor, which may be a no-op 
 if you grab its resource and set it to null.

 On all compilers...


 That's a relief, thank you for your help.



 On all compilers...


 ... modulo bugs.

 Closely Related: https://github.com/dlang/dmd/pull/6852


And also: 
https://github.com/dlang/dmd/pull/6847/files#diff-89369a835b853bb3725fd1d10d9c2d5d
Jun 22 2017