www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UniquePtr in D

reply Benjamin Thaut <code benjamin-thaut.de> writes:
When working with C-libraries in D I often wish for a equivalent of the 
C++11 unique_ptr. Unfortunately this is not possible in D. Consider the 
following source code:

http://dpaste.dzfl.pl/6e71c815

Is error 1 a bug? Because there should cleary not be any copy at this point.

Should we implement moving of u so that error 2 goes away? The compiler 
could move u into the function and move back out afterwards, but that 
would mean that the contents of u would be invalid for the duration of 
the function call (unsafe?)

Kind Regards
Benjamin Thaut
Dec 22 2013
next sibling parent reply "Kelet" <kelethunter gmail.com> writes:
On Sunday, 22 December 2013 at 13:19:48 UTC, Benjamin Thaut wrote:
 When working with C-libraries in D I often wish for a 
 equivalent of the C++11 unique_ptr. Unfortunately this is not 
 possible in D. Consider the following source code:

 http://dpaste.dzfl.pl/6e71c815

 Is error 1 a bug? Because there should cleary not be any copy 
 at this point.

 Should we implement moving of u so that error 2 goes away? The 
 compiler could move u into the function and move back out 
 afterwards, but that would mean that the contents of u would be 
 invalid for the duration of the function call (unsafe?)

 Kind Regards
 Benjamin Thaut
Is std.typecons.Unique[1] not the equivalent of unique_ptr? [1]: http://dlang.org/phobos/std_typecons.html#.Unique Regards, Kelet
Dec 22 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 22.12.2013 14:24, schrieb Kelet:
 On Sunday, 22 December 2013 at 13:19:48 UTC, Benjamin Thaut wrote:
 When working with C-libraries in D I often wish for a equivalent of
 the C++11 unique_ptr. Unfortunately this is not possible in D.
 Consider the following source code:

 http://dpaste.dzfl.pl/6e71c815

 Is error 1 a bug? Because there should cleary not be any copy at this
 point.

 Should we implement moving of u so that error 2 goes away? The
 compiler could move u into the function and move back out afterwards,
 but that would mean that the contents of u would be invalid for the
 duration of the function call (unsafe?)

 Kind Regards
 Benjamin Thaut
Is std.typecons.Unique[1] not the equivalent of unique_ptr? [1]: http://dlang.org/phobos/std_typecons.html#.Unique Regards, Kelet
Well yes, but I'm more interrested in moving around the ownership between functions, which works in c++11 because of the move semantics they implemented. This doesn't work in D for the shown reasons.
Dec 22 2013
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
I also just noticed that std.typecons.Unique does not disable the copy 
constructor. That doesn't seem very safe to me. The source code for it 
is also littered with tons of "Doens't work yet" comments.
Dec 22 2013
prev sibling parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
 Well yes, but I'm more interrested in moving around the 
 ownership between functions, which works in c++11 because of 
 the move semantics they implemented. This doesn't work in D for 
 the shown reasons.
http://dpaste.dzfl.pl/d1a6f7d0 That's as close as I could get. It doesn't move the parameters outside of the function. I workaround it by returning the unique input arguments. It's like "here's your object back". Everything is pretty much safe in safe mode - as long as you don't pass Unique values by reference.
Dec 22 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 22.12.2013 14:36, schrieb Sergei Nosov:
 On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
 Well yes, but I'm more interrested in moving around the ownership
 between functions, which works in c++11 because of the move semantics
 they implemented. This doesn't work in D for the shown reasons.
http://dpaste.dzfl.pl/d1a6f7d0 That's as close as I could get. It doesn't move the parameters outside of the function. I workaround it by returning the unique input arguments. It's like "here's your object back". Everything is pretty much safe in safe mode - as long as you don't pass Unique values by reference.
Uh, this looks a lot better then std.typecons.Unique Did you try doing a pull request to replace std.typecons.Unique with your implementation? Kind Regards Benjamin Thaut
Dec 22 2013
parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Sunday, 22 December 2013 at 13:40:30 UTC, Benjamin Thaut wrote:
 Uh, this looks a lot better then std.typecons.Unique
 Did you try doing a pull request to replace std.typecons.Unique 
 with your implementation?
No, I didn't. I'm kind of thinking, that the "unique" concept currently can't be fully implemented as a library solution. It needs at least some language support - disallow refernce usage for safety, make obvious implicit casts for... you know... for kids (currently, when I use this implementation ".unique" and "Unique!T" everywhere kind of clutters the code, and it also adds some burden on writing generic (or just general) code). So, it's kind of an open question.
 You probably want to fix this:
 class C{}
 void main(){
    auto x = unique!C().pack;
    auto y = x.unpack;
    auto z = x.unpack;
    assert(y.irel is z.irel);
}
That's right! Thanks!
Dec 22 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/22/2013 02:36 PM, Sergei Nosov wrote:
 On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
 Well yes, but I'm more interrested in moving around the ownership
 between functions, which works in c++11 because of the move semantics
 they implemented. This doesn't work in D for the shown reasons.
http://dpaste.dzfl.pl/d1a6f7d0 That's as close as I could get. It doesn't move the parameters outside of the function. I workaround it by returning the unique input arguments. It's like "here's your object back". Everything is pretty much safe in safe mode - as long as you don't pass Unique values by reference.
You probably want to fix this: class C{} void main(){ auto x = unique!C().pack; auto y = x.unpack; auto z = x.unpack; assert(y.irel is z.irel); }
Dec 22 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/22/2013 02:19 PM, Benjamin Thaut wrote:
 When working with C-libraries in D I often wish for a equivalent of the
 C++11 unique_ptr. Unfortunately this is not possible in D. Consider the
 following source code:

 http://dpaste.dzfl.pl/6e71c815

 Is error 1 a bug? Because there should cleary not be any copy at this
 point.
 ...
I don't think the conditions when a struct is moved are actually documented beyond the NRVO case. I think it ideally would be a bug, but this would require some kind of DIP.
 Should we implement moving of u so that error 2 goes away? The compiler
 could move u into the function and move back out afterwards, but that
 would mean that the contents of u would be invalid for the duration of
 the function call (unsafe?)

 Kind Regards
 Benjamin Thaut
The problem is that currently variable 'u' needs to be valid in order to be assigned to. It would be better if it was moved into test2 and then reinitialized. Currently, structs with disabled default construction and postblit are pretty much useless as value types. One has to include some kind of invalid default state. (As Sergei's implementation also does.) Then it is always possible to use explicit moves: import core.stdc.stdio; import std.algorithm; struct UniquePtr{ private int m_i; private bool _valid=false; property bool valid(){ return valid; } disable this(this); this(int i){ m_i = i; _valid = true; } ~this(){ if(_valid) printf("deleting %d\n", m_i); } } UniquePtr test1(){ auto u = UniquePtr(5); return u; } UniquePtr test2(UniquePtr u){ return move(u); } void main(string[] args){ auto u = test1(); u = test2(move(u)); }
Dec 22 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/22/2013 03:13 PM, Timon Gehr wrote:
 Is error 1 a bug? Because there should cleary not be any copy at this
 point.
 ...
I don't think the conditions when a struct is moved are actually documented beyond the NRVO case. I think it ideally would be a bug, but this would require some kind of DIP.
The main issue would probably be internal pointers in safe code.
Dec 22 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/22/2013 03:19 PM, Timon Gehr wrote:
 On 12/22/2013 03:13 PM, Timon Gehr wrote:
 Is error 1 a bug? Because there should cleary not be any copy at this
 point.
 ...
I don't think the conditions when a struct is moved are actually documented beyond the NRVO case. I think it ideally would be a bug, but this would require some kind of DIP.
The main issue would probably be internal pointers in safe code.
Scrap that, it would be disallowed to create them in safe code anyway, and hence the memory corruption would be attributed to the system code that created the pointer.
Dec 22 2013