Topic: New smart pointer: CopyConstructible and
Author: alexandre.isoard@gmail.com
Date: Fri, 16 Dec 2016 03:32:25 -0800 (PST)
Raw View
------=_Part_415_597689489.1481887945418
Content-Type: multipart/alternative;
boundary="----=_Part_416_1112300632.1481887945419"
------=_Part_416_1112300632.1481887945419
Content-Type: text/plain; charset=UTF-8
*Proposal*
template<class T,
class Cloner = std::default_clone<T>,
class Deleter = std::default_delete
<http://en.cppreference.com/w/cpp/memory/default_delete><T>
> class copy_ptr
std::copy_ptr is a smart pointer that owns and manages another object
through a pointer and disposes of that object when the copy_ptr goes out of
scope.
Additionally, it allocates a clone of the underlying object when it is
copied from, ensuring one copy_ptr manages each allocated object.
The object is disposed of using the associated deleter when either of the
following happens:
- the managing copy_ptr object is destroyed
- the managing copy_ptr object is assigned another pointer via operator=
<http://en.cppreference.com/w/cpp/memory/unique_ptr/operator%3D> or
reset() <http://en.cppreference.com/w/cpp/memory/unique_ptr/reset>.
The object is disposed of using a potentially user-supplied deleter by
calling get_deleter()(ptr). The default deleter uses the delete operator,
which destroys the object and deallocates the memory.
The object is cloned using the associated cloner when either of the
following happens:
- an other copy_ptr object is copy constructed from the managing copy_ptr
- an other copy_ptr object is copy assigned from the managing copy_ptr
The object is cloned using a potentially user-supplied cloner by calling
get_cloner()(ptr). The default cloner uses the new operator and the copy
constructor of the underlying type, which allocate a new object and copy
its original content.
A copy_ptr may alternatively own no object, in which case it is called
empty.
The class satisfies the requirements of MoveConstructible
<http://en.cppreference.com/w/cpp/concept/MoveConstructible>, MoveAssignable
<http://en.cppreference.com/w/cpp/concept/MoveAssignable>, CopyConstructible
<http://en.cppreference.com/w/cpp/concept/CopyConstructible> and
CopyAssignable <http://en.cppreference.com/w/cpp/concept/CopyAssignable> (the
later two may require T to be CopyConstructible).
*Member Types*
- pointer: T*
- element_type: T, the type of the object managed by this copy_ptr
- cloner_type: Cloner, the function object or lvalue reference to
function or to function object, to be called from the copy constructor and
copy assignment operators
- deleter_type: Deleter, the function object or lvalue reference to
function or to function object, to be called from the destructor
*Member Functions*
- operator=: assigns the copy_ptr
- release: returns a pointer to the managed object and releases ownership
- reset: replaces the managed object
- swap: swaps the managed objects
- get: returns a pointer to the managed object
- get_cloner: returns the cloner that is used for copy the managed object
- get_deleter: returns the deleter that is used for destruction of the
managed object
- operator bool: checks if there is an associated managed object
- operator*, operator->: dereferences pointer to the managed object
- make_copy: creates a copy pointer that manages a new object
- operator==, operator!=, etc: compares to an other copy_ptr or with
nullptr
- std::swap: specializes the std::swap algorithm
- std::hash<std::copy_ptr>: hash support for std::copy_ptr
*Example*
#include<iostream>
#include<memory>
struct Foo
{
Foo() { std::cout << "Foo::Foo()\n"; }
Foo(const Foo& o) { std::cout << "Foo::Foo(const Foo&)\n"; }
~Foo() { std::cout << "Foo::~Foo()\n"; }
void bar() { std::cout << "Foo::bar()\n"; }
}
void f(const Foo&)
{
std::cout << "f(const Foo&)\n";
}
int main()
{
std::copy_ptr<Foo> p1(new Foo); // p1 owns Foo
if (p1) p1->bar();
{
std::copy_ptr<Foo> p2(std::move(p1)); // now p2 owns Foo
f(*p2);
p1 = p2; // cloned into p1
std::cout << "destroying p2...\n";
}
if (p1) p1->bar();
// Second Foo instance is destroyed when p1 goes out of scope
}
Output:
Foo::Foo()
Foo::bar()
f(const Foo&)
Foo::Foo(const Foo&)
destroying p2...
Foo::~Foo()
Foo::bar()
Foo::~Foo()
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/13702f32-32c2-447f-9996-3624fd678675%40isocpp.org.
------=_Part_416_1112300632.1481887945419
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><b>Proposal</b><div><br></div><div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Cloner</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">default_clone</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">>,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Deleter</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><a href=3D"http://en.cppreference.com/w/cpp/memory/default_delete=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">default_delete</span></a><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> copy_ptr</span></div></code></div><br><font face=3D"courier new,=
monospace">std::copy_ptr</font> is a smart pointer that owns and manages a=
nother object through a pointer and disposes of that object when the <font =
face=3D"courier new, monospace">copy_ptr </font>goes out of scope.<div>Addi=
tionally, it allocates a clone of the underlying object when it is copied f=
rom, ensuring one <font face=3D"courier new, monospace">copy_ptr </font>man=
ages each allocated object.<br><br>The object is disposed of using the asso=
ciated deleter when either of the following happens:<br><ul><li>the managin=
g <font face=3D"courier new, monospace">copy_ptr </font>object is destroyed=
<br></li><li>the managing <font face=3D"courier new, monospace">copy_ptr </=
font>object is assigned another pointer via <a href=3D"http://en.cppreferen=
ce.com/w/cpp/memory/unique_ptr/operator%3D">operator=3D</a> or <a href=3D"h=
ttp://en.cppreference.com/w/cpp/memory/unique_ptr/reset">reset()</a>.</li><=
/ul>The object is disposed of using a potentially user-supplied deleter by =
calling <font face=3D"courier new, monospace">get_deleter()(ptr)</font>. Th=
e default deleter uses the <font face=3D"courier new, monospace">delete </f=
ont>operator, which destroys the object and deallocates the memory.</div><d=
iv><br></div><div>The object is cloned using the associated cloner when eit=
her of the following happens:</div><div><ul><li>an other <font face=3D"cour=
ier new, monospace">copy_ptr </font>object is copy constructed from the man=
aging copy_ptr</li><li>an other <font face=3D"courier new, monospace">copy_=
ptr </font>object is copy assigned from the managing copy_ptr</li></ul><div=
>The object is cloned using a potentially user-supplied cloner by calling <=
font face=3D"courier new, monospace">get_cloner()(ptr)</font>. The default =
cloner uses the <font face=3D"courier new, monospace">new </font>operator a=
nd the copy constructor of the underlying type, which allocate a new object=
and copy its original content.</div><br>A <font face=3D"courier new, monos=
pace">copy_ptr </font>may alternatively own no object, in which case it is =
called empty.<div><br></div>The class satisfies the requirements of <a href=
=3D"http://en.cppreference.com/w/cpp/concept/MoveConstructible">MoveConstru=
ctible</a>,=C2=A0<a href=3D"http://en.cppreference.com/w/cpp/concept/MoveAs=
signable">MoveAssignable</a>, <a href=3D"http://en.cppreference.com/w/cpp/c=
oncept/CopyConstructible">CopyConstructible</a> and=C2=A0<a href=3D"http://=
en.cppreference.com/w/cpp/concept/CopyAssignable">CopyAssignable</a>=C2=A0(=
the later two may require T to be CopyConstructible).<br></div><div><br></d=
iv><div><b>Member Types</b></div><div><ul><li><font face=3D"courier new, mo=
nospace">pointer</font>: <font face=3D"courier new, monospace">T*</font></l=
i><li><font face=3D"courier new, monospace">element_type</font>: <font face=
=3D"courier new, monospace">T</font>, the type of the object managed by thi=
s <font face=3D"courier new, monospace">copy_ptr</font></li><li><font face=
=3D"courier new, monospace">cloner_type</font>:=C2=A0<font face=3D"courier =
new, monospace">Cloner</font>, the function object or lvalue reference to f=
unction or to function object, to be called from the copy constructor and c=
opy assignment operators</li><li><font face=3D"courier new, monospace">dele=
ter_type</font>:=C2=A0<font face=3D"courier new, monospace">Deleter</font>,=
the function object or lvalue reference to function or to function object,=
to be called from the destructor</li></ul></div><div><br></div><div><b>Mem=
ber Functions</b></div><div><ul><li>operator=3D: assigns the copy_ptr</li><=
li>release: returns a pointer to the managed object and releases ownership<=
/li><li>reset: replaces the managed object</li><li>swap: swaps the managed =
objects</li><li>get: returns a pointer to the managed object</li><li>get_cl=
oner: returns the cloner that is used for copy the managed object</li><li>g=
et_deleter: returns the deleter that is used for destruction of the managed=
object</li><li>operator bool: checks if there is an associated managed obj=
ect</li><li>operator*, operator->: dereferences pointer to the managed o=
bject</li><li>make_copy: creates a copy pointer that manages a new object</=
li><li>operator=3D=3D, operator!=3D, etc: compares to an other copy_ptr or =
with nullptr</li><li>std::swap: specializes the std::swap algorithm</li><li=
>std::hash<std::copy_ptr>: hash support for std::copy_ptr</li></ul></=
div><div><b>Example</b></div><div><br></div><div><div class=3D"prettyprint"=
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#66006=
6"><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span=
><span style=3D"color: #080;" class=3D"styled-by-prettify"><iostream>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span><=
span style=3D"color: #080;" class=3D"styled-by-prettify"><memory></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"Foo::Foo()\n"</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> o</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #080;" class=3D"styled-by-prettify">"Foo::Foo(const F=
oo&)\n"</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">~</span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"Foo::~Foo()\n"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> bar</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"Foo::=
bar()\n"</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"f(const Foo&)\n"</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><div cla=
ss=3D"subprettyprint">=C2=A0 =C2=A0 std::copy_ptr<Foo> p1(new Foo); =
=C2=A0// p1 owns Foo</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 if (p=
1) p1->bar();</div><div class=3D"subprettyprint">=C2=A0</div><div class=
=3D"subprettyprint">=C2=A0 =C2=A0 {</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 std::copy_ptr<Foo> p2(std::move(p1)); =C2=A0=
// now p2 owns Foo</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 f(*p2);</div><div class=3D"subprettyprint">=C2=A0</div><div class=3D=
"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 p1 =3D p2; =C2=A0// cloned int=
o p1</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::co=
ut << "destroying p2...\n";</div><div class=3D"subprettypri=
nt">=C2=A0 =C2=A0 }</div><div class=3D"subprettyprint">=C2=A0</div><div cla=
ss=3D"subprettyprint">=C2=A0 =C2=A0 if (p1) p1->bar();</div><div class=
=3D"subprettyprint">=C2=A0</div><div class=3D"subprettyprint">=C2=A0 =C2=A0=
// Second Foo instance is destroyed when p1 goes out of scope</div></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font></div></=
code></div><br>Output:</div><div><br></div><font face=3D"courier new, monos=
pace">Foo::Foo()</font><div><font face=3D"courier new, monospace">Foo::bar(=
)</font></div><div><font face=3D"courier new, monospace">f(const Foo&)<=
/font></div><div><font face=3D"courier new, monospace">Foo::Foo(const Foo&a=
mp;)</font></div><div><font face=3D"courier new, monospace">destroying p2..=
..</font></div><div><font face=3D"courier new, monospace">Foo::~Foo()</font>=
</div><div><font face=3D"courier new, monospace">Foo::bar()</font></div><di=
v><font face=3D"courier new, monospace">Foo::~Foo()</font><br><div><br></di=
v></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/13702f32-32c2-447f-9996-3624fd678675%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/13702f32-32c2-447f-9996-3624fd678675=
%40isocpp.org</a>.<br />
------=_Part_416_1112300632.1481887945419--
------=_Part_415_597689489.1481887945418--
.
Author: alexandre.isoard@gmail.com
Date: Fri, 16 Dec 2016 03:36:31 -0800 (PST)
Raw View
------=_Part_435_335899302.1481888191580
Content-Type: multipart/alternative;
boundary="----=_Part_436_1096523731.1481888191580"
------=_Part_436_1096523731.1481888191580
Content-Type: text/plain; charset=UTF-8
I forgot to add the following member function:
- copy: returns a pointer to a copy of the managed object
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02f36598-ca05-4c8c-b420-884cb5e10ec1%40isocpp.org.
------=_Part_436_1096523731.1481888191580
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I forgot to add the following member function:</div><=
div><ul><li>copy: returns a pointer to a copy of the managed object</li></u=
l></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02f36598-ca05-4c8c-b420-884cb5e10ec1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02f36598-ca05-4c8c-b420-884cb5e10ec1=
%40isocpp.org</a>.<br />
------=_Part_436_1096523731.1481888191580--
------=_Part_435_335899302.1481888191580--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 13:40:54 +0200
Raw View
On 16 December 2016 at 13:32, <alexandre.isoard@gmail.com> wrote:
> std::copy_ptr is a smart pointer that owns and manages another object
There is ongoing work in the area, in
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0201r1.pdf
which originally was closer to a cloning pointer than a polymorphic
value. The paper author has told me that
he thinks it's a good idea to propose both a cloning pointer and a
polymorphic value, and that he plans to
do just that in the future.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY3c67YgivjPTSCB%2BFLUGfiFgi8F_8kcSSUwPeBp9tMmw%40mail.gmail.com.
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 12:44:38 +0100
Raw View
--001a11377e185632a80543c518bc
Content-Type: text/plain; charset=UTF-8
So it transfers ownership when moving and does a deep copy when copying?
I don't think two so different semantics are a great idea.
Jonathan
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZxM5qe9qVfags_iNrd0YpvUo2xmSw-OqifnHJ%2B4wJtxA%40mail.gmail.com.
--001a11377e185632a80543c518bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">So it transfers ownership when moving and does a deep copy w=
hen copying?</p>
<p dir=3D"ltr">I don't think two so different semantics are a great ide=
a.</p>
<p dir=3D"ltr">Jonathan</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJZxM5qe9qVfags_iNrd0YpvUo2xmSw-=
OqifnHJ%2B4wJtxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZxM5qe9q=
Vfags_iNrd0YpvUo2xmSw-OqifnHJ%2B4wJtxA%40mail.gmail.com</a>.<br />
--001a11377e185632a80543c518bc--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 13:48:52 +0200
Raw View
On 16 December 2016 at 13:44, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> So it transfers ownership when moving and does a deep copy when copying?
>
> I don't think two so different semantics are a great idea.
Right, and I think My Little Pony is under-appreciated, but if I
really want to convey useful information to anyone,
I explain why. Those semantics happen to be superior to the alternatives.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZ9MjM%3DjCd2YkHHVjurPZB7mscgzbxnOjdLWqZSt=
p0bBQ%40mail.gmail.com.
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Fri, 16 Dec 2016 03:58:40 -0800 (PST)
Raw View
------=_Part_419_239395026.1481889520061
Content-Type: multipart/alternative;
boundary="----=_Part_420_2068846563.1481889520061"
------=_Part_420_2068846563.1481889520061
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, 16 December 2016 11:44:40 UTC, Jonathan M=C3=BCller wrote:
>
> So it transfers ownership when moving and does a deep copy when copying?
>
> I don't think two so different semantics are a great idea.
>
>
>
That seems to work for std::vector, and many other types.
The difference here would be that the dynamic type can vary from the static=
=20
type, but I don't see why that means that "move when you can move and copy=
=20
otherwise" stops being a sensible policy.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e1e780b7-34ea-41bf-9aba-22a1eb6a5f3f%40isocpp.or=
g.
------=_Part_420_2068846563.1481889520061
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, 16 December 2016 11:44:40 UTC, Jonathan M=
=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"lt=
r">So it transfers ownership when moving and does a deep copy when copying?=
</p>
<p dir=3D"ltr">I don't think two so different semantics are a great ide=
a.</p>
<p dir=3D"ltr"><br></p></blockquote><div><br></div><div>That seems to work =
for std::vector, and many other types.</div><div><br></div><div>The differe=
nce here would be that the dynamic type can vary from the static type, but =
I don't see why that means that "move when you can move and copy o=
therwise" stops being a sensible policy.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e1e780b7-34ea-41bf-9aba-22a1eb6a5f3f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e1e780b7-34ea-41bf-9aba-22a1eb6a5f3f=
%40isocpp.org</a>.<br />
------=_Part_420_2068846563.1481889520061--
------=_Part_419_239395026.1481889520061--
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 13:05:29 +0100
Raw View
--001a1144c922dd50ff0543c56286
Content-Type: text/plain; charset=UTF-8
On Dec 16, 2016 12:48, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
>
> Right, and I think My Little Pony is under-appreciated, but if I
> really want to convey useful information to anyone,
> I explain why. Those semantics happen to be superior to the alternatives.
Take std::optional, when you move it the old optional will not become
empty: move does basically the same as copy, just uses T's copy instead of
move constructor.
And this behavior makes sense: optional<T> is supposed to behave like a T.
std::unique_ptr on the other hand is only moveable and transfers ownership.
This also makes sense.
Now, std::optional does not work with polymorphic objects. So I see a point
for a smart pointer with deep copying semantics. But then it should behave
like the type so moving should also da a "move clone".
Now consider a smart pointer with deep copying semantics but ownership
transfer on move: What is it supposed to model? It does not behave like the
type T as moving does something different.
Consider using the pointer with a type that is only copyable. If you have
code that takes a reference directly and (somehow) invokes a move
operation, the move will copy, so it is safe to use moved-from object
there. But if you use that with this smart pointer, it is not safe anymore,
as the pointer will become null.
I personally think that this kind of semantic difference is not a good idea.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJb9BfQzhoWxLz4-QvD-PkEupxucguMvQEETfcUM7Ed%3DJA%40mail.gmail.com.
--001a1144c922dd50ff0543c56286
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 16, 2016 12:48, "Ville Voutilainen" <<a =
href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>=
> wrote:<br>
><br>
> Right, and I think My Little Pony is under-appreciated, but if I<br>
> really want to convey useful information to anyone,<br>
> I explain why. Those semantics happen to be superior to the alternativ=
es.</p>
<p dir=3D"ltr">Take std::optional, when you move it the old optional will n=
ot become empty: move does basically the same as copy, just uses T's co=
py instead of move constructor.<br>
And this behavior makes sense: optional<T> is supposed to behave like=
a T.</p>
<p dir=3D"ltr">std::unique_ptr on the other hand is only moveable and trans=
fers ownership. This also makes sense.</p>
<p dir=3D"ltr">Now, std::optional does not work with polymorphic objects. S=
o I see a point for a smart pointer with deep copying semantics. But then i=
t should behave like the type so moving should also da a "move clone&q=
uot;.</p>
<p dir=3D"ltr">Now consider a smart pointer with deep copying semantics but=
ownership transfer on move: What is it supposed to model? It does not beha=
ve like the type T as moving does something different.</p>
<p dir=3D"ltr">Consider using the pointer with a type that is only copyable=
.. If you have code that takes a reference directly and (somehow) invokes a =
move operation, the move will copy, so it is safe to use moved-from object =
there. But if you use that with this smart pointer, it is not safe anymore,=
as the pointer will become null.</p>
<p dir=3D"ltr">I personally think that this kind of semantic difference is =
not a good idea.</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJb9BfQzhoWxLz4-QvD-PkEupxucguMv=
QEETfcUM7Ed%3DJA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJb9BfQzho=
WxLz4-QvD-PkEupxucguMvQEETfcUM7Ed%3DJA%40mail.gmail.com</a>.<br />
--001a1144c922dd50ff0543c56286--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 14:11:48 +0200
Raw View
On 16 December 2016 at 14:05, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On Dec 16, 2016 12:48, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> wrote:
>>
>> Right, and I think My Little Pony is under-appreciated, but if I
>> really want to convey useful information to anyone,
>> I explain why. Those semantics happen to be superior to the alternatives=
..
>
> Take std::optional, when you move it the old optional will not become emp=
ty:
> move does basically the same as copy, just uses T's copy instead of move
> constructor.
> And this behavior makes sense: optional<T> is supposed to behave like a T=
..
>
> std::unique_ptr on the other hand is only moveable and transfers ownershi=
p.
> This also makes sense.
>
> Now, std::optional does not work with polymorphic objects. So I see a poi=
nt
> for a smart pointer with deep copying semantics. But then it should behav=
e
> like the type so moving should also da a "move clone".
>
> Now consider a smart pointer with deep copying semantics but ownership
> transfer on move: What is it supposed to model? It does not behave like t=
he
> type T as moving does something different.
>
> Consider using the pointer with a type that is only copyable. If you have
> code that takes a reference directly and (somehow) invokes a move operati=
on,
> the move will copy, so it is safe to use moved-from object there. But if =
you
> use that with this smart pointer, it is not safe anymore, as the pointer
> will become null.
>
> I personally think that this kind of semantic difference is not a good id=
ea.
That semantic difference allows doing noexcept moves, which ends up
being such a major
win that quite many people are able to tolerate this trade-off.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUb4-hGZq8ZDNR%3DeMv2erJK%2B8UH8Qj%3DSNeG%2=
B9DBW678Wkw%40mail.gmail.com.
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 13:17:04 +0100
Raw View
--001a114fd5b44990b70543c58cbc
Content-Type: text/plain; charset=UTF-8
On Dec 16, 2016 13:11, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
>
> That semantic difference allows doing noexcept moves, which ends up
> being such a major
> win that quite many people are able to tolerate this trade-off.
Yes, I can understand that.
But what about a free function `clone()` that copies a `std::unique_ptr`?
This does not change anything about unique pointer which is fine as it is
and still allows deep copy.
Only downside: You can't copy it in generic code. But with move semantics,
how often would you need that anyway.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbQAx5Pne%2Bqu4A92Pd%3DNgiLQsj8auGuJHeZiKmz1fouQg%40mail.gmail.com.
--001a114fd5b44990b70543c58cbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 16, 2016 13:11, "Ville Voutilainen" <<a =
href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>=
> wrote:<br>
><br>
> That semantic difference allows doing noexcept moves, which ends up<br=
>
> being such a major<br>
> win that quite many people are able to tolerate this trade-off.</p>
<p dir=3D"ltr">Yes, I can understand that.</p>
<p dir=3D"ltr">But what about a free function `clone()` that copies a `std:=
:unique_ptr`?</p>
<p dir=3D"ltr">This does not change anything about unique pointer which is =
fine as it is and still allows deep copy.</p>
<p dir=3D"ltr">Only downside: You can't copy it in generic code. But wi=
th move semantics, how often would you need that anyway.<br></p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJbQAx5Pne%2Bqu4A92Pd%3DNgiLQsj8=
auGuJHeZiKmz1fouQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbQAx5P=
ne%2Bqu4A92Pd%3DNgiLQsj8auGuJHeZiKmz1fouQg%40mail.gmail.com</a>.<br />
--001a114fd5b44990b70543c58cbc--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Fri, 16 Dec 2016 04:17:57 -0800 (PST)
Raw View
------=_Part_536_1984025714.1481890677120
Content-Type: multipart/alternative;
boundary="----=_Part_537_1038365811.1481890677120"
------=_Part_537_1038365811.1481890677120
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, 16 December 2016 12:17:06 UTC, Jonathan M=C3=BCller wrote:
>
> On Dec 16, 2016 13:11, "Ville Voutilainen" <ville.vo...@gmail.com=20
> <javascript:>> wrote:
> >
> > That semantic difference allows doing noexcept moves, which ends up
> > being such a major
> > win that quite many people are able to tolerate this trade-off.
>
> Yes, I can understand that.
>
> But what about a free function `clone()` that copies a `std::unique_ptr`?
>
> This does not change anything about unique pointer which is fine as it is=
=20
> and still allows deep copy.
>
How do you know the dynamic type?
=20
> Only downside: You can't copy it in generic code. But with move semantics=
,=20
> how often would you need that anyway.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a1beb4e1-0b2e-4d0b-b955-dc8005518e4f%40isocpp.or=
g.
------=_Part_537_1038365811.1481890677120
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, 16 December 2016 12:17:06 UTC, Jonathan=
M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"=
ltr">On Dec 16, 2016 13:11, "Ville Voutilainen" <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"wZ16iERhCgAJ" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">ville.vo...@gmail.=
com</a>> wrote:<br>
><br>
> That semantic difference allows doing noexcept moves, which ends up<br=
>
> being such a major<br>
> win that quite many people are able to tolerate this trade-off.</p>
<p dir=3D"ltr">Yes, I can understand that.</p>
<p dir=3D"ltr">But what about a free function `clone()` that copies a `std:=
:unique_ptr`?</p>
<p dir=3D"ltr">This does not change anything about unique pointer which is =
fine as it is and still allows deep copy.</p></blockquote><div><br></div><d=
iv>How do you know the dynamic type?</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<p dir=3D"ltr">Only downside: You can't copy it in generic code. But wi=
th move semantics, how often would you need that anyway.<br></p>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1beb4e1-0b2e-4d0b-b955-dc8005518e4f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1beb4e1-0b2e-4d0b-b955-dc8005518e4f=
%40isocpp.org</a>.<br />
------=_Part_537_1038365811.1481890677120--
------=_Part_536_1984025714.1481890677120--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 14:19:09 +0200
Raw View
On 16 December 2016 at 14:17, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On Dec 16, 2016 13:11, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> wrote:
>>
>> That semantic difference allows doing noexcept moves, which ends up
>> being such a major
>> win that quite many people are able to tolerate this trade-off.
>
> Yes, I can understand that.
>
> But what about a free function `clone()` that copies a `std::unique_ptr`?
That doesn't provide the convenience we're looking for with these
proposed wrappers. The best thing
about them is that you can stash them into a struct and define no
special member functions for that
struct and you get the right semantics. Such a free function would
need to be called manually, and
it's not type-erasing and polymorphic, whereas the proposed indirect
and cloned_ptr are.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZ-Xm2cQ6jCwQaSAhF%2BsCudqnHeivrJvqCQ4mhKv=
9rN%2Bg%40mail.gmail.com.
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 13:20:43 +0100
Raw View
--001a1144c92259be250543c599be
Content-Type: text/plain; charset=UTF-8
On Dec 16, 2016 13:17, "Jonathan Wakely" <cxx@kayari.org> wrote:
> How do you know the dynamic type?
How would the proposed copy_ptr now it?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJYxcqgmzJWOkVwghC5aLErniN3ah0g820%3DMtz3O694PLg%40mail.gmail.com.
--001a1144c92259be250543c599be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 16, 2016 13:17, "Jonathan Wakely" <<a hr=
ef=3D"mailto:cxx@kayari.org">cxx@kayari.org</a>> wrote:<br>
> How do you know the dynamic type?</p>
<p dir=3D"ltr">How would the proposed copy_ptr now it?<br>
</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJYxcqgmzJWOkVwghC5aLErniN3ah0g8=
20%3DMtz3O694PLg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJYxcqgmzJ=
WOkVwghC5aLErniN3ah0g820%3DMtz3O694PLg%40mail.gmail.com</a>.<br />
--001a1144c92259be250543c599be--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Fri, 16 Dec 2016 04:25:32 -0800 (PST)
Raw View
------=_Part_438_419946093.1481891132093
Content-Type: multipart/alternative;
boundary="----=_Part_439_937456352.1481891132093"
------=_Part_439_937456352.1481891132093
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, 16 December 2016 12:20:45 UTC, Jonathan M=C3=BCller wrote:
>
> On Dec 16, 2016 13:17, "Jonathan Wakely" <c...@kayari.org <javascript:>>=
=20
> wrote:
> > How do you know the dynamic type?
>
> How would the proposed copy_ptr now it?
>
p0201r1 deals with that problem, which is why it's a better approach.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/314742e5-f0e8-47f8-a9fd-c808436426fc%40isocpp.or=
g.
------=_Part_439_937456352.1481891132093
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, 16 December 2016 12:20:45 UTC, Jonathan M=C3=BC=
ller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">On =
Dec 16, 2016 13:17, "Jonathan Wakely" <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"rVz_iXdhCgAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">c...@kayari.org</a>> wrot=
e:<br>
> How do you know the dynamic type?</p>
<p dir=3D"ltr">How would the proposed copy_ptr now it?<br></p></blockquote>=
<div><br></div><div>=C2=A0p0201r1 deals with that problem, which is why it&=
#39;s a better approach.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/314742e5-f0e8-47f8-a9fd-c808436426fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/314742e5-f0e8-47f8-a9fd-c808436426fc=
%40isocpp.org</a>.<br />
------=_Part_439_937456352.1481891132093--
------=_Part_438_419946093.1481891132093--
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 13:26:18 +0100
Raw View
--001a1145b1ba4eb8ce0543c5adc0
Content-Type: text/plain; charset=UTF-8
On Dec 16, 2016 13:19, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
> That doesn't provide the convenience we're looking for with these
> proposed wrappers. The best thing
> about them is that you can stash them into a struct and define no
> special member functions for that
> struct and you get the right semantics. Such a free function would
> need to be called manually, and
> it's not type-erasing and polymorphic, whereas the proposed indirect
> and cloned_ptr are.
But I don't think you get the right semantics for that, that's my point.
You get inconsistent semantics.
As a struct member I would rather have a non-null wrapper that gives value
sematics to a polymorphic type. Not a mix between optional and unique_ptr.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ%2BAR_UC_xheJnkn4yBg7iny3_BHNXHOa1M1%2BiZEpuqiQ%40mail.gmail.com.
--001a1145b1ba4eb8ce0543c5adc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 16, 2016 13:19, "Ville Voutilainen" <<a =
href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>=
> wrote:<br>
> That doesn't provide the convenience we're looking for with th=
ese<br>
> proposed wrappers. The best thing<br>
> about them is that you can stash them into a struct and define no<br>
> special member functions for that<br>
> struct and you get the right semantics. Such a free function would<br>
> need to be called manually, and<br>
> it's not type-erasing and polymorphic, whereas the proposed indire=
ct<br>
> and cloned_ptr are.</p>
<p dir=3D"ltr">But I don't think you get the right semantics for that, =
that's my point.<br>
You get inconsistent semantics.</p>
<p dir=3D"ltr">As a struct member I would rather have a non-null wrapper th=
at gives value sematics to a polymorphic type. Not a mix between optional a=
nd unique_ptr.</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ%2BAR_UC_xheJnkn4yBg7iny3_BHN=
XHOa1M1%2BiZEpuqiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ%2BAR=
_UC_xheJnkn4yBg7iny3_BHNXHOa1M1%2BiZEpuqiQ%40mail.gmail.com</a>.<br />
--001a1145b1ba4eb8ce0543c5adc0--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 14:28:57 +0200
Raw View
On 16 December 2016 at 14:26, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On Dec 16, 2016 13:19, "Ville Voutilainen" <ville.voutilainen@gmail.com>
> wrote:
>> That doesn't provide the convenience we're looking for with these
>> proposed wrappers. The best thing
>> about them is that you can stash them into a struct and define no
>> special member functions for that
>> struct and you get the right semantics. Such a free function would
>> need to be called manually, and
>> it's not type-erasing and polymorphic, whereas the proposed indirect
>> and cloned_ptr are.
>
> But I don't think you get the right semantics for that, that's my point.
> You get inconsistent semantics.
But I do, otherwise I wouldn't have chosen a cloned_ptr.
> As a struct member I would rather have a non-null wrapper that gives valu=
e
> sematics to a polymorphic type.
Like the proposed std::indirect? I got the impression that its latest
feedback was to move it
closer to value semantics of a polymorphic type.
>Not a mix between optional and unique_ptr.
All pointers are a mix between "optional" and something else since
they can be null. And that's
just fine for many cases.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYq%2B_To254SGVAesMfZtFJDLSVmLvU%3DU3bhBq8=
3xZdA1w%40mail.gmail.com.
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Fri, 16 Dec 2016 13:36:33 +0100
Raw View
On 16.12.2016 13:25, Jonathan Wakely wrote:
> p0201r1 deals with that problem, which is why it's a better approach.
On 16.12.2016 13:28, Ville Voutilainen wrote:
> Like the proposed std::indirect? I got the impression that its latest
> feedback was to move it
> closer to value semantics of a polymorphic type.
Yeah, exactly. I like `std::indirect`, it behaves like a `T` and has
consistent semantics.
> But I do, otherwise I wouldn't have chosen a cloned_ptr.
Alright, hard to argue with that and I get your arguments.
I just don't think that's particularly "clean".
If the type wasn't polymorphic you'd embed it as a member directly,
so copying will copy all members and moving will move all members.
But if you change it to use a polymorphic type you use a cloning_ptr,
so copy will still copy everything but moving will suddenly leave the
type with an "empty" member?
I wouldn't like using that struct with that change.
There might be a possible use case for cloning_ptr,
but I don't think its as a member.
And if you don't use it is a member,
you don't need a copy constructor but can use a free function.
> All pointers are a mix between "optional" and something else since
> they can be null. And that's
> just fine for many cases.
I meant on a semantic point of view: mix between value semantics and
ownership transfer.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8c29792-37a9-2eb1-1a5e-69ccfe247661%40gmail.com.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 16 Dec 2016 07:46:58 -0500
Raw View
It sounds to me like this may be another difference between clone_ptr and p=
olymorphic value. And more reason to have both.
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Jonathan M=C3=BCller
Sent: Friday, December 16, 2016 7:36 AM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] New smart pointer: CopyConstructible and CopyA=
ssignable flavor of unique_ptr
On 16.12.2016 13:25, Jonathan Wakely wrote:
> p0201r1 deals with that problem, which is why it's a better approach.
On 16.12.2016 13:28, Ville Voutilainen wrote:
> Like the proposed std::indirect? I got the impression that its latest
> feedback was to move it
> closer to value semantics of a polymorphic type.
Yeah, exactly. I like `std::indirect`, it behaves like a `T` and has
consistent semantics.
> But I do, otherwise I wouldn't have chosen a cloned_ptr.
Alright, hard to argue with that and I get your arguments.
I just don't think that's particularly "clean".
If the type wasn't polymorphic you'd embed it as a member directly,
so copying will copy all members and moving will move all members.
But if you change it to use a polymorphic type you use a cloning_ptr,
so copy will still copy everything but moving will suddenly leave the=20
type with an "empty" member?
I wouldn't like using that struct with that change.
There might be a possible use case for cloning_ptr,
but I don't think its as a member.
And if you don't use it is a member,
you don't need a copy constructor but can use a free function.
> All pointers are a mix between "optional" and something else since
> they can be null. And that's
> just fine for many cases.
I meant on a semantic point of view: mix between value semantics and=20
ownership transfer.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c8c29792-37a9-2eb1-1a5e-69ccfe247661%40gmail.com=
..
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161216124658.4919375.82156.21506%40gmail.com.
.
Author: alexandre.isoard@gmail.com
Date: Fri, 16 Dec 2016 06:22:10 -0800 (PST)
Raw View
------=_Part_720_1868468284.1481898130784
Content-Type: multipart/alternative;
boundary="----=_Part_721_1303644550.1481898130784"
------=_Part_721_1303644550.1481898130784
Content-Type: text/plain; charset=UTF-8
On Friday, December 16, 2016 at 11:40:56 AM UTC, Ville Voutilainen wrote:
>
> On 16 December 2016 at 13:32, <alexandr...@gmail.com <javascript:>>
> wrote:
> > std::copy_ptr is a smart pointer that owns and manages another object
>
> There is ongoing work in the area, in
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0201r1.pdf
> which originally was closer to a cloning pointer than a polymorphic
> value. The paper author has told me that
> he thinks it's a good idea to propose both a cloning pointer and a
> polymorphic value, and that he plans to
> do just that in the future.
>
Thank you. This seems indeed a good plan.
To add some precisions:
- std::copy_ptr would perform a deep copy even when copying from a const
std::copy_ptr into a const std::copy_ptr.
That is:
const std::copy_ptr<T*> x(foo);
const std::copy_ptr<T*> y(x);
Would end up with two copies of foo. Else when they go out of scope a
double free would occur.
By the way, here is a example use case that I needed recently:
I am wrapping an external C library which has the following particularities:
- All the objects are opaque pointers
- All objects have deep-copy functions and deleters.
- Most of its functions free their arguments and allocate their results
Behind the hood it uses copy-on-write to make copy cheap and it sometimes
recycle one of its argument when the returned object has the same structure
(to avoid a free and a malloc). (but that is semantically identical to an
actual copy and an actual free)
What I do is that I wrap those objects into a copy_ptr and provide the
custom copy and custom deleter. This allows me to do the following:
copy_ptr<obj> do_something(copy_ptr<obj> a, copy_ptr<obj> b) {
return make_copy(obj_do_something(a.release(), b.release());
}
Where obj_do_something is the C function, and do_something is the C++
wrapper.
This handle nicely the case where we don't want a spurious copy:
For example:
a = do_something(std::move(a), b);
Will deep-copy b, then move a, compute and move it back to a.
This provides a move-semantic aware wrapper that handle all the allocation
for free and do not perform spurious copies.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2298fa65-32bb-435a-a486-c7e000267c11%40isocpp.org.
------=_Part_721_1303644550.1481898130784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, December 16, 2016 at 11:40:56 AM UTC, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16 D=
ecember 2016 at 13:32, =C2=A0<<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"8movcEtfCgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">alexandr...@gmail.com</a>> wrote:
<br>> std::copy_ptr is a smart pointer that owns and manages another obj=
ect
<br>
<br>There is ongoing work in the area, in
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0201r1.=
pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%=
2Fdocs%2Fpapers%2F2016%2Fp0201r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNEw-dD03A2HwSOMFD1XO51yMA9D7w';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2=
FWG21%2Fdocs%2Fpapers%2F2016%2Fp0201r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNEw-dD03A2HwSOMFD1XO51yMA9D7w';return true;">http://open-std.org=
/JTC1/SC22/<wbr>WG21/docs/papers/2016/p0201r1.<wbr>pdf</a>
<br>which originally was closer to a cloning pointer than a polymorphic
<br>value. The paper author has told me that
<br>he thinks it's a good idea to propose both a cloning pointer and a
<br>polymorphic value, and that he plans to
<br>do just that in the future.
<br></blockquote><div><br></div><div>Thank you. This seems indeed a good pl=
an.</div><div><br></div><div>To add some precisions:</div><div><ul><li>std:=
:copy_ptr would perform a deep copy even when copying from a const std::cop=
y_ptr into a const std::copy_ptr.<br></li></ul><div>That is:</div></div><di=
v><br></div><div>const std::copy_ptr<T*> x(foo);</div><div>const std:=
:copy_ptr<T*> y(x);</div><div><br></div><div>Would end up with two co=
pies of foo. Else when they go out of scope a double free would occur.</div=
><div><br></div><div><br></div><div>By the way, here is a example use case =
that I needed recently:</div><div><br></div><div>I am wrapping an external =
C library which has the following particularities:</div><div><ul><li>All th=
e objects are opaque pointers</li><li>All objects have deep-copy functions =
and deleters.</li><li>Most of its functions free their arguments and alloca=
te their results</li></ul><div>Behind the hood it uses copy-on-write to mak=
e copy cheap and it sometimes recycle one of its argument when the returned=
object has the same structure (to avoid a free and a malloc). (but that is=
semantically identical to an actual copy and an actual free)</div></div><d=
iv><br></div><div>What I do is that I wrap those objects into a copy_ptr an=
d provide the custom copy and custom deleter. This allows me to do the foll=
owing:</div><div><br></div><div>copy_ptr<obj> do_something(copy_ptr&l=
t;obj> a, copy_ptr<obj> b) {</div><div>=C2=A0 =C2=A0 return make_c=
opy(obj_do_something(a.release(), b.release());<br>}</div><div><br></div><d=
iv>Where obj_do_something is the C function, and do_something is the C++ wr=
apper.</div><div>This handle nicely the case where we don't want a spur=
ious copy:</div><div><br></div><div>For example:</div><div><br></div><div>a=
=3D do_something(std::move(a), b);</div><div><br></div><div>Will deep-copy=
b, then move a, compute and move it back to a.</div><div><br></div><div>Th=
is provides a move-semantic aware wrapper that handle all the allocation fo=
r free and do not perform spurious copies.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2298fa65-32bb-435a-a486-c7e000267c11%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2298fa65-32bb-435a-a486-c7e000267c11=
%40isocpp.org</a>.<br />
------=_Part_721_1303644550.1481898130784--
------=_Part_720_1868468284.1481898130784--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 16 Dec 2016 07:46:27 -0800 (PST)
Raw View
------=_Part_774_728247322.1481903188016
Content-Type: multipart/alternative;
boundary="----=_Part_775_1532963622.1481903188017"
------=_Part_775_1532963622.1481903188017
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 16, 2016 at 6:58:40 AM UTC-5, Jonathan Wakely wrote:
>
> On Friday, 16 December 2016 11:44:40 UTC, Jonathan M=C3=BCller wrote:
>>
>> So it transfers ownership when moving and does a deep copy when copying?
>>
>> I don't think two so different semantics are a great idea.
>>
>>
>>
> That seems to work for std::vector, and many other types.
>
I really think this needs to be emphasized. Cheap-move+deep-copy are hardly=
=20
an uncommon set of semantics in C++. Every standard library container uses=
=20
these semantics.
The only question is how deep the copy goes: whether you're creating a `T`=
=20
itself or some class derived from `T`.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/67a9e9ed-8748-4098-a43b-33598b516464%40isocpp.or=
g.
------=_Part_775_1532963622.1481903188017
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 16, 2016 at 6:58:40 AM UTC-5, Jonathan=
Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Friday, 16 December 2016 11:44:40 UTC, Jonathan M=C3=BCller wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">So it transfers ownershi=
p when moving and does a deep copy when copying?</p>
<p dir=3D"ltr">I don't think two so different semantics are a great ide=
a.</p>
<p dir=3D"ltr"><br></p></blockquote><div><br></div><div>That seems to work =
for std::vector, and many other types.</div></div></blockquote><div><br>I r=
eally think this needs to be emphasized. Cheap-move+deep-copy are hardly an=
uncommon set of semantics in C++. Every standard library container uses th=
ese semantics.<br><br>The only question is how deep the copy goes: whether =
you're creating a `T` itself or some class derived from `T`.<br></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67a9e9ed-8748-4098-a43b-33598b516464%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67a9e9ed-8748-4098-a43b-33598b516464=
%40isocpp.org</a>.<br />
------=_Part_775_1532963622.1481903188017--
------=_Part_774_728247322.1481903188016--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 16 Dec 2016 17:51:51 +0200
Raw View
On 16 December 2016 at 17:46, Nicol Bolas <jmckesson@gmail.com> wrote:
> The only question is how deep the copy goes: whether you're creating a `T`
> itself or some class derived from `T`.
In these problem areas the latter, even if I have a
deepcopyinghandle<T>. Copying or even
cloning a T itself is not all that difficult if it likes to be cloned.
It's much harder to clone
a U when all you have is a handle to a T, and that sort of deep
copying is a real life-saver
when provided by an easy-to-use library facility. It makes otherwise
hard problems trivial,
or rather allows focusing on the actual problem rather than the
cloning mechanics.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYkuueANAWE%3DRpdt6t%2B%3D38Q_FpLvrdJbtQmP6HSRfdD-g%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 16 Dec 2016 08:06:14 -0800 (PST)
Raw View
------=_Part_735_616581044.1481904374400
Content-Type: multipart/alternative;
boundary="----=_Part_736_1931310412.1481904374400"
------=_Part_736_1931310412.1481904374400
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 16, 2016 at 10:46:28 AM UTC-5, Nicol Bolas wrote:
>
> On Friday, December 16, 2016 at 6:58:40 AM UTC-5, Jonathan Wakely wrote:
>>
>> On Friday, 16 December 2016 11:44:40 UTC, Jonathan M=C3=BCller wrote:
>>>
>>> So it transfers ownership when moving and does a deep copy when copying=
?
>>>
>>> I don't think two so different semantics are a great idea.
>>>
>>>
>>>
>> That seems to work for std::vector, and many other types.
>>
>
> I really think this needs to be emphasized. Cheap-move+deep-copy are=20
> hardly an uncommon set of semantics in C++. Every standard library=20
> container uses these semantics.
>
> The only question is how deep the copy goes: whether you're creating a `T=
`=20
> itself or some class derived from `T`.
>
Oh, and one more C++ standard library type that has these semantics: `any`.=
=20
It requires that the types provided are copyable, and on copying an `any`,=
=20
it will perform a copy (of the exact type provided, of course). However,=20
the move may be merely a pointer-shift (to support small object=20
optimization, `any`s that store objects with noexcept moves may use the=20
object's move constructor instead of the `any` pointer-shift).
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ad1bfe2f-c769-4938-9f92-8f6b396f03e6%40isocpp.or=
g.
------=_Part_736_1931310412.1481904374400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 16, 2016 at 10:46:28 AM UTC-5, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
Friday, December 16, 2016 at 6:58:40 AM UTC-5, Jonathan Wakely wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, 16 December =
2016 11:44:40 UTC, Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><p dir=3D"ltr">So it transfers ownership when moving and does a=
deep copy when copying?</p>
<p dir=3D"ltr">I don't think two so different semantics are a great ide=
a.</p>
<p dir=3D"ltr"><br></p></blockquote><div><br></div><div>That seems to work =
for std::vector, and many other types.</div></div></blockquote><div><br>I r=
eally think this needs to be emphasized. Cheap-move+deep-copy are hardly an=
uncommon set of semantics in C++. Every standard library container uses th=
ese semantics.<br><br>The only question is how deep the copy goes: whether =
you're creating a `T` itself or some class derived from `T`.<br></div><=
/div></blockquote><div><br>Oh, and one more C++ standard library type that =
has these semantics: `any`. It requires that the types provided are copyabl=
e, and on copying an `any`, it will perform a copy (of the exact type provi=
ded, of course). However, the move may be merely a pointer-shift (to suppor=
t small object optimization, `any`s that store objects with noexcept moves =
may use the object's move constructor instead of the `any` pointer-shif=
t).<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad1bfe2f-c769-4938-9f92-8f6b396f03e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad1bfe2f-c769-4938-9f92-8f6b396f03e6=
%40isocpp.org</a>.<br />
------=_Part_736_1931310412.1481904374400--
------=_Part_735_616581044.1481904374400--
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Fri, 16 Dec 2016 18:43:31 -0800 (PST)
Raw View
------=_Part_2494_1330130897.1481942611913
Content-Type: multipart/alternative;
boundary="----=_Part_2495_93022081.1481942611913"
------=_Part_2495_93022081.1481942611913
Content-Type: text/plain; charset=UTF-8
On Friday, December 16, 2016 at 3:32:25 AM UTC-8, Alexandre Isoard wrote:
>
> *Proposal*
>
> template<class T,
> class Cloner = std::default_clone<T>,
> class Deleter = std::default_delete
> <http://en.cppreference.com/w/cpp/memory/default_delete><T>
> > class copy_ptr
>
> std::copy_ptr is a smart pointer that owns and manages another object
> through a pointer and disposes of that object when the copy_ptr goes out
> of scope.
> Additionally, it allocates a clone of the underlying object when it is
> copied from, ensuring one copy_ptr manages each allocated object.
>
> The object is disposed of using the associated deleter when either of the
> following happens:
>
> - the managing copy_ptr object is destroyed
> - the managing copy_ptr object is assigned another pointer via
> operator=
> <http://en.cppreference.com/w/cpp/memory/unique_ptr/operator%3D> or
> reset() <http://en.cppreference.com/w/cpp/memory/unique_ptr/reset>.
>
> The object is disposed of using a potentially user-supplied deleter by
> calling get_deleter()(ptr). The default deleter uses the delete operator,
> which destroys the object and deallocates the memory.
>
> The object is cloned using the associated cloner when either of the
> following happens:
>
> - an other copy_ptr object is copy constructed from the managing
> copy_ptr
> - an other copy_ptr object is copy assigned from the managing copy_ptr
>
> The object is cloned using a potentially user-supplied cloner by calling
> get_cloner()(ptr). The default cloner uses the new operator and the copy
> constructor of the underlying type, which allocate a new object and copy
> its original content.
>
> A copy_ptr may alternatively own no object, in which case it is called
> empty.
>
> The class satisfies the requirements of MoveConstructible
> <http://en.cppreference.com/w/cpp/concept/MoveConstructible>,
> MoveAssignable <http://en.cppreference.com/w/cpp/concept/MoveAssignable>,
> CopyConstructible
> <http://en.cppreference.com/w/cpp/concept/CopyConstructible> and
> CopyAssignable <http://en.cppreference.com/w/cpp/concept/CopyAssignable> (the
> later two may require T to be CopyConstructible).
>
> *Member Types*
>
> - pointer: T*
> - element_type: T, the type of the object managed by this copy_ptr
> - cloner_type: Cloner, the function object or lvalue reference to
> function or to function object, to be called from the copy constructor and
> copy assignment operators
> - deleter_type: Deleter, the function object or lvalue reference to
> function or to function object, to be called from the destructor
>
>
> *Member Functions*
>
> - operator=: assigns the copy_ptr
> - release: returns a pointer to the managed object and releases
> ownership
> - reset: replaces the managed object
> - swap: swaps the managed objects
> - get: returns a pointer to the managed object
> - get_cloner: returns the cloner that is used for copy the managed
> object
> - get_deleter: returns the deleter that is used for destruction of the
> managed object
> - operator bool: checks if there is an associated managed object
> - operator*, operator->: dereferences pointer to the managed object
> - make_copy: creates a copy pointer that manages a new object
> - operator==, operator!=, etc: compares to an other copy_ptr or with
> nullptr
>
> You have a major issue with equality that is fatal to the proposal, IMO.
Copying creates a new object. If equality is defined on the pointer, then
copies are *never* equal to their original (except nullptr case). If you
define equality by the value-type, then you have confusingly different
semantics from the other smart-pointer types.
You could delete the equality operators (maybe keep
"operator==(std::nullptr_t)" only), but that also sounds like a fatal flaw.
>
> - std::swap: specializes the std::swap algorithm
> - std::hash<std::copy_ptr>: hash support for std::copy_ptr
>
> *Example*
>
> #include<iostream>
> #include<memory>
>
> struct Foo
> {
> Foo() { std::cout << "Foo::Foo()\n"; }
> Foo(const Foo& o) { std::cout << "Foo::Foo(const Foo&)\n"; }
> ~Foo() { std::cout << "Foo::~Foo()\n"; }
> void bar() { std::cout << "Foo::bar()\n"; }
> }
>
> void f(const Foo&)
> {
> std::cout << "f(const Foo&)\n";
> }
>
> int main()
> {
> std::copy_ptr<Foo> p1(new Foo); // p1 owns Foo
> if (p1) p1->bar();
>
> {
> std::copy_ptr<Foo> p2(std::move(p1)); // now p2 owns Foo
> f(*p2);
>
> p1 = p2; // cloned into p1
> std::cout << "destroying p2...\n";
> }
>
> if (p1) p1->bar();
>
> // Second Foo instance is destroyed when p1 goes out of scope
> }
>
> Output:
>
> Foo::Foo()
> Foo::bar()
> f(const Foo&)
> Foo::Foo(const Foo&)
> destroying p2...
> Foo::~Foo()
> Foo::bar()
> Foo::~Foo()
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6911ac18-c144-4e4b-9fad-fe360fbb4c55%40isocpp.org.
------=_Part_2495_93022081.1481942611913
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, December 16, 2016 at 3:32:25 AM UTC-8, =
Alexandre Isoard wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><b>Proposal</b><div><br></div><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:#008">template</s=
pan><span style=3D"color:#660"><</span><span style=3D"color:#008">class<=
/span><span style=3D"color:#000"> T</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008">class</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">Cloner</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000">default_clone</span><span style=3D=
"color:#660"><</span><span style=3D"color:#000">T</span><span style=3D"c=
olor:#660">>,</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color:#008">class</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">Deleter</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><a =
href=3D"http://en.cppreference.com/w/cpp/memory/default_delete" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Fdefault_d=
elete\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHtNWhNDR8JsARzrVNyDZKv9uIz6Q&=
#39;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Fdefault_delete\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHtNWhNDR8JsARzrVNyDZKv9uIz6Q';retu=
rn true;"><span style=3D"color:#000">std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">default_delete</span></a><span style=3D"=
color:#660"><</span><span style=3D"color:#000">T</span><span style=3D"co=
lor:#660">></span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#660">></span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">class</span><span style=3D"color:#000"> copy_ptr</span></div></cod=
e></div><br><font face=3D"courier new, monospace">std::copy_ptr</font> is a=
smart pointer that owns and manages another object through a pointer and d=
isposes of that object when the <font face=3D"courier new, monospace">copy_=
ptr </font>goes out of scope.<div>Additionally, it allocates a clone of the=
underlying object when it is copied from, ensuring one <font face=3D"couri=
er new, monospace">copy_ptr </font>manages each allocated object.<br><br>Th=
e object is disposed of using the associated deleter when either of the fol=
lowing happens:<br><ul><li>the managing <font face=3D"courier new, monospac=
e">copy_ptr </font>object is destroyed<br></li><li>the managing <font face=
=3D"courier new, monospace">copy_ptr </font>object is assigned another poin=
ter via <a href=3D"http://en.cppreference.com/w/cpp/memory/unique_ptr/opera=
tor%3D" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2=
Fmemory%2Funique_ptr%2Foperator%253D\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNFkMowHwWb-CXJYRuER8z4Vdi0Qtg';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcp=
p%2Fmemory%2Funique_ptr%2Foperator%253D\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNFkMowHwWb-CXJYRuER8z4Vdi0Qtg';return true;">operator=3D</a> or <a =
href=3D"http://en.cppreference.com/w/cpp/memory/unique_ptr/reset" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Funique_=
ptr%2Freset\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGzmYfVvPXt1P7rhK2lyVW-j=
6bH8A';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fmemory%2Funique_ptr%2=
Freset\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGzmYfVvPXt1P7rhK2lyVW-j6bH8A=
';return true;">reset()</a>.</li></ul>The object is disposed of using a=
potentially user-supplied deleter by calling <font face=3D"courier new, mo=
nospace">get_deleter()(ptr)</font>. The default deleter uses the <font face=
=3D"courier new, monospace">delete </font>operator, which destroys the obje=
ct and deallocates the memory.</div><div><br></div><div>The object is clone=
d using the associated cloner when either of the following happens:</div><d=
iv><ul><li>an other <font face=3D"courier new, monospace">copy_ptr </font>o=
bject is copy constructed from the managing copy_ptr</li><li>an other <font=
face=3D"courier new, monospace">copy_ptr </font>object is copy assigned fr=
om the managing copy_ptr</li></ul><div>The object is cloned using a potenti=
ally user-supplied cloner by calling <font face=3D"courier new, monospace">=
get_cloner()(ptr)</font>. The default cloner uses the <font face=3D"courier=
new, monospace">new </font>operator and the copy constructor of the underl=
ying type, which allocate a new object and copy its original content.</div>=
<br>A <font face=3D"courier new, monospace">copy_ptr </font>may alternative=
ly own no object, in which case it is called empty.<div><br></div>The class=
satisfies the requirements of <a href=3D"http://en.cppreference.com/w/cpp/=
concept/MoveConstructible" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cpprefe=
rence.com%2Fw%2Fcpp%2Fconcept%2FMoveConstructible\x26sa\x3dD\x26sntz\x3d1\x=
26usg\x3dAFQjCNG9q1JBaTNiZ7Vh_C9K1hefbHQWoA';return true;" onclick=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference=
..com%2Fw%2Fcpp%2Fconcept%2FMoveConstructible\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNG9q1JBaTNiZ7Vh_C9K1hefbHQWoA';return true;">MoveConstructible=
</a>,=C2=A0<a href=3D"http://en.cppreference.com/w/cpp/concept/MoveAssignab=
le" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcon=
cept%2FMoveAssignable\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF6GrlYRYGOufF=
ABxI-2LHYYuUHzA';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FM=
oveAssignable\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF6GrlYRYGOufFABxI-2LH=
YYuUHzA';return true;">MoveAssigna<wbr>ble</a>, <a href=3D"http://en.cp=
preference.com/w/cpp/concept/CopyConstructible" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FCopyConstructible\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG-iAn9ftcEFUQ6NfvI6mNqhZH_Aw';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FCopyConstructible\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNG-iAn9ftcEFUQ6NfvI6mNqhZH_Aw';return true;=
">CopyConstructible</a> and=C2=A0<a href=3D"http://en.cppreference.com/w/cp=
p/concept/CopyAssignable" target=3D"_blank" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreferen=
ce.com%2Fw%2Fcpp%2Fconcept%2FCopyAssignable\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNHv92JdHik3TE576sBvuu5aQBH_9g';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2=
Fw%2Fcpp%2Fconcept%2FCopyAssignable\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NHv92JdHik3TE576sBvuu5aQBH_9g';return true;">CopyAssignable</a>=C2=A0(t=
he later two may require T to be CopyConstructible).<br></div><div><br></di=
v><div><b>Member Types</b></div><div><ul><li><font face=3D"courier new, mon=
ospace">pointer</font>: <font face=3D"courier new, monospace">T*</font></li=
><li><font face=3D"courier new, monospace">element_type</font>: <font face=
=3D"courier new, monospace">T</font>, the type of the object managed by thi=
s <font face=3D"courier new, monospace">copy_ptr</font></li><li><font face=
=3D"courier new, monospace">cloner_type</font>:=C2=A0<font face=3D"courier =
new, monospace">Cloner</font>, the function object or lvalue reference to f=
unction or to function object, to be called from the copy constructor and c=
opy assignment operators</li><li><font face=3D"courier new, monospace">dele=
ter_type</font>:=C2=A0<font face=3D"courier new, monospace">Deleter</font>,=
the function object or lvalue reference to function or to function object,=
to be called from the destructor</li></ul></div><div><br></div><div><b>Mem=
ber Functions</b></div><div><ul><li>operator=3D: assigns the copy_ptr</li><=
li>release: returns a pointer to the managed object and releases ownership<=
/li><li>reset: replaces the managed object</li><li>swap: swaps the managed =
objects</li><li>get: returns a pointer to the managed object</li><li>get_cl=
oner: returns the cloner that is used for copy the managed object</li><li>g=
et_deleter: returns the deleter that is used for destruction of the managed=
object</li><li>operator bool: checks if there is an associated managed obj=
ect</li><li>operator*, operator->: dereferences pointer to the managed o=
bject</li><li>make_copy: creates a copy pointer that manages a new object</=
li><li>operator=3D=3D, operator!=3D, etc: compares to an other copy_ptr or =
with nullptr</li></ul></div></div></blockquote><div>You have a major issue =
with equality that is fatal to the proposal, IMO.<br><br>Copying creates a =
new object. If equality is defined on the pointer, then copies are <i>never=
</i> equal to their original (except nullptr case). If you define equality =
by the value-type, then you have confusingly different semantics from the o=
ther smart-pointer types.<br><br>You could delete the equality operators (m=
aybe keep "operator=3D=3D(std::nullptr_t)" only), but that also s=
ounds like a fatal flaw.<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><ul><li>std::swap: specializes the std::swap al=
gorithm</li><li>std::hash<std::copy_ptr>: hash support for std::copy_=
ptr</li></ul></div><div><b>Example</b></div><div><br></div><div><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word"><code><div><font color=
=3D"#660066"><span style=3D"color:#800">#include</span><span style=3D"color=
:#080"><iostream></span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#800">#include</span><span style=3D"color:#080"><memory>=
;</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008=
">struct</span><span style=3D"color:#000"> </span><span style=3D"color:#606=
">Foo</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#606">Foo</span><span style=3D"color:#660">()</span><span style=
=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">cout </span><span style=
=3D"color:#660"><<</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#080">"Foo::Foo()\n"</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</s=
pan><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r:#606">Foo</span><span style=3D"color:#660">(</span><span style=3D"color:#=
008">const</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
06">Foo</span><span style=3D"color:#660">&</span><span style=3D"color:#=
000"> o</span><span style=3D"color:#660">)</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">cout =
</span><span style=3D"color:#660"><<</span><span style=3D"color:#000"=
> </span><span style=3D"color:#080">"Foo::Foo(const Foo&)\n"<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#660">~</span><span style=3D"color:#606"=
>Foo</span><span style=3D"color:#660">()</span><span style=3D"color:#000"> =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">cout </span><span style=3D"color:#660">&l=
t;<</span><span style=3D"color:#000"> </span><span style=3D"color:#080">=
"Foo::~Foo()\n"</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</s=
pan><span style=3D"color:#000"> bar</span><span style=3D"color:#660">()</sp=
an><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">cout </span><span style=
=3D"color:#660"><<</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#080">"Foo::bar()\n"</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> f</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#008">const</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Foo</span><span style=3D"color:#660">&)</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"col=
or:#660">::</span><span style=3D"color:#000">cout </span><span style=3D"col=
or:#660"><<</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#080">"f(const Foo&)\n"</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}=
</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> main</span><span style=3D"color:#660=
">()</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br></span><span style=3D"color:#000"><=
div>=C2=A0 =C2=A0 std::copy_ptr<Foo> p1(new Foo); =C2=A0// p1 owns Fo=
o</div><div>=C2=A0 =C2=A0 if (p1) p1->bar();</div><div>=C2=A0</div><div>=
=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::copy_ptr<Foo&=
gt; p2(std::move(p1)); =C2=A0// now p2 owns Foo</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 f(*p2);</div><div>=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 p=
1 =3D p2; =C2=A0// cloned into p1</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std=
::cout << "destroying p2...\n";</div><div>=C2=A0 =C2=A0 }</=
div><div>=C2=A0</div><div>=C2=A0 =C2=A0 if (p1) p1->bar();</div><div>=C2=
=A0</div><div>=C2=A0 =C2=A0 // Second Foo instance is destroyed when p1 goe=
s out of scope</div></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></font></div></code></div><br>Output:</div><div>=
<br></div><font face=3D"courier new, monospace">Foo::Foo()</font><div><font=
face=3D"courier new, monospace">Foo::bar()</font></div><div><font face=3D"=
courier new, monospace">f(const Foo&)</font></div><div><font face=3D"co=
urier new, monospace">Foo::Foo(const Foo&)</font></div><div><font face=
=3D"courier new, monospace">destroying p2...</font></div><div><font face=3D=
"courier new, monospace">Foo::~Foo()</font></div><div><font face=3D"courier=
new, monospace">Foo::bar()</font></div><div><font face=3D"courier new, mon=
ospace">Foo::~Foo()</font><br><div><br></div></div></div></blockquote></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6911ac18-c144-4e4b-9fad-fe360fbb4c55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6911ac18-c144-4e4b-9fad-fe360fbb4c55=
%40isocpp.org</a>.<br />
------=_Part_2495_93022081.1481942611913--
------=_Part_2494_1330130897.1481942611913--
.
Author: jgottman6@gmail.com
Date: Fri, 16 Dec 2016 18:45:38 -0800 (PST)
Raw View
------=_Part_349_817252494.1481942738584
Content-Type: multipart/alternative;
boundary="----=_Part_350_483177092.1481942738585"
------=_Part_350_483177092.1481942738585
Content-Type: text/plain; charset=UTF-8
Please don't define any relational operators for this class. If the
relational operators are defined to compare the contained pointers, then
given the code
clone_ptr<int> foo(new int(7));
clone_ptr<int> bar = foo;
assert(foo == bar);
the assertion will fail. This means that code using clone_ptr's in
associative containers will compile but completely fail to work at runtime.
Joe Gottman
On Friday, December 16, 2016 at 6:32:25 AM UTC-5, Alexandre Isoard wrote:
>
> *Proposal*
>
> template<class T,
> class Cloner = std::default_clone<T>,
> class Deleter = std::default_delete
> <http://en.cppreference.com/w/cpp/memory/default_delete><T>
> > class copy_ptr
>
> std::copy_ptr is a smart pointer that owns and manages another object
> through a pointer and disposes of that object when the copy_ptr goes out
> of scope.
> Additionally, it allocates a clone of the underlying object when it is
> copied from, ensuring one copy_ptr manages each allocated object.
>
> The object is disposed of using the associated deleter when either of the
> following happens:
>
> - the managing copy_ptr object is destroyed
> - the managing copy_ptr object is assigned another pointer via
> operator=
> <http://en.cppreference.com/w/cpp/memory/unique_ptr/operator%3D> or
> reset() <http://en.cppreference.com/w/cpp/memory/unique_ptr/reset>.
>
> The object is disposed of using a potentially user-supplied deleter by
> calling get_deleter()(ptr). The default deleter uses the delete operator,
> which destroys the object and deallocates the memory.
>
> The object is cloned using the associated cloner when either of the
> following happens:
>
> - an other copy_ptr object is copy constructed from the managing
> copy_ptr
> - an other copy_ptr object is copy assigned from the managing copy_ptr
>
> The object is cloned using a potentially user-supplied cloner by calling
> get_cloner()(ptr). The default cloner uses the new operator and the copy
> constructor of the underlying type, which allocate a new object and copy
> its original content.
>
> A copy_ptr may alternatively own no object, in which case it is called
> empty.
>
> The class satisfies the requirements of MoveConstructible
> <http://en.cppreference.com/w/cpp/concept/MoveConstructible>,
> MoveAssignable <http://en.cppreference.com/w/cpp/concept/MoveAssignable>,
> CopyConstructible
> <http://en.cppreference.com/w/cpp/concept/CopyConstructible> and
> CopyAssignable <http://en.cppreference.com/w/cpp/concept/CopyAssignable> (the
> later two may require T to be CopyConstructible).
>
> *Member Types*
>
> - pointer: T*
> - element_type: T, the type of the object managed by this copy_ptr
> - cloner_type: Cloner, the function object or lvalue reference to
> function or to function object, to be called from the copy constructor and
> copy assignment operators
> - deleter_type: Deleter, the function object or lvalue reference to
> function or to function object, to be called from the destructor
>
>
> *Member Functions*
>
> - operator=: assigns the copy_ptr
> - release: returns a pointer to the managed object and releases
> ownership
> - reset: replaces the managed object
> - swap: swaps the managed objects
> - get: returns a pointer to the managed object
> - get_cloner: returns the cloner that is used for copy the managed
> object
> - get_deleter: returns the deleter that is used for destruction of the
> managed object
> - operator bool: checks if there is an associated managed object
> - operator*, operator->: dereferences pointer to the managed object
> - make_copy: creates a copy pointer that manages a new object
> - operator==, operator!=, etc: compares to an other copy_ptr or with
> nullptr
> - std::swap: specializes the std::swap algorithm
> - std::hash<std::copy_ptr>: hash support for std::copy_ptr
>
> *Example*
>
> #include<iostream>
> #include<memory>
>
> struct Foo
> {
> Foo() { std::cout << "Foo::Foo()\n"; }
> Foo(const Foo& o) { std::cout << "Foo::Foo(const Foo&)\n"; }
> ~Foo() { std::cout << "Foo::~Foo()\n"; }
> void bar() { std::cout << "Foo::bar()\n"; }
> }
>
> void f(const Foo&)
> {
> std::cout << "f(const Foo&)\n";
> }
>
> int main()
> {
> std::copy_ptr<Foo> p1(new Foo); // p1 owns Foo
> if (p1) p1->bar();
>
> {
> std::copy_ptr<Foo> p2(std::move(p1)); // now p2 owns Foo
> f(*p2);
>
> p1 = p2; // cloned into p1
> std::cout << "destroying p2...\n";
> }
>
> if (p1) p1->bar();
>
> // Second Foo instance is destroyed when p1 goes out of scope
> }
>
> Output:
>
> Foo::Foo()
> Foo::bar()
> f(const Foo&)
> Foo::Foo(const Foo&)
> destroying p2...
> Foo::~Foo()
> Foo::bar()
> Foo::~Foo()
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/731cb931-eb89-41e0-8c1b-bfccd6329eaa%40isocpp.org.
------=_Part_350_483177092.1481942738585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Please don't define any relational operators for this =
class. If the relational operators are defined to compare the contained poi=
nters, then given the code<br><br><div style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">clone_ptr</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify"><int></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">7</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>clone_ptr</span><span style=3D"=
color: #080;" class=3D"styled-by-prettify"><int></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> bar </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">assert</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fo=
o </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></c=
ode></div><br><br>the assertion will fail.=C2=A0 This means that code using=
clone_ptr's in associative containers will compile but completely fail=
to work at runtime.<br><br>Joe Gottman<br><br><br>On Friday, December 16, =
2016 at 6:32:25 AM UTC-5, Alexandre Isoard wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><b>Proposal</b><div><br></div><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">template</span><span style=3D"color:#660"><</span><span =
style=3D"color:#008">class</span><span style=3D"color:#000"> T</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color:#008">class</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">Cloner</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> std</=
span><span style=3D"color:#660">::</span><span style=3D"color:#000">default=
_clone</span><span style=3D"color:#660"><</span><span style=3D"color:#00=
0">T</span><span style=3D"color:#660">>,</span><span style=3D"color:#000=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">Deleter</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> </span><a href=3D"http://en.cppreference.com/w/cpp/memory/=
default_delete" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw=
%2Fcpp%2Fmemory%2Fdefault_delete\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHt=
NWhNDR8JsARzrVNyDZKv9uIz6Q';return true;" onclick=3D"this.href=3D'h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2F=
memory%2Fdefault_delete\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHtNWhNDR8Js=
ARzrVNyDZKv9uIz6Q';return true;"><span style=3D"color:#000">std</span><=
span style=3D"color:#660">::</span><span style=3D"color:#000">default_delet=
e</span></a><span style=3D"color:#660"><</span><span style=3D"color:#000=
">T</span><span style=3D"color:#660">></span><span style=3D"color:#000">=
<br></span><span style=3D"color:#660">></span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">class</span><span style=3D"color:#000">=
copy_ptr</span></div></code></div><br><font face=3D"courier new, monospace=
">std::copy_ptr</font> is a smart pointer that owns and manages another obj=
ect through a pointer and disposes of that object when the <font face=3D"co=
urier new, monospace">copy_ptr </font>goes out of scope.<div>Additionally, =
it allocates a clone of the underlying object when it is copied from, ensur=
ing one <font face=3D"courier new, monospace">copy_ptr </font>manages each =
allocated object.<br><br>The object is disposed of using the associated del=
eter when either of the following happens:<br><ul><li>the managing <font fa=
ce=3D"courier new, monospace">copy_ptr </font>object is destroyed<br></li><=
li>the managing <font face=3D"courier new, monospace">copy_ptr </font>objec=
t is assigned another pointer via <a href=3D"http://en.cppreference.com/w/c=
pp/memory/unique_ptr/operator%3D" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cp=
preference.com%2Fw%2Fcpp%2Fmemory%2Funique_ptr%2Foperator%253D\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNFkMowHwWb-CXJYRuER8z4Vdi0Qtg';return true;"=
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen=
..cppreference.com%2Fw%2Fcpp%2Fmemory%2Funique_ptr%2Foperator%253D\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFkMowHwWb-CXJYRuER8z4Vdi0Qtg';return tru=
e;">operator=3D</a> or <a href=3D"http://en.cppreference.com/w/cpp/memory/u=
nique_ptr/reset" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2F=
w%2Fcpp%2Fmemory%2Funique_ptr%2Freset\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGzmYfVvPXt1P7rhK2lyVW-j6bH8A';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fc=
pp%2Fmemory%2Funique_ptr%2Freset\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGz=
mYfVvPXt1P7rhK2lyVW-j6bH8A';return true;">reset()</a>.</li></ul>The obj=
ect is disposed of using a potentially user-supplied deleter by calling <fo=
nt face=3D"courier new, monospace">get_deleter()(ptr)</font>. The default d=
eleter uses the <font face=3D"courier new, monospace">delete </font>operato=
r, which destroys the object and deallocates the memory.</div><div><br></di=
v><div>The object is cloned using the associated cloner when either of the =
following happens:</div><div><ul><li>an other <font face=3D"courier new, mo=
nospace">copy_ptr </font>object is copy constructed from the managing copy_=
ptr</li><li>an other <font face=3D"courier new, monospace">copy_ptr </font>=
object is copy assigned from the managing copy_ptr</li></ul><div>The object=
is cloned using a potentially user-supplied cloner by calling <font face=
=3D"courier new, monospace">get_cloner()(ptr)</font>. The default cloner us=
es the <font face=3D"courier new, monospace">new </font>operator and the co=
py constructor of the underlying type, which allocate a new object and copy=
its original content.</div><br>A <font face=3D"courier new, monospace">cop=
y_ptr </font>may alternatively own no object, in which case it is called em=
pty.<div><br></div>The class satisfies the requirements of <a href=3D"http:=
//en.cppreference.com/w/cpp/concept/MoveConstructible" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FMoveConstructible=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG9q1JBaTNiZ7Vh_C9K1hefbHQWoA';=
return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dht=
tp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FMoveConstructible\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG9q1JBaTNiZ7Vh_C9K1hefbHQWoA';retur=
n true;">MoveConstructible</a>,=C2=A0<a href=3D"http://en.cppreference.com/=
w/cpp/concept/MoveAssignable" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppref=
erence.com%2Fw%2Fcpp%2Fconcept%2FMoveAssignable\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNF6GrlYRYGOufFABxI-2LHYYuUHzA';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.c=
om%2Fw%2Fcpp%2Fconcept%2FMoveAssignable\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNF6GrlYRYGOufFABxI-2LHYYuUHzA';return true;">MoveAssigna<wbr>ble</a=
>, <a href=3D"http://en.cppreference.com/w/cpp/concept/CopyConstructible" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%=
2FCopyConstructible\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG-iAn9ftcEFUQ6N=
fvI6mNqhZH_Aw';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FCop=
yConstructible\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG-iAn9ftcEFUQ6NfvI6m=
NqhZH_Aw';return true;">CopyConstructible</a> and=C2=A0<a href=3D"http:=
//en.cppreference.com/w/cpp/concept/CopyAssignable" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FCopyAssignable\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHv92JdHik3TE576sBvuu5aQBH_9g';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fconcept%2FCopyAssignable\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNHv92JdHik3TE576sBvuu5aQBH_9g';return true;=
">CopyAssignable</a>=C2=A0(the later two may require T to be CopyConstructi=
ble).<br></div><div><br></div><div><b>Member Types</b></div><div><ul><li><f=
ont face=3D"courier new, monospace">pointer</font>: <font face=3D"courier n=
ew, monospace">T*</font></li><li><font face=3D"courier new, monospace">elem=
ent_type</font>: <font face=3D"courier new, monospace">T</font>, the type o=
f the object managed by this <font face=3D"courier new, monospace">copy_ptr=
</font></li><li><font face=3D"courier new, monospace">cloner_type</font>:=
=C2=A0<font face=3D"courier new, monospace">Cloner</font>, the function obj=
ect or lvalue reference to function or to function object, to be called fro=
m the copy constructor and copy assignment operators</li><li><font face=3D"=
courier new, monospace">deleter_type</font>:=C2=A0<font face=3D"courier new=
, monospace">Deleter</font>, the function object or lvalue reference to fun=
ction or to function object, to be called from the destructor</li></ul></di=
v><div><br></div><div><b>Member Functions</b></div><div><ul><li>operator=3D=
: assigns the copy_ptr</li><li>release: returns a pointer to the managed ob=
ject and releases ownership</li><li>reset: replaces the managed object</li>=
<li>swap: swaps the managed objects</li><li>get: returns a pointer to the m=
anaged object</li><li>get_cloner: returns the cloner that is used for copy =
the managed object</li><li>get_deleter: returns the deleter that is used fo=
r destruction of the managed object</li><li>operator bool: checks if there =
is an associated managed object</li><li>operator*, operator->: dereferen=
ces pointer to the managed object</li><li>make_copy: creates a copy pointer=
that manages a new object</li><li>operator=3D=3D, operator!=3D, etc: compa=
res to an other copy_ptr or with nullptr</li><li>std::swap: specializes the=
std::swap algorithm</li><li>std::hash<std::copy_ptr>: hash support f=
or std::copy_ptr</li></ul></div><div><b>Example</b></div><div><br></div><di=
v><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
font color=3D"#660066"><span style=3D"color:#800">#include</span><span styl=
e=3D"color:#080"><iostream></span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#800">#include</span><span style=3D"color:#080"><=
;memory></span><span style=3D"color:#000"><br><br></span><span style=3D"=
color:#008">struct</span><span style=3D"color:#000"> </span><span style=3D"=
color:#606">Foo</span><span style=3D"color:#000"><br></span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color:#606">Foo</span><span style=3D"color:#660">()</span><span=
style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> std</span><span=
style=3D"color:#660">::</span><span style=3D"color:#000">cout </span><span=
style=3D"color:#660"><<</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#080">"Foo::Foo()\n"</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">}</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#606">Foo</span><span style=3D"color:#660">(</span><span style=3D=
"color:#008">const</span><span style=3D"color:#000"> </span><span style=3D"=
color:#606">Foo</span><span style=3D"color:#660">&</span><span style=3D=
"color:#000"> o</span><span style=3D"color:#660">)</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#0=
00"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">cout </span><span style=3D"color:#660"><<</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#080">"Foo::Foo(const Foo&)\=
n"</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color:#660">~</span><span style=3D"colo=
r:#606">Foo</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"> std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000">cout </span><span style=3D"color:#=
660"><<</span><span style=3D"color:#000"> </span><span style=3D"color=
:#080">"Foo::~Foo()\n"</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">}</span><span =
style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">vo=
id</span><span style=3D"color:#000"> bar</span><span style=3D"color:#660">(=
)</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span=
style=3D"color:#660">{</span><span style=3D"color:#000"> std</span><span s=
tyle=3D"color:#660">::</span><span style=3D"color:#000">cout </span><span s=
tyle=3D"color:#660"><<</span><span style=3D"color:#000"> </span><span=
style=3D"color:#080">"Foo::bar()\n"</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}<=
/span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">=
void</span><span style=3D"color:#000"> f</span><span style=3D"color:#660">(=
</span><span style=3D"color:#008">const</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#606">Foo</span><span style=3D"color:#660">&=
)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D=
"color:#660">::</span><span style=3D"color:#000">cout </span><span style=3D=
"color:#660"><<</span><span style=3D"color:#000"> </span><span style=
=3D"color:#080">"f(const Foo&)\n"</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#6=
60">}</span><span style=3D"color:#000"><br><br></span><span style=3D"color:=
#008">int</span><span style=3D"color:#000"> main</span><span style=3D"color=
:#660">()</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"><br></span><span style=3D"color:#0=
00"><div>=C2=A0 =C2=A0 std::copy_ptr<Foo> p1(new Foo); =C2=A0// p1 ow=
ns Foo</div><div>=C2=A0 =C2=A0 if (p1) p1->bar();</div><div>=C2=A0</div>=
<div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::copy_ptr<=
;Foo> p2(std::move(p1)); =C2=A0// now p2 owns Foo</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 f(*p2);</div><div>=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 p1 =3D p2; =C2=A0// cloned into p1</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 std::cout << "destroying p2...\n";</div><div>=C2=A0 =
=C2=A0 }</div><div>=C2=A0</div><div>=C2=A0 =C2=A0 if (p1) p1->bar();</di=
v><div>=C2=A0</div><div>=C2=A0 =C2=A0 // Second Foo instance is destroyed w=
hen p1 goes out of scope</div></span><span style=3D"color:#660">}</span><sp=
an style=3D"color:#000"><br></span></font></div></code></div><br>Output:</d=
iv><div><br></div><font face=3D"courier new, monospace">Foo::Foo()</font><d=
iv><font face=3D"courier new, monospace">Foo::bar()</font></div><div><font =
face=3D"courier new, monospace">f(const Foo&)</font></div><div><font fa=
ce=3D"courier new, monospace">Foo::Foo(const Foo&)</font></div><div><fo=
nt face=3D"courier new, monospace">destroying p2...</font></div><div><font =
face=3D"courier new, monospace">Foo::~Foo()</font></div><div><font face=3D"=
courier new, monospace">Foo::bar()</font></div><div><font face=3D"courier n=
ew, monospace">Foo::~Foo()</font><br><div><br></div></div></div></blockquot=
e></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/731cb931-eb89-41e0-8c1b-bfccd6329eaa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/731cb931-eb89-41e0-8c1b-bfccd6329eaa=
%40isocpp.org</a>.<br />
------=_Part_350_483177092.1481942738585--
------=_Part_349_817252494.1481942738584--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 17 Dec 2016 14:52:08 +0100
Raw View
On 16.12.2016 17:06, Nicol Bolas wrote:
>
>
> I really think this needs to be emphasized. Cheap-move+deep-copy are
> hardly an uncommon set of semantics in C++. Every standard library
> container uses these semantics.
>
>
> Oh, and one more C++ standard library type that has these semantics:
> `any`. It requires that the types provided are copyable, and on copying
> an `any`, it will perform a copy (of the exact type provided, of
> course). However, the move may be merely a pointer-shift (to support
> small object optimization, `any`s that store objects with noexcept moves
> may use the object's move constructor instead of the `any` pointer-shift).
>
Exactly, every standard library *container* uses these semantics.
`std::any` is a container of a single type, so it also uses these
semantics. And this behavior makes sense, for a container.
Now `std::optional` and the proposed `std::indirect` are not containers,
they behave like a single value, hence their copy/move forward to `T`s
copy/move. This behavior also makes sense.
Now the copy_ptr here with mixed copy/move would also be a container
- a container of a single type or derived class or something like that.
I don't really see a use for such a container, but alright.
But the proposed copy_ptr is not really a smart pointer,
none of the other smart pointers do such things,
they simply manage the lifetime of an object.
This is all my opinion and you're free to ignore me,
but I think this distinction is important.
Jonathan
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e30ffb82-0d5f-fafd-39b4-28e60d07c948%40gmail.com.
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 15:11:09 +0100
Raw View
--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Sean Parent gave a talk[1] at Code::Dive this year where he talks about the
problems of such a clone_ptr type.
(He actually starts with a clone_ptr that was proposed to the Standards Com=
mittee
but is different to the one proposed here, but then discussing alternatives
that might seem reasonable)
Best
Manuel
[1] https://youtu.be/cK_kftBNgBc?t=3D40m45s
On Sat, Dec 17, 2016 at 02:52:08PM +0100, Jonathan M=C3=BCller wrote:
>On 16.12.2016 17:06, Nicol Bolas wrote:
>>
>>
>> I really think this needs to be emphasized. Cheap-move+deep-copy are
>> hardly an uncommon set of semantics in C++. Every standard library
>> container uses these semantics.
>>
>
>
>>
>>Oh, and one more C++ standard library type that has these semantics:
>>`any`. It requires that the types provided are copyable, and on copying
>>an `any`, it will perform a copy (of the exact type provided, of
>>course). However, the move may be merely a pointer-shift (to support
>>small object optimization, `any`s that store objects with noexcept moves
>>may use the object's move constructor instead of the `any` pointer-shift)=
..
>>
>
>Exactly, every standard library *container* uses these semantics.
>`std::any` is a container of a single type, so it also uses these
>semantics. And this behavior makes sense, for a container.
>
>Now `std::optional` and the proposed `std::indirect` are not containers,
>they behave like a single value, hence their copy/move forward to `T`s
>copy/move. This behavior also makes sense.
>
>Now the copy_ptr here with mixed copy/move would also be a container
>- a container of a single type or derived class or something like that.
>I don't really see a use for such a container, but alright.
>
>But the proposed copy_ptr is not really a smart pointer,
>none of the other smart pointers do such things,
>they simply manage the lifetime of an object.
>
>This is all my opinion and you're free to ignore me,
>but I think this distinction is important.
>
>Jonathan
>
>
>--
>You received this message because you are subscribed to the Google Groups =
"ISO C++ Standard - Future Proposals" group.
>To unsubscribe from this group and stop receiving emails from it, send an =
email to std-proposals+unsubscribe@isocpp.org.
>To post to this group, send email to std-proposals@isocpp.org.
>To view this discussion on the web visit https://groups.google.com/a/isocp=
p.org/d/msgid/std-proposals/e30ffb82-0d5f-fafd-39b4-28e60d07c948%40gmail.co=
m.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217141109.GA22645%40manuel-ThinkPad-L440.lo=
caldomain.
--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEi3F6I6jTgMCHgGvofAJ3kFaTK3oFAlhVR3AACgkQfAJ3kFaT
K3pCtBAArO9aHVXdjv/wcdKLfkMObaBNtXGiSMjOgqcC7hnZCfXSyYPlL2HK/H93
I44OmBdiAipexzvK+MWNaFqdEh3hATFYG5A1LeWmXTeLP8kH8sunR7Kjzn0iNS5X
KCdAThfdrqr2vUv/6R7QL/2XC1hUuq+zYVLnIrwhnat1RwDzi6/GtYMwvLsEdAkT
RU36+fpoxUFB1u32SZRpK70p0hpO99XGyq9a+vnO2EBBRFNlp3qnn6TfIkU7sKSu
cge1WbmQ9M59B85CkCuZNHfdz70aPv98kgs9uNgF+jUrlSwv3ieS+cLS9cEJLCJk
yrUTF36exUgB24y6uw7rRCTd/oM4kBdaGUtdZoXu7VKvko8+gNw3ROKs7Vt+tD/z
FvZbqbBh8cxJueqiGnHM+6OC7atcgh3WcFJJilq+vzaY3gYpifOVPJa8wsgWmjh9
5hX3WzIfGGgUCMD+eqn2e++Mwke6Nbufq+zCi4yCZK30cV3lrMtUzYOkB98XkWdZ
UWVHP77ZrHsF7o1AfuQWJafhGuSileVmWgGFB1qIGNCtQxnwSphbY0b9BaQV6aO2
IZG33D+PRYu81WUvfNrcIIiUNOpU3wDEBMuWBmLdbZVTOXvU8GP8Bjm7p/Jbr2vX
VrVtonRy2R0yUfbIvCBq/b6fZ37Vja0iWziID+NEo1KCr+M72Hs=
=Sf/a
-----END PGP SIGNATURE-----
--nFreZHaLTZJo0R7j--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 17 Dec 2016 15:22:07 +0100
Raw View
On 17.12.2016 15:11, Manuel Bergler wrote:
> Sean Parent gave a talk[1] at Code::Dive this year where he talks about the
> problems of such a clone_ptr type.
>
> (He actually starts with a clone_ptr that was proposed to the Standards
> Committee
> but is different to the one proposed here, but then discussing alternatives
> that might seem reasonable)
>
> Best
> Manuel
>
> [1] https://youtu.be/cK_kftBNgBc?t=40m45s
>
I was not aware of this talk, thank you.
Sean Parent worded it better (and had better examples), but that's my
opinion as well: clone_ptr is not a smart pointer.
If you want one, don't provide copy/assignment but add (non-)member
clone() that does the deep copy.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b1c473be-03c1-e4db-f0c4-a23f182c7154%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 17 Dec 2016 17:29:34 +0200
Raw View
On 17 December 2016 at 16:22, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> Sean Parent worded it better (and had better examples), but that's my
> opinion as well: clone_ptr is not a smart pointer.
> If you want one, don't provide copy/assignment but add (non-)member clone=
()
> that does the deep copy.
Such a type has just one problem: it's close to useless. It doesn't
violate Sean's lofty principles,
but it doesn't solve the problems it's aimed for either.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUYmdj2HwRpP2HhY%3DxujkFP1e5LYKkg6eOGBOF_yE=
-3Lcg%40mail.gmail.com.
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 17 Dec 2016 16:35:55 +0100
Raw View
On 17.12.2016 16:29, Ville Voutilainen wrote:
> Such a type has just one problem: it's close to useless. It doesn't
> violate Sean's lofty principles,
> but it doesn't solve the problems it's aimed for either.
What are the problems it's aimed for exactly?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3df7e8eb-01a0-7804-f476-504b5a25a9fe%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 17 Dec 2016 18:10:10 +0200
Raw View
On 17 December 2016 at 17:35, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
> On 17.12.2016 16:29, Ville Voutilainen wrote:
>>
>> Such a type has just one problem: it's close to useless. It doesn't
>> violate Sean's lofty principles,
>> but it doesn't solve the problems it's aimed for either.
>
>
> What are the problems it's aimed for exactly?
Convenient cloning, and automatic cloning when passed by value or
returned by value, including when
wrapped under something else as a member. Needing to manually invoke a
clone function more or less
completely defeats that purpose.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUaY3%2BMnXkmvaC%3DLxgRA_RD_XQpFfX-HT6X3iq1=
wD7ggCg%40mail.gmail.com.
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 18:04:28 +0100
Raw View
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 17, 2016 at 06:10:10PM +0200, Ville Voutilainen wrote:
>On 17 December 2016 at 17:35, Jonathan M=C3=BCller
><jonathanmueller.dev@gmail.com> wrote:
>> On 17.12.2016 16:29, Ville Voutilainen wrote:
>>>
>>> Such a type has just one problem: it's close to useless. It doesn't
>>> violate Sean's lofty principles,
>>> but it doesn't solve the problems it's aimed for either.
>>
>>
>> What are the problems it's aimed for exactly?
>
>
>Convenient cloning, and automatic cloning when passed by value or
>returned by value, including when
>wrapped under something else as a member. Needing to manually invoke a
>clone function more or less
>completely defeats that purpose.
>
I might miss something here, but I can't think of a use-case where the conv=
enience of returning it from a function by value having it implicitly clone=
the pointee with `return my_clone_ptr;` instead of just writing `return my=
_clone_ptr.clone();` is worth sacrificing the clarity of the latter version=
, in particular since you might actually have intended to move it but forgo=
t to call `std::move` on it before returning.
So as far as I can tell the only remaining benefit is that you needn't writ=
e a custom copy/move constructor/assignment operator for a struct/class hav=
ing one of these as a member?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217170428.GA10214%40manuel-ThinkPad-L440.lo=
caldomain.
--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEi3F6I6jTgMCHgGvofAJ3kFaTK3oFAlhVcBoACgkQfAJ3kFaT
K3rQuhAAs/KAVJviC5Q1OyII4DTO7ZCWgIgqtU+jyK6g1Y+UJOZubb96UHDSLJ3G
piljmowEOaGbztLlFfs1yhuncqYPV8YMXBp2miX+TkNeS09uIU5rb1bWY4jmd51l
nsiw9e/oTPqdngD83Z/ZyZXGxX2P8cSPiftqbyvWmbus/ai75e1I8TeFPr36llHF
jAgwZcem8P7aoG7zMqEi9Wa3aXyi0wZ29k4bEZvnRuvrZ8tWjF47KJQtZSgqI8AD
FLvXwcskWMrxbpd7OA0hdbGG+oZ9MjJmj4teTcRBiRP2lE5feP5RluE9YG3M3EEH
c/wPmpil3BtuY0oldtCIw3q7hoGXwKC/M/g+4WJugd+BjPNPmrNB4+0ljbiYdJ0b
a8jE/DwC+mVZEWXoNXNLm9MW9TZbO3+DjgoAD4e9lQNWdLDoczAlqgrJK1/K/TV1
uAjofNXkZRO1ztzEL9Rx5QrbZwa8daWi340K/ERH3hTHtzFn+d2cwqDsucdJce6Z
7B4XoLhgLXoB0Xy2BRglxGflZp3k1A5YNzwak1PaEoJUFAo4De3dRtETKdBi1Mpf
FQiPODNCk/Ix2bTveehDmd8CUBUMRh3YxWNisVYA7w6fh983k0vm0AnEcn5y278a
pLvydgiRGLTgMmCOSYUCCvyEwGIWWiWtKI9ABRybUqqGmG0WKvk=
=UjIz
-----END PGP SIGNATURE-----
--XsQoSWH+UP9D9v3l--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 17 Dec 2016 12:16:33 -0500
Raw View
=E2=80=8E>=C2=A0I might miss something here, but I can't think of a use-cas=
e where the convenience of returning it from a function by value having it =
implicitly clone the pointee with `return my_clone_ptr;` instead of just wr=
iting `return my_clone_ptr.clone();`
Templates. Where you don't know if T has .clone(). Cloning in C++ is typica=
lly spelled with the copy-constructor.=C2=A0
Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Manuel Bergler
Sent: Saturday, December 17, 2016 12:05 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: Re: [std-proposals] New smart pointer: CopyConstructible and CopyA=
ssignable flavor of unique_ptr
On Sat, Dec 17, 2016 at 06:10:10PM +0200, Ville Voutilainen wrote:
>On 17 December 2016 at 17:35, Jonathan M=C3=BCller
><jonathanmueller.dev@gmail.com> wrote:
>> On 17.12.2016 16:29, Ville Voutilainen wrote:
>>>
>>> Such a type has just one problem: it's close to useless. It doesn't
>>> violate Sean's lofty principles,
>>> but it doesn't solve the problems it's aimed for either.
>>
>>
>> What are the problems it's aimed for exactly?
>
>
>Convenient cloning, and automatic cloning when passed by value or
>returned by value, including when
>wrapped under something else as a member. Needing to manually invoke a
>clone function more or less
>completely defeats that purpose.
>
I might miss something here, but I can't think of a use-case where the conv=
enience of returning it from a function by value having it implicitly clone=
the pointee with `return my_clone_ptr;` instead of just writing `return my=
_clone_ptr.clone();` is worth sacrificing the clarity of the latter version=
, in particular since you might actually have intended to move it but forgo=
t to call `std::move` on it before returning.
So as far as I can tell the only remaining benefit is that you needn't writ=
e a custom copy/move constructor/assignment operator for a struct/class hav=
ing one of these as a member?
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217170428.GA10214%40manuel-ThinkPad-L440.lo=
caldomain.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217171633.4919375.58072.21574%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 09:30:25 -0800 (PST)
Raw View
------=_Part_968_1526482862.1481995825627
Content-Type: multipart/alternative;
boundary="----=_Part_969_1260698528.1481995825627"
------=_Part_969_1260698528.1481995825627
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 12:05:18 PM UTC-5, Manuel Bergler wrote:
>
> On Sat, Dec 17, 2016 at 06:10:10PM +0200, Ville Voutilainen wrote:=20
> >On 17 December 2016 at 17:35, Jonathan M=C3=BCller=20
> ><jonathanm...@gmail.com <javascript:>> wrote:=20
> >> On 17.12.2016 16:29, Ville Voutilainen wrote:=20
> >>>=20
> >>> Such a type has just one problem: it's close to useless. It doesn't=
=20
> >>> violate Sean's lofty principles,=20
> >>> but it doesn't solve the problems it's aimed for either.=20
> >>=20
> >>=20
> >> What are the problems it's aimed for exactly?=20
> >=20
> >=20
> >Convenient cloning, and automatic cloning when passed by value or=20
> >returned by value, including when=20
> >wrapped under something else as a member. Needing to manually invoke a=
=20
> >clone function more or less=20
> >completely defeats that purpose.=20
> >=20
>
> I might miss something here, but I can't think of a use-case where the=20
> convenience of returning it from a function by value having it implicitly=
=20
> clone the pointee with `return my_clone_ptr;` instead of just writing=20
> `return my_clone_ptr.clone();` is worth sacrificing the clarity of the=20
> latter version, in particular since you might actually have intended to=
=20
> move it but forgot to call `std::move` on it before returning.
>
Except that `return my_clone_ptr` will *always move*, unless `my_clone_ptr`=
=20
is a function parameter. That's part of the standard. Well, it could also=
=20
be elided, but at the very least, it will never copy (unless it's a=20
parameter).
So that right there explains one reason not to use `clone()` directly. And=
=20
as Tony says, templates are another. Guaranteed elision is another case=20
where you want to use it as a value, rather than calling `clone` explicitly=
..
The whole point of a `clone_ptr` is to make cloning *implicit*. It is used=
=20
for cases when clone operations need to look *exactly* like=20
language-defined copy operations. And that is *not unreasonable*.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ecbdbb9d-28a3-4441-9000-0f8311cfe100%40isocpp.or=
g.
------=_Part_969_1260698528.1481995825627
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, December 17, 2016 at 12:05:18 PM UTC-=
5, Manuel Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat=
, Dec 17, 2016 at 06:10:10PM +0200, Ville Voutilainen wrote:
<br>>On 17 December 2016 at 17:35, Jonathan M=C3=BCller
<br>><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"2FPHOpO_CgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">jonathanm...@gmail.<wbr>com</a>> wrote:
<br>>> On 17.12.2016 16:29, Ville Voutilainen wrote:
<br>>>>
<br>>>> Such a type has just one problem: it's close to useles=
s. It doesn't
<br>>>> violate Sean's lofty principles,
<br>>>> but it doesn't solve the problems it's aimed for e=
ither.
<br>>>
<br>>>
<br>>> What are the problems it's aimed for exactly?
<br>>
<br>>
<br>>Convenient cloning, and automatic cloning when passed by value or
<br>>returned by value, including when
<br>>wrapped under something else as a member. Needing to manually invok=
e a
<br>>clone function more or less
<br>>completely defeats that purpose.
<br>>
<br>
<br>I might miss something here, but I can't think of a use-case where =
the convenience of returning it from a function by value having it implicit=
ly clone the pointee with `return my_clone_ptr;` instead of just writing `r=
eturn my_clone_ptr.clone();` is worth sacrificing the clarity of the latter=
version, in particular since you might actually have intended to move it b=
ut forgot to call `std::move` on it before returning.<br></blockquote><div>=
<br>Except that `return my_clone_ptr` will <i>always move</i>, unless `my_c=
lone_ptr` is a function parameter. That's part of the standard. Well, i=
t could also be elided, but at the very least, it will never copy (unless i=
t's a parameter).<br><br>So that right there explains one reason not to=
use `clone()` directly. And as Tony says, templates are another. Guarantee=
d elision is another case where you want to use it as a value, rather than =
calling `clone` explicitly.<br><br>The whole point of a `clone_ptr` is to m=
ake cloning <i>implicit</i>. It is used for cases when clone operations nee=
d to look <i>exactly</i> like language-defined copy operations. And that is=
<i>not unreasonable</i>.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ecbdbb9d-28a3-4441-9000-0f8311cfe100%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ecbdbb9d-28a3-4441-9000-0f8311cfe100=
%40isocpp.org</a>.<br />
------=_Part_969_1260698528.1481995825627--
------=_Part_968_1526482862.1481995825627--
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 17 Dec 2016 18:48:26 +0100
Raw View
--94eb2c06fa8233c2fc0543de4b30
Content-Type: text/plain; charset=UTF-8
On Dec 17, 2016 18:16, "Tony V E" <tvaneerd@gmail.com> wrote:
>
> Templates. Where you don't know if T has .clone(). Cloning in C++ is
typically spelled with the copy-constructor.
>
But generic code would assume certain properties of a copy constructor,
this one does not have, as Sean Parent pointed out.
So copy constructing in generic code might be harmful.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJaAZkeJS9Maj2z0vYGnfuNnJZ%2BqFFdjeQyesTF5itJxHA%40mail.gmail.com.
--94eb2c06fa8233c2fc0543de4b30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 17, 2016 18:16, "Tony V E" <<a href=3D"m=
ailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
> Templates. Where you don't know if T has .clone(). Cloning in C++ =
is typically spelled with the copy-constructor.=C2=A0<br>
></p>
<p dir=3D"ltr">But generic code would assume certain properties of a copy c=
onstructor, this one does not have, as Sean Parent pointed out.</p>
<p dir=3D"ltr">So copy constructing in generic code might be harmful.</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJaAZkeJS9Maj2z0vYGnfuNnJZ%2BqFF=
djeQyesTF5itJxHA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJaAZkeJS9=
Maj2z0vYGnfuNnJZ%2BqFFdjeQyesTF5itJxHA%40mail.gmail.com</a>.<br />
--94eb2c06fa8233c2fc0543de4b30--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 10:04:47 -0800 (PST)
Raw View
------=_Part_921_1947486817.1481997887862
Content-Type: multipart/alternative;
boundary="----=_Part_922_1454908049.1481997887863"
------=_Part_922_1454908049.1481997887863
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 12:48:28 PM UTC-5, Jonathan M=C3=BCller w=
rote:
>
> On Dec 17, 2016 18:16, "Tony V E" <tvan...@gmail.com <javascript:>> wrote=
:
> >
> > Templates. Where you don't know if T has .clone(). Cloning in C++ is=20
> typically spelled with the copy-constructor.=20
> >
>
> But generic code would assume certain properties of a copy constructor,=
=20
> this one does not have, as Sean Parent pointed out.
>
So copy constructing in generic code might be harmful.=20
>
I don't think "might be harmful" is a good enough reason to not have the=20
type.
After all, such copying behavior won't break most standard library types.=
=20
`vector<clone_ptr>` will work as expected, as will `any`,=20
`optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
The principle failing of `clone_ptr`'s copy operation is the lack of=20
equality between the copied objects (since equality is based on pointers,=
=20
not `T`). So long as the template code does not care about equality after a=
=20
copy, the template code ought to be fine.
I think it's important to understand that `clone_ptr` is a solution to a=20
very specific problem, one that isn't exactly common. You shouldn't see a=
=20
huge number of these pointers lying around.
I'd say the biggest problem is that there's no way to conceptualize the=20
special nature of `clone_ptr`'s copy constructor. You can't write a=20
Concepts TS `requires` clause that says, "a copy constructor/assignment=20
shall ensure that the copied value is =3D=3D to the original." That's an=20
axiomatic distinction, not a syntactic one. And we don't have ways to=20
specify axioms or require based on them.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/15884364-3238-41c7-bc5a-aa5595a64ade%40isocpp.or=
g.
------=_Part_922_1454908049.1481997887863
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 12:48:28 PM UTC-5, Jonat=
han M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=
=3D"ltr">On Dec 17, 2016 18:16, "Tony V E" <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"Qt5aSe7BCgAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">tvan...@gmail.com</a>&g=
t; wrote:<br>
><br>
> Templates. Where you don't know if T has .clone(). Cloning in C++ =
is typically spelled with the copy-constructor.=C2=A0<br>
></p>
<p dir=3D"ltr">But generic code would assume certain properties of a copy c=
onstructor, this one does not have, as Sean Parent pointed out.</p></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>So copy=
constructing in generic code might be harmful. <br></div></blockquote><div=
><br>I don't think "might be harmful" is a good enough reason=
to not have the type.<br><br>After all, such copying behavior won't br=
eak most standard library types. `vector<clone_ptr>` will work as exp=
ected, as will `any`, `optional<clone_ptr>`, `variant<clone_ptr>=
;`, and so forth.<br><br>The principle failing of `clone_ptr`'s copy op=
eration is the lack of equality between the copied objects (since equality =
is based on pointers, not `T`). So long as the template code does not care =
about equality after a copy, the template code ought to be fine.<br><br>I t=
hink it's important to understand that `clone_ptr` is a solution to a v=
ery specific problem, one that isn't exactly common. You shouldn't =
see a huge number of these pointers lying around.<br><br>I'd say the bi=
ggest problem is that there's no way to conceptualize the special natur=
e of `clone_ptr`'s copy constructor. You can't write a Concepts TS =
`requires` clause that says, "a copy constructor/assignment shall ensu=
re that the copied value is =3D=3D to the original." That's an axi=
omatic distinction, not a syntactic one. And we don't have ways to spec=
ify axioms or require based on them.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15884364-3238-41c7-bc5a-aa5595a64ade%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15884364-3238-41c7-bc5a-aa5595a64ade=
%40isocpp.org</a>.<br />
------=_Part_922_1454908049.1481997887863--
------=_Part_921_1947486817.1481997887862--
.
Author: =?UTF-8?Q?Jonathan_M=C3=BCller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 17 Dec 2016 19:14:19 +0100
Raw View
--94eb2c06d7f4cd56140543dea7fa
Content-Type: text/plain; charset=UTF-8
On Dec 17, 2016 7:04 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> I don't think "might be harmful" is a good enough reason to not have the
type.
I think it's a very compelling reason. I rather have types that can be used
without thinking, because misuse is a compiler error.
> After all, such copying behavior won't break most standard library types.
`vector<clone_ptr>` will work as expected, as will `any`,
`optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
All of these type work without copy constructing. The only reason you'd
need copy constructing there is if you'd need to insert a copy or copy the
container. The first one is very easy, just call clone, the second requires
a for loop.
> I think it's important to understand that `clone_ptr` is a solution to a
very specific problem, one that isn't exactly common. You shouldn't see a
huge number of these pointers lying around.
Yeah, and that's why I can't really see a compelling use case for them.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_UFj7xcNwR_YNqCfbNtEMbXZgsYDyXCx%3DM51E2xdQ%40mail.gmail.com.
--94eb2c06d7f4cd56140543dea7fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Dec 17, 2016 7:04 PM, "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
><br>
> I don't think "might be harmful" is a good enough reason=
to not have the type.</p>
<p dir=3D"ltr">I think it's a very compelling reason. I rather have typ=
es that can be used without thinking, because misuse is a compiler error.</=
p>
<p dir=3D"ltr">> After all, such copying behavior won't break most s=
tandard library types. `vector<clone_ptr>` will work as expected, as =
will `any`, `optional<clone_ptr>`, `variant<clone_ptr>`, and so=
forth.</p>
<p dir=3D"ltr">All of these type work without copy constructing. The only r=
eason you'd need copy constructing there is if you'd need to insert=
a copy or copy the container. The first one is very easy, just call clone,=
the second requires a for loop.</p>
<p dir=3D"ltr">> I think it's important to understand that `clone_pt=
r` is a solution to a very specific problem, one that isn't exactly com=
mon. You shouldn't see a huge number of these pointers lying around.</p=
>
<p dir=3D"ltr">Yeah, and that's why I can't really see a compelling=
use case for them.</p>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_UFj7xcNwR_YNqCfbNtEMbXZgsY=
DyXCx%3DM51E2xdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_UFj7=
xcNwR_YNqCfbNtEMbXZgsYDyXCx%3DM51E2xdQ%40mail.gmail.com</a>.<br />
--94eb2c06d7f4cd56140543dea7fa--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 17 Dec 2016 18:16:02 +0000
Raw View
--94eb2c0b6858864dae0543deae3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
So you're saying that the standard should not contain tools targeted at
experts? (Just a note: it already does.)
On Sat, Dec 17, 2016 at 7:14 PM Jonathan M=C3=BCller <
jonathanmueller.dev@gmail.com> wrote:
> On Dec 17, 2016 7:04 PM, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> >
> > I don't think "might be harmful" is a good enough reason to not have th=
e
> type.
>
> I think it's a very compelling reason. I rather have types that can be
> used without thinking, because misuse is a compiler error.
>
> > After all, such copying behavior won't break most standard library
> types. `vector<clone_ptr>` will work as expected, as will `any`,
> `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
>
> All of these type work without copy constructing. The only reason you'd
> need copy constructing there is if you'd need to insert a copy or copy th=
e
> container. The first one is very easy, just call clone, the second requir=
es
> a for loop.
>
> > I think it's important to understand that `clone_ptr` is a solution to =
a
> very specific problem, one that isn't exactly common. You shouldn't see a
> huge number of these pointers lying around.
>
> Yeah, and that's why I can't really see a compelling use case for them.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_U=
Fj7xcNwR_YNqCfbNtEMbXZgsYDyXCx%3DM51E2xdQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_=
UFj7xcNwR_YNqCfbNtEMbXZgsYDyXCx%3DM51E2xdQ%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRj%2BqTfY2oBKk3nOy41Sd-EBqv5t-2Vr1T2t%3D6=
-Nf53yg%40mail.gmail.com.
--94eb2c0b6858864dae0543deae3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So you're saying that the standard should not contain =
tools targeted at experts? (Just a note: it already does.)</div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Sat, Dec 17, 2016 at 7:14 PM Jonath=
an M=C3=BCller <<a href=3D"mailto:jonathanmueller.dev@gmail.com">jonatha=
nmueller.dev@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><p dir=3D"ltr" class=3D"gmail_msg">On Dec 17, 2016 7:04 PM, "Nicol =
Bolas" <<a href=3D"mailto:jmckesson@gmail.com" class=3D"gmail_msg" =
target=3D"_blank">jmckesson@gmail.com</a>> wrote:<br class=3D"gmail_msg"=
>
><br class=3D"gmail_msg">
> I don't think "might be harmful" is a good enough reason=
to not have the type.</p>
<p dir=3D"ltr" class=3D"gmail_msg">I think it's a very compelling reaso=
n. I rather have types that can be used without thinking, because misuse is=
a compiler error.</p>
<p dir=3D"ltr" class=3D"gmail_msg">> After all, such copying behavior wo=
n't break most standard library types. `vector<clone_ptr>` will w=
ork as expected, as will `any`, `optional<clone_ptr>`, `variant<cl=
one_ptr>`, and so forth.</p>
<p dir=3D"ltr" class=3D"gmail_msg">All of these type work without copy cons=
tructing. The only reason you'd need copy constructing there is if you&=
#39;d need to insert a copy or copy the container. The first one is very ea=
sy, just call clone, the second requires a for loop.</p>
<p dir=3D"ltr" class=3D"gmail_msg">> I think it's important to under=
stand that `clone_ptr` is a solution to a very specific problem, one that i=
sn't exactly common. You shouldn't see a huge number of these point=
ers lying around.</p>
<p dir=3D"ltr" class=3D"gmail_msg">Yeah, and that's why I can't rea=
lly see a compelling use case for them.</p>
<p class=3D"gmail_msg"></p>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJa4V_UFj7xcNwR_YNqCfbNtEMbXZgsY=
DyXCx%3DM51E2xdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" class=3D"gmail_msg" target=3D"_blank">https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAEddoJa4V_UFj7xcNwR_YNqCfbNtEMbXZgsYDyXCx%3DM51=
E2xdQ%40mail.gmail.com</a>.<br class=3D"gmail_msg">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRj%2BqTfY2oBKk3nOy41Sd-EBqv5t-=
2Vr1T2t%3D6-Nf53yg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRj%2Bq=
TfY2oBKk3nOy41Sd-EBqv5t-2Vr1T2t%3D6-Nf53yg%40mail.gmail.com</a>.<br />
--94eb2c0b6858864dae0543deae3c--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 17 Dec 2016 20:18:08 +0200
Raw View
On 17 December 2016 at 20:14, Jonathan M=C3=BCller
<jonathanmueller.dev@gmail.com> wrote:
>> I don't think "might be harmful" is a good enough reason to not have the
>> type.
>
> I think it's a very compelling reason. I rather have types that can be us=
ed
> without thinking, because misuse is a compiler error.
Then by all means use indirect and don't use cloned_ptr.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZgjH_%3DjhtpYDnJGaas%2B__xHp-ATUi156DtAkG=
pcQM6Eg%40mail.gmail.com.
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 19:21:30 +0100
Raw View
--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote:
>
> After all, such copying behavior won't break most standard library type=
s.
> `vector<clone_ptr>` will work as expected, as will `any`,
> `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
>
It would certainly work with the STL types, but I'm fairly certain you migh=
t get very different results when using these in STL algorithms. With some =
implementations references to the pointees might be preserved since the alg=
orithm doesn't copy the clone_ptr whereas others might perform a copy, henc=
e invalidating existing references or at least having them point to a diffe=
rent object than the one returned from the algorithm.
> I think it's important to understand that `clone_ptr` is a solution to =
a
> very specific problem, one that isn't exactly common. You shouldn't see=
a
> huge number of these pointers lying around.
> I don't think "might be harmful" is a good enough reason to not have th=
e
> type.
Together with the fact that the problem it tries to solve isn't common it m=
ost
definitely is. If the type is very hard to use correctly and not really nee=
ded
all that often then I see no reason to have it.
> I'd say the biggest problem is that there's no way to conceptualize the
> special nature of `clone_ptr`'s copy constructor. You can't write a
> Concepts TS `requires` clause that says, "a copy constructor/assignment
> shall ensure that the copied value is =3D=3D to the original." That's a=
n
> axiomatic distinction, not a syntactic one. And we don't have ways to
> specify axioms or require based on them.
The problem really is that it tries to act both as a pointer type which wou=
ld entail that after copying it the pointee is the same for both pointers a=
nd at the same time it tries to be a object type where copying creates dist=
inct but equivalent instances.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217182130.GA4347%40manuel-ThinkPad-L440.loc=
aldomain.
--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEi3F6I6jTgMCHgGvofAJ3kFaTK3oFAlhVgigACgkQfAJ3kFaT
K3o5kg//RBZW6yvORLGqaaufJRCejB6cW7TkaKIFTZqCn539EYozX8zDfRd95fLA
BNrrDiavQRmEQk978bJ7fpb0ZAnrMaMZ1k7LPRd1jGw+YvnsOFzLYnhCMMqtIBhU
bfSwiIJHa1w3f7/znuHje2bywVupPXY1mA/1+MhOp4yaX98O4jTWjfEbYp9KGCKz
jF2vDkBl59fASGOC0TYiJ+zxjom0+5JZSvbb9Jsm0BTTRI+0x4DxHeS5F2N6S2Ix
iPdnRPxroiQ9k2uQfJbeJbz+IiEgKtNKjpz5P9QmAUEK5Z93C0W/RSfR6TKYQeWu
Wnne5EKOqrPTHRkib4DgZIwd2Soob3NAMKiNGTRsjPGJsIDvxJUFekhi1mnNYWA5
AknXsf4DNo2cmF0j5IW+q2NeliZYXLUdVWGePIRrsJ6C1plRDOrckOuEJSFDFuZr
W13SUPFlfalXLZyz2Bqz8k00wTI77Z4I7l4PnNZKnt+Qf6JHwu35LCYqfO3K4mbu
rQXJNb4QHwGkY7zXQnOmYgpOOB19hj+Z9+1kkOFTyHhpvOh0LDGkWLkONsIiKDmC
9qqFUDVqBi6WVN/Fg0UFvY0GmLmm6v8dIxwZByrCjWL7qJc/17S0xCi3Jbr0UNEI
x0QIg6M7zhHbb0fiK0lST+nbLXzkqXpqZIUXcNYeaiZssdNCiMo=
=KFjP
-----END PGP SIGNATURE-----
--82I3+IH0IqGh5yIs--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 10:25:44 -0800 (PST)
Raw View
------=_Part_887_2075252224.1481999144442
Content-Type: multipart/alternative;
boundary="----=_Part_888_1400561331.1481999144442"
------=_Part_888_1400561331.1481999144442
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 1:14:22 PM UTC-5, Jonathan M=C3=BCller wr=
ote:
>
> On Dec 17, 2016 7:04 PM, "Nicol Bolas" <jmck...@gmail.com <javascript:>>=
=20
> wrote:
> >
> > I don't think "might be harmful" is a good enough reason to not have th=
e=20
> type.
>
> I think it's a very compelling reason. I rather have types that can be=20
> used without thinking, because misuse is a compiler error.
>
C++ is not a safe language.
=20
> > After all, such copying behavior won't break most standard library=20
> types. `vector<clone_ptr>` will work as expected, as will `any`,=20
> `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
>
> All of these type work without copy constructing.
>
No, all of those types *can be used* without copy constructing. That's not=
=20
the same thing.
And it's not even true, because `any` has an explicit requirement that the=
=20
type it stores be copy-constructible. So if you have your way, we wouldn't=
=20
be able to put `clone_ptr` in an `any` at all. Indeed, that's one of the=20
most important demonstrations of why we need `clone_ptr`.
=20
> The only reason you'd need copy constructing there is if you'd need to=20
> insert a copy or copy the container. The first one is very easy, just cal=
l=20
> clone, the second requires a for loop.
>
Yes, and avoiding both of those is the point of `clone_ptr`.
What's the point of using `vector` if you're going to have to explicitly=20
make a loop to copy it? It helps *nobody*; it makes your code bulkier and=
=20
needlessly harder to read. All so that you have to call some member=20
function just to do the copy.
=20
> > I think it's important to understand that `clone_ptr` is a solution to =
a=20
> very specific problem, one that isn't exactly common. You shouldn't see a=
=20
> huge number of these pointers lying around.
>
> Yeah, and that's why I can't really see a compelling use case for them.
>
I could say the same thing about `small_vector` or `intrusive_ptr`, but=20
that doesn't mean we shouldn't have one.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b3a1aa29-394b-4930-80c6-2c217af65c52%40isocpp.or=
g.
------=_Part_888_1400561331.1481999144442
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 1:14:22 PM UTC-5, Jonath=
an M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D=
"ltr">On Dec 17, 2016 7:04 PM, "Nicol Bolas" <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hm7mJljDCgAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>=
> wrote:<br>
><br>
> I don't think "might be harmful" is a good enough reason=
to not have the type.</p>
<p dir=3D"ltr">I think it's a very compelling reason. I rather have typ=
es that can be used without thinking, because misuse is a compiler error.</=
p></blockquote><div><br>C++ is not a safe language.<br>=C2=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">> After all, such copying behavior won't break most s=
tandard library types. `vector<clone_ptr>` will work as expected, as =
will `any`, `optional<clone_ptr>`, `variant<clone_ptr>`, and so=
forth.</p>
<p dir=3D"ltr">All of these type work without copy constructing.</p></block=
quote><div><br>No, all of those types <i>can be used</i> without copy const=
ructing. That's not the same thing.<br><br>And it's not even true, =
because `any` has an explicit requirement that the type it stores be copy-c=
onstructible. So if you have your way, we wouldn't be able to put `clon=
e_ptr` in an `any` at all. Indeed, that's one of the most important dem=
onstrations of why we need `clone_ptr`.<br>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><p dir=3D"ltr">The only reason you'd need copy=
constructing there is if you'd need to insert a copy or copy the conta=
iner. The first one is very easy, just call clone, the second requires a fo=
r loop.</p></blockquote><div><br>Yes, and avoiding both of those is the poi=
nt of `clone_ptr`.<br><br>What's the point of using `vector` if you'=
;re going to have to explicitly make a loop to copy it? It helps <i>nobody<=
/i>; it makes your code bulkier and needlessly harder to read. All so that =
you have to call some member function just to do the copy.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">> I think it's important to understand that `clone_pt=
r` is a solution to a very specific problem, one that isn't exactly com=
mon. You shouldn't see a huge number of these pointers lying around.</p=
>
<p dir=3D"ltr">Yeah, and that's why I can't really see a compelling=
use case for them.</p></blockquote><div><br>I could say the same thing abo=
ut `small_vector` or `intrusive_ptr`, but that doesn't mean we shouldn&=
#39;t have one.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b3a1aa29-394b-4930-80c6-2c217af65c52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3a1aa29-394b-4930-80c6-2c217af65c52=
%40isocpp.org</a>.<br />
------=_Part_888_1400561331.1481999144442--
------=_Part_887_2075252224.1481999144442--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 10:43:08 -0800 (PST)
Raw View
------=_Part_1016_1976953854.1482000188759
Content-Type: multipart/alternative;
boundary="----=_Part_1017_1224326318.1482000188759"
------=_Part_1017_1224326318.1482000188759
Content-Type: text/plain; charset=UTF-8
On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel Bergler wrote:
>
> On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote:
> >
> > After all, such copying behavior won't break most standard library
> types.
> > `vector<clone_ptr>` will work as expected, as will `any`,
> > `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
> >
>
> It would certainly work with the STL types, but I'm fairly certain you
> might get very different results when using these in STL algorithms. With
> some implementations references to the pointees might be preserved since
> the algorithm doesn't copy the clone_ptr whereas others might perform a
> copy, hence invalidating existing references or at least having them point
> to a different object than the one returned from the algorithm.
>
Which is no different from passing a value type that gets copied, then
expecting the copies to be modifying the original value.
>
> > I think it's important to understand that `clone_ptr` is a solution to
> a
> > very specific problem, one that isn't exactly common. You shouldn't
> see a
> > huge number of these pointers lying around.
>
> > I don't think "might be harmful" is a good enough reason to not have
> the
> > type.
>
> Together with the fact that the problem it tries to solve isn't common it
> most
> definitely is. If the type is very hard to use correctly and not really
> needed
> all that often then I see no reason to have it.
>
> > I'd say the biggest problem is that there's no way to conceptualize
> the
> > special nature of `clone_ptr`'s copy constructor. You can't write a
> > Concepts TS `requires` clause that says, "a copy
> constructor/assignment
> > shall ensure that the copied value is == to the original." That's an
> > axiomatic distinction, not a syntactic one. And we don't have ways to
> > specify axioms or require based on them.
>
> The problem really is that it tries to act both as a pointer type which
> would entail that after copying it the pointee is the same for both
> pointers and at the same time it tries to be a object type where copying
> creates distinct but equivalent instances.
>
But this is *exactly* how `any` works. The *only difference* is that `any`
has no `operator==` overload.
I'd be fine if it weren't considered a smart pointer type, even though it
mostly is equivalent to `unique_ptr` in terms of interface. You could call
it `clone_ptr_value` and have the comparison operators compare the stored
value instead of the pointers. The main things are that it can
adopt/manage/release pointers, and its copy semantics copy the object they
point to.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5eae5f16-e129-4c95-8001-fc73cc4f3d03%40isocpp.org.
------=_Part_1017_1224326318.1482000188759
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel=
Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Dec 17,=
2016 at 10:04:47AM -0800, Nicol Bolas wrote:
<br>>
<br>> =C2=A0 After all, such copying behavior won't break most stand=
ard library types.
<br>> =C2=A0 `vector<clone_ptr>` will work as expected, as will `a=
ny`,
<br>> =C2=A0 `optional<clone_ptr>`, `variant<clone_ptr>`, an=
d so forth.
<br>>
<br>
<br>It would certainly work with the STL types, but I'm fairly certain =
you might get very different results when using these in STL algorithms. Wi=
th some implementations references to the pointees might be preserved since=
the algorithm doesn't copy the clone_ptr whereas others might perform =
a copy, hence invalidating existing references or at least having them poin=
t to a different object than the one returned from the algorithm.<br></bloc=
kquote><div><br>Which is no different from passing a value type that gets c=
opied, then expecting the copies to be modifying the original value.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>> =C2=A0 I think it's important to understand that `clone_ptr` i=
s a solution to a
<br>> =C2=A0 very specific problem, one that isn't exactly common. Y=
ou shouldn't see a
<br>> =C2=A0 huge number of these pointers lying around.
<br>
<br>> =C2=A0 I don't think "might be harmful" is a good en=
ough reason to not have the
<br>> =C2=A0 type.
<br>
<br>Together with the fact that the problem it tries to solve isn't com=
mon it most
<br>definitely is. If the type is very hard to use correctly and not really=
needed
<br>all that often then I see no reason to have it.
<br>
<br>> =C2=A0 I'd say the biggest problem is that there's no way =
to conceptualize the
<br>> =C2=A0 special nature of `clone_ptr`'s copy constructor. You c=
an't write a
<br>> =C2=A0 Concepts TS `requires` clause that says, "a copy const=
ructor/assignment
<br>> =C2=A0 shall ensure that the copied value is =3D=3D to the origina=
l." That's an
<br>> =C2=A0 axiomatic distinction, not a syntactic one. And we don'=
t have ways to
<br>> =C2=A0 specify axioms or require based on them.
<br>
<br>The problem really is that it tries to act both as a pointer type which=
would entail that after copying it the pointee is the same for both pointe=
rs and at the same time it tries to be a object type where copying creates =
distinct but equivalent instances.<br></blockquote><div><br>But this is <i>=
exactly</i> how `any` works. The <i>only difference</i> is that `any` has n=
o `operator=3D=3D` overload.<br><br>I'd be fine if it weren't consi=
dered a smart pointer type, even though it mostly is equivalent to `unique_=
ptr` in terms of interface. You could call it `clone_ptr_value` and have th=
e comparison operators compare the stored value instead of the pointers. Th=
e main things are that it can adopt/manage/release pointers, and its copy s=
emantics copy the object they point to.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5eae5f16-e129-4c95-8001-fc73cc4f3d03%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5eae5f16-e129-4c95-8001-fc73cc4f3d03=
%40isocpp.org</a>.<br />
------=_Part_1017_1224326318.1482000188759--
------=_Part_1016_1976953854.1482000188759--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 20:28:12 +0100
Raw View
--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 17, 2016 at 10:43:08AM -0800, Nicol Bolas wrote:
> On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel Bergler wrot=
e:
>
> On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote:
> >
> > =C2=A0 After all, such copying behavior won't break most standard l=
ibrary
> types.
> > =C2=A0 `vector<clone_ptr>` will work as expected, as will `any`,
> > =C2=A0 `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
> >
>
> It would certainly work with the STL types, but I'm fairly certain yo=
u
> might get very different results when using these in STL algorithms.
> With some implementations references to the pointees might be preserv=
ed
> since the algorithm doesn't copy the clone_ptr whereas others might
> perform a copy, hence invalidating existing references or at least
> having them point to a different object than the one returned from th=
e
> algorithm.
>
> Which is no different from passing a value type that gets copied, then
> expecting the copies to be modifying the original value.
> =C2=A0
It is different.
Consider for example something like
my_obj =3D std::accumulate(input.begin(), input.end(), std::move(my_obj=
),
some_function);
Afterwards references to my_obj will still be valid and correctly point to =
the
modified object.
On the other hand, if you have
auto f =3D [&someObj] (auto& acc, auto const& in) -> decltype(auto) {
acc->doSomethingModifyingThePointeeObj(in);
someObj.doSomething(acc) // note I really want the cloning here
// so I need to pass in the clone_ptr
// and not the pointee
return std::move(acc);
};
my_clone_ptr =3D std::accumulate(input.begin(), input.end(), std::move(=
my_clone_ptr), f);
now suddenly all references you got by calling `*my_clone_ptr` somewhen bef=
ore
might or might not be invalid, even though I moved the original clone_ptr i=
nto
the algorithm to ensure that it doesn't get copied.
I'm aware that this is somewhat of a silly example because you'd probably d=
o
this with a handwritten for-loop, but nevertheless it shows how hard it is =
to
use this type correctly with STL algorithms.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217192812.GA17421%40manuel-ThinkPad-L440.lo=
caldomain.
--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEi3F6I6jTgMCHgGvofAJ3kFaTK3oFAlhVkcoACgkQfAJ3kFaT
K3oo+BAAoDAp81yqVbaNaoy8ySmN+V/fQix8gv8e/InMd5a/+/HEkrtKn3PqRk9I
Y9PMlAJ7Eqa6JD5lk4lGaxhsH6+6/pe3REBI1xjEzEm/fjR0A4fYfGeGlPqKYwa/
nhjneYrggX2HHhaKdbPNnwrc9Q+IBiTkQBsie4r3cqzayo3Ast/TuGDEG3kB7/Sh
LBiIUJv6pcpMbB/oJSwjt2MW3B8UULgvEy9p7acdhhaYotRY5qqytdsblOTYDqmS
N2d9a6AOzjjI4tH5CHIMSei0j2uxvtZE86rFrhXphI5wKJvUFoPajSfgXMOjHw+7
O/rsggrHLzxaLbKoLhH+sAGun93h+MWGZCwjJlVGDOAAPNorLgjJ81nefTQtNzpk
1QOYKCN+L4SBUxGrVeLrbfOIAfmHJGmiug9+ECgisYwwH6PvDGk3D+TD6N6r2PiZ
dXhO98Z/g4sbWnsNOj1X+gMr4QQ1eP6TZHGHqazZiX/TtzVGAMzAmIJBBx9I35IL
1LRHJsfMH4NXLZc/uECLkAq04NsYP7G7gMMlzpWVybbJPlLn2uU8Wwbj58GJY6gh
cJtOMaJc+RJoJLDSssFAvC187bVc6ziH4a8+btPzZOgAJzGAbAAHGfYThloFG6tf
ZvjeQ5f2kW6qiJOqx1FjRABYUiEnkh4Twr9mUvmEQf4yYs7GIns=
=9trW
-----END PGP SIGNATURE-----
--UlVJffcvxoiEqYs2--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 17 Dec 2016 12:35:03 -0800 (PST)
Raw View
------=_Part_928_236439197.1482006903433
Content-Type: multipart/alternative;
boundary="----=_Part_929_1421785983.1482006903433"
------=_Part_929_1421785983.1482006903433
Content-Type: text/plain; charset=UTF-8
On Saturday, December 17, 2016 at 2:29:01 PM UTC-5, Manuel Bergler wrote:
>
> On Sat, Dec 17, 2016 at 10:43:08AM -0800, Nicol Bolas wrote:
> > On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel Bergler
> wrote:
> >
> > On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote:
> > >
> > > After all, such copying behavior won't break most standard
> library
> > types.
> > > `vector<clone_ptr>` will work as expected, as will `any`,
> > > `optional<clone_ptr>`, `variant<clone_ptr>`, and so forth.
> > >
> >
> > It would certainly work with the STL types, but I'm fairly certain
> you
> > might get very different results when using these in STL algorithms.
> > With some implementations references to the pointees might be
> preserved
> > since the algorithm doesn't copy the clone_ptr whereas others might
> > perform a copy, hence invalidating existing references or at least
> > having them point to a different object than the one returned from
> the
> > algorithm.
> >
> > Which is no different from passing a value type that gets copied, then
> > expecting the copies to be modifying the original value.
> >
>
> It is different.
>
> Consider for example something like
>
> my_obj = std::accumulate(input.begin(), input.end(),
> std::move(my_obj),
> some_function);
>
> Afterwards references to my_obj will still be valid and correctly point to
> the
> modified object.
>
> On the other hand, if you have
>
> auto f = [&someObj] (auto& acc, auto const& in) -> decltype(auto) {
> acc->doSomethingModifyingThePointeeObj(in);
> someObj.doSomething(acc) // note I really want the cloning here
> // so I need to pass in the clone_ptr
> // and not the pointee
> return std::move(acc);
> };
>
> my_clone_ptr = std::accumulate(input.begin(), input.end(),
> std::move(my_clone_ptr), f);
>
> now suddenly all references you got by calling `*my_clone_ptr` somewhen
> before
> might or might not be invalid,
Actually, the standard *guarantees* that it isn't valid. Your
`move(my_clone_ptr)` will move-construct the `init` parameter of
`accumulate`. However, the standard says:
> Computes its result by initializing the accumulator acc with the initial
value init
This means that it creates a new `T` called `acc`, which is initialized by
the `init` value. Therefore, it will initialize `acc` by *copy*. `init`
will hold the original pointer until the end of `accumulate`, when it will
be destroyed. What will be returned is `acc`, which is a copy of `init`.
> even though I moved the original clone_ptr into
> the algorithm to ensure that it doesn't get copied.
>
Replace `clone_ptr` with `any`. Or `vector`. Many types have this problem
with `accumulate`; I don't see why adding one more will hurt anything.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org.
------=_Part_929_1421785983.1482006903433
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 17, 2016 at 2:29:01 PM UTC-5, Manuel=
Bergler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Dec 17,=
2016 at 10:43:08AM -0800, Nicol Bolas wrote:
<br>> =C2=A0 On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel =
Bergler wrote:
<br>>
<br>> =C2=A0 =C2=A0 On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bola=
s wrote:
<br>> =C2=A0 =C2=A0 >
<br>> =C2=A0 =C2=A0 > =C2=A0 After all, such copying behavior won'=
;t break most standard library
<br>> =C2=A0 =C2=A0 types.
<br>> =C2=A0 =C2=A0 > =C2=A0 `vector<clone_ptr>` will work as e=
xpected, as will `any`,
<br>> =C2=A0 =C2=A0 > =C2=A0 `optional<clone_ptr>`, `variant<=
;clone_ptr>`, and so forth.
<br>> =C2=A0 =C2=A0 >
<br>>
<br>> =C2=A0 =C2=A0 It would certainly work with the STL types, but I=
9;m fairly certain you
<br>> =C2=A0 =C2=A0 might get very different results when using these in=
STL algorithms.
<br>> =C2=A0 =C2=A0 With some implementations references to the pointees=
might be preserved
<br>> =C2=A0 =C2=A0 since the algorithm doesn't copy the clone_ptr w=
hereas others might
<br>> =C2=A0 =C2=A0 perform a copy, hence invalidating existing referenc=
es or at least
<br>> =C2=A0 =C2=A0 having them point to a different object than the one=
returned from the
<br>> =C2=A0 =C2=A0 algorithm.
<br>>
<br>> =C2=A0 Which is no different from passing a value type that gets c=
opied, then
<br>> =C2=A0 expecting the copies to be modifying the original value.
<br>> =C2=A0 =C2=A0
<br>
<br>It is different.
<br>
<br>Consider for example something like
<br>
<br>=C2=A0 =C2=A0 my_obj =3D std::accumulate(input.begin(), input.end(), st=
d::move(my_obj),
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some_function);
<br>
<br>Afterwards references to my_obj will still be valid and correctly point=
to the
<br>modified object.
<br>
<br>On the other hand, if you have
<br>
<br>=C2=A0 =C2=A0 auto f =3D [&someObj] (auto& acc, auto const&=
in) -> decltype(auto) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 acc-><wbr>doSomethingModifyingThePointee=
<wbr>Obj(in);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 someObj.doSomething(acc) =C2=A0// note I re=
ally want the cloning here
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // so I need to pass in th=
e clone_ptr
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // and not the pointee
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::move(acc);
<br>=C2=A0 =C2=A0 };
<br>
<br>=C2=A0 =C2=A0 my_clone_ptr =3D std::accumulate(input.begin(), input.end=
(), std::move(my_clone_ptr), f);
<br>
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">now suddenly =
all references you got by calling `*my_clone_ptr` somewhen before
<br>might or might not be invalid,</blockquote><div><br>Actually, the stand=
ard <i>guarantees</i> that it isn't valid. Your `move(my_clone_ptr)` wi=
ll move-construct the `init` parameter of `accumulate`. However, the standa=
rd says:<br><br>> Computes its result by initializing the accumulator ac=
c with the initial value init<br><br>This means that it creates a new `T` c=
alled `acc`, which is initialized by the `init` value. Therefore, it will i=
nitialize `acc` by <i>copy</i>. `init` will hold the original pointer until=
the end of `accumulate`, when it will be destroyed. What will be returned =
is `acc`, which is a copy of `init`.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">even though I moved the original clone_ptr into
<br>the algorithm to ensure that it doesn't get copied.
<br></blockquote><div><br>Replace `clone_ptr` with `any`. Or `vector`. Many=
types have this problem with `accumulate`; I don't see why adding one =
more will hurt anything.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cb822c5c-fc50-48e5-ad60-fdb14580329c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb822c5c-fc50-48e5-ad60-fdb14580329c=
%40isocpp.org</a>.<br />
------=_Part_929_1421785983.1482006903433--
------=_Part_928_236439197.1482006903433--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 22:08:04 +0100
Raw View
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Dec 17, 2016 at 12:35:03PM -0800, Nicol Bolas wrote:
> It is different.
>
> Consider for example something like
>
> =C2=A0 =C2=A0 my_obj =3D std::accumulate(input.begin(), input.end(),
> std::move(my_obj),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some_function);
>
> Afterwards references to my_obj will still be valid and correctly poi=
nt
> to the
> modified object.
>
> On the other hand, if you have
>
> =C2=A0 =C2=A0 auto f =3D [&someObj] (auto& acc, auto const& in) -> de=
cltype(auto) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 acc->doSomethingModifyingThePointeeObj(in=
);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 someObj.doSomething(acc) =C2=A0// note I =
really want the cloning here
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // so I need to pass in t=
he clone_ptr
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // and not the pointee
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::move(acc);
> =C2=A0 =C2=A0 };
>
> =C2=A0 =C2=A0 my_clone_ptr =3D std::accumulate(input.begin(), input.e=
nd(),
> std::move(my_clone_ptr), f);
>
> now suddenly all references you got by calling `*my_clone_ptr` somewh=
en
> before
> might or might not be invalid,
>
> Actually, the standard guarantees that it isn't valid. Your
> `move(my_clone_ptr)` will move-construct the `init` parameter of
> `accumulate`. However, the standard says:
>
> > Computes its result by initializing the accumulator acc with the init=
ial
> value init
>
> This means that it creates a new `T` called `acc`, which is initialized=
by
> the `init` value. Therefore, it will initialize `acc` by copy. `init` w=
ill
> hold the original pointer until the end of `accumulate`, when it will b=
e
> destroyed. What will be returned is `acc`, which is a copy of `init`.
> =C2=A0
Apparently clang and gcc interpret this differently: They move it into plac=
e due to the std::move (see http://coliru.stacked-crooked.com/a/cbe39ffef2e=
bf716).
So in case of clang/gcc in my example the call to std::accumulate wouldn't =
invalidate existing references. But who knows, maybe some implementer of th=
e standard library will interpret the requirements the same way you did and=
actually perform a copy. But only forgetting to `return std::move(acc);` i=
n the lambda used for `std::accumulate` and using just `return acc;` result=
s in a copy.
This is the entire point: When even very experienced people are not able to
predict what will happen, how is this a good feature? It is just too hard t=
o
use correctly.
>
> even though I moved the original clone_ptr into
> the algorithm to ensure that it doesn't get copied.
>
> Replace `clone_ptr` with `any`. Or `vector`. Many types have this probl=
em
> with `accumulate`; I don't see why adding one more will hurt anything.
This is because these types don't act as pointers; you're not supposed to s=
tore references to individual elements of a vector or a std::any, whereas t=
he interface of this copy_ptr is designed to do exactly that, even though i=
t is dangerous/unpredictable.
The only way to get around that issue is to not have additional references =
to the pointee, but then there is no need to have the smart pointer interfa=
ce and you can just use `indirect<T>`.
>
> --
> You received this message because you are subscribed to the Google Grou=
ps
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send =
an
> email to [1]std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to [2]std-proposals@isocpp.org.
> To view this discussion on the web visit
> [3]https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb822c5=
c-fc50-48e5-ad60-fdb14580329c%40isocpp.org.
>
>References
>
> Visible links
> 1. mailto:std-proposals+unsubscribe@isocpp.org
> 2. mailto:std-proposals@isocpp.org
> 3. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb822c5=
c-fc50-48e5-ad60-fdb14580329c%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20161217210804.GA10967%40manuel-ThinkPad-L440.lo=
caldomain.
--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEi3F6I6jTgMCHgGvofAJ3kFaTK3oFAlhVqTEACgkQfAJ3kFaT
K3p1hQ/+JLqh4xIB0WtYR+TNENu1DcJXcXDpuhX3kpNTow+joCLuDbic3HSFXchz
3s7WdTGGPmLpcyMtbBqWodgfIdE5ob/N6awY1M2guEJWIBXbhEVDy+C8M7xlfzMw
Iz5w7B41nEHww08V7xQg6JkcgSfGhmJ1ul8VbTmNNlAguTkCAM/ZeZFwtNz3ubjz
t1I0f+OcUVazwAS74UyDjvQdPxGHutmTCTbJiYgnvtabe6oMTdSceXdT5f+LIGvC
Cg8hT1Bl3NrVPIE1zjplLrdZW0DdjOY5rj9xHI1cymo73CRKRlVi/q82q3G0RXYx
8l1ljnpcVdklmGKgi/mQ+THBSkeZgtIF8r4JT6/Z28HAz4sMLr53lj87vOr/nU/Z
HkNNwHGLRH1l3WW2cor93gg/thibMqVYvuZZjKSByPhsUtQVcsC4LWi7wLgupteo
QaIw/8RJ5o0pThOK/RcFoLCVR14Yu+VoAH+X2+YhZoD6qcanlx3BNp8dVycie6PC
iMPq7VkPzxPZLzNCdx3jBlqay9i3gC0KksKoy0szvtL2YfarKR+UWQHmR/zUoMMS
cPW9ylESAi1yREIz4DuHCiC3gF3D5N4fskpoDx0WJWiy/lUgN2cWZI9iyrnQAdMr
uJkJU45z8+hClULaq0f4onWz8tBRkHw28arM4lJnPilabVhDbnw=
=KGYm
-----END PGP SIGNATURE-----
--XsQoSWH+UP9D9v3l--
.
Author: Jonathan Coe <jbcoe@me.com>
Date: Sat, 17 Dec 2016 21:23:29 +0000
Raw View
--f403045dd96047ae270543e14cbc
Content-Type: text/plain; charset=UTF-8
On 17 December 2016 at 21:08, Manuel Bergler <berglerma@gmail.com> wrote:
> On Sat, Dec 17, 2016 at 12:35:03PM -0800, Nicol Bolas wrote:
>
>> It is different.
>>
>> Consider for example something like
>>
>> my_obj = std::accumulate(input.begin(), input.end(),
>> std::move(my_obj),
>> some_function);
>>
>> Afterwards references to my_obj will still be valid and correctly
>> point
>> to the
>> modified object.
>>
>> On the other hand, if you have
>>
>> auto f = [&someObj] (auto& acc, auto const& in) -> decltype(auto)
>> {
>> acc->doSomethingModifyingThePointeeObj(in);
>> someObj.doSomething(acc) // note I really want the cloning
>> here
>> // so I need to pass in the
>> clone_ptr
>> // and not the pointee
>> return std::move(acc);
>> };
>>
>> my_clone_ptr = std::accumulate(input.begin(), input.end(),
>> std::move(my_clone_ptr), f);
>>
>> now suddenly all references you got by calling `*my_clone_ptr`
>> somewhen
>> before
>> might or might not be invalid,
>>
>> Actually, the standard guarantees that it isn't valid. Your
>> `move(my_clone_ptr)` will move-construct the `init` parameter of
>> `accumulate`. However, the standard says:
>>
>> > Computes its result by initializing the accumulator acc with the
>> initial
>> value init
>>
>> This means that it creates a new `T` called `acc`, which is initialized
>> by
>> the `init` value. Therefore, it will initialize `acc` by copy. `init`
>> will
>> hold the original pointer until the end of `accumulate`, when it will be
>> destroyed. What will be returned is `acc`, which is a copy of `init`.
>>
>>
>
> Apparently clang and gcc interpret this differently: They move it into
> place due to the std::move (see http://coliru.stacked-crooked.
> com/a/cbe39ffef2ebf716).
>
> So in case of clang/gcc in my example the call to std::accumulate wouldn't
> invalidate existing references. But who knows, maybe some implementer of
> the standard library will interpret the requirements the same way you did
> and actually perform a copy. But only forgetting to `return
> std::move(acc);` in the lambda used for `std::accumulate` and using just
> `return acc;` results in a copy.
>
> This is the entire point: When even very experienced people are not able to
> predict what will happen, how is this a good feature? It is just too hard
> to
> use correctly.
>
>
>> even though I moved the original clone_ptr into
>> the algorithm to ensure that it doesn't get copied.
>>
>> Replace `clone_ptr` with `any`. Or `vector`. Many types have this
>> problem
>> with `accumulate`; I don't see why adding one more will hurt anything.
>>
>
> This is because these types don't act as pointers; you're not supposed to
> store references to individual elements of a vector or a std::any, whereas
> the interface of this copy_ptr is designed to do exactly that, even though
> it is dangerous/unpredictable.
>
> The only way to get around that issue is to not have additional references
> to the pointee, but then there is no need to have the smart pointer
> interface and you can just use `indirect<T>`.
>
>
Finishing touches to `polymorphic_value` (formerly know as `indirect`) are
being made here https://github.com/jbcoe/polymorphic_value.
>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> email to [1]std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to [2]std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> [3]https://groups.google.com/a/isocpp.org/d/msgid/std-propos
>> als/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org.
>>
>> References
>>
>> Visible links
>> 1. mailto:std-proposals+unsubscribe@isocpp.org
>> 2. mailto:std-proposals@isocpp.org
>> 3. https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>> /cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org?utm_
>> medium=email&utm_source=footer
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/20161217210804.GA10967%
> 40manuel-ThinkPad-L440.localdomain.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_eUtvYsPriPV-QSLED4Taxde1ShCMOuqpMm924JGVyzw%40mail.gmail.com.
--f403045dd96047ae270543e14cbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 17 December 2016 at 21:08, Manuel Bergler <span dir=3D"ltr"><<a h=
ref=3D"mailto:berglerma@gmail.com" target=3D"_blank">berglerma@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div class=3D"gmail-HOEnZb"><div cl=
ass=3D"gmail-h5">On Sat, Dec 17, 2016 at 12:35:03PM -0800, Nicol Bolas wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
=C2=A0 =C2=A0 It is different.<br>
<br>
=C2=A0 =C2=A0 Consider for example something like<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 my_obj =3D std::accumulate(input.begin(), input=
..end(),<br>
=C2=A0 =C2=A0 std::move(my_obj),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some_function);<br>
<br>
=C2=A0 =C2=A0 Afterwards references to my_obj will still be valid and corre=
ctly point<br>
=C2=A0 =C2=A0 to the<br>
=C2=A0 =C2=A0 modified object.<br>
<br>
=C2=A0 =C2=A0 On the other hand, if you have<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto f =3D [&someObj] (auto& acc, auto =
const& in) -> decltype(auto) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acc->doSomethingModifyingThePo=
<wbr>inteeObj(in);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 someObj.doSomething(acc) =C2=A0//=
note I really want the cloning here<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // so I need to=
pass in the clone_ptr<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // and not the =
pointee<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::move(acc);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 };<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 my_clone_ptr =3D std::accumulate(input.begin(),=
input.end(),<br>
=C2=A0 =C2=A0 std::move(my_clone_ptr), f);<br>
<br>
=C2=A0 =C2=A0 now suddenly all references you got by calling `*my_clone_ptr=
` somewhen<br>
=C2=A0 =C2=A0 before<br>
=C2=A0 =C2=A0 might or might not be invalid,<br>
<br>
=C2=A0 Actually, the standard guarantees that it isn't valid. Your<br>
=C2=A0 `move(my_clone_ptr)` will move-construct the `init` parameter of<br>
=C2=A0 `accumulate`. However, the standard says:<br>
<br>
=C2=A0 > Computes its result by initializing the accumulator acc with th=
e initial<br>
=C2=A0 value init<br>
<br>
=C2=A0 This means that it creates a new `T` called `acc`, which is initiali=
zed by<br>
=C2=A0 the `init` value. Therefore, it will initialize `acc` by copy. `init=
` will<br>
=C2=A0 hold the original pointer until the end of `accumulate`, when it wil=
l be<br>
=C2=A0 destroyed. What will be returned is `acc`, which is a copy of `init`=
..<br>
=C2=A0 =C2=A0<br>
</blockquote>
<br></div></div>
Apparently clang and gcc interpret this differently: They move it into plac=
e due to the std::move (see <a href=3D"http://coliru.stacked-crooked.com/a/=
cbe39ffef2ebf716" rel=3D"noreferrer" target=3D"_blank">http://coliru.stacke=
d-crooked.<wbr>com/a/cbe39ffef2ebf716</a>).<br>
<br>
So in case of clang/gcc in my example the call to std::accumulate wouldn=
9;t invalidate existing references. But who knows, maybe some implementer o=
f the standard library will interpret the requirements the same way you did=
and actually perform a copy. But only forgetting to `return std::move(acc)=
;` in the lambda used for `std::accumulate` and using just `return acc;` re=
sults in a copy.<br>
<br>
This is the entire point: When even very experienced people are not able to=
<br>
predict what will happen, how is this a good feature? It is just too hard t=
o<br>
use correctly.<span class=3D"gmail-"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
=C2=A0 =C2=A0 even though I moved the original clone_ptr into<br>
=C2=A0 =C2=A0 the algorithm to ensure that it doesn't get copied.<br>
<br>
=C2=A0 Replace `clone_ptr` with `any`. Or `vector`. Many types have this pr=
oblem<br>
=C2=A0 with `accumulate`; I don't see why adding one more will hurt any=
thing.<br>
</blockquote>
<br></span>
This is because these types don't act as pointers; you're not suppo=
sed to store references to individual elements of a vector or a std::any, w=
hereas the interface of this copy_ptr is designed to do exactly that, even =
though it is dangerous/unpredictable.<br>
<br>
The only way to get around that issue is to not have additional references =
to the pointee, but then there is no need to have the smart pointer interfa=
ce and you can just use `indirect<T>`.<br>
<br></blockquote><div><br></div><div>Finishing touches to `polymorphic_valu=
e` (formerly know as `indirect`) are being made here <a href=3D"https://git=
hub.com/jbcoe/polymorphic_value">https://github.com/jbcoe/polymorphic_value=
</a>.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><span class=3D"gmail-">
<br>
=C2=A0 --<br>
=C2=A0 You received this message because you are subscribed to the Google G=
roups<br>
=C2=A0 "ISO C++ Standard - Future Proposals" group.<br>
=C2=A0 To unsubscribe from this group and stop receiving emails from it, se=
nd an<br></span>
=C2=A0 email to [1]<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org=
" target=3D"_blank">std-proposals+unsubscribe@i<wbr>socpp.org</a>.<br>
=C2=A0 To post to this group, send email to [2]<a href=3D"mailto:std-propos=
als@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<span class=
=3D"gmail-"><br>
=C2=A0 To view this discussion on the web visit<br></span>
=C2=A0 [3]<a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org" rel=3D"noreferrer=
" target=3D"_blank">https://groups.google.com/a<wbr>/isocpp.org/d/msgid/std=
-propos<wbr>als/cb822c5c-fc50-48e5-ad60-<wbr>fdb14580329c%40isocpp.org</a>.=
<br>
<br>
References<br>
<br>
=C2=A0 Visible links<br>
=C2=A0 1. mailto:<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" =
target=3D"_blank">std-proposals+unsubscri<wbr>be@isocpp.org</a><br>
=C2=A0 2. mailto:<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_bla=
nk">std-proposals@isocpp.or<wbr>g</a><br>
=C2=A0 3. <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/cb822c5c-fc50-48e5-ad60-fdb14580329c%40isocpp.org?utm_medium=3Demail=
&utm_source=3Dfooter" rel=3D"noreferrer" target=3D"_blank">https://grou=
ps.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/cb822c5c-fc50-48=
e5-ad60-<wbr>fdb14580329c%40isocpp.org?utm_<wbr>medium=3Demail&utm_sour=
ce=3Dfooter</a><br>
</blockquote><span class=3D"gmail-">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20161217210804.GA10967%40manuel-Think=
Pad-L440.localdomain" rel=3D"noreferrer" target=3D"_blank">https://groups.g=
oogle.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/20161217210804.GA109=
67%<wbr>40manuel-ThinkPad-L440.<wbr>localdomain</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_eUtvYsPriPV-QSLED4Taxde1ShCMO=
uqpMm924JGVyzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAbBDD_eUtvYsPri=
PV-QSLED4Taxde1ShCMOuqpMm924JGVyzw%40mail.gmail.com</a>.<br />
--f403045dd96047ae270543e14cbc--
.
Author: Manuel Bergler <berglerma@gmail.com>
Date: Sat, 17 Dec 2016 22:25:36 +0100
Raw View
--001a114488a6daee590543e153c8
Content-Type: text/plain; charset=UTF-8
On Sat, Dec 17, 2016 at 10:08 PM, Manuel Bergler <berglerma@gmail.com>
wrote:
> Apparently clang and gcc interpret this differently: They move it into
> place due to the std::move (see http://coliru.stacked-crooked.
> com/a/cbe39ffef2ebf716).
>
> So in case of clang/gcc in my example the call to std::accumulate wouldn't
> invalidate existing references. But who knows, maybe some implementer of
> the standard library will interpret the requirements the same way you did
> and actually perform a copy. But only forgetting to `return
> std::move(acc);` in the lambda used for `std::accumulate` and using just
> `return acc;` results in a copy.
>
I just tested it with msvc (http://rextester.com/SZRHBC97716), as a matter
of fact they do indeed perform the copy as you suggested. So you end up
with platform dependent behavior for this one...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmtM9vxhmiCSaFLSm5Toct3qQ07wpPZU%3DbJa_v6H9BQbjQ%40mail.gmail.com.
--001a114488a6daee590543e153c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 17, 2016 at 10:08 PM, Manuel Bergler <span dir=3D"ltr"><<a href=
=3D"mailto:berglerma@gmail.com" target=3D"_blank">berglerma@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
class=3D"gmail-HOEnZb"><div class=3D"gmail-h5"></div></div>
Apparently clang and gcc interpret this differently: They move it into plac=
e due to the std::move (see <a href=3D"http://coliru.stacked-crooked.com/a/=
cbe39ffef2ebf716" rel=3D"noreferrer" target=3D"_blank">http://coliru.stacke=
d-crooked.<wbr>com/a/cbe39ffef2ebf716</a>).<br>
<br>
So in case of clang/gcc in my example the call to std::accumulate wouldn=
9;t invalidate existing references. But who knows, maybe some implementer o=
f the standard library will interpret the requirements the same way you did=
and actually perform a copy. But only forgetting to `return std::move(acc)=
;` in the lambda used for `std::accumulate` and using just `return acc;` re=
sults in a copy.<br></blockquote><div><br></div><div>I just tested it with =
msvc (<a href=3D"http://rextester.com/SZRHBC97716">http://rextester.com/SZR=
HBC97716</a>), as a matter of fact they do indeed perform the copy as you s=
uggested. So you end up with platform dependent behavior for this one...<br=
></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAM76qmtM9vxhmiCSaFLSm5Toct3qQ07wpPZU=
%3DbJa_v6H9BQbjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM76qmtM9vxhmi=
CSaFLSm5Toct3qQ07wpPZU%3DbJa_v6H9BQbjQ%40mail.gmail.com</a>.<br />
--001a114488a6daee590543e153c8--
.