Topic: What happened to N4282
Author: Bob Fang <bobfang1992@gmail.com>
Date: Sun, 10 Dec 2017 19:27:42 +0000
Raw View
--001a114dcde49c215b0560016a59
Content-Type: text/plain; charset="UTF-8"
Hi All,
Just out of curious, what happened to N4282, the proposal of having a dump
observer "smart" pointer? Is this still a live proposal?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf
Thanks a lot.
Best,
Bob
--
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/CANVf7NXAJ4fgPDsVPAFacHJaiHgGS0wVuUF3XcSQRNLBjkTCVA%40mail.gmail.com.
--001a114dcde49c215b0560016a59
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi All,</div><div><br></div><div>Just out of curious,=
what happened to N4282, the proposal of having a dump observer "smart=
" pointer? Is this still a live proposal?<br></div><div><br></div><div=
><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.p=
df">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf</a></=
div><div><br></div><div>Thanks a lot.</div><div><br></div><div>Best,</div><=
div>Bob<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/CANVf7NXAJ4fgPDsVPAFacHJaiHgGS0wVuUF3=
XcSQRNLBjkTCVA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANVf7NXAJ4fgPDsV=
PAFacHJaiHgGS0wVuUF3XcSQRNLBjkTCVA%40mail.gmail.com</a>.<br />
--001a114dcde49c215b0560016a59--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 10 Dec 2017 14:07:54 -0800 (PST)
Raw View
------=_Part_5549_360282825.1512943674644
Content-Type: multipart/alternative;
boundary="----=_Part_5550_1483266997.1512943674644"
------=_Part_5550_1483266997.1512943674644
Content-Type: text/plain; charset="UTF-8"
It was added to the Library Fundamentals TS v3.
Granted, I hope it never sees the light of day outside of that TS. The C++
Core Guidelines provides more reasonable ways to deal with this. In
recognition of the fact that naked pointers will never go away, we simply
assume that all naked pointers:
1: are non-owning.
2: point to a single object.
Basically, naked pointers are treated like a hypothetical `optional<T&>`.
If you want an owning pointer, you use a smart pointer or, if you cannot
properly encapsulate the ownership, `gsl::owner<T>`. If you want a
non-owning array, you use `gsl::span<T>`.
People are going to use `T*` for non-owning pointers; there's no getting
around that. We already have one way to spell that; we don't need a second
one.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fd278536-7104-4aa8-a0fd-bb9788e7c0aa%40isocpp.org.
------=_Part_5550_1483266997.1512943674644
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It was added to the Library Fundamentals TS v3.</div>=
<div><br></div><div>Granted, I hope it never sees the light of day outside =
of that TS. The C++ Core Guidelines provides more reasonable ways to deal w=
ith this. In recognition of the fact that naked pointers will never go away=
, we simply assume that all naked pointers:</div><div><br></div><div>1: are=
non-owning.</div><div>2: point to a single object.</div><div><br></div><di=
v>Basically, naked pointers are treated like a hypothetical `optional<T&=
amp;>`. If you want an owning pointer, you use a smart pointer or, if yo=
u cannot properly encapsulate the ownership, `gsl::owner<T>`. If you =
want a non-owning array, you use `gsl::span<T>`.</div><div><br></div>=
<div>People are going to use `T*` for non-owning pointers; there's no g=
etting around that. We already have one way to spell that; we don't nee=
d a second one.<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fd278536-7104-4aa8-a0fd-bb9788e7c0aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd278536-7104-4aa8-a0fd-bb9788e7c0aa=
%40isocpp.org</a>.<br />
------=_Part_5550_1483266997.1512943674644--
------=_Part_5549_360282825.1512943674644--
.
Author: Masse Nicolas <masse.nicolas@gmail.com>
Date: Sun, 7 Jan 2018 09:07:45 -0800 (PST)
Raw View
------=_Part_11728_855844777.1515344865180
Content-Type: multipart/alternative;
boundary="----=_Part_11729_305440276.1515344865181"
------=_Part_11729_305440276.1515344865181
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi all,
Le dimanche 10 d=C3=A9cembre 2017 23:07:54 UTC+1, Nicol Bolas a =C3=A9crit =
:
>
>
> Basically, naked pointers are treated like a hypothetical `optional<T&>`.=
=20
> If you want an owning pointer, you use a smart pointer or, if you cannot=
=20
> properly encapsulate the ownership, `gsl::owner<T>`. If you want a=20
> non-owning array, you use `gsl::span<T>`.
>
> People are going to use `T*` for non-owning pointers; there's no getting=
=20
> around that. We already have one way to spell that; we don't need a secon=
d=20
> one.
>
I should say I just don't agree with you.
When people use naked pointer, we can't know wether it is:
- for storing a non-owned pointer
- due to compatibility with C code
- poorly written code
- whathever
Also it goes against a rule I've set with myself who said that naked=20
pointer should always be avoided :D.
On the other side, when using std::observer_ptr<T>, you know:
- that the given pointer isn't owned and that you should not try to take=20
any ownership on it.
- the code is not that poorly written :)
So I see a real interest in this and hope it will be integrated into the=20
standard.
(In fact I've already written my own class for this, but I would be happy=
=20
if one day I can replace it with something provided by the stl).
Just my 2 cents,
Nicolas.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c82b2d47-e144-4809-b87a-f70d00d8a7e7%40isocpp.or=
g.
------=_Part_11729_305440276.1515344865181
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all,<br><br>Le dimanche 10 d=C3=A9cembre 2017 23:07:54 =
UTC+1, Nicol Bolas a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><br><div>Basically, naked pointers are treated lik=
e a hypothetical `optional<T&>`. If you want an owning pointer, y=
ou use a smart pointer or, if you cannot properly encapsulate the ownership=
, `gsl::owner<T>`. If you want a non-owning array, you use `gsl::span=
<T>`.</div><div><br></div><div>People are going to use `T*` for non-o=
wning pointers; there's no getting around that. We already have one way=
to spell that; we don't need a second one.<br></div></div></blockquote=
><div><br></div><div>I should say I just don't agree with you.</div><di=
v>When people use naked pointer, we can't know wether it is:</div><div>=
- for storing a non-owned pointer</div><div>- due to compatibility with C c=
ode</div><div>- poorly written code<br></div><div>- whathever</div><div><br=
></div><div>Also it goes against a rule I've set with myself who said t=
hat naked pointer should always be avoided :D.</div><div><br></div><div>On =
the other side, when using std::observer_ptr<T>, you know:</div><div>=
- that the given pointer isn't owned and that you should not try to tak=
e any ownership on it.</div><div>- the code is not that poorly written :)</=
div><br><div> So I see a real interest in this and hope it will be integrat=
ed into the standard.<br></div><div>(In fact I've already written my ow=
n class for this, but I would be happy if one day I can replace it with som=
ething provided by the stl).</div><div><br></div><div>Just my 2 cents,<br><=
/div><div></div><div>Nicolas.<br></div><div><br></div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c82b2d47-e144-4809-b87a-f70d00d8a7e7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c82b2d47-e144-4809-b87a-f70d00d8a7e7=
%40isocpp.org</a>.<br />
------=_Part_11729_305440276.1515344865181--
------=_Part_11728_855844777.1515344865180--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Sun, 7 Jan 2018 17:26:17 +0000
Raw View
--001a113db692bd358f056232fa08
Content-Type: text/plain; charset="UTF-8"
On 7 Jan 2018 17:07, "Masse Nicolas" <masse.nicolas@gmail.com> wrote:
Also it goes against a rule I've set with myself who said that naked
pointer should always be avoided :D.
A rule you have set yourself is not relevant though.
On the other side, when using std::observer_ptr<T>, you know:
- that the given pointer isn't owned and that you should not try to take
any ownership on it.
Yep, I agree that it should be included, but certainly not enforced.
- the code is not that poorly written :)
Subjective.
--
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/CAC%2B0CCMkA%2BFf4xBfOjSZV7mqZ2OtfbYDBvAvU1x%3Dit%3DDkX5-3g%40mail.gmail.com.
--001a113db692bd358f056232fa08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas=
s=3D"gmail_quote">On 7 Jan 2018 17:07, "Masse Nicolas" <<a hre=
f=3D"mailto:masse.nicolas@gmail.com">masse.nicolas@gmail.com</a>> wrote:=
<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Als=
o it goes against a rule I've set with myself who said that naked point=
er should always be avoided :D.<br></div></div></blockquote></div></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">A rule you have set yourself is =
not relevant though.</div><div dir=3D"auto"><br></div><div class=3D"gmail_e=
xtra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div></div><div>On the other side, when using std::observer_pt=
r<T>, you know:<br></div><div>- that the given pointer isn't owne=
d and that you should not try to take any ownership on it.</div></div></blo=
ckquote></div></div><div dir=3D"auto">Yep, I agree that it should be includ=
ed, but certainly not enforced.</div><div dir=3D"auto"><br></div><div class=
=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>- the code is not that poorly written :)</div=
></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Subjective.</div><div class=3D"gmail_extra" dir=3D"auto"></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/CAC%2B0CCMkA%2BFf4xBfOjSZV7mqZ2OtfbYD=
BvAvU1x%3Dit%3DDkX5-3g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
MkA%2BFf4xBfOjSZV7mqZ2OtfbYDBvAvU1x%3Dit%3DDkX5-3g%40mail.gmail.com</a>.<br=
/>
--001a113db692bd358f056232fa08--
.
Author: Bo Persson <bop@gmb.dk>
Date: Sun, 7 Jan 2018 23:17:57 +0100
Raw View
On 2018-01-07 18:07, Masse Nicolas wrote:
> Hi all,
>=20
> Le dimanche 10 d=C3=A9cembre 2017 23:07:54 UTC+1, Nicol Bolas a =C3=A9cri=
t=C2=A0:
>=20
>=20
> Basically, naked pointers are treated like a hypothetical
> `optional<T&>`. If you want an owning pointer, you use a smart
> pointer or, if you cannot properly encapsulate the ownership,
> `gsl::owner<T>`. If you want a non-owning array, you use `gsl::span<T=
>`.
>=20
> People are going to use `T*` for non-owning pointers; there's no
> getting around that. We already have one way to spell that; we don't
> need a second one.
>=20
>=20
> I should say I just don't agree with you.
> When people use naked pointer, we can't know wether it is:
> - for storing a non-owned pointer
> - due to compatibility with C code
> - poorly written code
> - whathever
>=20
> Also it goes against a rule I've set with myself who said that naked=20
> pointer should always be avoided :D.
>=20
> On the other side, when using std::observer_ptr<T>, you know:
> - that the given pointer isn't owned and that you should not try to take=
=20
> any ownership on it.
> - the code is not that poorly written :)
>=20
The trend for the C++ Core Guidelines seems to be that a raw pointer is=20
non-owning (and non-array).
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr
And then use the compilers' static analysis to warn about doing "owning=20
things" to the pointers.
I think the observer_ptr, while a good idea in isolation, has lost to=20
the more comprehensive guidelines.
Bo Persson
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/p2u66r%245uh%241%40blaine.gmane.org.
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Sun, 7 Jan 2018 23:38:54 +0100
Raw View
--001a113f3446bb60a5056237586f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I wrote my own observer_ptr too, feeling that it states intent explicitly.
However, it's probably true that std::reference_wrapper<> does the same
job. It's just a little less convenient when talking to c apis.
I don't like seeing naked pointers in c++ code. I'd be inclined to reject
code that used them at code review time unless it could be proven they were
necessary.
On 7 January 2018 at 23:17, Bo Persson <bop@gmb.dk> wrote:
> On 2018-01-07 18:07, Masse Nicolas wrote:
>
>> Hi all,
>>
>> Le dimanche 10 d=C3=A9cembre 2017 23:07:54 UTC+1, Nicol Bolas a =C3=A9cr=
it :
>>
>>
>> Basically, naked pointers are treated like a hypothetical
>> `optional<T&>`. If you want an owning pointer, you use a smart
>> pointer or, if you cannot properly encapsulate the ownership,
>> `gsl::owner<T>`. If you want a non-owning array, you use
>> `gsl::span<T>`.
>>
>> People are going to use `T*` for non-owning pointers; there's no
>> getting around that. We already have one way to spell that; we don't
>> need a second one.
>>
>>
>> I should say I just don't agree with you.
>> When people use naked pointer, we can't know wether it is:
>> - for storing a non-owned pointer
>> - due to compatibility with C code
>> - poorly written code
>> - whathever
>>
>> Also it goes against a rule I've set with myself who said that naked
>> pointer should always be avoided :D.
>>
>> On the other side, when using std::observer_ptr<T>, you know:
>> - that the given pointer isn't owned and that you should not try to take
>> any ownership on it.
>> - the code is not that poorly written :)
>>
>>
> The trend for the C++ Core Guidelines seems to be that a raw pointer is
> non-owning (and non-array).
>
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr
>
> And then use the compilers' static analysis to warn about doing "owning
> things" to the pointers.
>
> I think the observer_ptr, while a good idea in isolation, has lost to the
> more comprehensive guidelines.
>
>
> Bo Persson
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/p2u66r%245uh%241%40blaine.gmane.org.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hY-kSJAN5jbpp0gSK0GWBtEPpK%3DJx5XR3DsUxJLq=
Ag%2BbA%40mail.gmail.com.
--001a113f3446bb60a5056237586f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wrote my own observer_ptr too, feeling that it states in=
tent explicitly.<div><br></div><div>However, it's probably true that st=
d::reference_wrapper<> does the same job. It's just a little less=
convenient when talking to c apis.</div><div><br></div><div>I don't li=
ke seeing naked pointers in c++ code. I'd be inclined to reject code th=
at used them at code review time unless it could be proven they were necess=
ary.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On 7 January 2018 at 23:17, Bo Persson <span d=
ir=3D"ltr"><<a href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
2018-01-07 18:07, Masse Nicolas wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Le dimanche 10 d=C3=A9cembre 2017 23:07:54 UTC+1, Nicol Bolas a =C3=A9crit=
=C2=A0:<br>
<br>
<br>
=C2=A0 =C2=A0 Basically, naked pointers are treated like a hypothetical<br>
=C2=A0 =C2=A0 `optional<T&>`. If you want an owning pointer, you =
use a smart<br>
=C2=A0 =C2=A0 pointer or, if you cannot properly encapsulate the ownership,=
<br>
=C2=A0 =C2=A0 `gsl::owner<T>`. If you want a non-owning array, you us=
e `gsl::span<T>`.<br>
<br>
=C2=A0 =C2=A0 People are going to use `T*` for non-owning pointers; there&#=
39;s no<br>
=C2=A0 =C2=A0 getting around that. We already have one way to spell that; w=
e don't<br>
=C2=A0 =C2=A0 need a second one.<br>
<br>
<br>
I should say I just don't agree with you.<br>
When people use naked pointer, we can't know wether it is:<br>
- for storing a non-owned pointer<br>
- due to compatibility with C code<br>
- poorly written code<br>
- whathever<br>
<br>
Also it goes against a rule I've set with myself who said that naked po=
inter should always be avoided :D.<br>
<br>
On the other side, when using std::observer_ptr<T>, you know:<br>
- that the given pointer isn't owned and that you should not try to tak=
e any ownership on it.<br>
- the code is not that poorly written :)<br>
<br>
</blockquote>
<br></span>
The trend for the C++ Core Guidelines seems to be that a raw pointer is non=
-owning (and non-array).<br>
<br>
<a href=3D"http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-p=
tr" rel=3D"noreferrer" target=3D"_blank">http://isocpp.github.io/CppCor<wbr=
>eGuidelines/CppCoreGuidelines#<wbr>Rr-ptr</a><br>
<br>
And then use the compilers' static analysis to warn about doing "o=
wning things" to the pointers.<br>
<br>
I think the observer_ptr, while a good idea in isolation, has lost to the m=
ore comprehensive guidelines.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<span class=3D""><br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/p2u66r%245uh%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/p2u66r%245uh%241%40blaine.<wbr>gmane.org</=
a>.<br>
</blockquote></div><br></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/CALvx3hY-kSJAN5jbpp0gSK0GWBtEPpK%3DJx=
5XR3DsUxJLqAg%2BbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hY-kSJA=
N5jbpp0gSK0GWBtEPpK%3DJx5XR3DsUxJLqAg%2BbA%40mail.gmail.com</a>.<br />
--001a113f3446bb60a5056237586f--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 8 Jan 2018 02:17:04 +0200
Raw View
On 8 January 2018 at 00:17, Bo Persson <bop@gmb.dk> wrote:
>> On the other side, when using std::observer_ptr<T>, you know:
>> - that the given pointer isn't owned and that you should not try to take
>> any ownership on it.
>> - the code is not that poorly written :)
>>
>
> The trend for the C++ Core Guidelines seems to be that a raw pointer is
> non-owning (and non-array).
>
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-ptr
>
> And then use the compilers' static analysis to warn about doing "owning
> things" to the pointers.
>
> I think the observer_ptr, while a good idea in isolation, has lost to the
> more comprehensive guidelines.
Lost based on what? All those guidelines provide is yet another
question to ask. The current questions are
1) wtf is that pointer pointing to?
2) who owns it?
Core Guidelines add
3) does the author of this code use Core Guidelines or not?
4) are the Guidelines used everywhere, consistently?
While observer_ptr doesn't help with (1), it provides
2) certainly not you, so none of your concern
3) doesn't matter
4) doesn't matter
observer_ptr is a tool in the toolbox. There are other tools. Those
other tools aren't necessarily better just
because the Core Guidelines authors decided that raw pointers are non-owning.
--
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/CAFk2RUbX0HhCcRBGFoVJAq6Y8NYDOc7%2BnW4yB4Z1y%3D7w%3DnhAMQ%40mail.gmail.com.
.
Author: Masse Nicolas <masse.nicolas@gmail.com>
Date: Mon, 8 Jan 2018 12:02:07 -0800 (PST)
Raw View
------=_Part_15525_161495954.1515441727962
Content-Type: multipart/alternative;
boundary="----=_Part_15526_594878345.1515441727962"
------=_Part_15526_594878345.1515441727962
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le dimanche 7 janvier 2018 23:38:57 UTC+1, Richard Hodges a =C3=A9crit :
>
>
> However, it's probably true that std::reference_wrapper<> does the same=
=20
> job. It's just a little less convenient when talking to c apis.
>
>
Hi,
I agree with you.
std::reference_wrapper could often be used for that purpose.
I think the main problem with it is that they can't store a null pointer,=
=20
which can sometimes be a problem.
Masse Nicolas.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ad884b0a-e694-4be4-9d43-2398bc39b1cb%40isocpp.or=
g.
------=_Part_15526_594878345.1515441727962
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le dimanche 7 janvier 2018 23:38:57 UTC+1, Richard=
Hodges a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br></div><div>However, it's probably true that std:=
:reference_wrapper<> does the same job. It's just a little less c=
onvenient when talking to c apis.</div></div><div><br></div></blockquote><d=
iv><br></div><div>Hi,</div><div>I agree with you.</div><div>std::reference_=
wrapper could often be used for that purpose.</div><div>I think the main pr=
oblem with it is that they can't store a null pointer, which can someti=
mes be a problem.</div><div><br></div><div>Masse Nicolas.<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/ad884b0a-e694-4be4-9d43-2398bc39b1cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad884b0a-e694-4be4-9d43-2398bc39b1cb=
%40isocpp.org</a>.<br />
------=_Part_15526_594878345.1515441727962--
------=_Part_15525_161495954.1515441727962--
.