Topic: Questions on P0137R0 (Core Issue 1776:
Author: Patrice Roy <patricer@gmail.com>
Date: Sun, 10 Jan 2016 11:36:58 -0500
Raw View
--089e01538e30dfc0770528fd6df4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I did not know my personal report would be read by non-French native
speakers. It's cool in a way, although it's more my personal / technical
diary than a formal report like Botond Ballo's or others. Glad it helps,
that being said. I haven't looked at the English translations of my words,
so I can only hope it makes sense.
Others will answer your question #3 better than I could. For #2, I don't
think we have settled on the final wording yet (Hubert or others will
correct me if I'm wrong). for #1, it's definitely a meant as a library
function.
Cheers!
2016-01-10 6:24 GMT-05:00 Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>:
> P0137R0 "Core Issue 1776: Replacement of class objects containing
> reference members"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0137r0.html
>
> This is continuation of the previous thread
>
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gN-_7CJ58G4/=
discussion
> which raised questions on N4430 which is the previous version of P0137R0.
>
> The same request about the contents of the paper still applies to the
> revised one.
> > ... But I believe decisions from such discussions and their
> > rationales will be recorded in public papers.
> >
> > The current version (N4430) seems too quiet on that. I expect revised
> > one will include answers to given questions and possibly some more whic=
h
> > were already solved by yourself or in the committee.
>
> I have tried to read minutes of discussion made at Kona about the paper
> written in the following page in French, with Google translate service.
> http://h-deb.clg.qc.ca/Sujets/Orthogonal/wg21-2015-Kona.html
>
> But I still can't figure out answers for some of questions raised in the
> previous thread. So I retry with summarized questions.
>
>
> 1.
> Where std::launder() is expected to be written?
>
> Is it written in library function (operator* of optional, operator[] of
> vector, ...) or user code which use such functions with concerned types?
>
> This is the last question I made in the previous thread.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/qY=
BlvIv2DgAJ
>
> 2.
> What wording in the current standard (C++14) invalidates accesses
> through a result of conversion (reinterpret_cast) between pointer of an
> object and pointer to its first subobject?
>
> There is addition of Notes in the proposal:
> > [ Note: Nonetheless, if a pointer to the object is cast to a pointer to
> > the type of its first subobject (or vice versa), the resulting pointer
> > does not point to the subobject and cannot be used to access it.
> > =E2=80=94end note ]
> You claimed in the previous thread that "... it was observed that an
> existing C++ optimizer was already optimizing on the basis of such casts
> being invalid, based on a (reasonable) reading of the current wording of
> the standard." as the reason of banning such accesses.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/4J=
G3i4S25z8J
>
> I still can't find any such wording. While I know wording in 3.9.2
> [basic.compound] p3 (which is deleted in the proposal) that can be read
> to allowing such accesses.
> > ... If an object of type T is located at an address A, a pointer of typ=
e
> > cv T* whose value is the address A is said to point to that object,
> > regardless of how the value was obtained. ...
>
> That seems making incompatible changes to get some optimization
> opportunity. Can it be well justified?
>
>
> 3.
> It is possible (or not) to plug the effect of std::launder() to some use
> of built-in cast operators and union member access which are expected to
> be already written in lifetime manipulations like optional<T> do?
>
> That will reduce some chance of optimization, but sounds safer
> direction. It will encouraging people to avoid such casts or union
> member accesses for efficiency, which sounds good direction, too.
>
> This is the same question I made in the previous thread.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/7N=
WbeT1yFmcJ
>
> --
> k_satoda
>
> --
>
> ---
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--089e01538e30dfc0770528fd6df4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I did not know my personal report would be read =
by non-French native speakers. It's cool in a way, although it's mo=
re my personal / technical diary than a formal report like Botond Ballo'=
;s or others. Glad it helps, that being said. I haven't looked at the E=
nglish translations of my words, so I can only hope it makes sense.<br><br>=
</div>Others will answer your question #3 better than I could. For #2, I do=
n't think we have settled on the final wording yet (Hubert or others wi=
ll correct me if I'm wrong). for #1, it's definitely a meant as a l=
ibrary function.<br><br></div>Cheers!<br></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">2016-01-10 6:24 GMT-05:00 Kazutoshi Satoda <s=
pan dir=3D"ltr"><<a href=3D"mailto:k_satoda@f2.dion.ne.jp" target=3D"_bl=
ank">k_satoda@f2.dion.ne.jp</a>></span>:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">P0137R0 "Core Issue 1776: Replacement of class objects containing r=
eference members"<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0137r0.=
html" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2015/p0137r0.html</a><br>
<br>
This is continuation of the previous thread<br>
<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gN-=
_7CJ58G4/discussion" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/topic/std-proposals/gN-_7CJ58G4/discussion</a><br>
which raised questions on N4430 which is the previous version of P0137R0.<b=
r>
<br>
The same request about the contents of the paper still applies to the<br>
revised one.<br>
> ... But I believe decisions from such discussions and their<br>
> rationales will be recorded in public papers.<br>
><br>
> The current version (N4430) seems too quiet on that. I expect revised<=
br>
> one will include answers to given questions and possibly some more whi=
ch<br>
> were already solved by yourself or in the committee.<br>
<br>
I have tried to read minutes of discussion made at Kona about the paper<br>
written in the following page in French, with Google translate service.<br>
<a href=3D"http://h-deb.clg.qc.ca/Sujets/Orthogonal/wg21-2015-Kona.html" re=
l=3D"noreferrer" target=3D"_blank">http://h-deb.clg.qc.ca/Sujets/Orthogonal=
/wg21-2015-Kona.html</a><br>
<br>
But I still can't figure out answers for some of questions raised in th=
e<br>
previous thread. So I retry with summarized questions.<br>
<br>
<br>
1.<br>
Where std::launder() is expected to be written?<br>
<br>
Is it written in library function (operator* of optional, operator[] of<br>
vector, ...) or user code which use such functions with concerned types?<br=
>
<br>
This is the last question I made in the previous thread.<br>
<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7=
CJ58G4/qYBlvIv2DgAJ" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/qYBlvIv2DgAJ</a><br>
<br>
2.<br>
What wording in the current standard (C++14) invalidates accesses<br>
through a result of conversion (reinterpret_cast) between pointer of an<br>
object and pointer to its first subobject?<br>
<br>
There is addition of Notes in the proposal:<br>
> [ Note: Nonetheless, if a pointer to the object is cast to a pointer t=
o<br>
> the type of its first subobject (or vice versa), the resulting pointer=
<br>
> does not point to the subobject and cannot be used to access it.<br>
> =E2=80=94end note ]<br>
You claimed in the previous thread that "... it was observed that an<b=
r>
existing C++ optimizer was already optimizing on the basis of such casts<br=
>
being invalid, based on a (reasonable) reading of the current wording of<br=
>
the standard." as the reason of banning such accesses.<br>
<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7=
CJ58G4/4JG3i4S25z8J" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/4JG3i4S25z8J</a><br>
<br>
I still can't find any such wording. While I know wording in 3.9.2<br>
[basic.compound] p3 (which is deleted in the proposal) that can be read<br>
to allowing such accesses.<br>
> ... If an object of type T is located at an address A, a pointer of ty=
pe<br>
> cv T* whose value is the address A is said to point to that object,<br=
>
> regardless of how the value was obtained. ...<br>
<br>
That seems making incompatible changes to get some optimization<br>
opportunity. Can it be well justified?<br>
<br>
<br>
3.<br>
It is possible (or not) to plug the effect of std::launder() to some use<br=
>
of built-in cast operators and union member access which are expected to<br=
>
be already written in lifetime manipulations like optional<T> do?<br>
<br>
That will reduce some chance of optimization, but sounds safer<br>
direction. It will encouraging people to avoid such casts or union<br>
member accesses for efficiency, which sounds good direction, too.<br>
<br>
This is the same question I made in the previous thread.<br>
<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7=
CJ58G4/7NWbeT1yFmcJ" rel=3D"noreferrer" target=3D"_blank">https://groups.go=
ogle.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/7NWbeT1yFmcJ</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
k_satoda<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e01538e30dfc0770528fd6df4--
.