Topic: address-of operator should not produce a prvalue
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Thu, 26 Feb 2015 11:05:36 -0800 (PST)
Raw View
------=_Part_7677_1992501135.1424977536280
Content-Type: multipart/alternative;
boundary="----=_Part_7678_106584627.1424977536280"
------=_Part_7678_106584627.1424977536280
Content-Type: text/plain; charset=UTF-8
The address-of operator should produce an rvalue (in the C++11 sense)
rather than a prvalue.
Alternatively, pointer (and scalar) prvalues should not bind to rvalue
references.
cppreference.com says
*A prvalue ("pure" rvalue) is an expression that identifies a temporary
object (or a subobject thereof) or is a value not associated with any
object.*
but you can say that that the result of address-of is associated (in a
loose sense) with an object -- the object it just took the address of. It
produces a pointer that could theoretically have the delete operator called
on it somewhere.
Consider the following:
template <class S>
class sptr
{
S * m_obj;
bool m_mine;
void release() { if (m_mine) delete m_obj; m_obj=nullptr; }
public:
sptr (S *const &i=nullptr): m_obj(i), m_mine(false) {}
sptr (S *&&i): m_obj(i), m_mine(true) {i=nullptr;}
sptr&operator= (S *const &i) { release(); m_obj=i; m_mine=false; return *
this; }
sptr&operator= (S *&&i): { release(); m_obj=i; i=nullptr; m_mine=true;
return *this; }
// other stuff, you get the gist
~sptr ( release(); )
};
It's nice that I can now say
sptr<S> p_s (new S);
(because new produces an xvalue)
but I can also say
sptr<S> p_s;
S s;
p_s=&s; // uh-oh
Because &s in the second example is a prvalue, it binds to
the move-assignment operator, making p_s.m_mine==true and thus sptr::release will
attempt to delete an object it doesn't own.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7678_106584627.1424977536280
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font color=3D"#000088">The address-of operator shoul=
d produce an rvalue (in the C++11 sense) rather than a prva=
lue. </font></div><div><font color=3D"#000088">Alternatively, pointer=
(and scalar) prvalues should not bind to rvalue references. </font></=
div><div><font color=3D"#000088"></font><div><font color=3D"#000088"></font=
> </div></div><div><font color=3D"#000088">cppreference.com says</font=
></div><div><font color=3D"#000088"></font><div><font color=3D"#000088"></f=
ont> </div></div><div><font color=3D"#000088"><em>A prvalue ("pure" rv=
alue) is an expression that identifies a temporary object (or a subobject t=
hereof) or is a value not associated with any object.</em> </font></div><fo=
nt color=3D"#000088"></font><div><font color=3D"#000088"></font> </div=
><div><font color=3D"#000088">but you can say that that the result of addre=
ss-of is associated (in a loose sense) with an object -- the object it just=
took the address of. It produces a pointer that could theoreti=
cally have the delete operator called on it somewhere.</font></div><div><fo=
nt color=3D"#000088"><br></font></div><div><font color=3D"#000088">Consider=
the following:</font></div><div><font color=3D"#000088"></font><div><font =
color=3D"#000088"></font> </div></div><div><font color=3D"#000088"><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); bord=
er-image: none; -ms-word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">template</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"><</sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">clas=
s</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> =
S</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0)=
;">></span><div><font color=3D"#000088"><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(0, 0, 136);">class</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0);"> sptr</span></font></div><div><font =
color=3D"#000088"><span class=3D"styled-by-prettify" style=3D"color: rgb(10=
2, 102, 0);">{</span></font></div><div><font color=3D"#000088"><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> S </span><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">*</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> m_obj</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span>=
</font></div><div><font color=3D"#000088"><span class=3D"styled-by-prettify=
" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify"=
style=3D"color: rgb(0, 0, 136);">bool</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 0);"> m_mine</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(102, 102, 0);">;</span></font></div><div><fon=
t color=3D"#000088"><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(0=
, 0, 136);">void</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0);"> release</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(102, 102, 0);">()</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">{</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(0, 0, 136);">if</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify"=
style=3D"color: rgb(0, 0, 0);">m_mine</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(102, 102, 0);">)</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(0, 0, 136);">delete</span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(0, 0, 0);"> m_obj</span><span class=3D"sty=
led-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> m_obj</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=3D</span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">nullptr</span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">}<=
/span></font></div><div><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0);"> </span></div><div><font color=3D"#000088"><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">public</span><span=
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">:</span></=
font></div><div><font color=3D"#000088"><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> sptr </span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(102, 102, 0);">(</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(0, 0, 0);">S </span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(102, 102, 0);">*</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 136);">const</span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">&</span><span class=3D=
"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">i</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=3D</span><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">nullptr</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">):</span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> m_obj</=
span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=
(</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">i=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);=
">),</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);=
"> m_mine</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102,=
102, 0);">(</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0=
, 0, 136);">false</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(102, 102, 0);">)</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">{}</span></font></div><div><font color=3D"#000088"><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> sptr </span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">(</s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">S </s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">*=
&&</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, =
0, 0);">i</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102,=
102, 0);">):</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);"> m_obj</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(0, 0, 0);">i</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">),</span><span class=3D"styled-by-prettify" style=3D"c=
olor: rgb(0, 0, 0);"> m_mine</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(102, 102, 0);">(</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 136);">true</span><span class=3D"styled-by-prettify=
" style=3D"color: rgb(102, 102, 0);">)</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(102, 102, 0);">{</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(0, 0, 0);">i</span><span class=3D"styled-by-pret=
tify" style=3D"color: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(0, 0, 136);">nullptr</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(102, 102, 0);">;}</span></font></div>=
<div><font color=3D"#000088"><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(0, 0, 0);"> sptr</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(102, 102, 0);">&</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 136);">operator</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(102, 102, 0);">=3D</span><span class=3D"styled-b=
y-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(102, 102, 0);">(</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 0);">S </span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">*</span><span class=3D"sty=
led-by-prettify" style=3D"color: rgb(0, 0, 136);">const</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&</span><spa=
n class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">i</span><span=
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">)</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span>=
<span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> release<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"=
>();</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);=
"> m_obj</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, =
102, 0);">=3D</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);">i</span><span class=3D"styled-by-prettify" style=3D"color: rgb(1=
02, 102, 0);">;</span><span class=3D"styled-by-prettify" style=3D"color: rg=
b(0, 0, 0);"> m_mine</span><span class=3D"styled-by-prettify" style=3D"colo=
r: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 136);">false</span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 136);">return</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(102, 102, 0);">*</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(0, 0, 136);">this</span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(102, 102, 0);">}</span></font></div><div><=
font color=3D"#000088"><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0);"> sptr</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(102, 102, 0);">&</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 136);">operator</span><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(102, 102, 0);">(</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 0);">S </span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(102, 102, 0);">*&&</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">i</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">):</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span><span=
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> release</span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">();<=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> m_=
obj</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, =
0);">=3D</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,=
0);">i</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 1=
02, 0);">;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, =
0, 0);"> i</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102=
, 102, 0);">=3D</span><span class=3D"styled-by-prettify" style=3D"color: rg=
b(0, 0, 136);">nullptr</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 0);"> m_mine</span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">=3D</span><span class=3D"styled-by-prettify=
" style=3D"color: rgb(0, 0, 136);">true</span><span class=3D"styled-by-pret=
tify" style=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 136);">return</span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(102, 102, 0);">*</span><span class=3D"styl=
ed-by-prettify" style=3D"color: rgb(0, 0, 136);">this</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">}</span></font><=
/div><div><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
> </span></div><div><font color=3D"#000088"><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(136, 0, 0);">// other stuff, you get the gist</=
span></font></div><div><font color=3D"#000088"><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(136, 0, 0);"> ~sptr ( release(); ) </span></font=
></div><div><font color=3D"#000088"><span class=3D"styled-by-prettify" styl=
e=3D"color: rgb(136, 0, 0);">};</span></font></div></div></code></div></fon=
t><div><font color=3D"#000088"></font> </div></div><div><font color=3D=
"#000088"></font><div><font color=3D"#000088">It's nice that I can now say<=
/font></div></div><font color=3D"#000088"><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms-word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span class=3D"styled-by-prettify" styl=
e=3D"color: rgb(0, 0, 0);">sptr</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(102, 102, 0);"><</span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 0);">S</span><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 102, 0);">></span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);"> p_s </span><span class=3D"styled-b=
y-prettify" style=3D"color: rgb(102, 102, 0);">(</span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 136);">new</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"> S</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(102, 102, 0);">);</span><div><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span></div></d=
iv></code></div><p>(because new produces an xvalue)</p></font><p><font colo=
r=3D"#000088">but I can also say</font></p><div><font color=3D"#000088"><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); bord=
er-image: none; -ms-word-wrap: break-word; background-color: rgb(250, 250, =
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">sptr</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"><</span><s=
pan class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">S</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">></sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> p_s</=
span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=
;</span><div><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0=
);">S s</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 1=
02, 0);">;</span></div><div><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);">p_s</span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(102, 102, 0);">=3D&</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 0);">s</span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(102, 102, 0);">;</span><span class=3D"styled-by-prettify"=
style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(136, 0, 0);">// uh-oh</span></div><div><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(136, 0, 0);"> </span></div></div></c=
ode></div></font><div><font color=3D"#000088"></font>Because <font face=3D"=
courier new,monospace">&s</font> in the second example is a prvalue, it=
binds to the move-assignment operator, making <font face=3D"courier n=
ew,monospace">p_s.m_mine=3D=3Dtrue</font> and thus <font face=3D"courier ne=
w,monospace">sptr::release</font> will attempt to delete an object it =
doesn't own.</div></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7678_106584627.1424977536280--
------=_Part_7677_1992501135.1424977536280--
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Thu, 26 Feb 2015 11:19:03 -0800 (PST)
Raw View
------=_Part_7351_1208927432.1424978343047
Content-Type: multipart/alternative;
boundary="----=_Part_7352_1100565357.1424978343047"
------=_Part_7352_1100565357.1424978343047
Content-Type: text/plain; charset=UTF-8
Yes, the sptr destructor is a typo; it should read
~sptr() { release(); }
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7352_1100565357.1424978343047
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><div>Yes, the sptr destructor is a typo; it should read </div><div><font face="courier new,monospace">~sptr() { release(); }</font> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_7352_1100565357.1424978343047--
------=_Part_7351_1208927432.1424978343047--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 26 Feb 2015 20:12:12 +0000
Raw View
--001a11c13e261d66fb0510035e60
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 26, 2015 at 2:05 PM Spencer Simpson <ssimpson@baltometro.org>
wrote:
> but you can say that that the result of address-of is associated (in a
> loose sense) with an object -- the object it just took the address of.
>
The result of the address-of operator is not associated with any
**pointer** object. In the context of that quote, "object" refers to an
object of the same type than the prvalue expression. Otherwise you have to
consider that the iterators returned by 'std::list<T>::begin()' and 'end()'
are not prvalues either, since they may also relate to some other object,
and furthermore to an unrelated type.
> It produces a pointer that could theoretically have the delete operator
> called on it somewhere.
>
You can also call 'delete static_cast<int*>(0);' and clearly 0 is not
associated with any object.
>
> Consider the following:
>
You will just need to use a different design for your problem. I could
suggest passing a flag indicating ownership, although I don't really
believe in "sometimes"-owning smart pointers...
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c13e261d66fb0510035e60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote">On Thu, Feb 26, 2015 at 2:05 PM=
Spencer Simpson <<a href=3D"mailto:ssimpson@baltometro.org">ssimpson@ba=
ltometro.org</a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><span style=3D"color:rgb(0,0,136);font-size:13.1999998092651px">bu=
t you can say that that the result of address-of is associated (in a loose =
sense) with an object -- the object it just took the address of.</span></di=
v></div></blockquote><div><br>The result of the address-of operator is not =
associated with any **pointer** object.=C2=A0 In the context of that quote,=
"object" refers to an object of the same type than the prvalue e=
xpression.=C2=A0 Otherwise you have to consider that the iterators returned=
by 'std::list<T>::begin()' and 'end()' are not prval=
ues either, since they may also relate to some other object, and furthermor=
e to an unrelated type.<br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><span style=3D"color:rgb(0,0,136);font-size:13.19999980926=
51px">=C2=A0=C2=A0 It produces a pointer that could theoretically have the =
delete operator called on it somewhere.</span></div></div></blockquote><div=
><br>You can also call 'delete static_cast<int*>(0);' and cle=
arly 0 is not associated with any object.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><br></div><div><span style=3D"color:rgb(0,0,136);f=
ont-size:13.1999998092651px">Consider the following:</span><br></div><div><=
font color=3D"#000088"></font><div><span style=3D"font-size:13.199999809265=
1px"></span></div></div></div></blockquote><div><br></div><div>You will jus=
t need to use a different design for your problem. I could suggest passing =
a flag indicating ownership, although I don't really believe in "s=
ometimes"-owning smart pointers...</div></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c13e261d66fb0510035e60--
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Thu, 26 Feb 2015 12:29:55 -0800 (PST)
Raw View
------=_Part_7431_926943869.1424982595209
Content-Type: multipart/alternative;
boundary="----=_Part_7432_1299230945.1424982595209"
------=_Part_7432_1299230945.1424982595209
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, February 26, 2015 at 3:12:14 PM UTC-5, David Rodr=C3=ADguez Ib=
eas=20
wrote:
>
>
> The result of the address-of operator is not associated with any=20
> **pointer** object. In the context of that quote, "object" refers to an=
=20
> object of the same type than the prvalue expression.
>
Thus, "in a loose sense".
| Otherwise you have to consider that the iterators returned by=20
'std::list<T>::begin()' and 'end()' are not prvalues either, since they may=
=20
also relate to some other object, and furthermore to an unrelated type.
Well, if they're scalar, they needn't bind to rvalue references. If not,=
=20
they're beyond the scope of this proposal.
=20
> You can also call 'delete static_cast<int*>(0);' and clearly 0 is not=20
> associated with any object.
>
static_cast is not the address-of operator, which requires something to=20
have its address taken.
=20
> You will just need to use a different design for your problem. I could=20
> suggest passing a flag indicating ownership, although I don't really=20
> believe in "sometimes"-owning smart pointers...
>
Although the example's design is off-topic, I like it regardless of whether=
=20
this proposal is taken up or not. If circumstances force the design to be=
=20
not entirely rigorous, I think it balances rigor and the problem to be=20
solved adequately. Example #2 is thus an instance of "Doctor, it hurts=
=20
when I do this".=20
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_7432_1299230945.1424982595209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, February 26, 2015 at 3:12:14 PM UTC-5=
, David Rodr=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div><br>The result of the address-of o=
perator is not associated with any **pointer** object. In the context=
of that quote, "object" refers to an object of the same type than the prva=
lue expression.<br></div></div></div></blockquote><div><br></div><div>Thus,=
"in a loose sense".<div><br></div><div>| Otherwise you have to consider th=
at the iterators returned by 'std::list<T>::begin()' and 'end()' are =
not prvalues either, since they may also relate to some other object, and f=
urthermore to an unrelated type.<br><br></div><div>Well, if they're scalar,=
they needn't bind to rvalue references. If not, they're beyond the s=
cope of this proposal.</div></div><div> </div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>You can also call 'de=
lete static_cast<int*>(0);' and clearly 0 is not associated with any =
object.</div></div></div></blockquote><div><br></div><div>static_cast is no=
t the address-of operator, which requires something to have its address tak=
en.</div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"=
><div class=3D"gmail_quote"><div><font color=3D"#000088"></font><div><span =
style=3D"font-size: 13.19px;"></span></div></div><div>You will just need to=
use a different design for your problem. I could suggest passing a flag in=
dicating ownership, although I don't really believe in "sometimes"-owning s=
mart pointers...</div></div></div></blockquote><div><br></div><div>Although=
the example's design is off-topic, I like it regardless of whether th=
is proposal is taken up or not. If circumstances force the design to b=
e not entirely rigorous, I think it balances rigor and the problem to =
be solved adequately. Example #2 is thus an instance of "=
Doctor, it hurts when I do this". </div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7432_1299230945.1424982595209--
------=_Part_7431_926943869.1424982595209--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Fri, 27 Feb 2015 15:02:15 +0330
Raw View
--001a113fa19a9ea574051010399e
Content-Type: text/plain; charset=UTF-8
I personally don't like use of new as the initializer of smart pointers
when its possible to forward constructor parameters:
template<typename ...Args>
sptr::sptr(Args&&...args):m_mine{true},m_obj{new
S{std::forward<Args>(args)...}{};
but again IMHO result of address operator should be const and so should the
get member of smart pointers:
const pointer std::unique_ptr::get();
in contrast to:
pointer std::unique_ptr::release();
2015-02-26 22:35 GMT+03:30 Spencer Simpson <ssimpson@baltometro.org>:
> The address-of operator should produce an rvalue (in the C++11 sense)
> rather than a prvalue.
> Alternatively, pointer (and scalar) prvalues should not bind to rvalue
> references.
>
> cppreference.com says
>
> *A prvalue ("pure" rvalue) is an expression that identifies a temporary
> object (or a subobject thereof) or is a value not associated with any
> object.*
>
> but you can say that that the result of address-of is associated (in a
> loose sense) with an object -- the object it just took the address of. It
> produces a pointer that could theoretically have the delete operator called
> on it somewhere.
>
> Consider the following:
>
> template <class S>
> class sptr
> {
> S * m_obj;
> bool m_mine;
> void release() { if (m_mine) delete m_obj; m_obj=nullptr; }
> public:
> sptr (S *const &i=nullptr): m_obj(i), m_mine(false) {}
> sptr (S *&&i): m_obj(i), m_mine(true) {i=nullptr;}
> sptr&operator= (S *const &i) { release(); m_obj=i; m_mine=false; return *
> this; }
> sptr&operator= (S *&&i): { release(); m_obj=i; i=nullptr; m_mine=true;
> return *this; }
> // other stuff, you get the gist
> ~sptr ( release(); )
> };
>
> It's nice that I can now say
> sptr<S> p_s (new S);
>
> (because new produces an xvalue)
>
> but I can also say
> sptr<S> p_s;
> S s;
> p_s=&s; // uh-oh
> Because &s in the second example is a prvalue, it binds to
> the move-assignment operator, making p_s.m_mine==true and thus
> sptr::release will attempt to delete an object it doesn't own.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fa19a9ea574051010399e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div dir=3D"ltr">I personally don't like use of new as=
the initializer of smart pointers when its possible to forward constructor=
parameters:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">template<t=
ypename ...Args></div><div dir=3D"ltr">sptr::sptr(Args&&...args)=
:m_mine{true},m_obj{new S{std::forward<Args>(args)...}{};</div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr">but again IMHO result of address oper=
ator should be const and so should the get member of smart pointers:</div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr">const pointer std::unique_ptr::g=
et();</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">in contrast to:</div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr">pointer std::unique_ptr::relea=
se();</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">2015-02-26 22:35 GMT+03:30 Spencer Simpson <span dir=3D"lt=
r"><<a href=3D"mailto:ssimpson@baltometro.org" target=3D"_blank">ssimpso=
n@baltometro.org</a>></span>:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><font color=3D"#000088">The address-of operator should prod=
uce=C2=A0an rvalue=C2=A0 (in the C++11 sense) rather than a=C2=A0prvalue.=
=C2=A0 </font></div><div><font color=3D"#000088">Alternatively, pointer (an=
d scalar)=C2=A0prvalues should not bind to rvalue references. </font></div>=
<div><font color=3D"#000088"></font><div><font color=3D"#000088"></font>=C2=
=A0</div></div><div><font color=3D"#000088"><a href=3D"http://cppreference.=
com" target=3D"_blank">cppreference.com</a> says</font></div><div><font col=
or=3D"#000088"></font><div><font color=3D"#000088"></font>=C2=A0</div></div=
><div><font color=3D"#000088"><em>A prvalue ("pure" rvalue) is an=
expression that identifies a temporary object (or a subobject thereof) or =
is a value not associated with any object.</em> </font></div><font color=3D=
"#000088"></font><div><font color=3D"#000088"></font>=C2=A0</div><div><font=
color=3D"#000088">but you can say that that the result of address-of is as=
sociated (in a loose sense) with an object -- the object it just took the a=
ddress of.=C2=A0=C2=A0 It produces a pointer that could theoretically have =
the delete operator called on it somewhere.</font></div><div><font color=3D=
"#000088"><br></font></div><div><font color=3D"#000088">Consider the follow=
ing:</font></div><div><font color=3D"#000088"></font><div><font color=3D"#0=
00088"></font>=C2=A0</div></div><div><font color=3D"#000088"><div style=3D"=
border:1px solid rgb(187,187,187);background-color:rgb(250,250,250)"><code>=
<div><span style=3D"color:rgb(0,0,136)">template</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"><</span><span =
style=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> =
S</span><span style=3D"color:rgb(102,102,0)">></span><div><font color=3D=
"#000088"><span style=3D"color:rgb(0,0,136)">class</span><span style=3D"col=
or:rgb(0,0,0)"> sptr</span></font></div><div><font color=3D"#000088"><span =
style=3D"color:rgb(102,102,0)">{</span></font></div><div><font color=3D"#00=
0088"><span style=3D"color:rgb(0,0,0)"> S </span><span style=3D"color:rgb(1=
02,102,0)">*</span><span style=3D"color:rgb(0,0,0)"> m_obj</span><span styl=
e=3D"color:rgb(102,102,0)">;</span></font></div><div><font color=3D"#000088=
"><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136=
)">bool</span><span style=3D"color:rgb(0,0,0)"> m_mine</span><span style=3D=
"color:rgb(102,102,0)">;</span></font></div><div><font color=3D"#000088"><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">v=
oid</span><span style=3D"color:rgb(0,0,0)"> release</span><span style=3D"co=
lor:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span style=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(=
0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D=
"color:rgb(0,0,0)">m_mine</span><span style=3D"color:rgb(102,102,0)">)</spa=
n><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136=
)">delete</span><span style=3D"color:rgb(0,0,0)"> m_obj</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> m_obj</=
span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rg=
b(0,0,136)">nullptr</span><span style=3D"color:rgb(102,102,0)">;</span><spa=
n style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">}=
</span></font></div><div><span style=3D"color:rgb(0,0,0)"> </span></div><di=
v><font color=3D"#000088"><span style=3D"color:rgb(0,0,0)">=C2=A0</span><sp=
an style=3D"color:rgb(0,0,136)">public</span><span style=3D"color:rgb(102,1=
02,0)">:</span></font></div><div><font color=3D"#000088"><span style=3D"col=
or:rgb(0,0,0)"> sptr </span><span style=3D"color:rgb(102,102,0)">(</span><s=
pan style=3D"color:rgb(0,0,0)">S </span><span style=3D"color:rgb(102,102,0)=
">*</span><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&</span><sp=
an style=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">=
=3D</span><span style=3D"color:rgb(0,0,136)">nullptr</span><span style=3D"c=
olor:rgb(102,102,0)">):</span><span style=3D"color:rgb(0,0,0)"> m_obj</span=
><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,=
0)">i</span><span style=3D"color:rgb(102,102,0)">),</span><span style=3D"co=
lor:rgb(0,0,0)"> m_mine</span><span style=3D"color:rgb(102,102,0)">(</span>=
<span style=3D"color:rgb(0,0,136)">false</span><span style=3D"color:rgb(102=
,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"co=
lor:rgb(102,102,0)">{}</span></font></div><div><font color=3D"#000088"><spa=
n style=3D"color:rgb(0,0,0)"> sptr </span><span style=3D"color:rgb(102,102,=
0)">(</span><span style=3D"color:rgb(0,0,0)">S </span><span style=3D"color:=
rgb(102,102,0)">*&&</span><span style=3D"color:rgb(0,0,0)">i</span>=
<span style=3D"color:rgb(102,102,0)">):</span><span style=3D"color:rgb(0,0,=
0)"> m_obj</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">),</span=
><span style=3D"color:rgb(0,0,0)"> m_mine</span><span style=3D"color:rgb(10=
2,102,0)">(</span><span style=3D"color:rgb(0,0,136)">true</span><span style=
=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0=
)">i</span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"co=
lor:rgb(0,0,136)">nullptr</span><span style=3D"color:rgb(102,102,0)">;}</sp=
an></font></div><div><font color=3D"#000088"><span style=3D"color:rgb(0,0,0=
)"> sptr</span><span style=3D"color:rgb(102,102,0)">&</span><span style=
=3D"color:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)"=
>=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">S </span><span style=
=3D"color:rgb(102,102,0)">*</span><span style=3D"color:rgb(0,0,136)">const<=
/span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102=
,102,0)">&</span><span style=3D"color:rgb(0,0,0)">i</span><span style=
=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0=
)"> release</span><span style=3D"color:rgb(102,102,0)">();</span><span styl=
e=3D"color:rgb(0,0,0)"> m_obj</span><span style=3D"color:rgb(102,102,0)">=
=3D</span><span style=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb=
(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> m_mine</span><span s=
tyle=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,136)">=
false</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">return</span><spa=
n style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">*=
</span><span style=3D"color:rgb(0,0,136)">this</span><span style=3D"color:r=
gb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">}</span></font></div><div><font color=3D"#000088"=
><span style=3D"color:rgb(0,0,0)"> sptr</span><span style=3D"color:rgb(102,=
102,0)">&</span><span style=3D"color:rgb(0,0,136)">operator</span><span=
style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)">=
</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,0)">S </span><span style=3D"color:rgb(102,102,0)">*&&</span>=
<span style=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0=
)">):</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:r=
gb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"> release</span><spa=
n style=3D"color:rgb(102,102,0)">();</span><span style=3D"color:rgb(0,0,0)"=
> m_obj</span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D=
"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style=3D"color:rgb(0,0,0)"> i</span><span style=3D"color:rgb(102,102,0)"=
>=3D</span><span style=3D"color:rgb(0,0,136)">nullptr</span><span style=3D"=
color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> m_mine</spa=
n><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0=
,0,136)">true</span><span style=3D"color:rgb(102,102,0)">;</span><span styl=
e=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">return</s=
pan><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,1=
02,0)">*</span><span style=3D"color:rgb(0,0,136)">this</span><span style=3D=
"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span><sp=
an style=3D"color:rgb(102,102,0)">}</span></font></div><div><span style=3D"=
color:rgb(0,0,0)"> </span></div><div><font color=3D"#000088"><span style=3D=
"color:rgb(0,0,0)">=C2=A0</span><span style=3D"color:rgb(136,0,0)">// other=
stuff, you get the gist</span></font></div><div><font color=3D"#000088"><s=
pan style=3D"color:rgb(136,0,0)"> ~sptr ( release(); ) </span></font></div>=
<div><font color=3D"#000088"><span style=3D"color:rgb(136,0,0)">};</span></=
font></div></div></code></div></font><div><font color=3D"#000088"></font>=
=C2=A0</div></div><div><font color=3D"#000088"></font><div><font color=3D"#=
000088">It's nice that I can now say</font></div></div><font color=3D"#=
000088"><div style=3D"border:1px solid rgb(187,187,187);background-color:rg=
b(250,250,250)"><code><div><span style=3D"color:rgb(0,0,0)">sptr</span><spa=
n style=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,0)=
">S</span><span style=3D"color:rgb(102,102,0)">></span><span style=3D"co=
lor:rgb(0,0,0)"> p_s </span><span style=3D"color:rgb(102,102,0)">(</span><s=
pan style=3D"color:rgb(0,0,136)">new</span><span style=3D"color:rgb(0,0,0)"=
> S</span><span style=3D"color:rgb(102,102,0)">);</span><div><span style=3D=
"color:rgb(0,0,0)"> </span></div></div></code></div><p>(because new produce=
s an xvalue)</p></font><p><font color=3D"#000088">but I can also say</font>=
</p><div><font color=3D"#000088"><div style=3D"border:1px solid rgb(187,187=
,187);background-color:rgb(250,250,250)"><code><div><span style=3D"color:rg=
b(0,0,0)">sptr</span><span style=3D"color:rgb(102,102,0)"><</span><span =
style=3D"color:rgb(0,0,0)">S</span><span style=3D"color:rgb(102,102,0)">>=
;</span><span style=3D"color:rgb(0,0,0)"> p_s</span><span style=3D"color:rg=
b(102,102,0)">;</span><div><span style=3D"color:rgb(0,0,0)">S s</span><span=
style=3D"color:rgb(102,102,0)">;</span></div><div><span style=3D"color:rgb=
(0,0,0)">p_s</span><span style=3D"color:rgb(102,102,0)">=3D&</span><spa=
n style=3D"color:rgb(0,0,0)">s</span><span style=3D"color:rgb(102,102,0)">;=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(13=
6,0,0)">// uh-oh</span></div><div><span style=3D"color:rgb(136,0,0)"> </spa=
n></div></div></code></div></font><div><font color=3D"#000088"></font>Becau=
se <font face=3D"courier new,monospace">&s</font> in the second example=
is a prvalue, it binds to the=C2=A0move-assignment operator, making <font =
face=3D"courier new,monospace">p_s.m_mine=3D=3Dtrue</font> and thus <font f=
ace=3D"courier new,monospace">sptr::release</font>=C2=A0will attempt to del=
ete an object it doesn't own.</div></div></div><span class=3D"HOEnZb"><=
font color=3D"#888888">
<p></p>
-- <br>
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr">how am I supposed to end =
the twisted road of=C2=A0 your hair in the dark night??<br>unless the candl=
e of your face does turn a lamp up on my way!!!<br></div></div>
</div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fa19a9ea574051010399e--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 27 Feb 2015 13:08:11 +0100
Raw View
2015-02-27 12:32 GMT+01:00 Farid Mehrabi <farid.mehrabi@gmail.com>:
> I personally don't like use of new as the initializer of smart pointers when
> its possible to forward constructor parameters:
>
> template<typename ...Args>
> sptr::sptr(Args&&...args):m_mine{true},m_obj{new
> S{std::forward<Args>(args)...}{};
>
> but again IMHO result of address operator should be const and so should the
> get member of smart pointers:
>
> const pointer std::unique_ptr::get();
>
> in contrast to:
>
> pointer std::unique_ptr::release();
It has never been part of the design goals of unique_ptr (or
shared_ptr) to propagate cv-qualifications of the wrapped pointer-like
thingee and accepting your proposal would break existing code. I
strongly suggest to introduce your own additional layering for these
purposes.
There currently exists a proposal to add such a library component
(albeit restricted to const qualifications) the standard library, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4372.html
- Daniel
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Fri, 27 Feb 2015 05:48:35 -0800 (PST)
Raw View
------=_Part_636_1746822300.1425044915805
Content-Type: multipart/alternative;
boundary="----=_Part_637_593457963.1425044915805"
------=_Part_637_593457963.1425044915805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, February 27, 2015 at 7:08:17 AM UTC-5, Daniel Kr=C3=BCgler wrote=
:
>
> 2015-02-27 12:32 GMT+01:00 Farid Mehrabi <farid....@gmail.com=20
> <javascript:>>:=20
>
> > but again IMHO result of address operator should be const and so should=
=20
> the=20
> > get member of smart pointers:=20
>
> It has never been part of the design goals of unique_ptr (or=20
> shared_ptr) to propagate cv-qualifications of the wrapped pointer-like=20
> thingee and accepting your proposal would break existing code.
>
To whose proposal are you responding?
I suppose I should not have used my custom shared pointer as an
example, because people are taking about that rather than the=20
address-of operator's unique behavior of exposing values
bound to objects that already exist. .
The upshot of my proposal is: No good (and much harm) comes from=20
automatically binding &x to an rvalue reference, so it shouldn't do that.=
=20
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_637_593457963.1425044915805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, February 27, 2015 at 7:08:17 AM UTC-5, =
Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;">2015-02-27 12:32 GMT=
+01:00 Farid Mehrabi <<a onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascri=
pt:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"SR_d9CZA19=
QJ">farid....@gmail.com</a>>:
<br><br>> but again IMHO result of address operator should be const and =
so should the
<br>> get member of smart pointers:
<br>
<br>It has never been part of the design goals of unique_ptr (or
<br>shared_ptr) to propagate cv-qualifications of the wrapped pointer-like
<br>thingee and accepting your proposal would break existing code.<br></blo=
ckquote><div><br></div><div>To whose proposal are you responding?</div><div=
><br></div><div>I suppose I should not have used my custom shared poin=
ter as an</div><div>example, because people are taking about that rath=
er than the </div><div>address-of operator's unique behavior of exposing va=
lues</div><div>bound to objects that already exist. .</div><div=
><br></div><div>The upshot of my proposal is: No good (and much harm) comes=
from </div><div>automatically binding &x to an rvalue reference, so it=
shouldn't do that. </div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_637_593457963.1425044915805--
------=_Part_636_1746822300.1425044915805--
.
Author: Jean-Marc Bourguet <jm.bourguet@gmail.com>
Date: Fri, 27 Feb 2015 07:50:49 -0800 (PST)
Raw View
------=_Part_777_21922457.1425052249445
Content-Type: multipart/alternative;
boundary="----=_Part_778_1231031162.1425052249445"
------=_Part_778_1231031162.1425052249445
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le jeudi 26 f=C3=A9vrier 2015 20:05:36 UTC+1, Spencer Simpson a =C3=A9crit =
:
>
> The address-of operator should produce an rvalue (in the C++11 sense)=20
> rather than a prvalue.=20
>
Prvalues are rvalues. xvalues are rvalues as well. I don't understand how=
=20
what you propose would
solve your problem. Whatever you do for & will be also valid for new.
Yours,
--=20
Jean-Marc
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_778_1231031162.1425052249445
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le jeudi 26 f=C3=A9vrier 2015 20:05:36 UTC+1, Spencer Simp=
son a =C3=A9crit :<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"><div><font color=3D"#000088">The address-of operator should produ=
ce an rvalue (in the C++11 sense) rather than a prvalue.&nb=
sp;</font></div></div></blockquote><div><br></div><div>Prvalues are rvalues=
.. xvalues are rvalues as well. I don't understand how what you propos=
e would<br></div><div>solve your problem. Whatever you do for & w=
ill be also valid for new.</div><div><br></div><div>Yours,</div><div><br></=
div><div>-- </div><div>Jean-Marc</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_778_1231031162.1425052249445--
------=_Part_777_21922457.1425052249445--
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Fri, 27 Feb 2015 08:28:11 -0800 (PST)
Raw View
------=_Part_835_1471289295.1425054491392
Content-Type: multipart/alternative;
boundary="----=_Part_836_1832469507.1425054491392"
------=_Part_836_1832469507.1425054491392
Content-Type: text/plain; charset=UTF-8
>
>
>> Prvalues are rvalues. xvalues are rvalues as well. I don't understand
> how what you propose would
> solve your problem. Whatever you do for & will be also valid for new.
>
prvalues bind to rvalue-references. Ordinary rvalues do not.
An xvalue (i.e. result of new) should always bind to an rvalue-rerefence.
Allowing &x to bind to an rvalue reference implies the pointer thus
produced has move semantics, but in actual practice those semantics are
never intended by that operator.
If & produced an ordinary rvalue rather than a prvalue, it wouldn't bind to
an rvalue reference; but new (producing an xvalue) still would.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_836_1832469507.1425054491392
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div dir=3D"ltr"><div><br></div></div></blockquote><div>Pr=
values are rvalues. xvalues are rvalues as well. I don't understand h=
ow what you propose would<br></div><div>solve your problem. Whatever =
you do for & will be also valid for new.</div></div></blockquote><div><=
br></div><div>prvalues bind to rvalue-references. Ordinary rvalues do not.&=
nbsp;</div><div><br></div><div>An xvalue (i.e. result of new) should always=
bind to an rvalue-rerefence.<br><br><div>Allowing &x to bind to an rva=
lue reference implies the pointer thus produced has move semantics, but in =
actual practice those semantics are never intended by that operat=
or.</div></div><div><br></div><div>If & produced an ordinary rvalue rat=
her than a prvalue, it wouldn't bind to an rvalue reference; but new (produ=
cing an xvalue) still would.</div><div><br></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_836_1832469507.1425054491392--
------=_Part_835_1471289295.1425054491392--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Fri, 27 Feb 2015 11:51:31 -0500
Raw View
On 02/27/2015 11:28 AM, Spencer Simpson wrote:
> If & produced an ordinary rvalue rather than a prvalue, it wouldn't bind
> to an rvalue reference; but new (producing an xvalue) still would.
The standard does not define an "ordinary rvalue". All expressions
produce either an lvalue, an xvalue, or a prvalue. The taxonomy and
text in C++11 3.10 [basic.lval] explain this.
Tom.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 27 Feb 2015 11:53:21 -0500
Raw View
On Feb 27, 2015, at 11:28 AM, Spencer Simpson <ssimpson@baltometro.org> wro=
te:
> If & produced an ordinary rvalue rather than a prvalue, it wouldn't bind =
to an rvalue reference; but new (producing an xvalue) still would.
I recommend reading section 3.10 of N4296:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
It contains statements such as:
> Every expression belongs to exactly one of the fundamental classification=
s in this taxonomy: lvalue, xvalue, or prvalue.
According to Figure 1 in this section, an rvalue is an xvalue or a prvalue.=
=E2=80=9COrdinary rvalue=E2=80=9D is not in our vocabulary.
A new expression is a prvalue. The expression resulting from calling std::a=
ddressof is also a prvalue. & applied to a lvalue scalar also produces a p=
rvalue.
> An xvalue (i.e. result of new) should always bind to an rvalue-rerefence.
The result of new is a prvalue.
> prvalues bind to rvalue-references. Ordinary rvalues do not.=20
I can not dispute this as the standard does not define the term "ordinary r=
value". However for the standard definition of rvalue expression, they ind=
eed will bind to cv-compatible rvalue references, whether the expression is=
an xvalue or prvalue.
This SO answer provides software you can run yourself to experimentally det=
ermine the value category of any expression:
http://stackoverflow.com/a/20721887/576911
Howard
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Fri, 27 Feb 2015 09:02:39 -0800 (PST)
Raw View
------=_Part_851_659900798.1425056559286
Content-Type: multipart/alternative;
boundary="----=_Part_852_1347158878.1425056559286"
------=_Part_852_1347158878.1425056559286
Content-Type: text/plain; charset=UTF-8
>
>
> > prvalues bind to rvalue-references. Ordinary rvalues do not.
>
> I can not dispute this as the standard does not define the term "ordinary
> rvalue".
Mea culpa: Too obsessed with differentiating copy semantics from move
semantics
An experiment with
void Foo (int const &);
versus
void Foo (int &&);
showed that Foo(3)always called the second routine.
It does beg the question, do rvalue references even mean anything for
scalars?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_852_1347158878.1425056559286
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br>> prvalues bind to rva=
lue-references. Ordinary rvalues do not.=20
<br>
<br>I can not dispute this as the standard does not define the term "ordina=
ry rvalue". </blockquote><div><br></div><div><div>Mea culpa: Too obse=
ssed with differentiating copy semantics from move semantics </div><div><br=
></div><div>An experiment with</div><div><div><br></div><p class=3D"prettyp=
rint" style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -m=
s-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"></code><div class=3D"subprettyprint"><code class=3D"pretty=
print"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">=
void</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);=
"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 10=
2);">Foo</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,=
0);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 1=
02, 0);">(</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, =
0, 136);">int</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(0=
, 0, 136);">const</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(102, 102, 0);">&);</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 0);"><br></span></code></div><p></p><p>versus</p><p><div =
class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); border=
-image: none; -ms-word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">void</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102);">Foo</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><spa=
n class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">(</span><=
span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">int</spa=
n><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&=
;&);</span></div></code></div><div><br>showed that <font face=3D"courie=
r new,monospace">Foo(3)<font face=3D"arial,sans-serif">always called the se=
cond routine.</font></font></div><div><br></div><div>It does beg the questi=
on, do rvalue references even mean anything for scalars?<br></div></div></d=
iv></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_852_1347158878.1425056559286--
------=_Part_851_659900798.1425056559286--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 27 Feb 2015 12:15:53 -0500
Raw View
On Feb 27, 2015, at 12:02 PM, Spencer Simpson <ssimpson@baltometro.org> wrote:
> It does beg the question, do rvalue references even mean anything for scalars?
Scalars will overload in the same way as all other object types, consistent with your experiment. What you do with those overloads is up to you. The sequence:
int i = 1;
int j = std::move(i);
will not modify the value of i, and will assign j the value 1.
Howard
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 27 Feb 2015 09:27:17 -0800 (PST)
Raw View
------=_Part_680_1723855823.1425058037768
Content-Type: multipart/alternative;
boundary="----=_Part_681_1142935484.1425058037768"
------=_Part_681_1142935484.1425058037768
Content-Type: text/plain; charset=UTF-8
On Friday, February 27, 2015 at 11:28:11 AM UTC-5, Spencer Simpson wrote:
>
>
>>> Prvalues are rvalues. xvalues are rvalues as well. I don't understand
>> how what you propose would
>> solve your problem. Whatever you do for & will be also valid for new.
>>
>
> prvalues bind to rvalue-references. Ordinary rvalues do not.
>
> An xvalue (i.e. result of new) should always bind to an rvalue-rerefence.
>
> Allowing &x to bind to an rvalue reference implies the pointer thus
> produced has move semantics, but in actual practice those semantics are
> never intended by that operator.
>
And to me this is the crux of the issue.
What you want to do is to define semantics around the concept of moving vs.
copying a pointer. If you take the address of something, you argue that the
semantic intent is to copy the pointer, that you're not trying to transfer
ownership of the pointer itself.
There are several problems here, syntactically. The first is that the
address of operator can be *overloaded* (unfortunately). Which means that
it's up to the overload to decide what to return. And this includes the
value category. So there's no way to enforce these semantics globally.
The second is that std::addressof (the only solution if you really want to
get the address of an object. Unfortunately) returns the object by value.
So it's an xvalue. Which means, under your desired semantics, this would
represent moving the object.
So implementing your semantics would require lots of changes. Some of which
may not be backwards-compatible.
And personally... I can't say I agree with these semantics to begin with.
Consider your code:
ptr_type<T> a = &b;
ptr_type<T> c = new T;
If I know nothing about ptr_type's implementation, my expectation is that
both of these do the same thing. I would not expect 'a' and 'c' to be
semantically any different. And therefore, if ptr_type is an owning smart
pointer, I would very much expect the first line to fail code review, since
it clearly says that you're sticking a pointer that can't be deleted into a
smart pointer that will try to delete it.
I prefer being explicit about movement myself. If I were to have a smart
pointer class that could be owning or non-owning, then I would want that
expression to be *explicit* when it adopts a pointer (or doesn't adopt it).
So at the very least, I would want to see something like this:
ptr_type<T> a = {&b, noadopt};
ptr_type<T> c = new T;
That way, it's immediately obvious what's going on. You don't need to know
rules about what's a prvalue/xvalue/rvalue. You can read the code and
understand what's going on. By default, the pointer is adopted, and if you
don't want adoption, you use a different constructor. The deleters for
shared_ptr and unique_ptr's are a great way to handle the unowning case.
Don't make the reader of your code have to know esoteric rules about value
categories.
> If & produced an ordinary rvalue rather than a prvalue, it wouldn't bind
> to an rvalue reference; but new (producing an xvalue) still would.
>
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_681_1142935484.1425058037768
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, February 27, 2015 at 11:28:11 AM UTC-5,=
Spencer Simpson 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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb=
(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"lt=
r"><div><br></div></div></blockquote><div>Prvalues are rvalues. xvalu=
es are rvalues as well. I don't understand how what you propose would<br></=
div><div>solve your problem. Whatever you do for & will be also v=
alid for new.</div></div></blockquote><div><br></div><div>prvalues bind to =
rvalue-references. Ordinary rvalues do not. </div><div><br></div><div>=
An xvalue (i.e. result of new) should always bind to an rvalue-rerefence.<b=
r><br><div>Allowing &x to bind to an rvalue reference implies the point=
er thus produced has move semantics, but in actual practice those semantics=
are never intended by that operator.</div></div></div></blockquo=
te><div><br>And to me this is the crux of the issue.<br><br>What you want t=
o do is to define semantics around the concept of moving vs. copying a poin=
ter. If you take the address of something, you argue that the semantic inte=
nt is to copy the pointer, that you're not trying to transfer ownership of =
the pointer itself.<br><br>There are several problems here, syntactically. =
The first is that the address of operator can be <i>overloaded</i> (unfortu=
nately). Which means that it's up to the overload to decide what to return.=
And this includes the value category. So there's no way to enforce these s=
emantics globally.<br><br>The second is that std::addressof (the only solut=
ion if you really want to get the address of an object. Unfortunately) retu=
rns the object by value. So it's an xvalue. Which means, under your desired=
semantics, this would represent moving the object.<br><br>So implementing =
your semantics would require lots of changes. Some of which may not be back=
wards-compatible.<br><br>And personally... I can't say I agree with these s=
emantics to begin with. Consider your code:<br><br>ptr_type<T> a =3D =
&b;<br>ptr_type<T> c =3D new T;<br><br>If I know nothing about pt=
r_type's implementation, my expectation is that both of these do the same t=
hing. I would not expect 'a' and 'c' to be semantically any different. And =
therefore, if ptr_type is an owning smart pointer, I would very much expect=
the first line to fail code review, since it clearly says that you're stic=
king a pointer that can't be deleted into a smart pointer that will try to =
delete it.<br><br>I prefer being explicit about movement myself. If I were =
to have a smart pointer class that could be owning or non-owning, then I wo=
uld want that expression to be <i>explicit</i> when it adopts a pointer (or=
doesn't adopt it). So at the very least, I would want to see something lik=
e this:<br><br>ptr_type<T> a =3D {&b, noadopt};<br>ptr_type<T&=
gt; c =3D new T;<br><br>That way, it's immediately obvious what's going on.=
You don't need to know rules about what's a prvalue/xvalue/rvalue. You can=
read the code and understand what's going on. By default, the pointer is a=
dopted, and if you don't want adoption, you use a different constructor. Th=
e deleters for shared_ptr and unique_ptr's are a great way to handle the un=
owning case.<br><br>Don't make the reader of your code have to know esoteri=
c rules about value categories.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>If & produced an or=
dinary rvalue rather than a prvalue, it wouldn't bind to an rvalue referenc=
e; but new (producing an xvalue) still would.</div><div><br></div></div></b=
lockquote></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_681_1142935484.1425058037768--
------=_Part_680_1723855823.1425058037768--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 27 Feb 2015 12:35:38 -0500
Raw View
--089e013d119af9ce050510154bf3
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 27, 2015 at 12:15 PM, Howard Hinnant <howard.hinnant@gmail.com>
wrote:
> On Feb 27, 2015, at 12:02 PM, Spencer Simpson <ssimpson@baltometro.org>
> wrote:
>
> > It does beg the question, do rvalue references even mean anything for
> scalars?
>
> Scalars will overload in the same way as all other object types,
> consistent with your experiment. What you do with those overloads is up to
> you. The sequence:
>
> int i = 1;
> int j = std::move(i);
>
> will not modify the value of i, and will assign j the value 1.
>
> Howard
>
> --
>
>
>
I do sometimes wonder if we should be able to better differentiate a
prvalue from an xvalue - it might help with the "destructive move" ie an
xvalue is never left hanging around - it really is going to be deleted, not
reused, like a prvalue (IIUC).
I also sometimes wonder if we have too many type modifiers already :-)
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e013d119af9ce050510154bf3
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 Fri, Feb 27, 2015 at 12:15 PM, Howard Hinnant <span dir=3D"ltr"><=
<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howard.hinnan=
t@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On Feb 27, 2015, at 12:02 PM, Spencer Simpson <<a href=3D"mail=
to:ssimpson@baltometro.org">ssimpson@baltometro.org</a>> wrote:<br>
<br>
> It does beg the question, do rvalue references even mean anything for =
scalars?<br>
<br>
</span>Scalars will overload in the same way as all other object types, con=
sistent with your experiment.=C2=A0 What you do with those overloads is up =
to you.=C2=A0 The sequence:<br>
<br>
int i =3D 1;<br>
int j =3D std::move(i);<br>
<br>
will not modify the value of i, and will assign j the value 1.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Howard<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br><br></div></div></blockquote><div><br></div><div>I do sometimes wonder =
if we should be able to better differentiate a prvalue from an xvalue - it =
might help with the "destructive move" ie an xvalue is never left=
hanging around - it really is going to be deleted, not reused, like a prva=
lue (IIUC).<br></div><div>I also sometimes wonder if we have too many type =
modifiers already :-)<br></div></div><br></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d119af9ce050510154bf3--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 27 Feb 2015 12:41:01 -0500
Raw View
--089e014939fc41e49f0510155f73
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 27, 2015 at 12:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Friday, February 27, 2015 at 11:28:11 AM UTC-5, Spencer Simpson wrote:
>>
>>
>>>> Prvalues are rvalues. xvalues are rvalues as well. I don't understand
>>> how what you propose would
>>> solve your problem. Whatever you do for & will be also valid for new.
>>>
>>
>> prvalues bind to rvalue-references. Ordinary rvalues do not.
>>
>> An xvalue (i.e. result of new) should always bind to an rvalue-rerefence.
>>
>> Allowing &x to bind to an rvalue reference implies the pointer thus
>> produced has move semantics, but in actual practice those semantics are
>> never intended by that operator.
>>
>
> And to me this is the crux of the issue.
>
> What you want to do is to define semantics around the concept of moving
> vs. copying a pointer. If you take the address of something, you argue that
> the semantic intent is to copy the pointer, that you're not trying to
> transfer ownership of the pointer itself.
>
> There are several problems here, syntactically. The first is that the
> address of operator can be *overloaded* (unfortunately). Which means that
> it's up to the overload to decide what to return. And this includes the
> value category. So there's no way to enforce these semantics globally.
>
> The second is that std::addressof (the only solution if you really want to
> get the address of an object. Unfortunately) returns the object by value.
> So it's an xvalue. Which means, under your desired semantics, this would
> represent moving the object.
>
> So implementing your semantics would require lots of changes. Some of
> which may not be backwards-compatible.
>
> And personally... I can't say I agree with these semantics to begin with.
> Consider your code:
>
> ptr_type<T> a = &b;
> ptr_type<T> c = new T;
>
>
If you could say that like:
ptr_type<T> a = &b;
ptr_type<T> c = std::move(new T);
it _might_ be more easily understood? And not require a specialized and
wordy mylib::noadopt.
> If I know nothing about ptr_type's implementation, my expectation is that
> both of these do the same thing. I would not expect 'a' and 'c' to be
> semantically any different. And therefore, if ptr_type is an owning smart
> pointer, I would very much expect the first line to fail code review, since
> it clearly says that you're sticking a pointer that can't be deleted into a
> smart pointer that will try to delete it.
>
> I prefer being explicit about movement myself. If I were to have a smart
> pointer class that could be owning or non-owning, then I would want that
> expression to be *explicit* when it adopts a pointer (or doesn't adopt
> it). So at the very least, I would want to see something like this:
>
> ptr_type<T> a = {&b, noadopt};
> ptr_type<T> c = new T;
>
> That way, it's immediately obvious what's going on. You don't need to know
> rules about what's a prvalue/xvalue/rvalue. You can read the code and
> understand what's going on. By default, the pointer is adopted, and if you
> don't want adoption, you use a different constructor. The deleters for
> shared_ptr and unique_ptr's are a great way to handle the unowning case.
>
> Don't make the reader of your code have to know esoteric rules about value
> categories.
>
>
>> If & produced an ordinary rvalue rather than a prvalue, it wouldn't bind
>> to an rvalue reference; but new (producing an xvalue) still would.
>>
>> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e014939fc41e49f0510155f73
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 Fri, Feb 27, 2015 at 12:27 PM, Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><sp=
an class=3D""><br><br>On Friday, February 27, 2015 at 11:28:11 AM UTC-5, Sp=
encer Simpson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>=
<br></div></div></blockquote><div>Prvalues are rvalues. =C2=A0xvalues are r=
values as well. I don't understand how what you propose would<br></div>=
<div>solve your problem.=C2=A0 Whatever you do for & will be also valid=
for new.</div></div></blockquote><div><br></div><div>prvalues bind to rval=
ue-references. Ordinary rvalues do not.=C2=A0</div><div><br></div><div>An x=
value (i.e. result of new) should always bind to an rvalue-rerefence.<br><b=
r><div>Allowing &x to bind to an rvalue reference implies the pointer t=
hus produced has move semantics, but in actual practice those semantics=C2=
=A0are never=C2=A0intended by that operator.</div></div></div></blockquote>=
</span><div><br>And to me this is the crux of the issue.<br><br>What you wa=
nt to do is to define semantics around the concept of moving vs. copying a =
pointer. If you take the address of something, you argue that the semantic =
intent is to copy the pointer, that you're not trying to transfer owner=
ship of the pointer itself.<br><br>There are several problems here, syntact=
ically. The first is that the address of operator can be <i>overloaded</i> =
(unfortunately). Which means that it's up to the overload to decide wha=
t to return. And this includes the value category. So there's no way to=
enforce these semantics globally.<br><br>The second is that std::addressof=
(the only solution if you really want to get the address of an object. Unf=
ortunately) returns the object by value. So it's an xvalue. Which means=
, under your desired semantics, this would represent moving the object.<br>=
<br>So implementing your semantics would require lots of changes. Some of w=
hich may not be backwards-compatible.<br><br>And personally... I can't =
say I agree with these semantics to begin with. Consider your code:<br><br>=
ptr_type<T> a =3D &b;<br>ptr_type<T> c =3D new T;<br><br></=
div></div></blockquote><div><br></div><div>If you could say that like:<br><=
br></div><div>ptr_type<T> a =3D &b;<br></div><div>ptr_type<T&g=
t; c =3D std::move(new T);<br><br></div><div>it _might_ be more easily unde=
rstood? And not require a specialized and wordy mylib::noadopt.<br><br>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If I know=
nothing about ptr_type's implementation, my expectation is that both o=
f these do the same thing. I would not expect 'a' and 'c' t=
o be semantically any different. And therefore, if ptr_type is an owning sm=
art pointer, I would very much expect the first line to fail code review, s=
ince it clearly says that you're sticking a pointer that can't be d=
eleted into a smart pointer that will try to delete it.<br><br>I prefer bei=
ng explicit about movement myself. If I were to have a smart pointer class =
that could be owning or non-owning, then I would want that expression to be=
<i>explicit</i> when it adopts a pointer (or doesn't adopt it). So at =
the very least, I would want to see something like this:<br><br>ptr_type<=
;T> a =3D {&b, noadopt};<br>ptr_type<T> c =3D new T;<br><br>Th=
at way, it's immediately obvious what's going on. You don't nee=
d to know rules about what's a prvalue/xvalue/rvalue. You can read the =
code and understand what's going on. By default, the pointer is adopted=
, and if you don't want adoption, you use a different constructor. The =
deleters for shared_ptr and unique_ptr's are a great way to handle the =
unowning case.<br><br>Don't make the reader of your code have to know e=
soteric rules about value categories.<br><br></div><span class=3D""><blockq=
uote 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><br></div><div>If &a=
mp; produced an ordinary rvalue rather than a prvalue, it wouldn't bind=
to an rvalue reference; but new (producing an xvalue) still would.</div><d=
iv><br></div></div></blockquote></span></div><div class=3D"HOEnZb"><div cla=
ss=3D"h5">
<p></p>
-- <br>
<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+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e014939fc41e49f0510155f73--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 27 Feb 2015 13:08:38 -0500
Raw View
--001a1147119004ac2e051015c249
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 27, 2015 at 12:41 PM, Tony V E <tvaneerd@gmail.com> wrote:
> If you could say that like:
>
> ptr_type<T> a = &b;
> ptr_type<T> c = std::move(new T);
>
> it _might_ be more easily understood? And not require a specialized and
> wordy mylib::noadopt.
>
> No, 'new T' is a prvalue expression, calling 'std::move' on it does not
change anything, new returns a *value* as the default address-of operator
does also yield a *value* (the address of an object). I am with Nicol
here, code is for the maintainer, not the compiler. Explicitly stating
whether ownership is being acquired is important enough to be spelled in
code (It is also one, if not the main, reason why 'shared_ptr' and
'unique_ptr' constructors taking raw pointers are explicit).
David
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1147119004ac2e051015c249
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Feb 27, 2015 at 12:41 PM, Tony V E <span dir=3D"ltr"><<a href=3D=
"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>If you could say that like=
:<br><br></div><span class=3D""><div>ptr_type<T> a =3D &b;<br></d=
iv></span><div>ptr_type<T> c =3D std::move(new T);<br><br></div><div>=
it _might_ be more easily understood? And not require a specialized and wor=
dy mylib::noadopt.<br><br></div></div></div></div></blockquote><div>No, =
9;new T' is a prvalue expression, calling 'std::move' on it doe=
s not change anything, new returns a *value* as the default address-of oper=
ator does also yield a *value* (the address of an object).=C2=A0 I am with =
Nicol here, code is for the maintainer, not the compiler. Explicitly statin=
g whether ownership is being acquired is important enough to be spelled in =
code (It is also one, if not the main, reason why 'shared_ptr' and =
'unique_ptr' constructors taking raw pointers are explicit).<br><br=
>=C2=A0 =C2=A0 David</div></div></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1147119004ac2e051015c249--
.
Author: Spencer Simpson <ssimpson@baltometro.org>
Date: Fri, 27 Feb 2015 10:12:53 -0800 (PST)
Raw View
------=_Part_568_358942602.1425060774020
Content-Type: multipart/alternative;
boundary="----=_Part_569_466747391.1425060774020"
------=_Part_569_466747391.1425060774020
Content-Type: text/plain; charset=UTF-8
>
>
> If I know nothing about ptr_type's implementation, my expectation is that
> both of these do the same thing.
>
If a class has both a copy constructor and a move constructor, that's part
of the interface, and not an implementation detail.
> I prefer being explicit about movement myself.
>
std::move should be explicit enough.
>
> Don't make the reader of your code have to know esoteric rules about value
> categories.
>
Which is exactly what I wanted the proposal to do, make it absolutely clear
what was copy and what was move, and not worry about weird cases, by
limiting the types of things that bind to rvalue references.
I'm done; thanks for everybody's patience.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_569_466747391.1425060774020
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>If =
I know nothing about ptr_type's implementation, my expectation is that both=
of these do the same thing.<br></div></div></blockquote><div><br></div><di=
v>If a class has both a copy constructor and a move constructor, that's par=
t of the interface, and not an implementation detail.</div><div> </div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr"><div>I prefer being explicit=
about movement myself. <br></div></div></blockquote><div><br></div><div>st=
d::move should be explicit enough.</div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div><br>Don't make the reader of your code ha=
ve to know esoteric rules about value categories.<br></div></div></blockquo=
te><div><br></div><div>Which is exactly what I wanted the proposal to do,&n=
bsp;make it absolutely clear what was copy and what was move, and not =
worry about weird cases, by limiting the types of things that bind to =
rvalue references.</div><div>I'm done; thanks for everybody's patience.</di=
v></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_569_466747391.1425060774020--
------=_Part_568_358942602.1425060774020--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 27 Feb 2015 10:45:47 -0800
Raw View
On Friday 27 February 2015 10:12:53 Spencer Simpson wrote:
> > Don't make the reader of your code have to know esoteric rules about
> > value
> > categories.
>
> Which is exactly what I wanted the proposal to do, make it absolutely clear
> what was copy and what was move, and not worry about weird cases, by
> limiting the types of things that bind to rvalue references.
> I'm done; thanks for everybody's patience.
It's pretty clear what is a copy and what is a move.
The problem is answering "what is a move for a scalar". Like Tony said:
int i = 1;
int j = std::move(i);
will "move" i to j.
The following is also a scalar move:
template <typename T> struct Container
{
T t;
// ...
Container &operator=(Container &&other)
{ using std::swap; swap(t, other.t); return *this; }
};
Container<int> i = { 1 };
Container<int> j;
j = std::move(i);
Just with a different behaviour.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Sat, 28 Feb 2015 21:07:29 +0330
Raw View
--001a1134046aa12eb305102971db
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-02-27 15:38 GMT+03:30 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
>
> It has never been part of the design goals of unique_ptr (or
> shared_ptr) to propagate cv-qualifications of the wrapped pointer-like
> thingee and accepting your proposal would break existing code. I
> strongly suggest to introduce your own additional layering for these
> purposes.
>
>
Kind of you to reply but it has not been my point too.
> There currently exists a proposal to add such a library component
> (albeit restricted to const qualifications) the standard library, see
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4372.html
>
Good link but my post wasn`t about cv propagation. The const specifier was
meant to affect the pointer itself,not the pointed to object. AFAIK const
rvalues can`t bind to none const rvalue references. Prior to the rvalue
reference proposal, traditionally we used to consider rvalues as const(sort
of). In my opinion the pointer returned by any operator or function that
refers to a solid pointer should be const so the pointer(not the pointed to
object) can not be moved from. IMHO the OP`s example shows a defect in
current standard due to the fact that most of us are not used to apply
const specifier on the return type of value returning functions. I propose
that the default signature of '&x' should be:
T pointed_cv * const T::operator&() pointed_cv ;
also:
T pointed_cv * const unique_ptr<T pointed_cv>::operator->();
and:
T pointed_cv * const std::unique_ptr<T pointed_cv>::get() const;
in contrast to:
T pointed_cv * std::unique_ptr<T pointed_cv>::release();
same discussion goes for 'shared_ptr' or any [smart] pointer type.
where "pointed_cv" refers to cv-qualification of pointed to object while
'const' is affecting the [smart] pointer.
Should I add the full 'template' declarations to disambiguate all the above=
?
I just re-downloaded http://www.stroustrup.com/terminology.pdf to remember
the insane meanings of "xpg"s. So where should the 'const rvalue' be placed
on the "W"-shaped diagram? Isn`t this an "IM"? what shall we call it? Still
there are IMHO large gaps between the language constructs and theoretical
terms.
By the way I am a const-o-phile. It ('const') is good to encourage
optimizations, good to prevent unintended modifications, ...
I have a hysteria of using const on return types by default, unless proved
to be more advantageous otherwise. So it just took me an instant to shoot
the upfront beast with my old favorite weapon. My proposal is now targeting
the solution towards OP`s suggested dilemma, without changing any existing
ABI; Nobody - I guess - has applied OP`s approach in production code but if
my humble response is accepted, Someone will. I have always felt sore about
using raw pointers for initializing smart pointers because of the points
observed in the OP`s approach. IMHO facilitating this approach might
improve code safety, by preventing a shared_ptr/unique_ptr/smart_ptr from
being accidentally initialized with '&x'.
regards,
FM
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1134046aa12eb305102971db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">2015-02-27 15:38 GMT+03:30 Daniel Kr=C3=BCgler <span d=
ir=3D"ltr"><<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blan=
k">daniel.kruegler@gmail.com</a>></span>:</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><b=
r>
</span>It has never been part of the design goals of unique_ptr (or<br>
shared_ptr) to propagate cv-qualifications of the wrapped pointer-like<br>
thingee and accepting your proposal would break existing code. I<br>
strongly suggest to introduce your own additional layering for these<br>
purposes.<br>
<br></blockquote><div style=3D"direction:ltr"><br></div><div dir=3D"ltr">Ki=
nd of you to reply but it has not been my point too.</div><div dir=3D"ltr">=
=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-s=
tyle:solid;padding-left:1ex">
There currently exists a proposal to add such a library component<br>
(albeit restricted to const qualifications) the standard library, see<br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4372.ht=
ml" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
15/n4372.html</a><br>=C2=A0</blockquote><div dir=3D"ltr">Good link but my p=
ost wasn`t about cv propagation. The const specifier was meant to affect th=
e pointer itself,not the pointed to object. AFAIK const rvalues can`t bind =
to none const rvalue references. Prior to the rvalue reference proposal, tr=
aditionally we used to consider rvalues as const(sort of). In my opinion th=
e pointer returned by any operator or function that refers to a solid point=
er should be const so the pointer(not the pointed to object) can not be mov=
ed from. IMHO the OP`s example shows a defect in current standard due to th=
e fact that most of us are not used to apply const specifier on the return =
type of value returning functions. I propose that the default signature of =
'&x' should be:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr=
">T pointed_cv * const T::operator&()=C2=A0pointed_cv=C2=A0;</div><div =
dir=3D"ltr"><br></div><div dir=3D"ltr">also:</div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr">T pointed_cv * const=C2=A0<span style=3D"font-size:14px"=
>unique_ptr</span><<span style=3D"font-size:14px">T=C2=A0</span>pointed_=
cv>::operator->();</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">a=
nd:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div dir=3D"rtl" style=
=3D"font-size:14px"><div dir=3D"ltr"><span style=3D"font-size:small">T poin=
ted_cv * const</span>=C2=A0std::unique_ptr<T=C2=A0<span style=3D"font-si=
ze:small">pointed_cv</span>>::get() const;</div><div dir=3D"ltr"><br></d=
iv><div dir=3D"ltr">in contrast to:</div><div dir=3D"ltr"><br></div><div di=
r=3D"ltr"><span style=3D"font-size:small">T pointed_cv *=C2=A0</span>std::u=
nique_ptr<T=C2=A0<span style=3D"font-size:small">pointed_cv</span>>::=
release();</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">same discussion=
goes for 'shared_ptr' or any [smart] =C2=A0pointer type.</div><div=
dir=3D"ltr"><br></div><div dir=3D"ltr"><span style=3D"font-size:small">whe=
re "pointed_cv" refers to cv-qualification of pointed to object w=
hile 'const' is affecting the [smart] pointer.</span><br></div><div=
dir=3D"ltr">Should I add the full 'template' declarations to disam=
biguate all the above?</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><di=
v dir=3D"ltr" style=3D"font-size:small">I just re-downloaded<font color=3D"=
#0000ff">=C2=A0<a href=3D"http://www.stroustrup.com/terminology.pdf">http:/=
/www.stroustrup.com/terminology.pdf</a></font>=C2=A0to remember the insane =
meanings of "xpg"s. So where should the 'const rvalue' be=
placed on the "W"-shaped diagram? Isn`t this an "IM"? =
what shall we call it? Still there are IMHO large gaps between the language=
constructs and theoretical terms.</div><div><br></div><div>By the way I am=
a const-o-phile. It ('const') is good to encourage optimizations, =
good to prevent unintended modifications, ...</div><div>I have a hysteria o=
f using const on return types by default, unless proved to be more advantag=
eous=C2=A0otherwise. So it just took me an instant to shoot the upfront bea=
st with my old favorite weapon. My proposal is now targeting the solution t=
owards OP`s suggested dilemma, without changing any existing ABI; Nobody - =
I guess - has applied OP`s approach in production code but if my humble res=
ponse is accepted, Someone will. I have always felt sore about using raw po=
inters for initializing smart pointers because of the points observed in th=
e OP`s approach. IMHO facilitating this approach might improve code safety,=
by preventing a shared_ptr/unique_ptr/smart_ptr from being accidentally in=
itialized with '&x'.=C2=A0</div><div><br></div></div><div dir=
=3D"ltr">regards,</div><div dir=3D"ltr">FM</div></div><div style=3D"font-si=
ze:14px"></div></div><div style=3D"direction:ltr">=C2=A0</div></div>
</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134046aa12eb305102971db--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sat, 28 Feb 2015 19:25:09 +0100
Raw View
2015-02-28 18:37 GMT+01:00 Farid Mehrabi <farid.mehrabi@gmail.com>:
>> There currently exists a proposal to add such a library component
>> (albeit restricted to const qualifications) the standard library, see
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4372.html
>>
>
> Good link but my post wasn`t about cv propagation.
OK, I misunderstood your suggestion, I (falsly) assumed that you had a
typo in your code when you suggested to add const to the returned
type.
> The const specifier was
> meant to affect the pointer itself,not the pointed to object.
Can you please elaborate why you the returned pointer value itself
should be const? Especially since C++11 with move semantics I haven't
seen good use-cases to return const prvalues. For non-class types this
const-qualification will be removed during expression analysis anyway.
For class-types it only prevents the move-semantics. Once I get the
value as a non-const value, I still can modify it.
> AFAIK const
> rvalues can`t bind to none const rvalue references.
You are mislead. The language requires that the following code is well-formed:
int const foo() { return 42; }
int&& ri = foo();
int main() {}
It will work for class-types. But for what reasons do you want this property?
> Prior to the rvalue
> reference proposal, traditionally we used to consider rvalues as const(sort
> of).
This code style is no longer recommended since C++11. I never have
considered the C++03 recommendation as useful in my own code bases.
>In my opinion the pointer returned by any operator or function that
> refers to a solid pointer should be const so the pointer(not the pointed to
> object) can not be moved from.
But why? Please provide some convincing examples where this is really helpful.
>IMHO the OP`s example shows a defect in
> current standard due to the fact that most of us are not used to apply const
> specifier on the return type of value returning functions.
Why should they? The const-qualifier-sequence of a function returning
a value is (in general) not related to a possible const-qualification
of the return value. To the contrary: const-qualifying the return
value of such a function prevents useful things and I see now real
advantage when it is applied.
> I propose that
> the default signature of '&x' should be:
>
> T pointed_cv * const T::operator&() pointed_cv ;
>
> also:
>
> T pointed_cv * const unique_ptr<T pointed_cv>::operator->();
>
> and:
>
> T pointed_cv * const std::unique_ptr<T pointed_cv>::get() const;
>
> in contrast to:
>
> T pointed_cv * std::unique_ptr<T pointed_cv>::release();
>
> same discussion goes for 'shared_ptr' or any [smart] pointer type.
I'm strongly opposed to those changes, especially since I'm not seeing
any advantage for these additional signatures. const-qualifying
functions makes sense to propagate const, such as I quoted in my
previous response, but in your example there is no real usefulness for
this.
>
> where "pointed_cv" refers to cv-qualification of pointed to object while
> 'const' is affecting the [smart] pointer.
> Should I add the full 'template' declarations to disambiguate all the above?
>
> I just re-downloaded http://www.stroustrup.com/terminology.pdf to remember
> the insane meanings of "xpg"s.
What precisely are you meaning by xpg? Assuming you meant xvalues,
prvalues, and glvalues: Why should these meanings be insane?
> So where should the 'const rvalue' be placed
> on the "W"-shaped diagram? Isn`t this an "IM"? what shall we call it?
Why should a const prvalue something different than a prvalue?
> Still
> there are IMHO large gaps between the language constructs and theoretical
> terms.
Sorry, I fail to see these gaps in regard to value categories.
> By the way I am a const-o-phile. It ('const') is good to encourage
> optimizations, good to prevent unintended modifications, ...
Well, const has some good reasons, but it seems to me that your
suggestion does not belong to one of those.
> I have a hysteria of using const on return types by default, unless proved
> to be more advantageous otherwise. So it just took me an instant to shoot
> the upfront beast with my old favorite weapon. My proposal is now targeting
> the solution towards OP`s suggested dilemma, without changing any existing
> ABI; Nobody - I guess - has applied OP`s approach in production code but if
> my humble response is accepted, Someone will. I have always felt sore about
> using raw pointers for initializing smart pointers because of the points
> observed in the OP`s approach. IMHO facilitating this approach might improve
> code safety, by preventing a shared_ptr/unique_ptr/smart_ptr from being
> accidentally initialized with '&x'.
I fail to see what kind of "code-safety" your suggestions would bring
to the C++ community.
- Daniel
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 28 Feb 2015 10:29:37 -0800 (PST)
Raw View
------=_Part_1862_552999015.1425148177813
Content-Type: multipart/alternative;
boundary="----=_Part_1863_2092704536.1425148177813"
------=_Part_1863_2092704536.1425148177813
Content-Type: text/plain; charset=UTF-8
On Friday, February 27, 2015 at 1:12:54 PM UTC-5, Spencer Simpson wrote:
>
>
>> If I know nothing about ptr_type's implementation, my expectation is that
>> both of these do the same thing.
>>
>
> If a class has both a copy constructor and a move constructor, that's part
> of the interface, and not an implementation detail.
>
>
>> I prefer being explicit about movement myself.
>>
>
> std::move should be explicit enough.
>
>
>>
>> Don't make the reader of your code have to know esoteric rules about
>> value categories.
>>
>
> Which is exactly what I wanted the proposal to do, make it absolutely
> clear what was copy and what was move, and not worry about weird cases, by
> limiting the types of things that bind to rvalue references.
>
Except that it isn't "absolutely clear".
shared_ptr<T> t = new T;
That isn't a move. Or at least, not how that concept is generally taught.
It seems like a transfer of ownership, but it isn't *technically* doing so.
Nothing owned the pointer to begin with, so you're *creating* ownership
(via construction), rather than transferring it.
By contrast:
shared_ptr<T> t = std::move(some_unique_ptr);
*This* is a logical transfer of ownership. The unique_ptr owned it, and the
ownership is moved into the shared_ptr.
What understanding your code requires is an understanding of the language
differences between a pointer generated by `&X` and a pointer generated by
`new T`. Those are the esoteric differences I was talking about.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1863_2092704536.1425148177813
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, February 27, 2015 at 1:12:54 PM UTC-5, =
Spencer Simpson 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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"><div><br>If I know nothing about=
ptr_type's implementation, my expectation is that both of these do the sam=
e thing.<br></div></div></blockquote><div><br></div><div>If a class has bot=
h a copy constructor and a move constructor, that's part of the interface, =
and not an implementation detail.</div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr"><div>I prefer being explicit about movement myself. <br></=
div></div></blockquote><div><br></div><div>std::move should be explicit eno=
ugh.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><br>Don't=
make the reader of your code have to know esoteric rules about value categ=
ories.<br></div></div></blockquote><div><br></div><div>Which is exactly wha=
t I wanted the proposal to do, make it absolutely clear what was copy&=
nbsp;and what was move, and not worry about weird cases, by limiting the ty=
pes of things that bind to rvalue references.</div></div></blockquote>=
<div><br>Except that it isn't "absolutely clear".<br><br>shared_ptr<T>=
; t =3D new T;<br><br>That isn't a move. Or at least, not how that concept =
is generally taught. It seems like a transfer of ownership, but it isn't <i=
>technically</i> doing so. Nothing owned the pointer to begin with, so you'=
re <i>creating</i> ownership (via construction), rather than transferring i=
t.<br><br>By contrast:<br><br>shared_ptr<T> t =3D std::move(some_uniq=
ue_ptr);<br><br><i>This</i> is a logical transfer of ownership. The unique_=
ptr owned it, and the ownership is moved into the shared_ptr.<br><br>What u=
nderstanding your code requires is an understanding of the language differe=
nces between a pointer generated by `&X` and a pointer generated by `ne=
w T`. Those are the esoteric differences I was talking about.<br></div></di=
v>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1863_2092704536.1425148177813--
------=_Part_1862_552999015.1425148177813--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sun, 1 Mar 2015 01:06:09 +0100
Raw View
--001a1139ba94cd810c05102ee040
Content-Type: text/plain; charset=UTF-8
On 28 February 2015 at 18:37, Farid Mehrabi <farid.mehrabi@gmail.com> wrote:
> By the way I am a const-o-phile. It ('const') is good to encourage
> optimizations,
>
Does it? I've not found it to help optimizations all that much. Could you
post a few examples in something like GCC Explorer <http://gcc.godbolt.org>
where the mere addition of a "const" both didn't change semantics and
helped optimization? Benchmarks as well for that code would be even better
(as it isn't known to be an optimization w/o measurements).
> IMHO facilitating this approach might improve code safety, by preventing a
> shared_ptr/unique_ptr/smart_ptr from being accidentally initialized with
> '&x'.
>
I've never seen this done accidentally. I have seen brand new beginners to
the language do this deliberately because they didn't understand smart
pointers, but education about ownership and lifetime proved far more
valuable. Certainly better than adding a new obscure corner to the
language that would be all but unteachable to anyone but an expert.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1139ba94cd810c05102ee040
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 28 February 2015 at 18:37, F=
arid Mehrabi <span dir=3D"ltr"><<a href=3D"mailto:farid.mehrabi@gmail.co=
m" target=3D"_blank">farid.mehrabi@gmail.com</a>></span> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>By the way I am a=
const-o-phile. It ('const') is good to encourage optimizations,</d=
iv></blockquote><div><br></div><div>Does it?=C2=A0 I've not found it to=
help optimizations all that much.=C2=A0 Could you post a few examples in s=
omething like GCC Explorer <<a href=3D"http://gcc.godbolt.org">http://gc=
c.godbolt.org</a>> where the mere addition of a "const" both d=
idn't change semantics and helped optimization?=C2=A0 Benchmarks as wel=
l for that code would be even better (as it isn't known to be an optimi=
zation w/o measurements).</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div>IMHO facilitating this approach might improve code safety, by prev=
enting a shared_ptr/unique_ptr/smart_ptr from being accidentally initialize=
d with '&x'.=C2=A0<br></div><div></div></blockquote></div><br>I=
've never seen this done accidentally.=C2=A0 I have seen brand new begi=
nners to the language do this deliberately because they didn't understa=
nd smart pointers, but education about ownership and lifetime proved far mo=
re valuable.=C2=A0 Certainly better than adding a new obscure corner to the=
language that would be all but unteachable to anyone but an expert.<br>-- =
<br><div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 =
<mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevi=
n@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1139ba94cd810c05102ee040--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 2 Mar 2015 00:08:14 -0800 (PST)
Raw View
------=_Part_2500_1796242829.1425283694830
Content-Type: multipart/alternative;
boundary="----=_Part_2501_128117477.1425283694831"
------=_Part_2501_128117477.1425283694831
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, February 28, 2015 at 4:06:51 PM UTC-8, Nevin ":-)" Liber wrote=
:
>
> On 28 February 2015 at 18:37, Farid Mehrabi <farid....@gmail.com=20
> <javascript:>> wrote:
>
>> =20
>>
> IMHO facilitating this approach might improve code safety, by preventing =
a=20
>> shared_ptr/unique_ptr/smart_ptr from being accidentally initialized with=
=20
>> '&x'.=20
>>
>
> I've never seen this done accidentally. I have seen brand new beginners=
=20
> to the language do this deliberately because they didn't understand smart=
=20
> pointers, but education about ownership and lifetime proved far more=20
> valuable.
>
I think it's time to come out and say openly that Farid and Spencer are=20
suffering from a misconception of what "ownership" means in this context,=
=20
and from a confusion between "pointer object" and "pointed-to object".=20
Going all the way back to Spencer's original post:
> cppreference.com says
> *A prvalue ("pure" rvalue) is an expression that identifies a temporary=
=20
object (or a subobject thereof) or is a value not associated with any=20
object.*
> but you can say that that the result of address-of is associated (in a=20
loose sense) with an object -- the object it just took the address of.
**You** could say that, but C++ doesn't. The value (or temporary object)=20
identified by &x (that is, a pointer with value 0x0000000028947304) is not=
=20
associated with any other object; it is certainly not associated with x (an=
=20
int object with value 5).
Similarly, the value (or temporary object) identified by -x (that is, an=20
int with value -5) is not associated with x (an int object with value 5),=
=20
even though *"you could say that the result of unary-minus is associated=20
(in a loose sense) with an object =E2=80=94 the object it just negated."*
Your idea that operator& should return a const-qualified object is a bad=20
idea. It should (and does) return a *pointer*, which is conceptually the=20
same kind of thing as a shared_ptr or your sptr. In fact, there's a=20
proposal out already=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf> (N4282)=
=20
to introduce observer_ptr<T>, "the world's dumbest smart pointer", which=20
has the same ownership guarantees as good old T*. Consider the following=20
function signature:
observer_ptr<T> take_address(T& t) { return make_observer(&t); }
int main() {
int i =3D 42;
observer_ptr<int> obs;
obs =3D take_address(i); // does this move-assign or copy-assign?
}
You (Spencer and Farid) should read up on move semantics until you have=20
convinced yourself that it would be a Very Bad Idea to replace the=20
preceding code with
const observer_ptr<T> take_address(T& t) { return make_observer(&t); }
Now that you're convinced, let's substitute operator& for take_address and=
=20
T* for observer_ptr<T>. You have now convinced yourself that
T* const operator&(T& t) { ... }
is the wrong signature for operator&. Excellent! Our work here is done.
HTH,
Arthur
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2501_128117477.1425283694831
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, February 28, 2015 at 4:06:51 PM UTC-8, Nevin =
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On 28 February 2015 at 18:37, Farid Mehrabi <span dir=3D"ltr"><<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"KplkIMKjpQcJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">farid....@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"> <br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>IMHO facilita=
ting this approach might improve code safety, by preventing a shared_ptr/un=
ique_ptr/smart_<wbr>ptr from being accidentally initialized with '&x'.&=
nbsp;<br></div><div></div></blockquote></div><br>I've never seen this done =
accidentally. I have seen brand new beginners to the language do this=
deliberately because they didn't understand smart pointers, but education =
about ownership and lifetime proved far more valuable.</div></blockquote><d=
iv><br></div><div>I think it's time to come out and say openly that Farid a=
nd Spencer are suffering from a misconception of what "ownership" means in =
this context, and from a confusion between "pointer object" and "pointed-to=
object". Going all the way back to Spencer's original post:</div><div><br>=
</div><div>> <a href=3D"http://cppreference.com" target=3D"_blank" =
rel=3D"nofollow" style=3D"cursor: pointer;">cppreference.com</a><span style=
=3D"color: rgb(0, 0, 136);"> </span><span style=3D"color: rgb(0, 0, 13=
6);">says</span></div><div><div><font color=3D"#000088"></font><div><font c=
olor=3D"#000088"></font>> <em style=3D"color: rgb(0, 0, 136);">A pr=
value ("pure" rvalue) is an expression that identifies a temporary object (=
or a subobject thereof) or is a value not associated with any object.</em><=
/div></div><font color=3D"#000088"></font><div><font color=3D"#000088"></fo=
nt>> <span style=3D"color: rgb(0, 0, 136);">but you can say that th=
at the result of address-of is associated (in a loose sense) with an object=
-- the object it just took the address of.</span></div></div><div><br></di=
v><div><i>*You*</i> could say that, but C++ doesn't. The value (or temporar=
y object) identified by <font face=3D"courier new, monospace">&x</font>=
(that is, a pointer with value <font face=3D"courier new, monospace">0x000=
0000028947304</font>) is not associated with any other object; it is certai=
nly not associated with <font face=3D"courier new, monospace">x</font> (an =
int object with value <font face=3D"courier new, monospace">5</font>).</div=
><div>Similarly, the value (or temporary object) identified by <font face=
=3D"courier new, monospace">-x</font> (that is, an int with value <fon=
t face=3D"courier new, monospace">-5</font>) is not associated with <font f=
ace=3D"courier new, monospace">x</font> (an int object with value <font fac=
e=3D"courier new, monospace">5</font>), even though <i>"you could say that =
the result of<font face=3D"arial, sans-serif"> unary-minus</font> is a=
ssociated (in a loose sense) with an object =E2=80=94 the object it just ne=
gated."</i></div><div><br></div><div>Your idea that <font face=3D"courier n=
ew, monospace">operator&</font> should return a const-qualified object =
is a bad idea. It should (and does) return a <i><b>pointer</b></i>, which i=
s conceptually the same kind of thing as a <font face=3D"courier new, monos=
pace">shared_ptr</font> or your <font face=3D"courier new, monospace">sptr<=
/font>. In fact, <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2014/n4282.pdf">there's a proposal out already</a> (N4282) to intr=
oduce <font face=3D"courier new, monospace">observer_ptr<T></font>, "=
the world's dumbest smart pointer", which has the same ownership guarantees=
as good old <font face=3D"courier new, monospace">T*</font>. Consider=
the following function signature:</div><div><br></div><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> observer_ptr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> t</span><font color=3D"#000088"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">ake_address</span></font><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> t</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: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> make_observer</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(&</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </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><br> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">42</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> observer_ptr</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify"><int></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> obs</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> =
obs </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> take_addres=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color:=
#800;" class=3D"styled-by-prettify">// does this move-assign or copy-assig=
n?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><div><br></div><div>You (Spencer and Farid) should rea=
d up on move semantics until you have convinced yourself that it would be a=
Very Bad Idea to replace the preceding code with<br></div><div><br></div><=
div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> observer_ptr</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> t</span><font color=3D"#000088"><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">ake_address</span></font><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><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: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> make_observer</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(&</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">t</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"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span></div></code></div></div><div><br></div><div>Now that you'=
re convinced, let's substitute <font face=3D"courier new, monospace">operat=
or&</font> for <font face=3D"courier new, monospace">take_address</font=
> and <font face=3D"courier new, monospace">T*</font> for <font face=3D"cou=
rier new, monospace">observer_ptr<T></font>. You have now convinced y=
ourself that</div><br><div class=3D"prettyprint" style=3D"background-color:=
rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> T</span><spa=
n 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=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an 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"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><div><br></div><div>is the wro=
ng signature for <font face=3D"courier new, monospace">operator&</font>=
.. Excellent! Our work here is done.</div><div><br></div><div>HTH,</div><div=
>Arthur</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2501_128117477.1425283694831--
------=_Part_2500_1796242829.1425283694830--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 02 Mar 2015 13:13:58 -0500
Raw View
On 2015-02-28 12:37, Farid Mehrabi wrote:
> I propose that the default signature of '&x' should be:
>
> T pointed_cv * const T::operator&() pointed_cv ;
No. In fact, don't even write code like that (ever); the 'const' there
is useless and at least GCC ignores it entirely, and can warn you that
it is doing so (see -Wignored-qualifiers). Actually, "useless" is not
strong enough; it's *actively harmful* as it gives an impression of
const-ness that does not exist.
(I've seen one library, though I forget which offhand, that had a
horribly broken API due to this misunderstanding.)
> By the way I am a const-o-phile.
Me too :-). But never in the above case; in fact I routinely build with
-Werror=ignored-qualifiers.
p.s. Don't declare by-value parameters 'const' (in a declaration) for
the same reason :-). (In a definition it's okay and even good, as it
actually means something in that case... though I admit that I rarely do
that...)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Tue, 3 Mar 2015 23:30:30 +0330
Raw View
--001a1135a514b4dbd2051067ca74
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com>:
> 2015-02-28 18:37 GMT+01:00 Farid Mehrabi <farid.mehrabi@gmail.com>:
> >> There currently exists a proposal to add such a library component
> >> (albeit restricted to const qualifications) the standard library, see
> >>
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4372.html
> >>
> >
> > Good link but my post wasn`t about cv propagation.
>
> OK, I misunderstood your suggestion, I (falsly) assumed that you had a
> typo in your code when you suggested to add const to the returned
> type.
>
> > The const specifier was
> > meant to affect the pointer itself,not the pointed to object.
>
> Can you please elaborate why you the returned pointer value itself
> should be const? Especially since C++11 with move semantics I haven't
> seen good use-cases to return const prvalues. For non-class types this
> const-qualification will be removed during expression analysis anyway.
> For class-types it only prevents the move-semantics. Once I get the
> value as a non-const value, I still can modify it.
>
> > AFAIK const
> > rvalues can`t bind to none const rvalue references.
>
> You are mislead. The language requires that the following code is
> well-formed:
>
> int const foo() { return 42; }
>
> int&& ri =3D foo();
>
> int main() {}
>
> It will work for class-types. But for what reasons do you want this
> property?
>
>
It is but why should it be well-formed?
> > Prior to the rvalue
> > reference proposal, traditionally we used to consider rvalues as
> const(sort
> > of).
>
> This code style is no longer recommended since C++11. I never have
> considered the C++03 recommendation as useful in my own code bases.
>
> >In my opinion the pointer returned by any operator or function that
> > refers to a solid pointer should be const so the pointer(not the pointe=
d
> to
> > object) can not be moved from.
>
> But why? Please provide some convincing examples where this is really
> helpful.
>
> >IMHO the OP`s example shows a defect in
> > current standard due to the fact that most of us are not used to apply
> const
> > specifier on the return type of value returning functions.
>
> Why should they? The const-qualifier-sequence of a function returning
> a value is (in general) not related to a possible const-qualification
> of the return value. To the contrary: const-qualifying the return
> value of such a function prevents useful things and I see now real
> advantage when it is applied.
>
> > I propose that
> > the default signature of '&x' should be:
> >
> > T pointed_cv * const T::operator&() pointed_cv ;
> >
> > also:
> >
> > T pointed_cv * const unique_ptr<T pointed_cv>::operator->();
> >
> > and:
> >
> > T pointed_cv * const std::unique_ptr<T pointed_cv>::get() const;
> >
> > in contrast to:
> >
> > T pointed_cv * std::unique_ptr<T pointed_cv>::release();
> >
> > same discussion goes for 'shared_ptr' or any [smart] pointer type.
>
> I'm strongly opposed to those changes, especially since I'm not seeing
> any advantage for these additional signatures. const-qualifying
> functions makes sense to propagate const, such as I quoted in my
> previous response, but in your example there is no real usefulness for
> this.
>
I t was based on wrong assumptions, but let`s pretend that your example is
ill-formed: now the difference between const and mutable pointer rvalues
can be used to distinguish owned and orphaned pointers.
> >
> > where "pointed_cv" refers to cv-qualification of pointed to object whil=
e
> > 'const' is affecting the [smart] pointer.
> > Should I add the full 'template' declarations to disambiguate all the
> above?
> >
> > I just re-downloaded http://www.stroustrup.com/terminology.pdf to
> remember
> > the insane meanings of "xpg"s.
>
> What precisely are you meaning by xpg? Assuming you meant xvalues,
> prvalues, and glvalues: Why should these meanings be insane?
>
> > So where should the 'const rvalue' be placed
> > on the "W"-shaped diagram? Isn`t this an "IM"? what shall we call it?
>
> Why should a const prvalue something different than a prvalue?
>
>
the 'const' qualifier is supposed to prevent modifications - including
moving from - the rvalue that is already lacking identity. By striping it
of its mobility, it falls completely out of the diagram.
> Still
> > there are IMHO large gaps between the language constructs and theoretic=
al
> > terms.
>
> Sorry, I fail to see these gaps in regard to value categories.
>
>
Although currently built-in type 'const rvalues' are treated as prvalues,
class types seem to be not: They are still 'IM'.
> > By the way I am a const-o-phile. It ('const') is good to encourage
> > optimizations, good to prevent unintended modifications, ...
>
> Well, const has some good reasons, but it seems to me that your
> suggestion does not belong to one of those.
>
> I fail to see what kind of "code-safety" your suggestions would bring
> to the C++ community.
>
> - Daniel
>
distinction between mobile and immobile pointers can be one reason.
regards,
FM.
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does sheds some light up on my way!!!
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1135a514b4dbd2051067ca74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler <span d=
ir=3D"ltr"><<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blan=
k">daniel.kruegler@gmail.com</a>></span>:</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span cl=
ass=3D"">2015-02-28 18:37 GMT+01:00 Farid Mehrabi <<a href=3D"mailto:far=
id.mehrabi@gmail.com">farid.mehrabi@gmail.com</a>>:<br>
>> There currently exists a proposal to add such a library component<=
br>
>> (albeit restricted to const qualifications) the standard library, =
see<br>
>><br>
>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015=
/n4372.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2015/n4372.html</a><br>
>><br>
><br>
> Good link but my post wasn`t about cv propagation.<br>
<br>
</span>OK, I misunderstood your suggestion, I (falsly) assumed that you had=
a<br>
typo in your code when you suggested to add const to the returned<br>
type.<br>
<span class=3D""><br>
> The const specifier was<br>
> meant to affect the pointer itself,not the pointed to object.<br>
<br>
</span>Can you please elaborate why you the returned pointer value itself<b=
r>
should be const? Especially since C++11 with move semantics I haven't<b=
r>
seen good use-cases to return const prvalues. For non-class types this<br>
const-qualification will be removed during expression analysis anyway.<br>
For class-types it only prevents the move-semantics. Once I get the<br>
value as a non-const value, I still can modify it.<br>
<span class=3D""><br>
> AFAIK const<br>
> rvalues can`t bind to none const rvalue references.<br>
<br>
</span>You are mislead. The language requires that the following code is we=
ll-formed:<br>
<br>
int const foo() { return 42; }<br>
<br>
int&& ri =3D foo();<br>
<br>
int main() {}<br>
<br>
It will work for class-types. But for what reasons do you want this propert=
y?<br>
<span class=3D""><br></span></blockquote><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">It is but why should it be well-formed?</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><span class=3D"">
> Prior to the rvalue<br>
> reference proposal, traditionally we used to consider rvalues as const=
(sort<br>
> of).<br>
<br>
</span>This code style is no longer recommended since C++11. I never have<b=
r>
considered the C++03 recommendation as useful in my own code bases.<br>
<span class=3D""><br>
>In my opinion the pointer returned by any operator or function that<br>
> refers to a solid pointer should be const so the pointer(not the point=
ed to<br>
> object) can not be moved from.<br>
<br>
</span>But why? Please provide some convincing examples where this is reall=
y helpful.<br>
<span class=3D""><br>
>IMHO the OP`s example shows a defect in<br>
> current standard due to the fact that most of us are not used to apply=
const<br>
> specifier on the return type of value returning functions.<br>
<br>
</span>Why should they? The const-qualifier-sequence of a function returnin=
g<br>
a value is (in general) not related to a possible const-qualification<br>
of the return value. To the contrary: const-qualifying the return<br>
value of such a function prevents useful things and I see now real<br>
advantage when it is applied.<br>
<span class=3D""><br>
> I propose that<br>
> the default signature of '&x' should be:<br>
><br>
> T pointed_cv * const T::operator&() pointed_cv ;<br>
><br>
> also:<br>
><br>
> T pointed_cv * const unique_ptr<T pointed_cv>::operator->();<=
br>
><br>
> and:<br>
><br>
> T pointed_cv * const std::unique_ptr<T pointed_cv>::get() const;=
<br>
><br>
> in contrast to:<br>
><br>
> T pointed_cv * std::unique_ptr<T pointed_cv>::release();<br>
><br>
> same discussion goes for 'shared_ptr' or any [smart]=C2=A0 poi=
nter type.<br>
<br>
</span>I'm strongly opposed to those changes, especially since I'm =
not seeing<br>
any advantage for these additional signatures. const-qualifying<br>
functions makes sense to propagate const, such as I quoted in my<br>
previous response, but in your example there is no real usefulness for<br>
this.<br></blockquote><div><br></div><div dir=3D"ltr">I t was based on wron=
g assumptions, but let`s pretend that your example is ill-formed: now the d=
ifference between const and mutable pointer rvalues can be used to distingu=
ish owned and orphaned pointers.</div><div style=3D"direction:ltr">=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">
<span class=3D"">><br>
> where "pointed_cv" refers to cv-qualification of pointed to =
object while<br>
> 'const' is affecting the [smart] pointer.<br>
> Should I add the full 'template' declarations to disambiguate =
all the above?<br>
><br>
> I just re-downloaded <a href=3D"http://www.stroustrup.com/terminology.=
pdf" target=3D"_blank">http://www.stroustrup.com/terminology.pdf</a> to rem=
ember<br>
> the insane meanings of "xpg"s.<br>
<br>
</span>What precisely are you meaning by xpg? Assuming you meant xvalues,<b=
r>
prvalues, and glvalues: Why should these meanings be insane?<br>
<span class=3D""><br>
> So where should the 'const rvalue' be placed<br>
> on the "W"-shaped diagram? Isn`t this an "IM"? wha=
t shall we call it?<br>
<br>
</span>Why should a const prvalue something different than a prvalue?<br>
<span class=3D""><br></span></blockquote><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">the 'const' qualifier is supposed to prevent modification=
s - including moving from - the rvalue that is already lacking identity. By=
striping it of its mobility, it falls completely out of the diagram.=C2=A0=
</div><div dir=3D"ltr"><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><span class=3D"">
> Still<br>
> there are IMHO large gaps between the language constructs and theoreti=
cal<br>
> terms.<br>
<br>
</span>Sorry, I fail to see these gaps in regard to value categories.<br>
<span class=3D""><br></span></blockquote><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">Although currently built-in type 'const rvalues' are trea=
ted as prvalues, class types seem to be not: They are still 'IM'.</=
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);bord=
er-left-style:solid;padding-left:1ex"><span class=3D"">
> By the way I am a const-o-phile. It ('const') is good to encou=
rage<br>
> optimizations, good to prevent unintended modifications, ...<br>
<br>
</span>Well, const has some good reasons, but it seems to me that your<br>
suggestion does not belong to one of those.<br>
<span class=3D""><br></span>I fail to see what kind of "code-safety&qu=
ot; your suggestions would bring<br>
to the C++ community.<br>
<div class=3D""><div class=3D"h5"><br>
- Daniel<br></div></div></blockquote><div style=3D"direction:ltr"><br></div=
><div dir=3D"ltr">distinction between mobile and immobile pointers can be o=
ne reason.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">regards,</div><=
div dir=3D"ltr">FM.=C2=A0</div><div style=3D"direction:ltr">=C2=A0</div></d=
iv>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr">how am I supposed=
to end the twisted road of=C2=A0 your hair in the dark night??<br>unless t=
he candle of your face does sheds some light up on my way!!!<br></div></div=
>
</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135a514b4dbd2051067ca74--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 03 Mar 2015 15:31:51 -0500
Raw View
On 2015-03-03 15:00, Farid Mehrabi wrote:
> 2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler wrote:
>> You are mislead. The language requires that the following code is
>> well-formed:
>>
>> int const foo() { return 42; }
>>
>> int&& ri =3D foo();
>>
>> int main() {}
>>
>> It will work for class-types. But for what reasons do you want this
>> property?
>
> It is but why should it be well-formed?
....because the 'const' is meaningless in that context. The above is
*exactly* equivalent to:
int foo() { return 42; }
int&& ri =3D foo();
int main() {}
At least in GCC, there is *no way at all* to tell the difference between
those two inputs=C2=B9. In fact, GCC simply drops the 'const' from the abov=
e
example.
(=C2=B9 Well, there is one way; -Wignored-qualifiers will emit a diagnostic
for the first. What I mean is that they will behave the same, generate
the exact same AST and output code, and there is nothing within the
source to tell them apart.)
And, like I said elsewhere; *don't ever write the first version*. Don't
put a 'const' there; it's terrible practice.
If you want that code to be ill-formed, you must first change the
standard to require that a const return value means something. (Which...
might be adequate for your original purpose, but is a MUCH more
significant change than you originally suggested. Also likely one with
serious compatibility issues.)
>> Why should a const prvalue something different than a prvalue?
>
> the 'const' qualifier is supposed to prevent modifications - including
> moving from - the rvalue that is already lacking identity. By striping it
> of its mobility, it falls completely out of the diagram.
Well, it doesn't, and the const qualifier here doesn't mean anything and
is *ignored entirely* by compilers.
--=20
Matthew
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Wed, 4 Mar 2015 00:55:27 +0330
Raw View
--001a11359c7073ed6d051068fa35
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-03-04 0:01 GMT+03:30 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2015-03-03 15:00, Farid Mehrabi wrote:
> > 2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler wrote:
> >> You are mislead. The language requires that the following code is
> >> well-formed:
> >>
> >> int const foo() { return 42; }
> >>
> >> int&& ri =3D foo();
> >>
> >> int main() {}
> >>
> >> It will work for class-types. But for what reasons do you want this
> >> property?
> >
> > It is but why should it be well-formed?
>
> ...because the 'const' is meaningless in that context. The above is
> *exactly* equivalent to:
>
> int foo() { return 42; }
> int&& ri =3D foo();
> int main() {}
>
> At least in GCC, there is *no way at all* to tell the difference between
> those two inputs=C2=B9. In fact, GCC simply drops the 'const' from the ab=
ove
> example.
>
> (=C2=B9 Well, there is one way; -Wignored-qualifiers will emit a diagnost=
ic
> for the first. What I mean is that they will behave the same, generate
> the exact same AST and output code, and there is nothing within the
> source to tell them apart.)
>
> And, like I said elsewhere; *don't ever write the first version*. Don't
> put a 'const' there; it's terrible practice.
>
> If you want that code to be ill-formed, you must first change the
> standard to require that a const return value means something. (Which...
> might be adequate for your original purpose, but is a MUCH more
>
don`t yell plz, I am not deaf.
> significant change than you originally suggested. Also likely one with
> serious compatibility issues.)
>
>
Significance in terms of difficulty in compiler modification I guess. but
compatibility? marking the built-in return type as const should have been
very rare I believe ( only in case some level of paranoia akin to mine
might have encouraged anybody).
>> Why should a const prvalue something different than a prvalue?
> >
> > the 'const' qualifier is supposed to prevent modifications - including
> > moving from - the rvalue that is already lacking identity. By striping =
it
> > of its mobility, it falls completely out of the diagram.
>
> Well, it doesn't, and the const qualifier here doesn't mean anything and
> is *ignored entirely* by compilers.
>
I figured it earlier (and that is about built-in types only) . and as I
think you implied, the const qualifier could make a difference that would
find use cases unless the standard had prevented (which in our case has
indeed) it from being so.
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does shed some light up on my way!!!
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11359c7073ed6d051068fa35
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">2015-03-04 0:01 GMT+03:30 Matthew Woehlke <span dir=3D=
"ltr"><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blan=
k">mw_triad@users.sourceforge.net</a>></span>:</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On =
2015-03-03 15:00, Farid Mehrabi wrote:<br>
<span class=3D"">> 2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler wrote:=
<br>
>> You are mislead. The language requires that the following code is<=
br>
>> well-formed:<br>
>><br>
>> int const foo() { return 42; }<br>
>><br>
>> int&& ri =3D foo();<br>
>><br>
>> int main() {}<br>
>><br>
>> It will work for class-types. But for what reasons do you want thi=
s<br>
>> property?<br>
><br>
> It is but why should it be well-formed?<br>
<br>
</span>...because the 'const' is meaningless in that context. The a=
bove is<br>
*exactly* equivalent to:<br>
<br>
=C2=A0 int foo() { return 42; }<br>
<span class=3D"">=C2=A0 int&& ri =3D foo();<br>
=C2=A0 int main() {}<br>
<br>
</span>At least in GCC, there is *no way at all* to tell the difference bet=
ween<br>
those two inputs=C2=B9. In fact, GCC simply drops the 'const' from =
the above<br>
example.<br>
<br>
(=C2=B9 Well, there is one way; -Wignored-qualifiers will emit a diagnostic=
<br>
for the first. What I mean is that they will behave the same, generate<br>
the exact same AST and output code, and there is nothing within the<br>
source to tell them apart.)<br>
<br>
And, like I said elsewhere; *don't ever write the first version*. Don&#=
39;t<br>
put a 'const' there; it's terrible practice.<br>
<br>
If you want that code to be ill-formed, you must first change the<br>
standard to require that a const return value means something. (Which...<br=
>
might be adequate for your original purpose, but is a MUCH more<br></blockq=
uote><div dir=3D"ltr"><br></div><div dir=3D"ltr">don`t yell plz, I am not d=
eaf.=C2=A0</div><div style=3D"direction:ltr">=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
significant change than you originally suggested. Also likely one with<br>
serious compatibility issues.)<br>
<span class=3D""><br></span></blockquote><div dir=3D"ltr"><br></div><div di=
r=3D"ltr">Significance in terms of =C2=A0difficulty in compiler modificatio=
n I guess. but compatibility? marking the built-in return type as const sho=
uld have been very rare I believe ( only in case some level of paranoia aki=
n to mine might have encouraged anybody).</div><div dir=3D"ltr"><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><span class=3D"">
>> Why should a const prvalue something different than a prvalue?<br>
><br>
> the 'const' qualifier is supposed to prevent modifications - i=
ncluding<br>
> moving from - the rvalue that is already lacking identity. By striping=
it<br>
> of its mobility, it falls completely out of the diagram.<br>
<br>
</span>Well, it doesn't, and the const qualifier here doesn't mean =
anything and<br>
is *ignored entirely* by compilers.<br></blockquote><div style=3D"direction=
:ltr"><br></div><div dir=3D"ltr">I figured it earlier (and that is about bu=
ilt-in types only) . and as I think you implied, =C2=A0the const qualifier =
could make a difference that would find use cases unless the standard had p=
revented=C2=A0(which in our case has indeed) it from being so.</div></div><=
br clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature"><div =
dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your hair in=
the dark night??<br>unless the candle of your face does shed some light up=
on my way!!!<br></div></div>
</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11359c7073ed6d051068fa35--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 03 Mar 2015 14:00:13 -0800
Raw View
On Wednesday 04 March 2015 00:55:27 Farid Mehrabi wrote:
> Significance in terms of difficulty in compiler modification I guess. but
> compatibility? marking the built-in return type as const should have been
> very rare I believe ( only in case some level of paranoia akin to mine
> might have encouraged anybody).
Sorry, but you might be surprised.
I remember this consulting company that added const everywhere to a codebase
because "it couldn't hurt"...
That's quite different from adding auto to all automatic variables in C++98
because no one has taught auto since the early 1970s and the B language.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 03 Mar 2015 17:27:58 -0500
Raw View
On 2015-03-03 16:25, Farid Mehrabi wrote:
> 2015-03-04 0:01 GMT+03:30 Matthew Woehlke:
>> [...] you must first change the standard to require that a const
>> return value means something. (Which... might be adequate for your
>> original purpose, but is a MUCH more significant change than you
>> originally suggested. Also likely one with serious compatibility
>> issues.)
>
> Significance in terms of difficulty in compiler modification I guess. bu=
t
> compatibility? marking the built-in return type as const should have been
> very rare I believe ( only in case some level of paranoia akin to mine
> might have encouraged anybody).
Yes, compatibility. As previously mentioned, na=C3=AFve programmers have be=
en
incorrectly marking return values as 'const'. Currently this means
nothing. If it suddenly starts to mean something, than any case where
the const or lack thereof is relevant (and those must exist, or there is
no point to making such a change) will suddenly have different behavior
(e.g. call different overloads, or just fail to compile).
BTW, if such a change is made, then what would be the type of 'foo' in
this example? 'int' or 'const int'? What if 'auto' is replaced with
'auto&&'?
int const bar();
auto foo =3D bar();
--=20
Matthew
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 4 Mar 2015 00:21:54 +0100
Raw View
On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:
> On 2015-03-03 16:25, Farid Mehrabi wrote:
> > 2015-03-04 0:01 GMT+03:30 Matthew Woehlke:
> >> [...] you must first change the standard to require that a const
> >> return value means something. (Which... might be adequate for your
> >> original purpose, but is a MUCH more significant change than you
> >> originally suggested. Also likely one with serious compatibility
> >> issues.)
> >
> > Significance in terms of difficulty in compiler modification I guess. =
but
> > compatibility? marking the built-in return type as const should have be=
en
> > very rare I believe ( only in case some level of paranoia akin to mine
> > might have encouraged anybody).
>=20
> Yes, compatibility. As previously mentioned, na=C3=AFve programmers have =
been
> incorrectly marking return values as 'const'. Currently this means
> nothing.
It actually do mean something - annoyance and trouble.
Consider a library with many current clients and declarations like the
following one:
struct foo_base {
virtual const int bar();
};
In this case removing the 'const' in the base class will trigger compilatio=
n
failures in the clients and that makes a gradual migration away from the
unnecessary const version harder.
/MF
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 3 Mar 2015 17:41:55 -0800 (PST)
Raw View
------=_Part_5668_908282467.1425433315857
Content-Type: multipart/alternative;
boundary="----=_Part_5669_1189659993.1425433315857"
------=_Part_5669_1189659993.1425433315857
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 3, 2015 at 3:32:08 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-03-03 15:00, Farid Mehrabi wrote:=20
> > 2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler wrote:=20
> >> You are mislead. The language requires that the following code is=20
> >> well-formed:=20
> >>=20
> >> int const foo() { return 42; }=20
> >>=20
> >> int&& ri =3D foo();=20
> >>=20
> >> int main() {}=20
> >>=20
> >> It will work for class-types. But for what reasons do you want this=20
> >> property?=20
> >=20
> > It is but why should it be well-formed?=20
>
> ...because the 'const' is meaningless in that context.
Not entirely.
If you return a value by 'const', then the caller cannot bind it to a=20
non-const lvalue <https://ideone.com/C7KWGn> or rvalue=20
<https://ideone.com/bhxlAN>. Now granted, I can't see a good reason why you=
=20
would *want* to prevent the user from doing either of these two things.
But there is a difference.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5669_1189659993.1425433315857
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 3:32:08 PM UTC-5, Mat=
thew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-03-=
03 15:00, Farid Mehrabi wrote:
<br>> 2015-02-28 21:55 GMT+03:30 Daniel Kr=C3=BCgler wrote:
<br>>> You are mislead. The language requires that the following code=
is
<br>>> well-formed:
<br>>>
<br>>> int const foo() { return 42; }
<br>>>
<br>>> int&& ri =3D foo();
<br>>>
<br>>> int main() {}
<br>>>
<br>>> It will work for class-types. But for what reasons do you want=
this
<br>>> property?
<br>>
<br>> It is but why should it be well-formed?
<br>
<br>...because the 'const' is meaningless in that context.</blockquote><div=
><br>Not entirely.<br><br>If you return a value by 'const', then the caller=
cannot bind it to a non-const <a href=3D"https://ideone.com/C7KWGn">lvalue=
</a> or <a href=3D"https://ideone.com/bhxlAN">rvalue</a>. Now granted, I ca=
n't see a good reason why you would <i>want</i> to prevent the user from do=
ing either of these two things.<br><br>But there is a difference.</div><br>=
</div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5669_1189659993.1425433315857--
------=_Part_5668_908282467.1425433315857--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 04 Mar 2015 11:00:11 -0500
Raw View
On 2015-03-03 20:41, Nicol Bolas wrote:
> On Tuesday, March 3, 2015 at 3:32:08 PM UTC-5, Matthew Woehlke wrote:
>> ...because the 'const' is meaningless in ['int const foo(...)'].
>
> Not entirely.
>
> If you return a value by 'const', then the caller cannot bind it to a
> non-const lvalue <https://ideone.com/C7KWGn>
Actually, that's not legal with or without the const.
> or rvalue <https://ideone.com/bhxlAN>.
....and that's also a class type. On a *class type* it means something.
On a POD type, which is what I used in my example, and which is what
this entire thread has been talking about (pointers, specifically), it
does not; see https://ideone.com/eCERHi (which is const yet has no errors).
That said, returning a const class by value still seems dubious...
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 04 Mar 2015 11:07:36 -0500
Raw View
On 2015-03-03 18:21, Magnus Fromreide wrote:
> On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:
>> Currently [marking POD return values 'const'] means nothing.
>
> It actually do mean something - annoyance and trouble.
>
> Consider a library with many current clients and declarations like the
> following one:
>
> struct foo_base {
> virtual const int bar();
> };
>
> In this case removing the 'const' in the base class will trigger compilation
> failures in the clients and that makes a gradual migration away from the
> unnecessary const version harder.
Hmm... Okay, the const doesn't mean anything *else*. That said, I'd
almost consider it a defect that override resolution considers a
meaningless token.
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Wed, 4 Mar 2015 21:42:06 +0330
Raw View
--001a11470f42d0045705107a64b0
Content-Type: text/plain; charset=UTF-8
Just one question: why should a library programmer pay the extra typing
time to qualify a return type as 'const' while he dose not really mean that
the result is supposed to be const?
regards,
FM.
2015-03-04 19:37 GMT+03:30 Matthew Woehlke <mw_triad@users.sourceforge.net>:
> On 2015-03-03 18:21, Magnus Fromreide wrote:
> > On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:
> >> Currently [marking POD return values 'const'] means nothing.
> >
> > It actually do mean something - annoyance and trouble.
> >
> > Consider a library with many current clients and declarations like the
> > following one:
> >
> > struct foo_base {
> > virtual const int bar();
> > };
> >
> > In this case removing the 'const' in the base class will trigger
> compilation
> > failures in the clients and that makes a gradual migration away from the
> > unnecessary const version harder.
>
> Hmm... Okay, the const doesn't mean anything *else*. That said, I'd
> almost consider it a defect that override resolution considers a
> meaningless token.
>
> --
> Matthew
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11470f42d0045705107a64b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><div dir=3D"ltr">Just one question: why should a library p=
rogrammer pay the extra typing time to qualify a return type as 'const&=
#39; while he dose not really mean that the result is supposed to be const?=
</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">regards,</div><div dir=3D=
"ltr">FM.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">2015-03-04 19:37 GMT+03:30 Matthew Woehlke <span dir=
=3D"ltr"><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_b=
lank">mw_triad@users.sourceforge.net</a>></span>:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">On 2015-03-03 18:21, Magnus Fromreide wrote:=
<br>
> On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:<br>
</span>>> Currently [marking POD return values 'const'] means=
nothing.<br>
<span class=3D"">><br>
> It actually do mean something - annoyance and trouble.<br>
><br>
> Consider a library with many current clients and declarations like the=
<br>
> following one:<br>
><br>
> struct foo_base {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0virtual const int bar();<br>
> };<br>
><br>
> In this case removing the 'const' in the base class will trigg=
er compilation<br>
> failures in the clients and that makes a gradual migration away from t=
he<br>
> unnecessary const version harder.<br>
<br>
</span>Hmm... Okay, the const doesn't mean anything *else*. That said, =
I'd<br>
almost consider it a defect that override resolution considers a<br>
meaningless token.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">how am I supposed to end th=
e twisted road of=C2=A0 your hair in the dark night??<br>unless the candle =
of your face does turn a lamp up on my way!!!<br></div></div>
</div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11470f42d0045705107a64b0--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 4 Mar 2015 19:36:12 +0100
Raw View
On Wed, Mar 04, 2015 at 09:42:06PM +0330, Farid Mehrabi wrote:
> Just one question: why should a library programmer pay the extra typing
> time to qualify a return type as 'const' while he dose not really mean th=
at
> the result is supposed to be const?
The thread did have a reference to "na=C3=AFve programmers (who) have been
incorrectly marking return values as 'const'" that fell away in Mathhew's
answer.
The reasoning could be that adding const to object return values prevents
mutating operations on the returned temporaries and having them on the
non-object return values will then be consistent and can't harm anything.
Then the interface gets set in stone and ensures lasting pain.
/MF
> regards,
> FM.
>=20
> 2015-03-04 19:37 GMT+03:30 Matthew Woehlke <mw_triad@users.sourceforge.ne=
t>:
>=20
> > On 2015-03-03 18:21, Magnus Fromreide wrote:
> > > On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:
> > >> Currently [marking POD return values 'const'] means nothing.
> > >
> > > It actually do mean something - annoyance and trouble.
> > >
> > > Consider a library with many current clients and declarations like th=
e
> > > following one:
> > >
> > > struct foo_base {
> > > virtual const int bar();
> > > };
> > >
> > > In this case removing the 'const' in the base class will trigger
> > compilation
> > > failures in the clients and that makes a gradual migration away from =
the
> > > unnecessary const version harder.
> >
> > Hmm... Okay, the const doesn't mean anything *else*. That said, I'd
> > almost consider it a defect that override resolution considers a
> > meaningless token.
> >
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 04 Mar 2015 13:52:09 -0500
Raw View
On 2015-03-04 13:36, Magnus Fromreide wrote:
> On Wed, Mar 04, 2015 at 09:42:06PM +0330, Farid Mehrabi wrote:
>> Just one question: why should a library programmer pay the extra typing
>> time to qualify a return type as 'const' while he dose not really mean t=
hat
>> the result is supposed to be const?
>=20
> The thread did have a reference to "na=C3=AFve programmers (who) have bee=
n
> incorrectly marking return values as 'const'" that fell away in Mathhew's
> answer.
>=20
> The reasoning could be that adding const to object return values prevents
> mutating operations on the returned temporaries and having them on the
> non-object return values will then be consistent and can't harm anything.
>=20
> Then the interface gets set in stone and ensures lasting pain.
I may need to go find what library it was that was doing this, because
this was NOT the problem. It was in fact the case that someone misused
const, where it was *very clear* that the intention was to return a
pointer to a const object, but in fact had no effect. I stumbled across
it specifically because I was trying to figure out why a bunch of
objects that clearly should have been const were not.
More concretely, this was happening:
typedef MyRealObject* MyObject;
const MyObject GetImmutableInstance();
That is, the return was literally a 'const ObjectType', where ObjectType
was a typedef of a pointer type. For various reasons, it was quite
obvious that the intent had been to return a pointer to const object.
(I suppose if anything this is more an argument for why that sort of
thing really ought to just be a hard error, but anyway the point that a
const POD return is identical=C2=B9 to a non-const POD return is critical t=
o
the OP's request. In the sense that the request is not possible without
changing that.)
(=C2=B9 Except, obnoxiously, that compilers will bitch and moan if the cons=
t
doesn't match when overriding virtual methods, despite that being the
*only* way in which the const has any meaning. IMO that's almost as bad
as saying that the parameter names must match in order to override...)
--=20
Matthew
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Wed, 4 Mar 2015 22:39:16 +0330
Raw View
--001a11c11de6382d3e05107b3196
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-03-04 22:06 GMT+03:30 Magnus Fromreide <magfr@lysator.liu.se>:
> On Wed, Mar 04, 2015 at 09:42:06PM +0330, Farid Mehrabi wrote:
> > Just one question: why should a library programmer pay the extra typing
> > time to qualify a return type as 'const' while he dose not really mean
> that
> > the result is supposed to be const?
>
> The thread did have a reference to "na=C3=AFve programmers (who) have bee=
n
> incorrectly marking return values as 'const'" that fell away in Mathhew's
> answer.
>
> The reasoning could be that adding const to object return values prevents
> mutating operations on the returned temporaries and having them on the
> non-object return values will then be consistent and can't harm anything.
if the programmer has assumed similarity between object & non-object const
return , then the code is already ill-formed but will be fixed by
proposed uniformity. the only case that needs further thought is type
deduction due to 'auto' or 'decltype' which are relatively new. let us
remember that old code on old compilers assumed that rvalues can only bind
to const references, though some compilers did not comply with the standard
in that regard. So I think it is not late to change the standard iff the
need for the proposed change is strong.
at least the confusion about use of cv on non-object return will be removed
as well as inconsistency between object and non-object types.
regards,
FM.
>
> > regards,
> > FM.
> >
> > 2015-03-04 19:37 GMT+03:30 Matthew Woehlke <
> mw_triad@users.sourceforge.net>:
> >
> > > On 2015-03-03 18:21, Magnus Fromreide wrote:
> > > > On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wrote:
> > > >> Currently [marking POD return values 'const'] means nothing.
> > > >
> > > > It actually do mean something - annoyance and trouble.
> > > >
> > > > Consider a library with many current clients and declarations like
> the
> > > > following one:
> > > >
> > > > struct foo_base {
> > > > virtual const int bar();
> > > > };
> > > >
> > > > In this case removing the 'const' in the base class will trigger
> > > compilation
> > > > failures in the clients and that makes a gradual migration away fro=
m
> the
> > > > unnecessary const version harder.
> > >
> > > Hmm... Okay, the const doesn't mean anything *else*. That said, I'd
> > > almost consider it a defect that override resolution considers a
> > > meaningless token.
> > >
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
how am I supposed to end the twisted road of your hair in the dark night??
unless the candle of your face does turn a lamp up on my way!!!
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c11de6382d3e05107b3196
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"rtl"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">2015-03-04 22:06 GMT+03:30 Magnus Fromreide <span dir=
=3D"ltr"><<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magf=
r@lysator.liu.se</a>></span>:</div><blockquote class=3D"gmail_quote" sty=
le=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"><span class=3D"">On =
Wed, Mar 04, 2015 at 09:42:06PM +0330, Farid Mehrabi wrote:<br>
> Just one question: why should a library programmer pay the extra typin=
g<br>
> time to qualify a return type as 'const' while he dose not rea=
lly mean that<br>
> the result is supposed to be const?<br>
<br>
</span>The thread did have a reference to "na=C3=AFve programmers (who=
) have been<br>
incorrectly marking return values as 'const'" that fell away i=
n Mathhew's<br>
answer.<br>
<br>
The reasoning could be that adding const to object return values prevents<b=
r>
mutating operations on the returned temporaries and having them on the<br>
non-object return values will then be consistent and can't harm anythin=
g.</blockquote><div><br></div><div style dir=3D"ltr">if the programmer has =
assumed=C2=A0similarity between object & non-object const return , then=
the code is already ill-formed but will be fixed by proposed=C2=A0uniformi=
ty. the only case that needs further thought is type deduction due to '=
auto' or 'decltype' which are relatively new. let us remember t=
hat old code on old compilers assumed that rvalues can only bind to const r=
eferences, though some compilers did not comply with the standard in that r=
egard. So I think it is not late to change the standard iff the need for th=
e proposed change is strong.</div><div style dir=3D"ltr">at least the confu=
sion about use of cv on non-object return will be removed as well as incons=
istency between object and non-object types.</div><div style dir=3D"ltr">=
=C2=A0</div><div style dir=3D"ltr">regards,</div><div style dir=3D"ltr">FM.=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><span class=3D"im"><br>
> regards,<br>
> FM.<br>
><br>
> 2015-03-04 19:37 GMT+03:30 Matthew Woehlke <<a href=3D"mailto:mw_tr=
iad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>>:<br>
><br>
> > On 2015-03-03 18:21, Magnus Fromreide wrote:<br>
> > > On Tue, Mar 03, 2015 at 05:27:58PM -0500, Matthew Woehlke wr=
ote:<br>
> > >> Currently [marking POD return values 'const'] me=
ans nothing.<br>
> > ><br>
> > > It actually do mean something - annoyance and trouble.<br>
> > ><br>
> > > Consider a library with many current clients and declaration=
s like the<br>
> > > following one:<br>
> > ><br>
> > > struct foo_base {<br>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0virtual const int bar();<br>
> > > };<br>
> > ><br>
> > > In this case removing the 'const' in the base class =
will trigger<br>
> > compilation<br>
> > > failures in the clients and that makes a gradual migration a=
way from the<br>
> > > unnecessary const version harder.<br>
> ><br>
> > Hmm... Okay, the const doesn't mean anything *else*. That sai=
d, I'd<br>
> > almost consider it a defect that override resolution considers a<=
br>
> > meaningless token.<br>
> ><br>
<br>
--<br>
<br>
</span><div class=3D""><div class=3D"h5">---<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr">how am I supposed to end th=
e twisted road of=C2=A0 your hair in the dark night??<br>unless the candle =
of your face does turn a lamp up on my way!!!<br></div></div>
</div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c11de6382d3e05107b3196--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 04 Mar 2015 14:57:10 -0800
Raw View
On Wednesday 04 March 2015 11:00:11 Matthew Woehlke wrote:
> ...and that's also a class type. On a *class type* it means something.
> On a POD type, which is what I used in my example, and which is what
> this entire thread has been talking about (pointers, specifically), it
> does not; see https://ideone.com/eCERHi (which is const yet has no errors).
That is not proof. I don't know which compiler it ran, but it's unlikely it
ran one of those that are known to encode constness of POD parameters and
return types (that come to mind: Sun Studio and Visual Studio).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 04 Mar 2015 18:27:21 -0500
Raw View
On 2015-03-04 17:57, Thiago Macieira wrote:
> On Wednesday 04 March 2015 11:00:11 Matthew Woehlke wrote:
>> ...and that's also a class type. On a *class type* it means something.
>> On a POD type, which is what I used in my example, and which is what
>> this entire thread has been talking about (pointers, specifically), it
>> does not; see https://ideone.com/eCERHi (which is const yet has no errors).
>
> That is not proof. I don't know which compiler it ran, but it's unlikely it
> ran one of those that are known to encode constness of POD parameters and
> return types (that come to mind: Sun Studio and Visual Studio).
I did mention GCC specifically in my original reply. I'm not sure what
ideone is using, but I also tested locally with GCC.
Still, either GCC is non-conforming (seems unlikely), or the standard
allows the compiler to disregard the 'const'. If the latter case, to me
that says that having a const POD return type is dubious if not outright
dangerous, regardless of what some particular compiler does. (If the
standard allows it to be ignored, what's to stop a compiler from
changing its behavior in some future release?)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 04 Mar 2015 18:09:23 -0800
Raw View
On Wednesday 04 March 2015 18:27:21 Matthew Woehlke wrote:
> Still, either GCC is non-conforming (seems unlikely), or the standard
> allows the compiler to disregard the 'const'. If the latter case, to me
> that says that having a const POD return type is dubious if not outright
> dangerous, regardless of what some particular compiler does. (If the
> standard allows it to be ignored, what's to stop a compiler from
> changing its behavior in some future release?)
I thought we were talking about virtual overrides differing in the constness. I
didn't actually read your source code, I only searched the site to see if it
had an option to select a different compiler.
TBH, I don't know about this particular scenario. PODs and non-PODs differ in
behaviour as to what you can do to their rvalues:
template <typename T> T returnIt();
template <typename T> void modifyIt1()
{
returnIt<T>() = T{};
}
template <typename T> void modifyIt2(T &&t) { t = T{}; }
struct S {};
int main()
{
// does not compile
modifyIt1<int>();
// compiles:
modifyIt1<S>();
// compiles:
modifyIt2(returnIt<const int>());
// does not compile
modifyIt2(returnIt<const S>());
}
In one case, you can modify an rvalue POD but not the rvalue non-POD; in the
other, you can modify the rvalue non-POD but can't the rvalue POD.
If GCC's implementation is non-conforming, then so is Clang's and ICC's. But
it would make sense if they were and the third case above weren't allowed: no
binding of a const prvalue to a non-const rvalue, regardless of PODness.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 05 Mar 2015 11:22:31 -0500
Raw View
On 2015-03-04 21:09, Thiago Macieira wrote:
> On Wednesday 04 March 2015 18:27:21 Matthew Woehlke wrote:
>> Still, either GCC is non-conforming (seems unlikely), or the standard
>> allows the compiler to disregard the 'const'. If the latter case, to me
>> that says that having a const POD return type is dubious if not outright
>> dangerous, regardless of what some particular compiler does. (If the
>> standard allows it to be ignored, what's to stop a compiler from
>> changing its behavior in some future release?)
>
> I thought we were talking about virtual overrides differing in the constness.
That was elsewhere in the thread :-).
> TBH, I don't know about this particular scenario. PODs and non-PODs differ in
> behaviour as to what you can do to their rvalues:
>
> template <typename T> T returnIt();
> template <typename T> void modifyIt1() { returnIt<T>() = T{}; }
>
> int main()
> {
> // compiles:
> modifyIt2(returnIt<const int>());
That... is very surprising. It does NOT compile if the return type is
not templated, i.e.:
const int test();
void mutate() { test() = 0; } // nope; error
> }
>
> In one case, you can modify an rvalue POD but not the rvalue non-POD; in the
> other, you can modify the rvalue non-POD but can't the rvalue POD.
>
> If GCC's implementation is non-conforming, then so is Clang's and ICC's. But
> it would make sense if they were and the third case above weren't allowed: no
> binding of a const prvalue to a non-const rvalue, regardless of PODness.
Do you mean that you think the third case compiling is an error? (If
yes, I would be rather inclined to agree.) I can't think of a good
reason why this should be allowed... I *could* argue that the template
case should allow the assignment regardless, for the sake of generic
programming, but it already doesn't because the non-const doesn't allow
the assignment either. It actually feels quite bizarre that the const
would *allow* assignment while the non-const does not.
(I have more sympathy for eliding the -Wignored-qualifiers diagnostic
here, since it would be somewhat obnoxious to avoid it in the template
case.)
I guess I can understand allowing modification of a non-POD rvalue,
since that could potentially have side effects (e.g. in operator=, or if
the destructor behaves differently depending on the value).
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 5 Mar 2015 11:43:22 -0800
Raw View
--001a11391184d925c105108fc703
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 5, 2015 at 8:22 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2015-03-04 21:09, Thiago Macieira wrote:
> > On Wednesday 04 March 2015 18:27:21 Matthew Woehlke wrote:
> >> Still, either GCC is non-conforming (seems unlikely), or the standard
> >> allows the compiler to disregard the 'const'. If the latter case, to me
> >> that says that having a const POD return type is dubious if not outright
> >> dangerous, regardless of what some particular compiler does. (If the
> >> standard allows it to be ignored, what's to stop a compiler from
> >> changing its behavior in some future release?)
> >
> > I thought we were talking about virtual overrides differing in the
> constness.
>
> That was elsewhere in the thread :-).
>
> > TBH, I don't know about this particular scenario. PODs and non-PODs
> differ in
> > behaviour as to what you can do to their rvalues:
> >
> > template <typename T> T returnIt();
> > template <typename T> void modifyIt1() { returnIt<T>() = T{}; }
> >
> > int main()
> > {
> > // compiles:
> > modifyIt2(returnIt<const int>());
>
> That... is very surprising. It does NOT compile if the return type is
> not templated, i.e.:
>
> const int test();
> void mutate() { test() = 0; } // nope; error
Thiago's example calls modifyIt2, not modifyIt1.
>
> > }
> >
> > In one case, you can modify an rvalue POD but not the rvalue non-POD; in
> the
> > other, you can modify the rvalue non-POD but can't the rvalue POD.
> >
> > If GCC's implementation is non-conforming, then so is Clang's and ICC's.
> But
> > it would make sense if they were and the third case above weren't
> allowed: no
> > binding of a const prvalue to a non-const rvalue, regardless of PODness.
>
> Do you mean that you think the third case compiling is an error? (If
> yes, I would be rather inclined to agree.) I can't think of a good
> reason why this should be allowed... I *could* argue that the template
> case should allow the assignment regardless, for the sake of generic
> programming, but it already doesn't because the non-const doesn't allow
> the assignment either. It actually feels quite bizarre that the const
> would *allow* assignment while the non-const does not.
>
> (I have more sympathy for eliding the -Wignored-qualifiers diagnostic
> here, since it would be somewhat obnoxious to avoid it in the template
> case.)
>
> I guess I can understand allowing modification of a non-POD rvalue,
> since that could potentially have side effects (e.g. in operator=, or if
> the destructor behaves differently depending on the value).
>
> --
> Matthew
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11391184d925c105108fc703
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 T=
hu, Mar 5, 2015 at 8:22 AM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><s=
pan class=3D"">On 2015-03-04 21:09, Thiago Macieira wrote:<br>
> On Wednesday 04 March 2015 18:27:21 Matthew Woehlke wrote:<br>
>> Still, either GCC is non-conforming (seems unlikely), or the stand=
ard<br>
>> allows the compiler to disregard the 'const'. If the latte=
r case, to me<br>
>> that says that having a const POD return type is dubious if not ou=
tright<br>
>> dangerous, regardless of what some particular compiler does. (If t=
he<br>
>> standard allows it to be ignored, what's to stop a compiler fr=
om<br>
>> changing its behavior in some future release?)<br>
><br>
> I thought we were talking about virtual overrides differing in the con=
stness.<br>
<br>
</span>That was elsewhere in the thread :-).<br>
<span class=3D""><br>
> TBH, I don't know about this particular scenario. PODs and non-POD=
s differ in<br>
> behaviour as to what you can do to their rvalues:<br>
><br>
> template <typename T> T returnIt();<br>
> template <typename T> void modifyIt1() { returnIt<T>() =3D=
T{}; }<br>
><br>
</span>> int main()<br>
<span class=3D"">> {<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// compiles:<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0modifyIt2(returnIt<const int>());<br>
<br>
</span>That... is very surprising. It does NOT compile if the return type i=
s<br>
not templated, i.e.:<br>
<br>
=C2=A0 const int test();<br>
=C2=A0 void mutate() { test() =3D 0; } // nope; error</blockquote><div><br>=
</div><div>Thiago's example calls modifyIt2, not modifyIt1.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
> }<br>
><br>
> In one case, you can modify an rvalue POD but not the rvalue non-POD; =
in the<br>
> other, you can modify the rvalue non-POD but can't the rvalue POD.=
<br>
><br>
> If GCC's implementation is non-conforming, then so is Clang's =
and ICC's. But<br>
> it would make sense if they were and the third case above weren't =
allowed: no<br>
> binding of a const prvalue to a non-const rvalue, regardless of PODnes=
s.<br>
<br>
</span>Do you mean that you think the third case compiling is an error? (If=
<br>
yes, I would be rather inclined to agree.) I can't think of a good<br>
reason why this should be allowed... I *could* argue that the template<br>
case should allow the assignment regardless, for the sake of generic<br>
programming, but it already doesn't because the non-const doesn't a=
llow<br>
the assignment either. It actually feels quite bizarre that the const<br>
would *allow* assignment while the non-const does not.<br>
<br>
(I have more sympathy for eliding the -Wignored-qualifiers diagnostic<br>
here, since it would be somewhat obnoxious to avoid it in the template<br>
case.)<br>
<br>
I guess I can understand allowing modification of a non-POD rvalue,<br>
since that could potentially have side effects (e.g. in operator=3D, or if<=
br>
the destructor behaves differently depending on the value).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11391184d925c105108fc703--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 05 Mar 2015 15:23:07 -0500
Raw View
On 2015-03-05 14:43, Richard Smith wrote:
> On Thu, Mar 5, 2015 at 8:22 AM, Matthew Woehlke wrote:
>> On 2015-03-04 21:09, Thiago Macieira wrote:
>>> On Wednesday 04 March 2015 18:27:21 Matthew Woehlke wrote:
>>>> Still, either GCC is non-conforming (seems unlikely), or the standard
>>>> allows the compiler to disregard the 'const'. If the latter case, to me
>>>> that says that having a const POD return type is dubious if not outright
>>>> dangerous, regardless of what some particular compiler does. (If the
>>>> standard allows it to be ignored, what's to stop a compiler from
>>>> changing its behavior in some future release?)
>>>
>>> TBH, I don't know about this particular scenario. PODs and non-PODs
>>> differ in behaviour as to what you can do to their rvalues:
>>>
>>> template <typename T> T returnIt();
>>> template <typename T> void modifyIt1() { returnIt<T>() = T{}; }
>>>
>>> int main()
>>> {
>>> // compiles:
>>> modifyIt2(returnIt<const int>());
>>
>> const int test();
>> void mutate() { test() = 0; } // nope; error
>
> Thiago's example calls modifyIt2, not modifyIt1.
D'oh. Well... but that was just my original point; both the const and
non-const convert to POD&& and can be modified after such conversion.
(Or rather, there is no such thing as a 'const POD rvalue'... except for
override resolution.)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.