Topic: RFC: Adding Symmetry Between shared_ptr and weak_ptr
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 10 Jan 2015 11:01:53 -0800 (PST)
Raw View
------=_Part_346_1649129070.1420916513874
Content-Type: multipart/alternative;
boundary="----=_Part_347_494773300.1420916513877"
------=_Part_347_494773300.1420916513877
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I've got a rough draft of a proposal for the next meeting in May, and would=
=20
like to hear anyone's feedback on the format and content before then.
https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html
The TL;DR is that it proposes two very small new library features:
- shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr, symmetric=
=20
with weak_ptr::lock()
- An two-argument constructor for weak_ptr(), symmetric with shared_ptr's=
=20
two-argument constructor
=E2=80=93Arthur
--=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_347_494773300.1420916513877
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've got a rough draft of a proposal for the next mee=
ting in May, and would like to hear anyone's feedback on the format and con=
tent before then.</div><div><br></div>https://quuxplusone.github.io/draft/N=
weak_ptr_proposal.html<br><div><br></div><div>The TL;DR is that it proposes=
two very small new library features:</div><div>- shared_ptr::unlock(), whi=
ch turns a shared_ptr into a weak_ptr, symmetric with weak_ptr::lock()</div=
><div>- An two-argument constructor for weak_ptr(), symmetric with shared_p=
tr's two-argument constructor</div><div><br></div><div>=E2=80=93Arthur</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_347_494773300.1420916513877--
------=_Part_346_1649129070.1420916513874--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Jan 2015 21:10:57 +0200
Raw View
On 10 January 2015 at 21:01, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> I've got a rough draft of a proposal for the next meeting in May, and would
> like to hear anyone's feedback on the format and content before then.
>
> https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html
>
> The TL;DR is that it proposes two very small new library features:
> - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr, symmetric
> with weak_ptr::lock()
> - An two-argument constructor for weak_ptr(), symmetric with shared_ptr's
> two-argument constructor
Looks good to me, I found the rationale (and the whole proposal) very
reasonable and well-written.
--
---
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: gmisocpp@gmail.com
Date: Sat, 10 Jan 2015 13:26:19 -0800 (PST)
Raw View
------=_Part_394_719413188.1420925179890
Content-Type: multipart/alternative;
boundary="----=_Part_395_844518106.1420925179890"
------=_Part_395_844518106.1420925179890
Content-Type: text/plain; charset=UTF-8
Nice proposal.
On Sunday, January 11, 2015 at 8:10:59 AM UTC+13, Ville Voutilainen wrote:
>
> On 10 January 2015 at 21:01, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
> > I've got a rough draft of a proposal for the next meeting in May, and
> would
> > like to hear anyone's feedback on the format and content before then.
> >
> > https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html
> >
> > The TL;DR is that it proposes two very small new library features:
> > - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr,
> symmetric
> > with weak_ptr::lock()
> > - An two-argument constructor for weak_ptr(), symmetric with
> shared_ptr's
> > two-argument constructor
>
>
> Looks good to me, I found the rationale (and the whole proposal) very
> reasonable and well-written.
>
Ville, a few things slightly touched on by this proposal:
In your view, if the naming of lock/unlock is of
sufficient irritation, would it be so bad to add [[deprecated]] to the
existing names and/or add the preferred new ones?
And if there are sufficient other candidates where renaming might be
useful, like the empty() -> is_empty() example referenced; would collecting
the simpler cases up and having a consolidated proposal to fix them all
help procedure wise in general versus lots of individual cases? If so, we
could make a separate post asking for rename recommendations. I saw
renaming shared_mutex -> timed_shared_mutex or something was another rename
case floating around at one point, but I'm sure that one or some might be
better handled as separate proposals.
And is there any reason not to make [[warn_unused_result]].standard now?
Isn't it time we did that so this proposal and everyone can benefit from it?
I think I suggested this before but I think it got shot down. But I might
be wrong Right now I can't see why this attribute shouldn't be standard.
It seems like even things like strlen() would benefit from it. I mean why
calculate a strings length if you don't capture or use the result anywhere.
Something tells me someone will have a good reason, even for this
particular example lol.
--
---
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_395_844518106.1420925179890
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nice proposal.<br><br>On Sunday, January 11, 2015 at 8:10:=
59 AM UTC+13, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;">On 10 Ja=
nuary 2015 at 21:01, Arthur O'Dwyer <<a onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;" h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"TywIrdXFGqwJ=
">arthur....@gmail.com</a>> wrote:
<br>> I've got a rough draft of a proposal for the next meeting in May, =
and would
<br>> like to hear anyone's feedback on the format and content before th=
en.
<br>>
<br>> <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fquuxplusone.github.io%2Fdraft%2FNweak_ptr_proposal.html\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEpCBJmD4KOlkKAXe6DwO0kgU69zQ';return true;" oncli=
ck=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fquuxplusone=
..github.io%2Fdraft%2FNweak_ptr_proposal.html\46sa\75D\46sntz\0751\46usg\75A=
FQjCNEpCBJmD4KOlkKAXe6DwO0kgU69zQ';return true;" href=3D"https://quuxpluson=
e.github.io/draft/Nweak_ptr_proposal.html" target=3D"_blank">https://quuxpl=
usone.github.io/<wbr>draft/Nweak_ptr_proposal.html</a>
<br>>
<br>> The TL;DR is that it proposes two very small new library features:
<br>> - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr, =
symmetric
<br>> with weak_ptr::lock()
<br>> - An two-argument constructor for weak_ptr(), symmetric with share=
d_ptr's
<br>> two-argument constructor
<br>
<br>
<br>Looks good to me, I found the rationale (and the whole proposal) very
<br>reasonable and well-written.
<br></blockquote><div><br></div><div>Ville, a few things slightly touc=
hed on by this proposal:</div><div><br></div><div><div>In your view, i=
f the naming of lock/unlock is of sufficient irritation=
, would it be so bad to add [[deprecated]] to the exist=
ing names and/or add the preferred new ones?</div><div><br></div>=
<div>And if there are sufficient other candidates where renaming =
might be useful, like the empty() -> is_empty() example refere=
nced; would collecting the simpler cases up and having =
a consolidated proposal to fix them all help procedure wise in general vers=
us lots of individual cases? If so, we could make a separate post aski=
ng for rename recommendations. I saw renaming shared_mutex -> timed=
_shared_mutex or something was another rename case floating aroun=
d at one point, but I'm sure that one or some might be better han=
dled as separate proposals.</div><div><div><code><font face=3D"Arial">=
<br></font></code></div><div><code><font face=3D"Arial">And is there any re=
ason not to make</font> </code><code>[[warn_unused_result]]<=
/code>.standard now? Isn't it time we did that so this proposal and ev=
eryone can benefit from it?</div><div>I think I suggested this before but I=
think it got shot down. But I might be wrong Right now I can't see wh=
y this attribute shouldn't be standard.</div><div>It seems like even things=
like strlen() would benefit from it. I mean why calculate a strings length=
if you don't capture or use the result anywhere. Something tells me someon=
e will have a good reason, even for this particular example lol.<=
/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 />
------=_Part_395_844518106.1420925179890--
------=_Part_394_719413188.1420925179890--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 11 Jan 2015 10:02:06 +0200
Raw View
On 10 January 2015 at 23:26, <gmisocpp@gmail.com> wrote:
> Ville, a few things slightly touched on by this proposal:
>
> In your view, if the naming of lock/unlock is of sufficient irritation,
> would it be so bad to add [[deprecated]] to the existing names and/or add
> the preferred new ones?
Deprecate what, exactly? The conversion constructor of weak_ptr that takes
a shared_ptr? Why would that be deprecated?
> And if there are sufficient other candidates where renaming might be useful,
> like the empty() -> is_empty() example referenced; would collecting the
That function name is water under the bridge. If you want to entertain the
idea of changing it, you need to do so if/when a new standard library
is created.
> make a separate post asking for rename recommendations. I saw renaming
> shared_mutex -> timed_shared_mutex or something was another rename case
> floating around at one point, but I'm sure that one or some might be better
That renaming was already done.
> And is there any reason not to make [[warn_unused_result]].standard now?
How is that related to the proposal at hand?
--
---
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: gmisocpp@gmail.com
Date: Sun, 11 Jan 2015 03:07:06 -0800 (PST)
Raw View
------=_Part_1580_945259956.1420974426718
Content-Type: multipart/alternative;
boundary="----=_Part_1581_2047543633.1420974426718"
------=_Part_1581_2047543633.1420974426718
Content-Type: text/plain; charset=UTF-8
On Sunday, January 11, 2015 at 9:02:08 PM UTC+13, Ville Voutilainen wrote:
>
> On 10 January 2015 at 23:26, <gmis...@gmail.com <javascript:>> wrote:
> > Ville, a few things slightly touched on by this proposal:
> >
> > In your view, if the naming of lock/unlock is of sufficient irritation,
> > would it be so bad to add [[deprecated]] to the existing names and/or
> add
> > the preferred new ones?
>
> Deprecate what, exactly? The conversion constructor of weak_ptr that takes
> a shared_ptr? Why would that be deprecated?
>
The proposal says "If it were not too late to rename lock..." etc. so I was
wondering why it's too late to rename anything, but I misread things as
they go on to say basically it's fine so forget what I said here.
>
> > And if there are sufficient other candidates where renaming might be
> useful,
> > like the empty() -> is_empty() example referenced; would collecting the
>
> That function name is water under the bridge. If you want to entertain the
> idea of changing it, you need to do so if/when a new standard library
> is created.
>
> make a separate post asking for rename recommendations. I saw renaming
> shared_mutex -> timed_shared_mutex or something was another rename case
> floating around at one point, but I'm sure that one or some might be
better
That renaming was already done.
I was wondering generally if there was a bunch of undesirably named things
if the committee found it easier procedurally to collect them all up in a
batch to rename them or deal with each item as a individual proposal.
Anyway it doesn't matter if it's a distraction to this proposal.
>
>
> > And is there any reason not to make [[warn_unused_result]].standard now?
>
> How is that related to the proposal at hand?
>
It's related in so much as the OP's proposal directly refers to it and it's
come up before, but it's not essential to this proposal.
--
---
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_1581_2047543633.1420974426718
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, January 11, 2015 at 9:02:08 PM UTC+13, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;">On 10 January 2015 at =
23:26, <<a onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"VKTOoBxMUc0J">gmis...@gmail.com</a>=
> wrote:
<br>> Ville, a few things slightly touched on by this proposal:
<br>>
<br>> In your view, if the naming of lock/unlock is of sufficient irrita=
tion,
<br>> would it be so bad to add [[deprecated]] to the existing names and=
/or add
<br>> the preferred new ones?
<br>
<br>Deprecate what, exactly? The conversion constructor of weak_ptr that ta=
kes
<br>a shared_ptr? Why would that be deprecated?
<br></blockquote><div><br></div><div>The proposal says "If it were not too =
late to rename lock..." etc. so I was wondering why it's too late to rename=
anything, but I misread things as they go on to say basically it's fi=
ne so forget what I said here.</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>> And if there are sufficient other candidates where renaming might =
be useful,
<br>> like the empty() -> is_empty() example referenced; would collec=
ting the
<br>
<br>That function name is water under the bridge. If you want to entertain =
the
<br>idea of changing it, you need to do so if/when a new standard library
<br>is created.
<br></blockquote><div><br>> make a separate post asking for rename recom=
mendations. I saw renaming
<br>> shared_mutex -> timed_shared_mutex or something was another ren=
ame case
<br>> floating around at one point, but I'm sure that one or some might =
be better
<br>
<br>That renaming was already done.
</div><div><br></div><div><div>I was wondering generally if =
there was a bunch of undesirably named things if the committee found it eas=
ier procedurally to collect them all up in a batch to rename them or deal w=
ith each item as a individual proposal. Anyway it doesn't matter if it=
's a distraction to this proposal.</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><br>
<br>> And is there any reason not to make [[warn_unused_result]].<wbr>st=
andard now?
<br>
<br>How is that related to the proposal at hand?
<br></blockquote></div><div><br></div><div>It's related in so much as =
the OP's proposal directly refers to it and it's come up before, but&n=
bsp;it's not essential to this proposal.</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_1581_2047543633.1420974426718--
------=_Part_1580_945259956.1420974426718--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Jan 2015 19:54:51 +0800
Raw View
--Apple-Mail=_6A8AC0D9-5B26-4D4F-A7A0-1A527F56086C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9311, at 3:01 AM, Arthur O'Dwyer <arthur.j.odwye=
r@gmail.com> wrote:
>=20
> I've got a rough draft of a proposal for the next meeting in May, and wou=
ld like to hear anyone's feedback on the format and content before then.
There could be an rvalue-qualified overload of unlock() which does the rese=
t automatically.
auto wptr =3D std::move( sptr ).unlock();
--=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=_6A8AC0D9-5B26-4D4F-A7A0-1A527F56086C
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=9311, at 3:01 AM, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwy=
er@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">I've got a rough draft of a proposal for the next mee=
ting in May, and would like to hear anyone's feedback on the format and con=
tent before then.</div></div></div></blockquote><div><br class=3D""></div><=
div>There could be an rvalue-qualified overload of <font face=3D"Courier" c=
lass=3D"">unlock()</font> which does the reset automatically.</div><div><br=
class=3D""></div><div><font face=3D"Courier" class=3D"">auto wptr =3D std:=
:move( sptr ).unlock();</font></div></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=_6A8AC0D9-5B26-4D4F-A7A0-1A527F56086C--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 11 Jan 2015 13:56:02 +0200
Raw View
On 11 January 2015 at 13:07, <gmisocpp@gmail.com> wrote:
> I was wondering generally if there was a bunch of undesirably named things
> if the committee found it easier procedurally to collect them all up in a
> batch to rename them or deal with each item as a individual proposal. Anyway
> it doesn't matter if it's a distraction to this proposal.
Well, doing such large-scale renaming is hard, because it's doubtful
we can agree
on the renamings. :)
>> > And is there any reason not to make [[warn_unused_result]].standard now?
>> How is that related to the proposal at hand?
> It's related in so much as the OP's proposal directly refers to it and it's
> come up before, but it's not essential to this proposal.
Well, I guess that should be explored separately.
--
---
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: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 11 Jan 2015 12:33:39 -0800 (PST)
Raw View
------=_Part_2443_972956686.1421008419367
Content-Type: multipart/alternative;
boundary="----=_Part_2444_1542533344.1421008419367"
------=_Part_2444_1542533344.1421008419367
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, January 10, 2015 at 1:26:20 PM UTC-8, gmis...@gmail.com wrote:
>
> Nice proposal.
>
Thanks!
=20
> In your view, if the naming of lock/unlock is of=20
> sufficient irritation, would it be so bad to add [[deprecated]] to the=20
> existing names and/or add the preferred new ones?
>
> And if there are sufficient other candidates where renaming might be=20
> useful, like the empty() -> is_empty() example referenced; would collecti=
ng=20
> the simpler cases up and having a consolidated proposal to fix them all=
=20
> help procedure wise in general versus lots of individual cases? If so, we=
=20
> could make a separate post asking for rename recommendations. I saw=20
> renaming shared_mutex -> timed_shared_mutex or something was another rena=
me=20
> case floating around at one point, but I'm sure that one or some might be=
=20
> better handled as separate proposals.
>
Deprecating std::vector::empty() is a non-starter. :D And far, far outside=
=20
the scope of this proposal, of course.
Deprecating or renaming std::shared_ptr::lock() is also a non-starter, in=
=20
my opinion, even though it's a couple orders of magnitude more obscure than=
=20
vector::empty(), and has only been around since C++11. Hence my "If it were=
=20
not too late to rename..." comment in the paper.
The shared_mutex -> shared_timed_mutex renaming seems to have gone as=20
follows:
N2406 (2007-09-09) (Hinnant): shared_mutex is proposed for TR2. (The name=
=20
comes from Boost.) It is still absent from C++11 working draft N3337.
N3427 (2012-09-23), N3568 (2013-03-11), N3659 (2013-04-19) (Hinnant):=20
shared_mutex is introduced to the standard. N3659 is adopted into working=
=20
draft N3797.
N3891 (2014-01-14) (Sutter, Nishanov): shared_mutex is renamed to=20
shared_timed_mutex. Adopted at Issaquah into (current) working draft N4296.
N3961 (2014-02-25), N3995 (2014-05-20) (Nishanov): A coauthor of N3891=20
proposes a new class shared_mutex that lacks timing functionality.
Observe that the original attitude "let's put timeout functionality into=20
shared_mutex" came from Boost, and the new attitude "let's make timeout=20
support optional" came from Microsoft. This is apparently for technical=20
reasons on Windows: they have a fast reader-writer lock that lacks timeout=
=20
support, and a heavyweight one that has timeout support, so they really=20
want a place in the standard library to expose the fast one. The new,=20
untimed std::shared_mutex will provide such a place.
In other words, that particular renaming had solid technical reasons and=20
the weight of Microsoft behind it; it wasn't a purely stylistic change. I=
=20
don't think any purely stylistic changes like empty()->is_empty() or=20
lock()->strengthen() will ever happen.
There might be some precedent for the Standard's providing silly *synonyms*=
=20
for the existing constructs, analogous to how they made 'and' a synonym for=
=20
'&&', but again, that was a change made (in 1991) for ostensibly technical=
=20
reasons, and had the weight of IBM behind it.
ftp://std.dkuug.dk/mirror/www.maths.warwick.ac.uk/cpp/iso/minutes/91-0093.t=
xt
And is there any reason not to make [[warn_unused_result]].standard now?=20
> Isn't it time we did that so this proposal and everyone can benefit from =
it?
>>
>> I think I suggested this before but I think it got shot down. But I migh=
t=20
> be wrong Right now I can't see why this attribute shouldn't be standard.
> It seems like even things like strlen() would benefit from it. I mean why=
=20
> calculate a strings length if you don't capture or use the result anywher=
e.=20
> Something tells me someone will have a good reason, even for this=20
> particular example lol.
>
I think I agree that [[warn_unused_result]] should be standardized, but=20
again that's obviously far, far out of scope for this proposal.
That proposer should look at 7.6.5 [dcl.attr.deprecated] for the=20
appropriate wording.
=E2=80=93Arthur
--=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_2444_1542533344.1421008419367
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, January 10, 2015 at 1:26:20 PM UTC-8, gmis...=
@gmail.com 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">Nice proposal.<br></div></blockquote><div><br></div><div>Thanks!</div><=
div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>In your view, if the naming of lock/unlock is o=
f sufficient irritation, would it be so bad to add=
[[deprecated]] to the existing names and/or add the preferred ne=
w ones?<br></div><div><div><br></div><div>And if there are sufficient =
other candidates where renaming might be useful, like the em=
pty() -> is_empty() example referenced; would collecting the s=
impler cases up and having a consolidated proposal to fix them al=
l help procedure wise in general versus lots of individual cases? If s=
o, we could make a separate post asking for rename recommendations. I saw r=
enaming shared_mutex -> timed_shared_mutex or something was an=
other rename case floating around at one point, but I'm sure that=
one or some might be better handled as separate proposals.</div>=
</div></div></blockquote><div><br></div><div>Deprecating std::vector::empty=
() is a non-starter. :D And far, far outside the scope of this propos=
al, of course.</div><div>Deprecating or renaming std::shared_ptr::lock() is=
also a non-starter, in my opinion, even though it's a couple orders of mag=
nitude more obscure than vector::empty(), and has only been around since C+=
+11. Hence my "If it were not too late to rename..." comment in the paper.<=
/div><div><br></div><div>The shared_mutex -> shared_timed_mutex renaming=
seems to have gone as follows:</div><div>N2406 (2007-09-09) (Hinnant): sha=
red_mutex is proposed for TR2. (The name comes from Boost.) It is sti=
ll absent from C++11 working draft N3337.</div>N3427 (2012-09-23), N3568 (2=
013-03-11), N3659 (2013-04-19) (Hinnant): shared_mutex is introduced to the=
standard. N3659 is adopted into working draft N3797.<br>N3891 (2014-01-14)=
(Sutter, Nishanov): shared_mutex is renamed to shared_timed_mutex. Adopted=
at Issaquah into (current) working draft N4296.<br>N3961 (2014-02-25), N39=
95 (2014-05-20) (Nishanov): A coauthor of N3891 proposes a new class shared=
_mutex that lacks timing functionality.<div><br></div><div>Observe that the=
original attitude "let's put timeout functionality into shared_mutex" came=
from Boost, and the new attitude "let's make timeout support optional" cam=
e from Microsoft. This is apparently for technical reasons on Windows: they=
have a fast reader-writer lock that lacks timeout support, and a heavyweig=
ht one that has timeout support, so they really want a place in the standar=
d library to expose the fast one. The new, untimed std::shared_mutex will p=
rovide such a place.</div><div><br></div><div>In other words, that particul=
ar renaming had solid technical reasons and the weight of Microsoft behind =
it; it wasn't a purely stylistic change. I don't think any purely sty=
listic changes like empty()->is_empty() or lock()->strengthen() will =
ever happen.</div><div>There might be some precedent for the Standard's pro=
viding silly *synonyms* for the existing constructs, analogous to how they =
made 'and' a synonym for '&&', but again, that was a change made (i=
n 1991) for ostensibly technical reasons, and had the weight of IBM behind =
it.</div><div>ftp://std.dkuug.dk/mirror/www.maths.warwick.ac.uk/cpp/iso/min=
utes/91-0093.txt<br></div><div><br> <br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><code><font face=3D"Arial">And is there any reas=
on not to make</font> </code><code>[[warn_unused_<wbr>result=
]]</code>.standard now? Isn't it time we did that so this proposal and=
everyone can benefit from it?<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204=
, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr"=
></div></blockquote><div>I think I suggested this before but I think it got=
shot down. But I might be wrong Right now I can't see why this attrib=
ute shouldn't be standard.</div><div>It seems like even things like strlen(=
) would benefit from it. I mean why calculate a strings length if you don't=
capture or use the result anywhere. Something tells me someone will have&n=
bsp;a good reason, even for this particular example lol.</div></div></=
blockquote><div><br></div><div>I think I agree that [[warn_unused_result]] =
should be standardized, but again that's obviously far, far out of scope fo=
r this proposal.</div><div>That proposer should look at 7.6.5 [dcl.attr.dep=
recated] for the appropriate wording.</div><div><br></div></div><div>=E2=80=
=93Arthur</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_2444_1542533344.1421008419367--
------=_Part_2443_972956686.1421008419367--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 11 Jan 2015 23:59:22 -0800 (PST)
Raw View
------=_Part_2866_1773251657.1421049562945
Content-Type: multipart/alternative;
boundary="----=_Part_2867_262546133.1421049562945"
------=_Part_2867_262546133.1421049562945
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, January 11, 2015 at 3:55:01 AM UTC-8, David Krauss wrote:
> On 2015=E2=80=9301=E2=80=9311, at 3:01 AM, Arthur O'Dwyer <arthur....@gma=
il.com=20
<javascript:>> wrote:
>>
>> I've got a rough draft of a proposal for the next meeting in May, and=20
would like to hear anyone's feedback on the format and content before then.
>
> There could be an rvalue-qualified overload of unlock() which does the=20
reset automatically.
> auto wptr =3D std::move( sptr ).unlock();
That's an interesting idea. I think it's not a good idea, though, because=
=20
it seems to be implying a general rule that if you do an operation on a=20
"moved-from" shared_ptr, then you implicitly reset the shared_ptr =E2=80=94=
and=20
that's not currently the general rule. It seems attractive, but look how=20
much we'd have to "fix" to make it actually true as a general rule:
shared_ptr<T> sptr2 =3D std::move(sptr); // does reset
weak_ptr<T> wptr2 =3D std::move(sptr); // doesn't reset; merely=20
dispatches to the constructor taking const shared_ptr&
shared_ptr<T> sptr2 =3D std::move(wptr).lock(); // doesn't reset wptr,=
=20
under the current standard
I guess the most fundamental argument against your idea is that it does=20
*more* than just add symmetry to the standard; for symmetry we'd have to=20
add new &&-ref-qualified overloads of both shared_ptr::unlock *and*=20
weak_ptr::lock.
I'm considering how to address your idea in the paper (probably in section=
=20
5c or in a new 5d), but I'm not sure how to introduce it in a way that=20
doesn't feel redundant after we've already dismissed the idea of "fixing"
weak_ptr<T> wptr2 =3D std::move(sptr); // doesn't reset
.. Also, ref-qualified overloads are pretty arcane, IMHO. In Frankfurt in=20
2009, the Committee apparently rejected a proposal (N2819) to add the &=20
ref-qualifier to a whole bunch of assignment operators.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941
http://stackoverflow.com/questions/21052377/whats-a-use-case-for-overloadin=
g-member-functions-on-reference-qualifiers
Does anyone know offhand if there currently exist any ref-qualified member=
=20
functions in the standard library?
=E2=80=93Arthur
--=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_2867_262546133.1421049562945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, January 11, 2015 at 3:55:01 AM UTC-8, David Kra=
uss wrote:<div>> On 2015=E2=80=9301=E2=80=9311, at 3:01 AM, Arthur O'Dwy=
er <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"p=
1foN_EWE8gJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">arthur....@gmail.com</a>> wr=
ote:</div><div>>></div><div>>> I've got a rough draft of a prop=
osal for the next meeting in May, and would like to hear anyone's feedback =
on the format and content before then.</div><div>></div><div>> There =
could be an rvalue-qualified overload of <font face=3D"Courier">unlock()</f=
ont> which does the reset automatically.</div><div>> <font face=3D"couri=
er new, monospace"> </font><span style=3D"font-family: Co=
urier;">auto wptr =3D std::move( sptr ).unlock();</span></div><div><br></di=
v><div><font face=3D"arial, sans-serif">That's an interesting idea. I think=
it's not a good idea, though, because it seems to be implying a general ru=
le that if you do an operation on a "moved-from" </font><font face=3D"couri=
er new, monospace">shared_ptr</font><font face=3D"arial, sans-serif">, then=
you implicitly reset the </font><font face=3D"courier new, monospace">shar=
ed_ptr</font><font face=3D"arial, sans-serif"> =E2=80=94 and that's not cur=
rently the general rule. It seems attractive, but look how much we'd have t=
o "fix" to make it actually true as a general rule:</font></div><div><font =
face=3D"arial, sans-serif"><br></font></div><div><font face=3D"courier new,=
monospace"> shared_ptr<T> sptr2 =3D std::move(sptr); &n=
bsp;// does reset</font></div><div><font face=3D"courier new, monospace">&n=
bsp; weak_ptr<T> wptr2 =3D std::move(sptr); // doesn't r=
eset; merely dispatches to the constructor taking const shared_ptr&</fo=
nt></div><div><font face=3D"courier new, monospace"> shared_pt=
r<T> sptr2 =3D std::move(wptr).lock(); // doesn't reset wptr, u=
nder the current standard</font></div><div><span style=3D"font-family: aria=
l, sans-serif;"><br></span></div><div><span style=3D"font-family: arial, sa=
ns-serif;">I guess the most fundamental argument against your idea is that =
it does *more* than just add symmetry to the standard; for symmetry we'd ha=
ve to add new </span><font face=3D"courier new, monospace">&&</font=
><span style=3D"font-family: arial, sans-serif;">-ref-qualified overloads o=
f both </span><font face=3D"courier new, monospace">shared_ptr::unlock=
</font><span style=3D"font-family: arial, sans-serif;"> <i>and</i> </s=
pan><font face=3D"courier new, monospace">weak_ptr::lock</font><span style=
=3D"font-family: arial, sans-serif;">.</span></div><div><span style=3D"font=
-family: arial, sans-serif;"><br></span></div><div><span style=3D"font-fami=
ly: arial, sans-serif;">I'm considering how to address your idea in the pap=
er (probably in section 5c or in a new 5d), but I'm not sure how to introdu=
ce it in a way that doesn't feel redundant after we've already dismissed th=
e idea of "fixing"</span></div><div><span style=3D"font-family: arial, sans=
-serif;"><br></span></div><div><font face=3D"courier new, monospace"> =
weak_ptr<T> wptr2 =3D std::move(sptr); // doesn't reset=
</font></div><div><span style=3D"font-family: arial, sans-serif;"><br></spa=
n></div><div><font face=3D"arial, sans-serif">. Also, ref-qualified overloa=
ds are pretty arcane, IMHO. In Frankfurt in 2009, the Committee apparently =
rejected a proposal (N2819) to add the </font><font face=3D"courier new, mo=
nospace">&</font><font face=3D"arial, sans-serif"> ref-qualifier to a w=
hole bunch of assignment operators.</font></div><div>http://www.open-std.or=
g/jtc1/sc22/wg21/docs/lwg-closed.html#941<br></div><div>http://stackoverflo=
w.com/questions/21052377/whats-a-use-case-for-overloading-member-functions-=
on-reference-qualifiers<br></div><div><br></div><div>Does anyone know offha=
nd if there currently exist any ref-qualified member functions in the stand=
ard library?</div><div><br></div><div><font face=3D"arial, sans-serif">=E2=
=80=93Arthur</font></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_2867_262546133.1421049562945--
------=_Part_2866_1773251657.1421049562945--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Jan 2015 10:54:30 +0200
Raw View
On 12 January 2015 at 09:59, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> Does anyone know offhand if there currently exist any ref-qualified member
> functions in the standard library?
Not yet, but std::experimental::optional includes some.
--
---
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: David Krauss <potswa@gmail.com>
Date: Mon, 12 Jan 2015 18:11:53 +0800
Raw View
--Apple-Mail=_2EF734A7-B721-4F45-84D9-40F7FBCBA603
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9312, at 4:54 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 12 January 2015 at 09:59, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> w=
rote:
>> Does anyone know offhand if there currently exist any ref-qualified memb=
er
>> functions in the standard library?
>=20
> Not yet, but std::experimental::optional includes some.
When both lvalue-qualified and rvalue-qualified overloads exist, should it =
even require specification? Splitting a member function in this way doesn=
=E2=80=99t fall into any of the cases of [member.functions] =C2=A717.6.5.5/=
2, but overloading a standard const & parameter with an extension && parame=
ter is permitted by the third bullet, and the effect is essentially the sam=
e.
Either [member.functions]/2.3 should be made more restrictive, or implement=
ations are already allowed to assume the user is passing xvalue arguments c=
orrectly, and to move from them even when the mandatory overloads fail to p=
reserve the value category. In the latter case, rvalue-qualified overloads =
should be added as a fourth bullet. In either case, it=E2=80=99s not really=
Arthur=E2=80=99s problem to deal with.
--=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=_2EF734A7-B721-4F45-84D9-40F7FBCBA603
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=9312, at 4:54 PM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D"">On 12 January 20=
15 at 09:59, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.com=
" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:<br class=3D""><blockq=
uote type=3D"cite" class=3D"">Does anyone know offhand if there currently e=
xist any ref-qualified member<br class=3D"">functions in the standard libra=
ry?<br class=3D""></blockquote><br class=3D"">Not yet, but std::experimenta=
l::optional includes some.</div></blockquote><div><br class=3D""></div></di=
v>When both lvalue-qualified and rvalue-qualified overloads exist, should i=
t even require specification? Splitting a member function in this way doesn=
=E2=80=99t fall into any of the cases of [member.functions] =C2=
=A717.6.5.5/2, but overloading a standard <font face=3D"Courier" class=
=3D"">const &</font> parameter with an extension <font face=3D"Courier"=
class=3D"">&&</font> parameter is permitted by the third bullet, a=
nd the effect is essentially the same.<div class=3D""><br class=3D""></div>=
<div class=3D"">Either [member.functions]/2.3 should be made more rest=
rictive, or implementations are already allowed to assume the user is passi=
ng xvalue arguments correctly, and to move from them even when the mandator=
y overloads fail to preserve the value category. In the latter case, rvalue=
-qualified overloads should be added as a fourth bullet. In either case, it=
=E2=80=99s not really Arthur=E2=80=99s problem to deal with.</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=_2EF734A7-B721-4F45-84D9-40F7FBCBA603--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 12 Jan 2015 20:47:00 +0800
Raw View
--Apple-Mail=_5EAAFCD6-70EA-41C8-91FE-8F07EF1E2819
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9301=E2=80=9312, at 6:13 PM, David Krauss <potswa@gmail.com=
<mailto:potswa@gmail.com>> wrote:
>=20
> And then, it=E2=80=99s not really Arthur=E2=80=99s problem to deal with.
Oops, in the first case (discrimination really isn=E2=80=99t a conforming e=
xtension), it is still Arthur=E2=80=99s decision.
This case isn=E2=80=99t particularly interesting, since the function always=
returns a prvalue, and if the shared_ptr is a temporary, it will get reset=
at the semicolon anyway. I only suggested it since it stood out, from the =
perspective of someone who does use ref-qualification pretty thoroughly.
Qualification makes things run smoother. It=E2=80=99s only arcane as long a=
s nobody uses it. Changes to operator=3D don=E2=80=99t make a fair comparis=
on, since that would have broken a lot of legacy code. That said, the diffe=
rence in this case might not be enough to warrant any effort at all.
--=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=_5EAAFCD6-70EA-41C8-91FE-8F07EF1E2819
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"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf=
-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><br class=3D""><div clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=
=9301=E2=80=9312, at 6:13 PM, David Krauss <<a href=3D"mailto:potswa@gma=
il.com" class=3D"">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><meta http-equiv=3D"Content-Type" cont=
ent=3D"text/html charset=3Dutf-8" class=3D""><div style=3D"word-wrap: break=
-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" cl=
ass=3D"" dir=3D"auto">And then, it=E2=80=99s not really Arthur=E2=80=99s pr=
oblem to deal with.</div></div></blockquote></div><div class=3D""><br class=
=3D""></div><div class=3D"">Oops, in the first case (discrimination really =
isn=E2=80=99t a conforming extension), it is still Arthur=E2=80=99s decisio=
n.</div><div class=3D""><br class=3D""></div><div class=3D"">This case isn=
=E2=80=99t particularly interesting, since the function always returns a pr=
value, and if the <font face=3D"Courier" class=3D"">shared_ptr</font> is a =
temporary, it will get reset at the semicolon anyway. I only suggested it s=
ince it stood out, from the perspective of someone who does use ref-qualifi=
cation pretty thoroughly.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">Qualification makes things run smoother. It=E2=80=99s only arcane =
as long as nobody uses it. Changes to <font face=3D"Courier" class=3D"=
">operator=3D</font> don=E2=80=99t make a fair comparison, since that would=
have broken a lot of legacy code. That said, the difference in this case m=
ight not be enough to warrant any effort at all.</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=_5EAAFCD6-70EA-41C8-91FE-8F07EF1E2819--
.
Author: jgottman6@gmail.com
Date: Tue, 13 Jan 2015 15:24:46 -0800 (PST)
Raw View
------=_Part_4880_1837022587.1421191486289
Content-Type: multipart/alternative;
boundary="----=_Part_4881_466226790.1421191486289"
------=_Part_4881_466226790.1421191486289
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Just one minor quibble. I don't see the use case for the weak_ptr overload=
=20
that takes a pointer and a weak_ptr. The pointer should always be some=20
kind of sub-object of an object pointed to by a shared_ptr, such as a data=
=20
member or container element. For you to have this pointer and know that it=
=20
is still valid, you should still have access to the shared_ptr owning it. =
=20
Therefore, you should be able to construct your new weak_ptr from the=20
pointer and the shared_ptr.
Joe Gottman
On Saturday, January 10, 2015 at 2:01:54 PM UTC-5, Arthur O'Dwyer wrote:
>
> I've got a rough draft of a proposal for the next meeting in May, and=20
> would like to hear anyone's feedback on the format and content before the=
n.
>
> https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html
>
> The TL;DR is that it proposes two very small new library features:
> - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr,=20
> symmetric with weak_ptr::lock()
> - An two-argument constructor for weak_ptr(), symmetric with shared_ptr's=
=20
> two-argument constructor
>
> =E2=80=93Arthur
>
--=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_4881_466226790.1421191486289
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just one minor quibble. I don't see the use case for=
the weak_ptr overload that takes a pointer and a weak_ptr. The point=
er should always be some kind of sub-object of an object pointed to by a sh=
ared_ptr, such as a data member or container element. For you to have=
this pointer and know that it is still valid, you should still have access=
to the shared_ptr owning it. Therefore, you should be able to constr=
uct your new weak_ptr from the pointer and the shared_ptr.<br><br>Joe Gottm=
an<br><br>On Saturday, January 10, 2015 at 2:01:54 PM UTC-5, Arthur O'Dwyer=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I=
've got a rough draft of a proposal for the next meeting in May, and would =
like to hear anyone's feedback on the format and content before then.</div>=
<div><br></div><a href=3D"https://quuxplusone.github.io/draft/Nweak_ptr_pro=
posal.html" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.googl=
e.com/url?q\75https%3A%2F%2Fquuxplusone.github.io%2Fdraft%2FNweak_ptr_propo=
sal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEpCBJmD4KOlkKAXe6DwO0kgU69zQ';r=
eturn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3=
A%2F%2Fquuxplusone.github.io%2Fdraft%2FNweak_ptr_proposal.html\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEpCBJmD4KOlkKAXe6DwO0kgU69zQ';return true;">https://=
quuxplusone.github.io/<wbr>draft/Nweak_ptr_proposal.html</a><br><div><br></=
div><div>The TL;DR is that it proposes two very small new library features:=
</div><div>- shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr=
, symmetric with weak_ptr::lock()</div><div>- An two-argument constructor f=
or weak_ptr(), symmetric with shared_ptr's two-argument constructor</div><d=
iv><br></div><div>=E2=80=93Arthur</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_4881_466226790.1421191486289--
------=_Part_4880_1837022587.1421191486289--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Tue, 13 Jan 2015 16:02:06 -0800
Raw View
--089e0102f2123a34d2050c9173f6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jan 13, 2015 at 3:24 PM, <jgottman6@gmail.com> wrote:
> On Saturday, January 10, 2015 at 2:01:54 PM UTC-5, Arthur O'Dwyer wrote:
>
>> I've got a rough draft of a proposal for the next meeting in May, and
>> would like to hear anyone's feedback on the format and content before th=
en.
>>
>> https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html
>>
>
>
Just one minor quibble. I don't see the use case for the weak_ptr overload
> that takes a pointer and a weak_ptr. The pointer should always be some
> kind of sub-object of an object pointed to by a shared_ptr, such as a dat=
a
> member or container element. For you to have this pointer and know that =
it
> is still valid, you should still have access to the shared_ptr owning it.
> Therefore, you should be able to construct your new weak_ptr from the
> pointer and the shared_ptr.
>
I'm not convinced that your analysis is correct in all possible use-cases.
(Maybe we only have a weak_ptr at this point in the program, and we don't
wish to lock it unnecessarily, and for some reason we *can* compute the
appropriate raw pointer without evaluating the weak_ptr.)
However, you're right in that shared_ptr(weak_ptr<Y> const&, T*) doesn't
exist, so I'm not adding any symmetry via this particular overload. I'm
mulling it over.
=E2=80=93Arthur
--=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/.
--089e0102f2123a34d2050c9173f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jan 13, 2015 at 3:24 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:jgottman6@gmail.com" target=3D"_blank">jgottman6@gmail.com<=
/a>></span> wrote:=C2=A0<div><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, January 10, 2015 =
at 2:01:54 PM UTC-5, Arthur O'Dwyer wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>I've got a rough draft of a proposal for the next=
meeting in May, and would like to hear anyone's feedback on the format=
and content before then.</div><div><br></div><a href=3D"https://quuxpluson=
e.github.io/draft/Nweak_ptr_proposal.html" target=3D"_blank">https://quuxpl=
usone.github.io/<u></u>draft/Nweak_ptr_proposal.html</a></div></blockquote>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr">=C2=A0</div></blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex"><div dir=3D"ltr">Just one minor quibble.=C2=A0 I don't se=
e the use case for the weak_ptr overload that takes a pointer and a weak_pt=
r.=C2=A0 The pointer should always be some kind of sub-object of an object =
pointed to by a shared_ptr, such as a data member or container element.=C2=
=A0 For you to have this pointer and know that it is still valid, you shoul=
d still have access to the shared_ptr owning it.=C2=A0 Therefore, you shoul=
d be able to construct your new weak_ptr from the pointer and the shared_pt=
r.</div></blockquote><div><br></div><div>I'm not convinced that your an=
alysis is correct in all possible use-cases. (Maybe we only have a weak_ptr=
at this point in the program, and we don't wish to lock it unnecessari=
ly, and for some reason we *can* compute the appropriate raw pointer withou=
t evaluating the weak_ptr.)</div><div><br></div><div>However, you're ri=
ght in that <font face=3D"monospace, monospace">shared_ptr(weak_ptr<Y>=
; const&, T*)</font> doesn't exist, so I'm not adding any symme=
try via this particular overload. I'm mulling it over.</div><div><br></=
div><div>=E2=80=93Arthur</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">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 />
--089e0102f2123a34d2050c9173f6--
.