Topic: weak_ptr lock API and shared_ptr constructor
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 4 Aug 2017 07:55:05 -0700 (PDT)
Raw View
------=_Part_682_990572089.1501858505212
Content-Type: multipart/alternative;
boundary="----=_Part_683_1297350012.1501858505212"
------=_Part_683_1297350012.1501858505212
Content-Type: text/plain; charset="UTF-8"
On Friday, August 4, 2017 at 10:05:28 AM UTC-4, husain jiruwala wrote:
>
> Suggestion here is that lock API of weak_ptr and shared_ptr ctor which
> takes weak_ptr as argument should atomically call reset on weak_ptr when
> they fail to create a shared_ptr out of weak_ptr
>
Well currently, `weak_ptr::lock()` is a `const` function, and the
constructor that takes a `weak_ptr` likewise takes a `const&`. So changing
this behavior will require either changing these interfaces (which can
break people's code) or effectively saying that these functions can modify
the `weak_ptr`, but not in visible ways.
But here's the thing: the behavior you want is technically possible *right
now*. After all, an empty `weak_ptr` and an expired `weak_ptr` are
equivalent, from the user's perspective. So you could implement `weak_ptr`
to store the shared state pointer in a `mutable` member, thus allowing it
to be changed during these operations.
I don't think it's a good idea to actually enforce such behavior. There are
downsides to doing so. For example, your atomicity requirement. That
doesn't sound like something you can do with a simple atomic operation. It
seems like it would require a real mutex, which ups the cost of `lock`ing a
`weak_ptr`.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/50f73d0d-76be-4fa6-888c-c85b7e3ad587%40isocpp.org.
------=_Part_683_1297350012.1501858505212
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 4, 2017 at 10:05:28 AM UTC-4, husain jir=
uwala wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">S=
uggestion here is that lock API of weak_ptr and shared_ptr ctor which takes=
weak_ptr as argument should atomically call reset on weak_ptr when they fa=
il to create a shared_ptr out of weak_ptr</div></blockquote><div><br>Well c=
urrently, `weak_ptr::lock()` is a `const` function, and the=20
constructor that takes a `weak_ptr` likewise takes a `const&`. So=20
changing this behavior will require either changing these interfaces (which=
can break people's code) or effectively saying that these functions ca=
n modify the `weak_ptr`, but not in visible ways.<br><br>But here's the=
thing: the behavior you want is technically possible <i>right now</i>. Aft=
er all, an empty `weak_ptr` and an expired `weak_ptr` are equivalent, from =
the user's perspective. So you could implement `weak_ptr` to store the =
shared state pointer in a `mutable` member, thus allowing it to be changed =
during these operations.<br><br>I don't think it's a good idea to a=
ctually enforce such behavior. There are downsides to doing so. For example=
, your atomicity requirement. That doesn't sound like something you can=
do with a simple atomic operation. It seems like it would require a real m=
utex, which ups the cost of `lock`ing a `weak_ptr`.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/50f73d0d-76be-4fa6-888c-c85b7e3ad587%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/50f73d0d-76be-4fa6-888c-c85b7e3ad587=
%40isocpp.org</a>.<br />
------=_Part_683_1297350012.1501858505212--
------=_Part_682_990572089.1501858505212--
.
Author: husain jiruwala <husain.255@gmail.com>
Date: Sun, 6 Aug 2017 22:57:22 -0700 (PDT)
Raw View
------=_Part_2892_1347110043.1502085442376
Content-Type: multipart/alternative;
boundary="----=_Part_2893_420483449.1502085442376"
------=_Part_2893_420483449.1502085442376
Content-Type: text/plain; charset="UTF-8"
Agreed.
Thanks
On Friday, 4 August 2017 20:25:05 UTC+5:30, Nicol Bolas wrote:
>
> On Friday, August 4, 2017 at 10:05:28 AM UTC-4, husain jiruwala wrote:
>>
>> Suggestion here is that lock API of weak_ptr and shared_ptr ctor which
>> takes weak_ptr as argument should atomically call reset on weak_ptr when
>> they fail to create a shared_ptr out of weak_ptr
>>
>
> Well currently, `weak_ptr::lock()` is a `const` function, and the
> constructor that takes a `weak_ptr` likewise takes a `const&`. So changing
> this behavior will require either changing these interfaces (which can
> break people's code) or effectively saying that these functions can modify
> the `weak_ptr`, but not in visible ways.
>
> But here's the thing: the behavior you want is technically possible *right
> now*. After all, an empty `weak_ptr` and an expired `weak_ptr` are
> equivalent, from the user's perspective. So you could implement `weak_ptr`
> to store the shared state pointer in a `mutable` member, thus allowing it
> to be changed during these operations.
>
> I don't think it's a good idea to actually enforce such behavior. There
> are downsides to doing so. For example, your atomicity requirement. That
> doesn't sound like something you can do with a simple atomic operation. It
> seems like it would require a real mutex, which ups the cost of `lock`ing a
> `weak_ptr`.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02fc455b-71c7-4837-aa14-8fdae7a0b712%40isocpp.org.
------=_Part_2893_420483449.1502085442376
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agreed.<div><br></div><div>Thanks<br><br>On Friday, 4 Augu=
st 2017 20:25:05 UTC+5:30, Nicol Bolas wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">On Friday, August 4, 2017 at 10:05:28 AM U=
TC-4, husain jiruwala wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Suggestion here is that lock API of weak_ptr and shared_ptr ctor =
which takes weak_ptr as argument should atomically call reset on weak_ptr w=
hen they fail to create a shared_ptr out of weak_ptr</div></blockquote><div=
><br>Well currently, `weak_ptr::lock()` is a `const` function, and the=20
constructor that takes a `weak_ptr` likewise takes a `const&`. So=20
changing this behavior will require either changing these interfaces (which=
can break people's code) or effectively saying that these functions ca=
n modify the `weak_ptr`, but not in visible ways.<br><br>But here's the=
thing: the behavior you want is technically possible <i>right now</i>. Aft=
er all, an empty `weak_ptr` and an expired `weak_ptr` are equivalent, from =
the user's perspective. So you could implement `weak_ptr` to store the =
shared state pointer in a `mutable` member, thus allowing it to be changed =
during these operations.<br><br>I don't think it's a good idea to a=
ctually enforce such behavior. There are downsides to doing so. For example=
, your atomicity requirement. That doesn't sound like something you can=
do with a simple atomic operation. It seems like it would require a real m=
utex, which ups the cost of `lock`ing a `weak_ptr`.<br></div></div></blockq=
uote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02fc455b-71c7-4837-aa14-8fdae7a0b712%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02fc455b-71c7-4837-aa14-8fdae7a0b712=
%40isocpp.org</a>.<br />
------=_Part_2893_420483449.1502085442376--
------=_Part_2892_1347110043.1502085442376--
.