Topic: add operator-> to std::weak_ptr
Author: Taylor Holliday <wtholliday@gmail.com>
Date: Thu, 15 Jan 2015 13:51:01 -0800 (PST)
Raw View
------=_Part_275_1681562104.1421358661829
Content-Type: multipart/alternative;
boundary="----=_Part_276_1129487408.1421358661829"
------=_Part_276_1129487408.1421358661829
Content-Type: text/plain; charset=UTF-8
This would be implemented as follows:
std::shared_ptr<T> operator->() {
auto shared = lock();
if(shared == nullptr) {
throw std::bad_weak_ptr(); // or some other exception
}
return shared;
}
The lifetime of the returned shared_ptr nicely scopes a member function
call.
Thoughts? I assume this has been proposed before.
- Taylor
--
---
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_276_1129487408.1421358661829
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This would be implemented as follows:<div><br></div><div><=
pre class=3D"lang-cpp prettyprint prettyprinted" style=3D"margin-bottom: 10=
px; padding: 5px; font-size: 14px; background-color: rgb(238, 238, 238); fo=
nt-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'D=
ejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, ser=
if; overflow: auto; width: auto; max-height: 600px; word-wrap: normal; colo=
r: rgb(0, 0, 0); line-height: 17.804800033569336px;"><code style=3D"font-fa=
mily: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu=
Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, serif; w=
hite-space: inherit;"><span class=3D"pln" style=3D"background-color: transp=
arent;"> std</span><span class=3D"pun" style=3D"background-color: transpa=
rent;">::</span><span class=3D"pln" style=3D"background-color: transparent;=
">shared_ptr</span><span class=3D"pun" style=3D"background-color: transpare=
nt;"><</span><span class=3D"pln" style=3D"background-color: transparent;=
">T</span><span class=3D"pun" style=3D"background-color: transparent;">>=
</span><span class=3D"pln" style=3D"background-color: transparent;"> </span=
><span class=3D"kwd" style=3D"background-color: transparent; color: rgb(0, =
0, 139);">operator</span><span class=3D"pun" style=3D"background-color: tra=
nsparent;">->()</span><span class=3D"pln" style=3D"background-color: tra=
nsparent;"> </span><span class=3D"pun" style=3D"background-color: transpare=
nt;">{</span><span class=3D"pln" style=3D"background-color: transparent;">
</span><span class=3D"kwd" style=3D"background-color: transparent; co=
lor: rgb(0, 0, 139);">auto</span><span class=3D"pln" style=3D"background-co=
lor: transparent;"> shared </span><span class=3D"pun" style=3D"background-c=
olor: transparent;">=3D</span><span class=3D"pln" style=3D"background-color=
: transparent;"> lock</span><span class=3D"pun" style=3D"background-color: =
transparent;">();</span><span class=3D"pln" style=3D"background-color: tran=
sparent;">
</span><span class=3D"kwd" style=3D"background-color: transparent; co=
lor: rgb(0, 0, 139);">if</span><span class=3D"pun" style=3D"background-colo=
r: transparent;">(</span><span class=3D"pln" style=3D"background-color: tra=
nsparent;">shared </span><span class=3D"pun" style=3D"background-color: tra=
nsparent;">=3D=3D</span><span class=3D"pln" style=3D"background-color: tran=
sparent;"> </span><span class=3D"kwd" style=3D"background-color: transparen=
t; color: rgb(0, 0, 139);">nullptr</span><span class=3D"pun" style=3D"backg=
round-color: transparent;">)</span><span class=3D"pln" style=3D"background-=
color: transparent;"> </span><span class=3D"pun" style=3D"background-color:=
transparent;">{</span><span class=3D"pln" style=3D"background-color: trans=
parent;">
</span><span class=3D"kwd" style=3D"background-color: transparent=
; color: rgb(0, 0, 139);">throw</span><span class=3D"pln" style=3D"backgrou=
nd-color: transparent;"> std</span><span class=3D"pun" style=3D"background-=
color: transparent;">::</span><span class=3D"pln" style=3D"background-color=
: transparent;">bad_weak_ptr</span><span class=3D"pun" style=3D"background-=
color: transparent;">();</span><span class=3D"pln" style=3D"background-colo=
r: transparent;"> </span><span class=3D"com" style=3D"background-color: tra=
nsparent; color: rgb(128, 128, 128);">// or some other exception</span><spa=
n class=3D"pln" style=3D"background-color: transparent;">
</span><span class=3D"pun" style=3D"background-color: transparent;">}=
</span><span class=3D"pln" style=3D"background-color: transparent;">
</span><span class=3D"kwd" style=3D"background-color: transparent; co=
lor: rgb(0, 0, 139);">return</span><span class=3D"pln" style=3D"background-=
color: transparent;"> shared</span><span class=3D"pun" style=3D"background-=
color: transparent;">;</span><span class=3D"pln" style=3D"background-color:=
transparent;">
</span><span class=3D"pun" style=3D"background-color: transparent;">}</sp=
an></code></pre><div>The lifetime of the returned shared_ptr nicely scopes =
a member function call.</div><div><br></div><div>Thoughts? I assume this ha=
s been proposed before.</div><div><br></div><div>- Taylor</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_276_1129487408.1421358661829--
------=_Part_275_1681562104.1421358661829--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 15 Jan 2015 16:02:08 -0600
Raw View
--001a11395784480c73050cb80454
Content-Type: text/plain; charset=UTF-8
On 15 January 2015 at 15:51, Taylor Holliday <wtholliday@gmail.com> wrote:
> This would be implemented as follows:
>
> std::shared_ptr<T> operator->() {
> auto shared = lock();
> if(shared == nullptr) {
> throw std::bad_weak_ptr(); // or some other exception
> }
> return shared;
> }
>
> The lifetime of the returned shared_ptr nicely scopes a member function
> call.
>
> Thoughts?
>
What is the use case (other than "we can")? It means that the caller isn't
participating in ownership yet still expects someone else to be keeping the
object alive. Why wouldn't I just pass a shared_ptr instead?
Note: if the answer is "to detect programming bugs", such as how some
people abuse things like vector::at(), I am firmly against that, as that
use case is far better served by asserts rather than pretending it is a
recoverable error.
--
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/.
--001a11395784480c73050cb80454
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 15 January 2015 at 15:51, Taylor Holliday <span dir=3D"=
ltr"><<a href=3D"mailto:wtholliday@gmail.com" target=3D"_blank">wthollid=
ay@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This would=
be implemented as follows:<div><br></div><div><pre style=3D"margin-bottom:=
10px;padding:5px;font-size:14px;background-color:rgb(238,238,238);font-fami=
ly:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono'=
,'DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier=
New',monospace,serif;overflow:auto;width:auto;max-height:600px;word-wr=
ap:normal;color:rgb(0,0,0);line-height:17.804800033569336px"><code style=3D=
"font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation=
Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono',&#=
39;Courier New',monospace,serif;white-space:inherit"><span style=3D"bac=
kground-color:transparent"> std</span><span style=3D"background-color:tra=
nsparent">::</span><span style=3D"background-color:transparent">shared_ptr<=
/span><span style=3D"background-color:transparent"><</span><span style=
=3D"background-color:transparent">T</span><span style=3D"background-color:t=
ransparent">></span><span style=3D"background-color:transparent"> </span=
><span style=3D"background-color:transparent;color:rgb(0,0,139)">operator</=
span><span style=3D"background-color:transparent">->()</span><span style=
=3D"background-color:transparent"> </span><span style=3D"background-color:t=
ransparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">auto</span><span style=3D"background-color:transparent"> shared </span><s=
pan style=3D"background-color:transparent">=3D</span><span style=3D"backgro=
und-color:transparent"> lock</span><span style=3D"background-color:transpar=
ent">();</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">if</span><span style=3D"background-color:transparent">(</span><span style=
=3D"background-color:transparent">shared </span><span style=3D"background-c=
olor:transparent">=3D=3D</span><span style=3D"background-color:transparent"=
> </span><span style=3D"background-color:transparent;color:rgb(0,0,139)">nu=
llptr</span><span style=3D"background-color:transparent">)</span><span styl=
e=3D"background-color:transparent"> </span><span style=3D"background-color:=
transparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,=
139)">throw</span><span style=3D"background-color:transparent"> std</span><=
span style=3D"background-color:transparent">::</span><span style=3D"backgro=
und-color:transparent">bad_weak_ptr</span><span style=3D"background-color:t=
ransparent">();</span><span style=3D"background-color:transparent"> </span>=
<span style=3D"background-color:transparent;color:rgb(128,128,128)">// or s=
ome other exception</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent">}</span><span sty=
le=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">return</span><span style=3D"background-color:transparent"> shared</span><=
span style=3D"background-color:transparent">;</span><span style=3D"backgrou=
nd-color:transparent">
</span><span style=3D"background-color:transparent">}</span></code></pre>=
<div>The lifetime of the returned shared_ptr nicely scopes a member functio=
n call.</div><div><br></div><div>Thoughts?<br clear=3D"all"></div></div></d=
iv></blockquote><div><br></div><div>What is the use case (other than "=
we can")?=C2=A0 It means that the caller isn't participating in ow=
nership yet still expects someone else to be keeping the object alive.=C2=
=A0 Why wouldn't I just pass a shared_ptr instead?<br><br></div><div>No=
te:=C2=A0 if the answer is "to detect programming bugs", such as =
how some people abuse things like vector::at(), I am firmly against that, a=
s that use case is far better served by asserts rather than pretending it i=
s a recoverable error.<br></div></div>-- <br><div class=3D"gmail_signature"=
>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@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 />
--001a11395784480c73050cb80454--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 15 Jan 2015 14:27:09 -0800
Raw View
On Thursday 15 January 2015 13:51:01 Taylor Holliday wrote:
> This would be implemented as follows:
>
> std::shared_ptr<T> operator->() {
> auto shared = lock();
> if(shared == nullptr) {
> throw std::bad_weak_ptr(); // or some other exception
> }
> return shared;
> }
>
> The lifetime of the returned shared_ptr nicely scopes a member function
> call.
>
> Thoughts? I assume this has been proposed before.
So you can write:
ptr->foo();
instead of
ptr.lock()->foo();
?
Are the 7 extra characters that much of a burden to write? I'd say that being
explicit that there's more happening than just obtaining a pointer is a good
thing. Source code is read more often than it's written.
--
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: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 15 Jan 2015 16:30:48 -0600
Raw View
--001a113a6922c60805050cb86ac9
Content-Type: text/plain; charset=UTF-8
On 15 January 2015 at 16:27, Thiago Macieira <thiago@macieira.org> wrote:
>
>
> So you can write:
>
> ptr->foo();
>
> instead of
>
> ptr.lock()->foo();
>
lock() doesn't throw, so the dereference would invoke UB on an empty
shared_ptr.
--
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/.
--001a113a6922c60805050cb86ac9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 15 January 2015 at 16:27, Thiago Macieira <span dir=3D"=
ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@ma=
cieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
</span>So you can write:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ptr->foo();<br>
<br>
instead of<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ptr.lock()->foo();<br></blockquote><div><br>=
</div><div>lock() doesn't throw, so the dereference would invoke UB on =
an empty shared_ptr.<br></div></div>-- <br><div>=C2=A0Nevin ":-)"=
Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>>=C2=A0 <a href=3D"tel:%28847%29%2069=
1-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a></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 />
--001a113a6922c60805050cb86ac9--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Thu, 15 Jan 2015 16:44:24 -0800 (PST)
Raw View
------=_Part_190_1375607837.1421369064741
Content-Type: multipart/alternative;
boundary="----=_Part_191_31972857.1421369064741"
------=_Part_191_31972857.1421369064741
Content-Type: text/plain; charset=UTF-8
The implicit safety you're implying here assumes that the user is aware
that -> on a weak_ptr is only usable for expressions that outlive the
lifetime of the temporary returned by ->. That's just far too big of a
surface area to expect. It would mean very "obvious" code like the
following would now compile but be dangerously broken:
weak_ptr<Thing> ptr = get_thing();
auto& foo = ptr->some_member;
use(foo); // foo might be long gone by this point
Without comprehensive lifetime tracking a la Rust, there's not a lot of
ways to achieve both convenience and safety for your case, as the language
has no way to know that the lifetime of `foo` is dependent on the lifetime
of the temporary returned by `ptr->`. While yes, we do have other similar
surprises lurking in C++ already, there's no good reason to add yet another
hidden trap just to save a few characters of typing.
On Thursday, January 15, 2015 at 1:51:01 PM UTC-8, Taylor Holliday wrote:
>
> This would be implemented as follows:
>
> std::shared_ptr<T> operator->() {
> auto shared = lock();
> if(shared == nullptr) {
> throw std::bad_weak_ptr(); // or some other exception
> }
> return shared;
> }
>
> The lifetime of the returned shared_ptr nicely scopes a member function
> call.
>
> Thoughts? I assume this has been proposed before.
>
> - Taylor
>
--
---
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_191_31972857.1421369064741
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The implicit safety you're implying here assumes that=
the user is aware that -> on a weak_ptr is only usable for expressions =
that outlive the lifetime of the temporary returned by ->. That's just f=
ar too big of a surface area to expect. It would mean very "obvious" code l=
ike the following would now compile but be dangerously broken:</div><div><b=
r></div><div> weak_ptr<Thing> ptr =3D get_thing();</div><div>&n=
bsp; auto& foo =3D ptr->some_member;</div><div> use(foo); // f=
oo might be long gone by this point</div><div><br></div><div>Without compre=
hensive lifetime tracking a la Rust, there's not a lot of ways to achieve b=
oth convenience and safety for your case, as the language has no way to kno=
w that the lifetime of `foo` is dependent on the lifetime of the temporary =
returned by `ptr->`. While yes, we do have other similar surprises lurki=
ng in C++ already, there's no good reason to add yet another hidden trap ju=
st to save a few characters of typing.</div><div><br></div><div>On Thursday=
, January 15, 2015 at 1:51:01 PM UTC-8, Taylor Holliday wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This would be implemented =
as follows:<div><br></div><div><pre style=3D"margin-bottom:10px;padding:5px=
;font-size:14px;background-color:rgb(238,238,238);font-family:Consolas,Menl=
o,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream V=
era Sans Mono','Courier New',monospace,serif;overflow:auto;width:auto;max-h=
eight:600px;word-wrap:normal;color:rgb(0,0,0);line-height:17.80480003356933=
6px"><code style=3D"font-family:Consolas,Menlo,Monaco,'Lucida Console','Lib=
eration Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',m=
onospace,serif;white-space:inherit"><span style=3D"background-color:transpa=
rent"> std</span><span style=3D"background-color:transparent">::</span><s=
pan style=3D"background-color:transparent">shared_ptr</span><span style=3D"=
background-color:transparent"><</span><span style=3D"background-color:tr=
ansparent">T</span><span style=3D"background-color:transparent">></span>=
<span style=3D"background-color:transparent"> </span><span style=3D"backgro=
und-color:transparent;color:rgb(0,0,139)">operator</span><span style=3D"bac=
kground-color:transparent">->()</span><span style=3D"background-color:tr=
ansparent"> </span><span style=3D"background-color:transparent">{</span><sp=
an style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">auto</span><span style=3D"background-color:transparent"> shared </span><s=
pan style=3D"background-color:transparent">=3D</span><span style=3D"backgro=
und-color:transparent"> lock</span><span style=3D"background-color:transpar=
ent">();</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">if</span><span style=3D"background-color:transparent">(</span><span style=
=3D"background-color:transparent">shared </span><span style=3D"background-c=
olor:transparent">=3D=3D</span><span style=3D"background-color:transparent"=
> </span><span style=3D"background-color:transparent;color:rgb(0,0,139)">nu=
llptr</span><span style=3D"background-color:transparent">)</span><span styl=
e=3D"background-color:transparent"> </span><span style=3D"background-color:=
transparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,=
139)">throw</span><span style=3D"background-color:transparent"> std</span><=
span style=3D"background-color:transparent">::</span><span style=3D"backgro=
und-color:transparent">bad_weak_ptr</span><span style=3D"background-color:t=
ransparent">();</span><span style=3D"background-color:transparent"> </span>=
<span style=3D"background-color:transparent;color:rgb(128,128,128)">// or s=
ome other exception</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent">}</span><span sty=
le=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">return</span><span style=3D"background-color:transparent"> shared</span><=
span style=3D"background-color:transparent">;</span><span style=3D"backgrou=
nd-color:transparent">
</span><span style=3D"background-color:transparent">}</span></code></pre>=
<div>The lifetime of the returned shared_ptr nicely scopes a member functio=
n call.</div><div><br></div><div>Thoughts? I assume this has been proposed =
before.</div><div><br></div><div>- Taylor</div></div></div></blockquote></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_191_31972857.1421369064741--
------=_Part_190_1375607837.1421369064741--
.
Author: Taylor Holliday <wtholliday@gmail.com>
Date: Thu, 15 Jan 2015 16:54:00 -0800 (PST)
Raw View
------=_Part_445_439500355.1421369640668
Content-Type: multipart/alternative;
boundary="----=_Part_446_1486204452.1421369640668"
------=_Part_446_1486204452.1421369640668
Content-Type: text/plain; charset=UTF-8
Hmm. It seems pretty easy to shoot yourself in the foot that way anyway if
you don't know what you're doing:
weak_ptr<Thing> ptr = get_thing();
auto& foo = ptr.lock()->some_member;
use(foo); // foo might be long gone by this point
On Thursday, January 15, 2015 at 4:44:24 PM UTC-8, Sean Middleditch wrote:
>
> The implicit safety you're implying here assumes that the user is aware
> that -> on a weak_ptr is only usable for expressions that outlive the
> lifetime of the temporary returned by ->. That's just far too big of a
> surface area to expect. It would mean very "obvious" code like the
> following would now compile but be dangerously broken:
>
> weak_ptr<Thing> ptr = get_thing();
> auto& foo = ptr->some_member;
> use(foo); // foo might be long gone by this point
>
> Without comprehensive lifetime tracking a la Rust, there's not a lot of
> ways to achieve both convenience and safety for your case, as the language
> has no way to know that the lifetime of `foo` is dependent on the lifetime
> of the temporary returned by `ptr->`. While yes, we do have other similar
> surprises lurking in C++ already, there's no good reason to add yet another
> hidden trap just to save a few characters of typing.
>
> On Thursday, January 15, 2015 at 1:51:01 PM UTC-8, Taylor Holliday wrote:
>>
>> This would be implemented as follows:
>>
>> std::shared_ptr<T> operator->() {
>> auto shared = lock();
>> if(shared == nullptr) {
>> throw std::bad_weak_ptr(); // or some other exception
>> }
>> return shared;
>> }
>>
>> The lifetime of the returned shared_ptr nicely scopes a member function
>> call.
>>
>> Thoughts? I assume this has been proposed before.
>>
>> - Taylor
>>
>
--
---
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_446_1486204452.1421369640668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hmm. It seems pretty easy to shoot yourself in the foot th=
at way anyway if you don't know what you're doing:<div><br></div><div><div>=
weak_ptr<Thing> ptr =3D get_thing();</div><div>auto& foo =3D ptr.=
lock()->some_member;</div><div>use(foo); // foo might be long gone by th=
is point</div><br>On Thursday, January 15, 2015 at 4:44:24 PM UTC-8, Sean M=
iddleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>The implicit safety you're implying here assumes that the user is =
aware that -> on a weak_ptr is only usable for expressions that outlive =
the lifetime of the temporary returned by ->. That's just far too big of=
a surface area to expect. It would mean very "obvious" code like the follo=
wing would now compile but be dangerously broken:</div><div><br></div><div>=
weak_ptr<Thing> ptr =3D get_thing();</div><div> auto&=
; foo =3D ptr->some_member;</div><div> use(foo); // foo might be l=
ong gone by this point</div><div><br></div><div>Without comprehensive lifet=
ime tracking a la Rust, there's not a lot of ways to achieve both convenien=
ce and safety for your case, as the language has no way to know that the li=
fetime of `foo` is dependent on the lifetime of the temporary returned by `=
ptr->`. While yes, we do have other similar surprises lurking in C++ alr=
eady, there's no good reason to add yet another hidden trap just to save a =
few characters of typing.</div><div><br></div><div>On Thursday, January 15,=
2015 at 1:51:01 PM UTC-8, Taylor Holliday wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">This would be implemented as follows:<div><b=
r></div><div><pre style=3D"margin-bottom:10px;padding:5px;font-size:14px;ba=
ckground-color:rgb(238,238,238);font-family:Consolas,Menlo,Monaco,'Lucida C=
onsole','Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Co=
urier New',monospace,serif;overflow:auto;width:auto;max-height:600px;word-w=
rap:normal;color:rgb(0,0,0);line-height:17.804800033569336px"><code style=
=3D"font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','D=
ejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace,serif;w=
hite-space:inherit"><span style=3D"background-color:transparent"> std</sp=
an><span style=3D"background-color:transparent">::</span><span style=3D"bac=
kground-color:transparent">shared_ptr</span><span style=3D"background-color=
:transparent"><</span><span style=3D"background-color:transparent">T</sp=
an><span style=3D"background-color:transparent">></span><span style=3D"b=
ackground-color:transparent"> </span><span style=3D"background-color:transp=
arent;color:rgb(0,0,139)">operator</span><span style=3D"background-color:tr=
ansparent">->()</span><span style=3D"background-color:transparent"> </sp=
an><span style=3D"background-color:transparent">{</span><span style=3D"back=
ground-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">auto</span><span style=3D"background-color:transparent"> shared </span><s=
pan style=3D"background-color:transparent">=3D</span><span style=3D"backgro=
und-color:transparent"> lock</span><span style=3D"background-color:transpar=
ent">();</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">if</span><span style=3D"background-color:transparent">(</span><span style=
=3D"background-color:transparent">shared </span><span style=3D"background-c=
olor:transparent">=3D=3D</span><span style=3D"background-color:transparent"=
> </span><span style=3D"background-color:transparent;color:rgb(0,0,139)">nu=
llptr</span><span style=3D"background-color:transparent">)</span><span styl=
e=3D"background-color:transparent"> </span><span style=3D"background-color:=
transparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,=
139)">throw</span><span style=3D"background-color:transparent"> std</span><=
span style=3D"background-color:transparent">::</span><span style=3D"backgro=
und-color:transparent">bad_weak_ptr</span><span style=3D"background-color:t=
ransparent">();</span><span style=3D"background-color:transparent"> </span>=
<span style=3D"background-color:transparent;color:rgb(128,128,128)">// or s=
ome other exception</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent">}</span><span sty=
le=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">return</span><span style=3D"background-color:transparent"> shared</span><=
span style=3D"background-color:transparent">;</span><span style=3D"backgrou=
nd-color:transparent">
</span><span style=3D"background-color:transparent">}</span></code></pre>=
<div>The lifetime of the returned shared_ptr nicely scopes a member functio=
n call.</div><div><br></div><div>Thoughts? I assume this has been proposed =
before.</div><div><br></div><div>- Taylor</div></div></div></blockquote></d=
iv></div></blockquote></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_446_1486204452.1421369640668--
------=_Part_445_439500355.1421369640668--
.
Author: Taylor Holliday <wtholliday@gmail.com>
Date: Thu, 15 Jan 2015 17:16:35 -0800 (PST)
Raw View
------=_Part_451_1924837324.1421370995651
Content-Type: multipart/alternative;
boundary="----=_Part_452_1047246060.1421370995651"
------=_Part_452_1047246060.1421370995651
Content-Type: text/plain; charset=UTF-8
On Thursday, January 15, 2015 at 2:02:50 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 15 January 2015 at 15:51, Taylor Holliday <wthol...@gmail.com
> <javascript:>> wrote:
>
>> This would be implemented as follows:
>>
>> std::shared_ptr<T> operator->() {
>> auto shared = lock();
>> if(shared == nullptr) {
>> throw std::bad_weak_ptr(); // or some other exception
>> }
>> return shared;
>> }
>>
>> The lifetime of the returned shared_ptr nicely scopes a member function
>> call.
>>
>> Thoughts?
>>
>
> What is the use case (other than "we can")? It means that the caller
> isn't participating in ownership yet still expects someone else to be
> keeping the object alive. Why wouldn't I just pass a shared_ptr instead?
>
I was using weak_ptr in a template that expects something to behave like a
pointer. Ended up having to add a generic function overloaded on weak_ptr
that would lock (I couldn't simply pass in a shared_ptr). Turned out not to
be that bad actually.
>
> Note: if the answer is "to detect programming bugs", such as how some
> people abuse things like vector::at(), I am firmly against that, as that
> use case is far better served by asserts rather than pretending it is a
> recoverable error.
>
Oh man we are in different worlds. I subclassed vector to add range
checking to operator[] :-\
But point taken, since shared_ptr::operator-> is unsafe it would be kind of
weird if weak_ptr::operator-> threw.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (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/.
------=_Part_452_1047246060.1421370995651
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, January 15, 2015 at 2:02:50 PM UTC-8, Nevin "=
:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On 15 January 2015 at 15:51, Taylor Holliday <span dir=3D"ltr"><<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"HnoydAYqI_sJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">wthol...@gmail.com</a>>=
;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">This would be implemented as follows:<div><br></div=
><div><pre style=3D"margin-bottom:10px;padding:5px;font-size:14px;backgroun=
d-color:rgb(238,238,238);font-family:Consolas,Menlo,Monaco,'Lucida Console'=
,'Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier N=
ew',monospace,serif;overflow:auto;width:auto;max-height:600px;word-wrap:nor=
mal;color:rgb(0,0,0);line-height:17.804800033569336px"><code style=3D"font-=
family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu San=
s Mono','Bitstream Vera Sans Mono','Courier New',monospace,serif;white-spac=
e:inherit"><span style=3D"background-color:transparent"> std</span><span =
style=3D"background-color:transparent">::</span><span style=3D"background-c=
olor:transparent">shared_ptr</span><span style=3D"background-color:transpar=
ent"><</span><span style=3D"background-color:transparent">T</span><span =
style=3D"background-color:transparent">></span><span style=3D"background=
-color:transparent"> </span><span style=3D"background-color:transparent;col=
or:rgb(0,0,139)">operator</span><span style=3D"background-color:transparent=
">->()</span><span style=3D"background-color:transparent"> </span><span =
style=3D"background-color:transparent">{</span><span style=3D"background-co=
lor:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">auto</span><span style=3D"background-color:transparent"> shared </span><s=
pan style=3D"background-color:transparent">=3D</span><span style=3D"backgro=
und-color:transparent"> lock</span><span style=3D"background-color:transpar=
ent">();</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">if</span><span style=3D"background-color:transparent">(</span><span style=
=3D"background-color:transparent">shared </span><span style=3D"background-c=
olor:transparent">=3D=3D</span><span style=3D"background-color:transparent"=
> </span><span style=3D"background-color:transparent;color:rgb(0,0,139)">nu=
llptr</span><span style=3D"background-color:transparent">)</span><span styl=
e=3D"background-color:transparent"> </span><span style=3D"background-color:=
transparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,=
139)">throw</span><span style=3D"background-color:transparent"> std</span><=
span style=3D"background-color:transparent">::</span><span style=3D"backgro=
und-color:transparent">bad_weak_ptr</span><span style=3D"background-color:t=
ransparent">();</span><span style=3D"background-color:transparent"> </span>=
<span style=3D"background-color:transparent;color:rgb(128,128,128)">// or s=
ome other exception</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent">}</span><span sty=
le=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">return</span><span style=3D"background-color:transparent"> shared</span><=
span style=3D"background-color:transparent">;</span><span style=3D"backgrou=
nd-color:transparent">
</span><span style=3D"background-color:transparent">}</span></code></pre>=
<div>The lifetime of the returned shared_ptr nicely scopes a member functio=
n call.</div><div><br></div><div>Thoughts?<br clear=3D"all"></div></div></d=
iv></blockquote><div><br></div><div>What is the use case (other than "we ca=
n")? It means that the caller isn't participating in ownership yet st=
ill expects someone else to be keeping the object alive. Why wouldn't=
I just pass a shared_ptr instead?<br></div></div></div></div></blockquote>=
<div><br></div><div>I was using weak_ptr in a template that expects somethi=
ng to behave like a pointer. Ended up having to add a generic function over=
loaded on weak_ptr that would lock (I couldn't simply pass in a shared_ptr)=
.. Turned out not to be that bad actually.</div><div> </div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div><br></div><div>Note: if the answer is "to detect program=
ming bugs", such as how some people abuse things like vector::at(), I am fi=
rmly against that, as that use case is far better served by asserts rather =
than pretending it is a recoverable error.<br></div></div></div></div></blo=
ckquote><div><br></div><div>Oh man we are in different worlds. I subclassed=
vector to add range checking to operator[] :-\</div><div><br></div><div>Bu=
t point taken, since shared_ptr::operator-> is unsafe it would be kind o=
f weird if weak_ptr::operator-> threw.</div><div> </div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div></div></div>-- <br><div> Nevin ":-)" Liber <mail=
to:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Hnoyd=
AYqI_sJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord=
..com</a><wbr>> (847) 691-1404</div>
</div></div>
</blockquote></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_452_1047246060.1421370995651--
------=_Part_451_1924837324.1421370995651--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 16 Jan 2015 09:37:12 +0800
Raw View
--Apple-Mail=_92899319-87A7-4A11-AB0B-903CA8415367
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9316, at 9:16 AM, Taylor Holliday <wtholliday@gm=
ail.com> wrote:
>=20
> I was using weak_ptr in a template that expects something to behave like =
a pointer. Ended up having to add a generic function overloaded on weak_ptr=
that would lock (I couldn't simply pass in a shared_ptr). Turned out not t=
o be that bad actually.
weak_ptr isn=E2=80=99t a pointer, it=E2=80=99s a contract for getting a poi=
nter.
Perhaps weak_ptr should be an instance of a general =E2=80=9Cfancy pointer=
=E2=80=9D concept that transforms into something else when dereferenced. Da=
tabase queries are another use-case of this. Ordinary pointers and smart po=
inters should satisfy the concept with a trivial transformation.
--=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/.
--Apple-Mail=_92899319-87A7-4A11-AB0B-903CA8415367
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9316, at 9:16 AM, Taylor Holliday <<a href=3D"mailto:wtholliday@g=
mail.com" class=3D"">wtholliday@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D=
"">I was using weak_ptr in a template that expects something to behave like=
a pointer. Ended up having to add a generic function overloaded on weak_pt=
r that would lock (I couldn't simply pass in a shared_ptr). Turned out not =
to be that bad actually.</div></div></blockquote><br class=3D""></div><div>=
<font face=3D"Courier" class=3D"">weak_ptr</font> isn=E2=80=99t a pointer, =
it=E2=80=99s a contract for getting a pointer.</div><div><br class=3D""></d=
iv><div>Perhaps <font face=3D"Courier" class=3D"">weak_ptr</font> should be=
an instance of a general =E2=80=9Cfancy pointer=E2=80=9D concept that tran=
sforms into something else when dereferenced. Database queries are another =
use-case of this. Ordinary pointers and smart pointers should satisfy the c=
oncept with a trivial transformation.</div></body></html>
<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 />
--Apple-Mail=_92899319-87A7-4A11-AB0B-903CA8415367--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Fri, 16 Jan 2015 08:11:46 -0500
Raw View
--089e012277aeffba37050cc4b6f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jan 15, 2015 at 8:37 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9301=E2=80=9316, at 9:16 AM, Taylor Holliday <wtholliday@gm=
ail.com> wrote:
>
> I was using weak_ptr in a template that expects something to behave like =
a
> pointer. Ended up having to add a generic function overloaded on weak_ptr
> that would lock (I couldn't simply pass in a shared_ptr). Turned out not =
to
> be that bad actually.
>
>
> weak_ptr isn=E2=80=99t a pointer, it=E2=80=99s a contract for getting a p=
ointer.
>
Agreed, regardless of what the name might hint. The addition of
'operator->' would make it less obvious that it is *not* a pointer and
lead to a weird interface with 'operator->' but not 'operator*' or a way to
get the underlying object.
Today, even if the name is misleading, at least it is easy to teach that
'weak_ptr' is not a pointer but a mechanism to [possibly] obtain one.
This goes along with a recent request to provide "symmetry" to weak_ptr,
providing an aliasing constructor for 'weak_ptr' and an 'unlock' function
to 'shared_ptr'. I don't believe there is value of symmetry between a
pointer and a non-pointer type. But that is a different discussion.
David
--=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/.
--089e012277aeffba37050cc4b6f5
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 Thu, Jan 15, 2015 at 8:37 PM, David Krauss <span dir=3D"ltr"><<a =
href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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 style=3D"word-wrap:br=
eak-word"><span class=3D""><br><div><blockquote type=3D"cite"><div>On 2015=
=E2=80=9301=E2=80=9316, at 9:16 AM, Taylor Holliday <<a href=3D"mailto:w=
tholliday@gmail.com" target=3D"_blank">wtholliday@gmail.com</a>> wrote:<=
/div><br><div><div style=3D"font-family:Helvetica;font-size:12px;font-style=
:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-h=
eight:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px">I was using weak_ptr in a template that expects=
something to behave like a pointer. Ended up having to add a generic funct=
ion overloaded on weak_ptr that would lock (I couldn't simply pass in a=
shared_ptr). Turned out not to be that bad actually.</div></div></blockquo=
te><br></div></span><div><font face=3D"Courier">weak_ptr</font> isn=E2=80=
=99t a pointer, it=E2=80=99s a contract for getting a pointer.</div></div><=
/blockquote><div><br></div><div>Agreed, regardless of what the name might h=
int. The addition of 'operator->' =C2=A0would make it less obvio=
us that it is *not* a pointer and lead to a weird interface with 'opera=
tor->' but not 'operator*' or a way to get the underlying ob=
ject.</div><div>=C2=A0<br>Today, even if the name is misleading, at least i=
t is easy to teach that 'weak_ptr' is not a pointer but a mechanism=
to [possibly] obtain one.<br><br>This goes along with a recent request to =
provide "symmetry" to weak_ptr, providing an aliasing constructor=
for 'weak_ptr' and an 'unlock' function to 'shared_ptr=
'. I don't believe there is value of symmetry between a pointer and=
a non-pointer type. But that is a different discussion.<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 />
--089e012277aeffba37050cc4b6f5--
.
Author: Dmitry Akimov <akimov.dima@gmail.com>
Date: Sat, 17 Jan 2015 00:30:06 -0800 (PST)
Raw View
------=_Part_1540_303064314.1421483406990
Content-Type: multipart/alternative;
boundary="----=_Part_1541_1918198361.1421483406990"
------=_Part_1541_1918198361.1421483406990
Content-Type: text/plain; charset=UTF-8
weak_ptr is generally a hazardous thing that must be operated very
carefully and consciously by its user. I even think that it is wrong to
have *anything *but a conversion to a shared_ptr on this type because
somebody may be tempted to write code like below:
weak_ptr<Foo> fooWeakPtr;
if (!fooWeakPtr.expired()) {
fooWeakPtr.lock()->CallMethod();
}
with your suggestion making it even easier and normal-looking:
weak_ptr<Foo> fooWeakPtr;
if (!fooWeakPtr.expired()) {
fooWeakPtr->CallMethod();
}
It is generally a bad idea to try to improve usability of hazardous stuff.
On Friday, January 16, 2015 at 12:51:01 AM UTC+3, Taylor Holliday wrote:
>
> This would be implemented as follows:
>
> std::shared_ptr<T> operator->() {
> auto shared = lock();
> if(shared == nullptr) {
> throw std::bad_weak_ptr(); // or some other exception
> }
> return shared;
> }
>
> The lifetime of the returned shared_ptr nicely scopes a member function
> call.
>
> Thoughts? I assume this has been proposed before.
>
> - Taylor
>
--
---
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_1541_1918198361.1421483406990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">weak_ptr is generally a hazardous thing that must be opera=
ted very carefully and consciously by its user. I even think that it is wro=
ng to have <i>anything </i>but a conversion to a shared_ptr on this type be=
cause somebody may be tempted to write code like below:<div><br></div><div>=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint">w=
eak_ptr<Foo> fooWeakPtr;</div><div class=3D"subprettyprint"> </d=
iv><div class=3D"subprettyprint">if (!fooWeakPtr.expired()) {</div><div cla=
ss=3D"subprettyprint"> fooWeakPtr.lock()->CallMethod();</di=
v><div class=3D"subprettyprint">}</div></div></code></div><div><br></div><d=
iv>with your suggestion making it even easier and normal-looking:</div><div=
><br></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 1=
87, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"subpre=
ttyprint">weak_ptr<Foo> fooWeakPtr;</div><div class=3D"subprettyprint=
"> </div><div class=3D"subprettyprint">if (!fooWeakPtr.expired()) {</d=
iv><div class=3D"subprettyprint"> fooWeakPtr->CallMethod();=
</div><div class=3D"subprettyprint">}</div></div></code></div><div><br></di=
v><div>It is generally a bad idea to try to improve usability of hazardous =
stuff.</div><div><br></div>On Friday, January 16, 2015 at 12:51:01 AM UTC+3=
, Taylor Holliday wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">This would be implemented as follows:<div><br></div><div><pre st=
yle=3D"margin-bottom:10px;padding:5px;font-size:14px;background-color:rgb(2=
38,238,238);font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation =
Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace=
,serif;overflow:auto;width:auto;max-height:600px;word-wrap:normal;color:rgb=
(0,0,0);line-height:17.804800033569336px"><code style=3D"font-family:Consol=
as,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bits=
tream Vera Sans Mono','Courier New',monospace,serif;white-space:inherit"><s=
pan style=3D"background-color:transparent"> std</span><span style=3D"back=
ground-color:transparent">::</span><span style=3D"background-color:transpar=
ent">shared_ptr</span><span style=3D"background-color:transparent"><</sp=
an><span style=3D"background-color:transparent">T</span><span style=3D"back=
ground-color:transparent">></span><span style=3D"background-color:transp=
arent"> </span><span style=3D"background-color:transparent;color:rgb(0,0,13=
9)">operator</span><span style=3D"background-color:transparent">->()</sp=
an><span style=3D"background-color:transparent"> </span><span style=3D"back=
ground-color:transparent">{</span><span style=3D"background-color:transpare=
nt">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">auto</span><span style=3D"background-color:transparent"> shared </span><s=
pan style=3D"background-color:transparent">=3D</span><span style=3D"backgro=
und-color:transparent"> lock</span><span style=3D"background-color:transpar=
ent">();</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">if</span><span style=3D"background-color:transparent">(</span><span style=
=3D"background-color:transparent">shared </span><span style=3D"background-c=
olor:transparent">=3D=3D</span><span style=3D"background-color:transparent"=
> </span><span style=3D"background-color:transparent;color:rgb(0,0,139)">nu=
llptr</span><span style=3D"background-color:transparent">)</span><span styl=
e=3D"background-color:transparent"> </span><span style=3D"background-color:=
transparent">{</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,=
139)">throw</span><span style=3D"background-color:transparent"> std</span><=
span style=3D"background-color:transparent">::</span><span style=3D"backgro=
und-color:transparent">bad_weak_ptr</span><span style=3D"background-color:t=
ransparent">();</span><span style=3D"background-color:transparent"> </span>=
<span style=3D"background-color:transparent;color:rgb(128,128,128)">// or s=
ome other exception</span><span style=3D"background-color:transparent">
</span><span style=3D"background-color:transparent">}</span><span sty=
le=3D"background-color:transparent">
</span><span style=3D"background-color:transparent;color:rgb(0,0,139)=
">return</span><span style=3D"background-color:transparent"> shared</span><=
span style=3D"background-color:transparent">;</span><span style=3D"backgrou=
nd-color:transparent">
</span><span style=3D"background-color:transparent">}</span></code></pre>=
<div>The lifetime of the returned shared_ptr nicely scopes a member functio=
n call.</div><div><br></div><div>Thoughts? I assume this has been proposed =
before.</div><div><br></div><div>- Taylor</div></div></div></blockquote></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_1541_1918198361.1421483406990--
------=_Part_1540_303064314.1421483406990--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 17 Jan 2015 17:10:07 -0500
Raw View
--089e0158b86e21f64b050ce05a5f
Content-Type: text/plain; charset=UTF-8
On Thu, Jan 15, 2015 at 7:54 PM, Taylor Holliday <wtholliday@gmail.com>
wrote:
> Hmm. It seems pretty easy to shoot yourself in the foot that way anyway if
> you don't know what you're doing:
>
> weak_ptr<Thing> ptr = get_thing();
> auto& foo = ptr.lock()->some_member;
> use(foo); // foo might be long gone by this point
>
>
Yep, so let's not make it worse.
And note an important difference in form: x-> vs x()->
Any time you see function()-> you should question the lifetime of the
return.
Without the () it is easy to forget that x-> might be a function call, and
thus something to question.
Also I'd prefer not to end up with code like:
x = ptr->x;
y = ptr->y;
....
where each -> is a separate call to lock().
Tony
--
---
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/.
--089e0158b86e21f64b050ce05a5f
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 Thu, Jan 15, 2015 at 7:54 PM, Taylor Holliday <span dir=3D"ltr"><=
<a href=3D"mailto:wtholliday@gmail.com" target=3D"_blank">wtholliday@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Hmm. It seems pretty easy to shoot yourself in the foot that way anyway i=
f you don't know what you're doing:<div><br></div><div><span class=
=3D""><div>weak_ptr<Thing> ptr =3D get_thing();</div></span><div>auto=
& foo =3D ptr.lock()->some_member;</div><span class=3D""><div>use(fo=
o); // foo might be long gone by this point</div><br></span></div></div></b=
lockquote><div><br></div><div>Yep, so let's not make it worse.<br><br>A=
nd note an important difference in form: =C2=A0 x->=C2=A0 vs=C2=A0 x()-&=
gt;<br><br></div><div>Any time you see function()->=C2=A0 you should que=
stion the lifetime of the return.<br></div><div>Without the () it is easy t=
o forget that x-> might be a function call, and thus something to questi=
on.<br><br></div><div>Also I'd prefer not to end up with code like:<br>=
<br></div><div>x =3D ptr->x;<br></div><div>y =3D ptr->y;<br>...<br><b=
r></div><div>where each -> is a separate call to lock().<br><br></div><d=
iv>Tony<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 />
--089e0158b86e21f64b050ce05a5f--
.
Author: Taylor Holliday <wtholliday@gmail.com>
Date: Sat, 17 Jan 2015 15:08:36 -0800 (PST)
Raw View
------=_Part_2162_421750647.1421536116222
Content-Type: multipart/alternative;
boundary="----=_Part_2163_1667089029.1421536116222"
------=_Part_2163_1667089029.1421536116222
Content-Type: text/plain; charset=UTF-8
This paper by Stroustrup would seem to endorse my suggestion, no?
http://www.stroustrup.com/wrapper.pdf
On Saturday, January 17, 2015 at 2:10:10 PM UTC-8, Tony V E wrote:
>
>
>
> On Thu, Jan 15, 2015 at 7:54 PM, Taylor Holliday <wthol...@gmail.com
> <javascript:>> wrote:
>
>> Hmm. It seems pretty easy to shoot yourself in the foot that way anyway
>> if you don't know what you're doing:
>>
>> weak_ptr<Thing> ptr = get_thing();
>> auto& foo = ptr.lock()->some_member;
>> use(foo); // foo might be long gone by this point
>>
>>
> Yep, so let's not make it worse.
>
> And note an important difference in form: x-> vs x()->
>
> Any time you see function()-> you should question the lifetime of the
> return.
> Without the () it is easy to forget that x-> might be a function call, and
> thus something to question.
>
> Also I'd prefer not to end up with code like:
>
> x = ptr->x;
> y = ptr->y;
> ...
>
> where each -> is a separate call to lock().
>
> Tony
>
--
---
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_2163_1667089029.1421536116222
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"" style=3D"color: rgb(0, 0, 0); font-family:=
Helvetica; font-size: 12px;">This paper by Stroustrup would seem to endors=
e my suggestion, no?</div><div class=3D"" style=3D"color: rgb(0, 0, 0); fon=
t-family: Helvetica; font-size: 12px;"><br class=3D""></div><div class=3D""=
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;"><a=
href=3D"http://www.stroustrup.com/wrapper.pdf" class=3D"">http://www.strou=
strup.com/wrapper.pdf</a></div><div><br></div><br>On Saturday, January 17, =
2015 at 2:10:10 PM UTC-8, Tony V E wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Thu,=
Jan 15, 2015 at 7:54 PM, Taylor Holliday <span dir=3D"ltr"><<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fEYnVvha-eMJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">wthol...@gmail.com</a>></sp=
an> 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">Hmm. It seems=
pretty easy to shoot yourself in the foot that way anyway if you don't kno=
w what you're doing:<div><br></div><div><span><div>weak_ptr<Thing> pt=
r =3D get_thing();</div></span><div>auto& foo =3D ptr.lock()->some_m=
ember;</div><span><div>use(foo); // foo might be long gone by this point</d=
iv><br></span></div></div></blockquote><div><br></div><div>Yep, so let's no=
t make it worse.<br><br>And note an important difference in form: x-=
> vs x()-><br><br></div><div>Any time you see function()-=
> you should question the lifetime of the return.<br></div><div>Wi=
thout the () it is easy to forget that x-> might be a function call, and=
thus something to question.<br><br></div><div>Also I'd prefer not to end u=
p with code like:<br><br></div><div>x =3D ptr->x;<br></div><div>y =3D pt=
r->y;<br>...<br><br></div><div>where each -> is a separate call to lo=
ck().<br><br></div><div>Tony<br></div></div></div></div>
</blockquote></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_2163_1667089029.1421536116222--
------=_Part_2162_421750647.1421536116222--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 17 Jan 2015 19:16:14 -0500
Raw View
--089e0158b86e1c1127050ce21df2
Content-Type: text/plain; charset=UTF-8
On Sat, Jan 17, 2015 at 6:08 PM, Taylor Holliday <wtholliday@gmail.com>
wrote:
> This paper by Stroustrup would seem to endorse my suggestion, no?
>
> http://www.stroustrup.com/wrapper.pdf
>
>
>
No.
- if A then B doesn't mean if B then A.
Stroustrup is saying *some* wrapping makes sense (or is common, whether it
makes sense or not), not that your wrapping makes sense - ie he doesn't
mention weak pointers
- that paper is 15 years old, I'm not sure even Stroustrup agrees with it
IMO, his wrapper might make sense for trace-logging, but I still wouldn't
recommend it for mutex locking (even if he mentions that as an example),
and I suspect he wouldn't really recommend it for locking either - locking
on each access is too inefficient, and you don't get a consistent snap-shot
of the object you are accessing (ie between ptr->x and ptr->y accesses, the
object could change - is that expected?). I think the locking example
falls into the "common" or "possible" category, not the "recommended"
category.
Also, even if Stroustrup thought your suggestion was great (and I honestly
doubt he would), I even more highly doubt the rest of the committee (in
particular the library sub committee, which I am more familiar with) would
agree with it. (And even though Stroustrup is smart and has lots of say in
the committee, if the rest of the committee disagrees, it doesn't happen)
But it does highlight that weak_ptr is somewhat poorly named. Thanks. I
think naming is important; unfortunately too late for this one :-(
Tony
On Saturday, January 17, 2015 at 2:10:10 PM UTC-8, Tony V E wrote:
>
>>
>>
>> On Thu, Jan 15, 2015 at 7:54 PM, Taylor Holliday <wthol...@gmail.com>
>> wrote:
>>
>>> Hmm. It seems pretty easy to shoot yourself in the foot that way anyway
>>> if you don't know what you're doing:
>>>
>>> weak_ptr<Thing> ptr = get_thing();
>>> auto& foo = ptr.lock()->some_member;
>>> use(foo); // foo might be long gone by this point
>>>
>>>
>> Yep, so let's not make it worse.
>>
>> And note an important difference in form: x-> vs x()->
>>
>> Any time you see function()-> you should question the lifetime of the
>> return.
>> Without the () it is easy to forget that x-> might be a function call,
>> and thus something to question.
>>
>> Also I'd prefer not to end up with code like:
>>
>> x = ptr->x;
>> y = ptr->y;
>> ...
>>
>> where each -> is a separate call to lock().
>>
>> Tony
>>
> --
>
> ---
> 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/.
--089e0158b86e1c1127050ce21df2
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 Sat, Jan 17, 2015 at 6:08 PM, Taylor Holliday <span dir=3D"ltr"><=
<a href=3D"mailto:wtholliday@gmail.com" target=3D"_blank">wtholliday@gmail.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px">This=
paper by Stroustrup would seem to endorse my suggestion, no?</div><div sty=
le=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div=
style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><a href=3D=
"http://www.stroustrup.com/wrapper.pdf" target=3D"_blank">http://www.strous=
trup.com/wrapper.pdf</a></div><div><br></div><br></div></blockquote><div><b=
r></div><div>No.<br><br></div><div>-=C2=A0 if A then B doesn't mean if =
B then A.<br>Stroustrup is saying *some* wrapping makes sense (or is common=
, whether it makes sense or not), not that your wrapping makes sense - ie h=
e doesn't mention weak pointers<br></div><div>- that paper is 15 years =
old, I'm not sure even Stroustrup agrees with it<br><br></div><div>IMO,=
his wrapper might make sense for trace-logging, but I still wouldn't r=
ecommend it for mutex locking (even if he mentions that as an example), and=
I suspect he wouldn't really recommend it for locking either - locking=
on each access is too inefficient, and you don't get a consistent snap=
-shot of the object you are accessing (ie between ptr->x and ptr->y a=
ccesses, the object could change - is that expected?).=C2=A0 I think the lo=
cking example falls into the "common" or "possible" cat=
egory, not the "recommended" category.<br><br></div>Also, even if=
Stroustrup thought your suggestion was great (and I honestly doubt he woul=
d), I even more highly doubt the rest of the committee (in particular the l=
ibrary sub committee, which I am more familiar with) would agree with it.=
=C2=A0 (And even though Stroustrup is smart and has lots of say in the comm=
ittee, if the rest of the committee disagrees, it doesn't happen)<br><b=
r></div><div class=3D"gmail_quote">But it does highlight that weak_ptr is s=
omewhat poorly named.=C2=A0 Thanks.=C2=A0 I think naming is important; unfo=
rtunately too late for this one :-(<br><br></div><div class=3D"gmail_quote"=
>Tony<br><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On S=
aturday, January 17, 2015 at 2:10:10 PM UTC-8, Tony V E wrote:<div><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><div cla=
ss=3D"gmail_quote">On Thu, Jan 15, 2015 at 7:54 PM, Taylor Holliday <span d=
ir=3D"ltr"><<a rel=3D"nofollow">wthol...@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hmm. It seems pretty ea=
sy to shoot yourself in the foot that way anyway if you don't know what=
you're doing:<div><br></div><div><span><div>weak_ptr<Thing> ptr =
=3D get_thing();</div></span><div>auto& foo =3D ptr.lock()->some_mem=
ber;</div><span><div>use(foo); // foo might be long gone by this point</div=
><br></span></div></div></blockquote><div><br></div><div>Yep, so let's =
not make it worse.<br><br>And note an important difference in form: =C2=A0 =
x->=C2=A0 vs=C2=A0 x()-><br><br></div><div>Any time you see function(=
)->=C2=A0 you should question the lifetime of the return.<br></div><div>=
Without the () it is easy to forget that x-> might be a function call, a=
nd thus something to question.<br><br></div><div>Also I'd prefer not to=
end up with code like:<br><br></div><div>x =3D ptr->x;<br></div><div>y =
=3D ptr->y;<br>...<br><br></div><div>where each -> is a separate call=
to lock().<br><br></div><div>Tony<br></div></div></div></div>
</blockquote></div></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" 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><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 />
--089e0158b86e1c1127050ce21df2--
.
Author: Taylor Holliday <wtholliday@gmail.com>
Date: Sun, 18 Jan 2015 12:32:45 -0800 (PST)
Raw View
------=_Part_143_1950021672.1421613165204
Content-Type: multipart/alternative;
boundary="----=_Part_144_1266304437.1421613165204"
------=_Part_144_1266304437.1421613165204
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 17, 2015 at 4:16:17 PM UTC-8, Tony V E wrote:
>
>
>
> On Sat, Jan 17, 2015 at 6:08 PM, Taylor Holliday <wthol...@gmail.com=20
> <javascript:>> wrote:
>
>> This paper by Stroustrup would seem to endorse my suggestion, no?
>>
>> http://www.stroustrup.com/wrapper.pdf
>>
>>
>>
> No.
>
> - if A then B doesn't mean if B then A.
> Stroustrup is saying *some* wrapping makes sense (or is common, whether i=
t=20
> makes sense or not), not that your wrapping makes sense - ie he doesn't=
=20
> mention weak pointers
> - that paper is 15 years old, I'm not sure even Stroustrup agrees with it
>
The paper says uses the following as example:
grab-lock do-something release-lock=20
and that is what I was proposing. The primary difference is that in this=20
case the lock can fail and throw. You=E2=80=99re right, it doesn=E2=80=99t =
mention weak=20
pointers. But it does endorse the ideas that it is ok in some cases to have=
=20
operator-> without operator* and that successive locking isn=E2=80=99t nece=
ssarily=20
terrible.
Fair point about the paper being old. It might be completely irrelevant.
=20
>
> IMO, his wrapper might make sense for trace-logging, but I still wouldn't=
=20
> recommend it for mutex locking (even if he mentions that as an example),=
=20
> and I suspect he wouldn't really recommend it for locking either - lockin=
g=20
> on each access is too inefficient, and you don't get a consistent snap-sh=
ot=20
> of the object you are accessing (ie between ptr->x and ptr->y accesses, t=
he=20
> object could change - is that expected?). I think the locking example=20
> falls into the "common" or "possible" category, not the "recommended"=20
> category.
>
The concern about efficiency seems like premature optimization to me.
The other concern regarding changes between accesses seems more legitimate.
What are the approaches taken in other languages? ObjC and Swift treat weak=
=20
references like how I propose: there is no explicit locking.
> But it does highlight that weak_ptr is somewhat poorly named. Thanks. I=
=20
> think naming is important; unfortunately too late for this one :-(
>
> Tony
>
>
What could it have been called?
--=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_144_1266304437.1421613165204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, January 17, 2015 at 4:16:17 PM UTC-8,=
Tony V E 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"lt=
r"><br><div><br><div class=3D"gmail_quote">On Sat, Jan 17, 2015 at 6:08 PM,=
Taylor Holliday <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"wUuEs9LNQ7EJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">wthol...@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div style=3D"color:rgb(0,0,0);font-fa=
mily:Helvetica;font-size:12px">This paper by Stroustrup would seem to endor=
se my suggestion, no?</div><div style=3D"color:rgb(0,0,0);font-family:Helve=
tica;font-size:12px"><br></div><div style=3D"color:rgb(0,0,0);font-family:H=
elvetica;font-size:12px"><a href=3D"http://www.stroustrup.com/wrapper.pdf" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.stroustrup.com%2Fwrapper.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNG3w7G5vGZrX-qJiDtzBsL5d2uTGA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stroustrup.=
com%2Fwrapper.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNG3w7G5vGZrX-qJiDtzBsL5=
d2uTGA';return true;">http://www.stroustrup.com/<wbr>wrapper.pdf</a></div><=
div><br></div><br></div></blockquote><div><br></div><div>No.<br><br></div><=
div>- if A then B doesn't mean if B then A.<br>Stroustrup is saying *=
some* wrapping makes sense (or is common, whether it makes sense or not), n=
ot that your wrapping makes sense - ie he doesn't mention weak pointers<br>=
</div><div>- that paper is 15 years old, I'm not sure even Stroustrup agree=
s with it<br></div></div></div></div></blockquote><div><br></div><div style=
=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;">The pape=
r says uses the following as example:</div><div style=3D"color: rgb(0, 0, 0=
); font-family: Helvetica; font-size: 12px;"><br></div><div style=3D"color:=
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;"><div class=3D"page=
" title=3D"Page 1"><div class=3D"layoutArea"><div class=3D"column"><p class=
=3D""><span class=3D"" style=3D"font-size: 9pt; font-family: Times; font-st=
yle: italic;">grab</span><span class=3D"" style=3D"font-size: 9pt; font-fam=
ily: Courier;">-</span><span class=3D"" style=3D"font-size: 9pt; font-famil=
y: Times; font-style: italic;">lock do</span><span class=3D"" style=3D"font=
-size: 9pt; font-family: Courier;">-</span><span class=3D"" style=3D"font-s=
ize: 9pt; font-family: Times; font-style: italic;">something release</span>=
<span class=3D"" style=3D"font-size: 9pt; font-family: Courier;">-</span><s=
pan class=3D"" style=3D"font-size: 9pt; font-family: Times; font-style: ita=
lic;">lock </span></p></div></div></div></div><div style=3D"color: rgb=
(0, 0, 0); font-family: Helvetica; font-size: 12px;">and that is what I was=
proposing. The primary difference is that in this case the lock can fail a=
nd throw. You=E2=80=99re right, it doesn=E2=80=99t mention weak pointers. B=
ut it does endorse the ideas that it is ok in some cases to have operator-&=
gt; without operator* and that successive locking isn=E2=80=99t necessarily=
terrible.</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px;"><br class=3D""></div><div><span style=3D"color: rgb(0, 0,=
0); font-family: Helvetica; font-size: 12px;">Fair point about the paper b=
eing old. It might be completely irrelevant.</span></div><div> </div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div><br></div><div>IMO, his wrapper might make sense for=
trace-logging, but I still wouldn't recommend it for mutex locking (even i=
f he mentions that as an example), and I suspect he wouldn't really recomme=
nd it for locking either - locking on each access is too inefficient, and y=
ou don't get a consistent snap-shot of the object you are accessing (ie bet=
ween ptr->x and ptr->y accesses, the object could change - is that ex=
pected?). I think the locking example falls into the "common" or "pos=
sible" category, not the "recommended" category.<br></div></div></div></div=
></blockquote><div><br></div><div style=3D"color: rgb(0, 0, 0); font-family=
: Helvetica; font-size: 12px;">The concern about efficiency seems like prem=
ature optimization to me.</div><div style=3D"color: rgb(0, 0, 0); font-fami=
ly: Helvetica; font-size: 12px;"><br class=3D""></div><div style=3D"color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;">The other concern r=
egarding changes between accesses seems more legitimate.</div><div style=3D=
"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;"><br class=
=3D""></div><div><span style=3D"color: rgb(0, 0, 0); font-family: Helvetica=
; font-size: 12px;">What are the approaches taken in other languages? ObjC =
and Swift treat weak references like how I propose: there is no explicit lo=
cking.</span></div><div><span style=3D"color: rgb(0, 0, 0); font-family: He=
lvetica; font-size: 12px;"><br></span></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">But it does highlight that weak_ptr is somewhat po=
orly named. Thanks. I think naming is important; unfortunately =
too late for this one :-(<br><br></div><div class=3D"gmail_quote">Tony<br><=
br></div></div></div></blockquote><div><br></div><div><span style=3D"color:=
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;">What could it have=
been called?</span></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_144_1266304437.1421613165204--
------=_Part_143_1950021672.1421613165204--
.