Topic: Allowing std::complex's magic permission for
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 26 Mar 2018 13:39:55 -0700 (PDT)
Raw View
------=_Part_15556_1354457546.1522096795603
Content-Type: multipart/alternative;
boundary="----=_Part_15557_596373869.1522096795603"
------=_Part_15557_596373869.1522096795603
Content-Type: text/plain; charset="UTF-8"
On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote:
>
> I would like to propose that C++ get a mechanism by which the magical
> ability of std::complex<T> * to be reinterpret_cast to T * could be allowed
> for other classes.
>
> A simple case of this is a vector4 type:
>
> struct vector3 { float x; float y; float z; float w; };
>
> The performance difference is strong enough that our project actually gets
> a much larger performance *increase* from using -fno-strict-aliasing
> versus -fstrict-aliasing with the changes required for compliance.
>
What does strict aliasing have to do with this? The strict aliasing rule is
not what prevents you from being able to do this cast. Indeed, nothing
prevents you from doing the cast. Since `vector4` is standard layout, the
standard *guarantees* that its first subobject shall have the same address
as the object itself. So the cast is OK.
What isn't OK is the pointer arithmetic that follows, or the assumption
that there is no padding between the elements.
--
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/6ec944b3-16c3-4f00-b0c9-a449a522d4ac%40isocpp.org.
------=_Part_15557_596373869.1522096795603
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myr=
iachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I would like to propose that C++ get a mechanism by which the magical abili=
ty of std::complex<T> * to be reinterpret_cast to T * could be allowe=
d for other classes.<br><br>A simple case of this is a vector4 type:<br><br=
>struct vector3 { float x; float y; float z; float w; };<br><br>The perform=
ance difference is strong enough that our project actually gets a much larg=
er performance <i>increase</i> from using -fno-strict-aliasing versus -fstr=
ict-aliasing with the changes required for compliance.<br></div></blockquot=
e><div><br>What does strict aliasing have to do with this? The strict alias=
ing rule is not what prevents you from being able to do this cast. Indeed, =
nothing prevents you from doing the cast. Since `vector4` is standard layou=
t, the standard *guarantees* that its first subobject shall have the same a=
ddress as the object itself. So the cast is OK.<br><br>What isn't OK is=
the pointer arithmetic that follows, or the assumption that there is no pa=
dding between the elements.<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/6ec944b3-16c3-4f00-b0c9-a449a522d4ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6ec944b3-16c3-4f00-b0c9-a449a522d4ac=
%40isocpp.org</a>.<br />
------=_Part_15557_596373869.1522096795603--
------=_Part_15556_1354457546.1522096795603--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 26 Mar 2018 14:59:34 -0700 (PDT)
Raw View
------=_Part_5272_970195018.1522101574846
Content-Type: multipart/alternative;
boundary="----=_Part_5273_1924448923.1522101574846"
------=_Part_5273_1924448923.1522101574846
Content-Type: text/plain; charset="UTF-8"
On Monday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:
>
>
>
> On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote:
>>
>> I would like to propose that C++ get a mechanism by which the magical
>> ability of std::complex<T> * to be reinterpret_cast to T * could be allowed
>> for other classes.
>>
>> A simple case of this is a vector4 type:
>>
>> struct vector3 { float x; float y; float z; float w; };
>>
>> The performance difference is strong enough that our project actually
>> gets a much larger performance *increase* from using
>> -fno-strict-aliasing versus -fstrict-aliasing with the changes required for
>> compliance.
>>
>
> What does strict aliasing have to do with this? The strict aliasing rule
> is not what prevents you from being able to do this cast. Indeed, nothing
> prevents you from doing the cast. Since `vector4` is standard layout, the
> standard *guarantees* that its first subobject shall have the same address
> as the object itself. So the cast is OK.
>
> What isn't OK is the pointer arithmetic that follows,
>
-fstrict-aliasing breaks our code, even though you're correct that it's not
an aliasing problem. -fstrict-aliasing seems to enable optimizations
around pointer arithmetic undefined behavior, and there's no
-fallow-evil-pointer-arithmetic option.
or the assumption that there is no padding between the elements.
>
The padding isn't a problem, because a simple static_assert can verify that
your compiler isn't putting any padding. Such code would be portable to
any implementation that doesn't put padding.
Melissa
--
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/2111ede0-62c6-4a41-8df3-f506d07f09f2%40isocpp.org.
------=_Part_5273_1924448923.1522101574846
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas=
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"><br><b=
r>On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">I would like to propose that=
C++ get a mechanism by which the magical ability of std::complex<T> =
* to be reinterpret_cast to T * could be allowed for other classes.<br><br>=
A simple case of this is a vector4 type:<br><br>struct vector3 { float x; f=
loat y; float z; float w; };<br><br>The performance difference is strong en=
ough that our project actually gets a much larger performance <i>increase</=
i> from using -fno-strict-aliasing versus -fstrict-aliasing with the change=
s required for compliance.<br></div></blockquote><div><br>What does strict =
aliasing have to do with this? The strict aliasing rule is not what prevent=
s you from being able to do this cast. Indeed, nothing prevents you from do=
ing the cast. Since `vector4` is standard layout, the standard *guarantees*=
that its first subobject shall have the same address as the object itself.=
So the cast is OK.<br><br>What isn't OK is the pointer arithmetic that=
follows, </div></div></blockquote><div><br>-fstrict-aliasing breaks our co=
de, even though you're correct that it's not an aliasing problem.=
=C2=A0 -fstrict-aliasing seems to enable optimizations around pointer arith=
metic undefined behavior, and there's no -fallow-evil-pointer-arithmeti=
c option.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>or the assumption that there is no padding between the eleme=
nts.<br></div></div></blockquote><div><br>The padding isn't a problem, =
because a simple static_assert can verify that your compiler isn't putt=
ing any padding.=C2=A0 Such code would be portable to any implementation th=
at doesn't put padding.<br><br>Melissa<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/2111ede0-62c6-4a41-8df3-f506d07f09f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2111ede0-62c6-4a41-8df3-f506d07f09f2=
%40isocpp.org</a>.<br />
------=_Part_5273_1924448923.1522101574846--
------=_Part_5272_970195018.1522101574846--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 26 Mar 2018 18:13:06 -0400
Raw View
--001a114b332c4e46fc05685815bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 26, 2018 at 4:39 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> What isn't OK is the pointer arithmetic that follows, or the assumption
> that there is no padding between the elements.
>
[class.mem] says
[ *Note:* There might therefore be unnamed padding within a standard-layout
struct object, but not at its beginning, as necessary to achieve
appropriate alignment. *=E2=80=94end note* ]
Granted that notes are non-normative, the assumption that padding is
present only to achieve appropriate alignment allows for reasoning about
pointer arithmetic between class members.
--=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/CAHSYqdba84TLvQ8HRCcae-nCQ-5Skyj%2Bi5RA7Z1wfTwcC=
4u2bQ%40mail.gmail.com.
--001a114b332c4e46fc05685815bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 26, 2018 at 4:39 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>What isn't OK is the pointer arithmetic that follows, or the as=
sumption that there is no padding between the elements.</div></div></blockq=
uote><div><br>[class.mem] says<br><div>[ <i>Note:</i> There might therefore=
be unnamed padding within a standard-layout struct object, but not at its =
beginning, as necessary to achieve appropriate alignment. <i>=E2=80=94end n=
ote</i> ]</div><div><br>Granted that notes are non-normative, the assumptio=
n that padding is present only to achieve appropriate alignment allows for =
reasoning about pointer arithmetic between class members.</div></div></div>=
</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/CAHSYqdba84TLvQ8HRCcae-nCQ-5Skyj%2Bi5=
RA7Z1wfTwcC4u2bQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdba84TLvQ=
8HRCcae-nCQ-5Skyj%2Bi5RA7Z1wfTwcC4u2bQ%40mail.gmail.com</a>.<br />
--001a114b332c4e46fc05685815bf--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Mon, 26 Mar 2018 16:53:37 -0700 (PDT)
Raw View
------=_Part_16167_1306440531.1522108417508
Content-Type: multipart/alternative;
boundary="----=_Part_16168_1007763179.1522108417509"
------=_Part_16168_1007763179.1522108417509
Content-Type: text/plain; charset="UTF-8"
On Monday, 26 March 2018 22:59:34 UTC+1, Myriachan wrote:
>
> On Monday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:
>>
>>
>>
>> On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote:
>>>
>>> I would like to propose that C++ get a mechanism by which the magical
>>> ability of std::complex<T> * to be reinterpret_cast to T * could be allowed
>>> for other classes.
>>>
>>> A simple case of this is a vector4 type:
>>>
>>> struct vector3 { float x; float y; float z; float w; };
>>>
>>> The performance difference is strong enough that our project actually
>>> gets a much larger performance *increase* from using
>>> -fno-strict-aliasing versus -fstrict-aliasing with the changes required for
>>> compliance.
>>>
>>
I'm not sure that any such magical ability necessarily exists. Contrary to
the note at cppreference, which does not appear to be derived from any
standards text, the libstdc++ implementation of each specialization
complex<Fp> has a single NSDM of type __complex__ Fp, that is the
corresponding C type _Complex Fp, which is magic at a language level - they
are specified in section 6.2.5 of ISO/IEC 9899, alongside the other
built-in types. It would likewise be perfectly reasonable for an
implementation to use an array Fp[2] as the NSDM, in which case there would
be no need for any magic AIUI.
Have you looked at how other standard libraries satisfy this requirement?
Indeed, other than having to rewrite member variable accesses to member
function calls, is there anything preventing you using a float[4] as the
single NSDM of your vector4 type?
> What does strict aliasing have to do with this? The strict aliasing rule
>> is not what prevents you from being able to do this cast. Indeed, nothing
>> prevents you from doing the cast. Since `vector4` is standard layout, the
>> standard *guarantees* that its first subobject shall have the same address
>> as the object itself. So the cast is OK.
>>
>> What isn't OK is the pointer arithmetic that follows,
>>
>
> -fstrict-aliasing breaks our code, even though you're correct that it's
> not an aliasing problem. -fstrict-aliasing seems to enable optimizations
> around pointer arithmetic undefined behavior, and there's no
> -fallow-evil-pointer-arithmetic option.
>
> or the assumption that there is no padding between the elements.
>>
>
> The padding isn't a problem, because a simple static_assert can verify
> that your compiler isn't putting any padding. Such code would be portable
> to any implementation that doesn't put padding.
>
>
It would be a strange implementation indeed that placed padding between or
after members of the same type. I'm not even sure that it's allowed,
alignas excepted.
> Melissa
>
--
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/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org.
------=_Part_16168_1007763179.1522108417509
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 26 March 2018 22:59:34 UTC+1, Myriachan=
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">On Mo=
nday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, March 26, 2018=
at 4:26:58 PM UTC-4, Myriachan wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">I would like to propose that C++ get a mechanism by whi=
ch the magical ability of std::complex<T> * to be reinterpret_cast to=
T * could be allowed for other classes.<br><br>A simple case of this is a =
vector4 type:<br><br>struct vector3 { float x; float y; float z; float w; }=
;<br><br>The performance difference is strong enough that our project actua=
lly gets a much larger performance <i>increase</i> from using -fno-strict-a=
liasing versus -fstrict-aliasing with the changes required for compliance.<=
/div></blockquote></div></blockquote></div></blockquote><div>=C2=A0</div><d=
iv>I'm not sure that any such magical ability necessarily exists. Contr=
ary to the note at cppreference, which does not appear to be derived from a=
ny standards text, the libstdc++ implementation of each specialization comp=
lex<Fp> has a single NSDM of type __complex__ Fp, that is the corresp=
onding C type _Complex Fp, which is magic at a language level - they are sp=
ecified in section 6.2.5 of ISO/IEC 9899, alongside the other built-in type=
s. It would likewise be perfectly reasonable for an implementation to use a=
n array Fp[2] as the NSDM, in which case there would be no need for any mag=
ic AIUI.</div><div><br></div><div>Have you looked at how other standard lib=
raries satisfy this requirement?</div><div><br></div><div>Indeed, other tha=
n having to rewrite member variable accesses to member function calls, is t=
here anything preventing you using a float[4] as the single NSDM of your ve=
ctor4 type?=C2=A0</div><div>=C2=A0</div><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"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>What does strict aliasing have to do with this? The strict al=
iasing rule is not what prevents you from being able to do this cast. Indee=
d, nothing prevents you from doing the cast. Since `vector4` is standard la=
yout, the standard *guarantees* that its first subobject shall have the sam=
e address as the object itself. So the cast is OK.<br><br>What isn't OK=
is the pointer arithmetic that follows, </div></div></blockquote><div><br>=
-fstrict-aliasing breaks our code, even though you're correct that it&#=
39;s not an aliasing problem.=C2=A0 -fstrict-aliasing seems to enable optim=
izations around pointer arithmetic undefined behavior, and there's no -=
fallow-evil-pointer-<wbr>arithmetic option.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>or the assumption that there i=
s no padding between the elements.<br></div></div></blockquote><div><br>The=
padding isn't a problem, because a simple static_assert can verify tha=
t your compiler isn't putting any padding.=C2=A0 Such code would be por=
table to any implementation that doesn't put padding.<br><br></div></di=
v></blockquote><div><br></div><div>It would be a strange implementation ind=
eed that placed padding between or after members of the same type. I'm =
not even sure that it's allowed, alignas excepted.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Meliss=
a<br></div></div></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/627b1086-2f31-402a-92b0-223bf15d33b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/627b1086-2f31-402a-92b0-223bf15d33b5=
%40isocpp.org</a>.<br />
------=_Part_16168_1007763179.1522108417509--
------=_Part_16167_1306440531.1522108417508--
.
Author: Bo Persson <bop@gmb.dk>
Date: Tue, 27 Mar 2018 02:03:20 +0200
Raw View
On 2018-03-26 22:26, Myriachan wrote:
> I would like to propose that C++ get a mechanism by which the magical
> ability of std::complex<T> * to be reinterpret_cast to T * could be
> allowed for other classes.
>
> A simple case of this is a vector4 type:
>
> struct vector3 { float x; float y; float z; float w; };
>
> The performance difference is strong enough that our project actually
> gets a much larger performance /increase/ from using
> -fno-strict-aliasing versus -fstrict-aliasing with the changes required
> for compliance.
>
This is not what the std::complex magic requires from the compiler.
At least one implementation (MSVC) instead stores a two element array,
which does away with any potential padding and also makes pointer
arithmetic reasonable.
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/isocpp.org/d/msgid/std-proposals/p9c1k7%24h28%241%40blaine.gmane.org.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 27 Mar 2018 05:35:20 +0000
Raw View
--001a113acf404395de05685e42d9
Content-Type: text/plain; charset="UTF-8"
On Mon, 26 Mar 2018, 16:53 Edward Catmur, <ed@catmur.co.uk> wrote:
>
>
> On Monday, 26 March 2018 22:59:34 UTC+1, Myriachan wrote:
>>
>> On Monday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote:
>>>>
>>>> I would like to propose that C++ get a mechanism by which the magical
>>>> ability of std::complex<T> * to be reinterpret_cast to T * could be allowed
>>>> for other classes.
>>>>
>>>> A simple case of this is a vector4 type:
>>>>
>>>> struct vector3 { float x; float y; float z; float w; };
>>>>
>>>> The performance difference is strong enough that our project actually
>>>> gets a much larger performance *increase* from using
>>>> -fno-strict-aliasing versus -fstrict-aliasing with the changes required for
>>>> compliance.
>>>>
>>>
> I'm not sure that any such magical ability necessarily exists. Contrary to
> the note at cppreference, which does not appear to be derived from any
> standards text, the libstdc++ implementation of each specialization
> complex<Fp> has a single NSDM of type __complex__ Fp, that is the
> corresponding C type _Complex Fp, which is magic at a language level - they
> are specified in section 6.2.5 of ISO/IEC 9899, alongside the other
> built-in types. It would likewise be perfectly reasonable for an
> implementation to use an array Fp[2] as the NSDM, in which case there would
> be no need for any magic AIUI.
>
> Have you looked at how other standard libraries satisfy this requirement?
>
> Indeed, other than having to rewrite member variable accesses to member
> function calls, is there anything preventing you using a float[4] as the
> single NSDM of your vector4 type?
>
>
>> What does strict aliasing have to do with this? The strict aliasing rule
>>> is not what prevents you from being able to do this cast. Indeed, nothing
>>> prevents you from doing the cast. Since `vector4` is standard layout, the
>>> standard *guarantees* that its first subobject shall have the same address
>>> as the object itself. So the cast is OK.
>>>
>>> What isn't OK is the pointer arithmetic that follows,
>>>
>>
>> -fstrict-aliasing breaks our code, even though you're correct that it's
>> not an aliasing problem. -fstrict-aliasing seems to enable optimizations
>> around pointer arithmetic undefined behavior, and there's no
>> -fallow-evil-pointer-arithmetic option.
>>
>> or the assumption that there is no padding between the elements.
>>>
>>
>> The padding isn't a problem, because a simple static_assert can verify
>> that your compiler isn't putting any padding. Such code would be portable
>> to any implementation that doesn't put padding.
>>
>>
> It would be a strange implementation indeed that placed padding between or
> after members of the same type. I'm not even sure that it's allowed,
> alignas excepted.
>
It is allowed, and ASan has a mode that does this to detect out-of-bounds
accesses within a class.
Melissa
>>
> --
> 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/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAOfiQq%3D-4tNw6mt19ri9L8V2JP8Dh_OPt38WL-%3D10dkEVnYOGA%40mail.gmail.com.
--001a113acf404395de05685e42d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Mon, 26 Mar 2018, 16:53 Edward Catmur, <<a href=3D"mailto:ed@catmur.c=
o.uk">ed@catmur.co.uk</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><br><br>On Monday, 26 March 2018 22:59:34 UTC+1, Myriach=
an 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">On Monda=
y, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, March 26, 2018 a=
t 4:26:58 PM UTC-4, Myriachan 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">I would like to propose that C++ get a mechanism by which=
the magical ability of std::complex<T> * to be reinterpret_cast to T=
* could be allowed for other classes.<br><br>A simple case of this is a ve=
ctor4 type:<br><br>struct vector3 { float x; float y; float z; float w; };<=
br><br>The performance difference is strong enough that our project actuall=
y gets a much larger performance <i>increase</i> from using -fno-strict-ali=
asing versus -fstrict-aliasing with the changes required for compliance.</d=
iv></blockquote></div></blockquote></div></blockquote><div>=C2=A0</div><div=
>I'm not sure that any such magical ability necessarily exists. Contrar=
y to the note at cppreference, which does not appear to be derived from any=
standards text, the libstdc++ implementation of each specialization comple=
x<Fp> has a single NSDM of type __complex__ Fp, that is the correspon=
ding C type _Complex Fp, which is magic at a language level - they are spec=
ified in section 6.2.5 of ISO/IEC 9899, alongside the other built-in types.=
It would likewise be perfectly reasonable for an implementation to use an =
array Fp[2] as the NSDM, in which case there would be no need for any magic=
AIUI.</div><div><br></div><div>Have you looked at how other standard libra=
ries satisfy this requirement?</div><div><br></div><div>Indeed, other than =
having to rewrite member variable accesses to member function calls, is the=
re anything preventing you using a float[4] as the single NSDM of your vect=
or4 type?=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>What does strict aliasing have to do with this? The strict aliasing =
rule is not what prevents you from being able to do this cast. Indeed, noth=
ing prevents you from doing the cast. Since `vector4` is standard layout, t=
he standard *guarantees* that its first subobject shall have the same addre=
ss as the object itself. So the cast is OK.<br><br>What isn't OK is the=
pointer arithmetic that follows, </div></div></blockquote><div><br>-fstric=
t-aliasing breaks our code, even though you're correct that it's no=
t an aliasing problem.=C2=A0 -fstrict-aliasing seems to enable optimization=
s around pointer arithmetic undefined behavior, and there's no -fallow-=
evil-pointer-arithmetic option.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>or the assumption that there is no padding =
between the elements.<br></div></div></blockquote><div><br>The padding isn&=
#39;t a problem, because a simple static_assert can verify that your compil=
er isn't putting any padding.=C2=A0 Such code would be portable to any =
implementation that doesn't put padding.<br><br></div></div></blockquot=
e><div><br></div><div>It would be a strange implementation indeed that plac=
ed padding between or after members of the same type. I'm not even sure=
that it's allowed, alignas excepted.</div></div></blockquote></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">It is allowed, and ASan has a mo=
de that does this to detect out-of-bounds accesses within a class.</div><di=
v dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Melissa<br></div></div></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" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/627b1086-2f31-402a-92b0-223bf15d33b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org</a>.<br>
</blockquote></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/CAOfiQq%3D-4tNw6mt19ri9L8V2JP8Dh_OPt3=
8WL-%3D10dkEVnYOGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D-4t=
Nw6mt19ri9L8V2JP8Dh_OPt38WL-%3D10dkEVnYOGA%40mail.gmail.com</a>.<br />
--001a113acf404395de05685e42d9--
.
Author: florian.csdt@gmail.com
Date: Tue, 27 Mar 2018 02:53:23 -0700 (PDT)
Raw View
------=_Part_17608_1844072844.1522144403475
Content-Type: multipart/alternative;
boundary="----=_Part_17609_1346117342.1522144403475"
------=_Part_17609_1346117342.1522144403475
Content-Type: text/plain; charset="UTF-8"
I have the impression that people are missing the big picture here.
I see one big problem that can be solved with overloadable
reinterpret_cast: smart pointers.
If you look closely at shared_pointer for instance, you will see:
template <class T, class U>
std::shared_ptr<T> static_pointer_cast(const std::shared_ptr<U>& r) noexcept
;
template <class T, class U>
std::shared_ptr<T> dynamic_pointer_cast(const std::shared_ptr<U>& r)
noexcept;
template <class T, class U>
std::shared_ptr<T> const_pointer_cast(const std::shared_ptr<U>& r) noexcept;
template <class T, class U>
std::shared_ptr<T> reinterpret_pointer_cast(const std::shared_ptr<U>& r)
noexcept;
If it were possible to overload dynamic_cast const_cast and
reinterpret_cast, this would have been unnecessary to have a different
interface for shared pointers than for regular pointers.
--
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/2f3f1821-385e-4357-bcf4-9a87312853fe%40isocpp.org.
------=_Part_17609_1346117342.1522144403475
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have the impression that people are missing the big pict=
ure here.<br><br>I see one big problem that can be solved with overloadable=
reinterpret_cast: smart pointers.<br>If you look closely at shared_pointer=
for instance, you will see:<br><br><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
class=3D"styled-by-prettify"></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">shared_ptr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sta=
tic_pointer_cast</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
st</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">shared_ptr</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">U</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">>&</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> noexcept</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><br><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">template</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">shared_ptr</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> dyn=
amic_pointer_cast</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">shared_ptr</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">U</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">>&</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> noexcept</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span></code></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> U</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">shared_ptr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> const_pointer_cast</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">shared_ptr</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>&=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></code></span></code></sp=
an><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">shared_ptr</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> reinterpret_p=
ointer_cast</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">shared_ptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">U</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">>&</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> noexcept</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></code></div></code></div><br>If it were possible to overlo=
ad dynamic_cast const_cast and reinterpret_cast, this would have been unnec=
essary to have a different interface for shared pointers than for regular p=
ointers.<br><br><div style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow=
-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><table class=3D"t-dcl-begin"></table></div></code>=
</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/2f3f1821-385e-4357-bcf4-9a87312853fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f3f1821-385e-4357-bcf4-9a87312853fe=
%40isocpp.org</a>.<br />
------=_Part_17609_1346117342.1522144403475--
------=_Part_17608_1844072844.1522144403475--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 27 Mar 2018 05:42:03 -0700 (PDT)
Raw View
------=_Part_18019_1477038113.1522154523740
Content-Type: multipart/alternative;
boundary="----=_Part_18020_473006291.1522154523740"
------=_Part_18020_473006291.1522154523740
Content-Type: text/plain; charset="UTF-8"
On Tuesday, 27 March 2018 01:03:29 UTC+1, Bo Persson wrote:
>
> On 2018-03-26 22:26, Myriachan wrote:
> > I would like to propose that C++ get a mechanism by which the magical
> > ability of std::complex<T> * to be reinterpret_cast to T * could be
> > allowed for other classes.
> >
> > A simple case of this is a vector4 type:
> >
> > struct vector3 { float x; float y; float z; float w; };
> >
> > The performance difference is strong enough that our project actually
> > gets a much larger performance /increase/ from using
> > -fno-strict-aliasing versus -fstrict-aliasing with the changes required
> > for compliance.
> >
>
> This is not what the std::complex magic requires from the compiler.
>
> At least one implementation (MSVC) instead stores a two element array,
> which does away with any potential padding and also makes pointer
> arithmetic reasonable.
>
Thanks. I've updated http://en.cppreference.com/w/cpp/numeric/complex
(section "Implementation notes") to reflect that MSVC uses the array
strategy and that magic is not needed for pointer arithmetic in that case.
nb. I'm making an unwarranted but I believe reasonable assumption that the
belief that complex is necessarily magic can be traced back to resources
like cppreference, and in any case can be successfully challenged there.
--
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/bf65a7d6-c289-4a6b-8da0-c72c97d5a082%40isocpp.org.
------=_Part_18020_473006291.1522154523740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 27 March 2018 01:03:29 UTC+1, Bo Persson wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 2018-03-26 22:26, Myriach=
an wrote:
<br>> I would like to propose that C++ get a mechanism by which the magi=
cal=20
<br>> ability of std::complex<T> * to be reinterpret_cast to T * c=
ould be=20
<br>> allowed for other classes.
<br>>=20
<br>> A simple case of this is a vector4 type:
<br>>=20
<br>> struct vector3 { float x; float y; float z; float w; };
<br>>=20
<br>> The performance difference is strong enough that our project actua=
lly=20
<br>> gets a much larger performance /increase/ from using=20
<br>> -fno-strict-aliasing versus -fstrict-aliasing with the changes req=
uired=20
<br>> for compliance.
<br>>=20
<br>
<br>This is not what the std::complex magic requires from the compiler.
<br>
<br>At least one implementation (MSVC) instead stores a two element array,=
=20
<br>which does away with any potential padding and also makes pointer=20
<br>arithmetic reasonable.
<br>
</blockquote><div><br></div><div>Thanks. I've updated http://en.cpprefe=
rence.com/w/cpp/numeric/complex (section "Implementation notes") =
to reflect that MSVC uses the array strategy and that magic is not needed f=
or pointer arithmetic in that case.</div><div><br></div><div>nb. I'm ma=
king an unwarranted but I believe reasonable assumption that the belief tha=
t complex is necessarily magic can be traced back to resources like cpprefe=
rence, and in any case can be successfully challenged there.</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/bf65a7d6-c289-4a6b-8da0-c72c97d5a082%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf65a7d6-c289-4a6b-8da0-c72c97d5a082=
%40isocpp.org</a>.<br />
------=_Part_18020_473006291.1522154523740--
------=_Part_18019_1477038113.1522154523740--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 27 Mar 2018 06:57:26 -0700 (PDT)
Raw View
------=_Part_18521_1404379364.1522159046543
Content-Type: multipart/alternative;
boundary="----=_Part_18522_882855502.1522159046543"
------=_Part_18522_882855502.1522159046543
Content-Type: text/plain; charset="UTF-8"
On Tuesday, March 27, 2018 at 5:53:23 AM UTC-4, floria...@gmail.com wrote:
>
> I have the impression that people are missing the big picture here.
>
> I see one big problem that can be solved with overloadable
> reinterpret_cast: smart pointers.
> If you look closely at shared_pointer for instance, you will see:
>
> template <class T, class U>
> std::shared_ptr<T> static_pointer_cast(const std::shared_ptr<U>& r)
> noexcept;
>
> template <class T, class U>
> std::shared_ptr<T> dynamic_pointer_cast(const std::shared_ptr<U>& r)
> noexcept;
>
> template <class T, class U>
> std::shared_ptr<T> const_pointer_cast(const std::shared_ptr<U>& r)
> noexcept;
>
> template <class T, class U>
> std::shared_ptr<T> reinterpret_pointer_cast(const std::shared_ptr<U>& r)
> noexcept;
>
> If it were possible to overload dynamic_cast const_cast and
> reinterpret_cast, this would have been unnecessary to have a different
> interface for shared pointers than for regular pointers.
>
If it were impossible to overload the reference operator, we wouldn't need
to use `std::addressof` in template programming. But we allowed that, and
therefore we have to write 99% of our `&value` statements as
`std::addressof(value)` just to dodge those few users who unwisely overload
`operator&`.
There are some operations where overloading on user-defined types is
reasonable. Casting is not one of them (and neither is `operator&`, but
that ship has sailed). If you need to execute specialized code for a cast,
then it's not a *cast* at all; it's simply a function call.
--
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/97df4987-b0ed-4080-b58d-fe48b532d1cf%40isocpp.org.
------=_Part_18522_882855502.1522159046543
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 27, 2018 at 5:53:23 AM UTC-4, floria...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">I have the impression that people are missing the big picture here.<br><=
br>I see one big problem that can be solved with overloadable reinterpret_c=
ast: smart pointers.<br>If you look closely at shared_pointer for instance,=
you will see:<br><br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><s=
pan style=3D"color:#000"></span><span style=3D"color:#008">template</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#008">class</span><span style=3D"color:#000"> T</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">class</span><span style=3D"color:#000"> U</span><span st=
yle=3D"color:#660">></span><span style=3D"color:#000"><br>std</span><spa=
n style=3D"color:#660">::</span><span style=3D"color:#000">shared_ptr</span=
><span style=3D"color:#660"><</span><span style=3D"color:#000">T</span><=
span style=3D"color:#660">></span><span style=3D"color:#000"> static_poi=
nter_cast</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
8">const</span><span style=3D"color:#000"> std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000">shared_ptr</span><span style=3D"co=
lor:#660"><</span><span style=3D"color:#000">U</span><span style=3D"colo=
r:#660">>&</span><span style=3D"color:#000"> r</span><span style=3D"=
color:#660">)</span><span style=3D"color:#000"> noexcept</span><span style=
=3D"color:#660">;</span><br><span style=3D"color:#000"><code><span style=3D=
"color:#000"><br></span><span style=3D"color:#008">template</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660"><</span><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> T</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">class</span><span style=3D"color:#000"> U</span><span style=3D"c=
olor:#660">></span><span style=3D"color:#000"><br>std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">shared_ptr</span><span =
style=3D"color:#660"><</span><span style=3D"color:#000">T</span><span st=
yle=3D"color:#660">></span><span style=3D"color:#000"> dynamic_pointer_c=
ast</span><span style=3D"color:#660">(</span><span style=3D"color:#008">con=
st</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">shared_ptr</span><span style=3D"color:#6=
60"><</span><span style=3D"color:#000">U</span><span style=3D"color:#660=
">>&</span><span style=3D"color:#000"> r</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> noexcept</span><span style=3D"col=
or:#660">;</span></code></span><span style=3D"color:#000"><code><span style=
=3D"color:#660"><code><span style=3D"color:#000"><br><br></span><span style=
=3D"color:#008">template</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660"><</span><span style=3D"color:#008">class</span><span s=
tyle=3D"color:#000"> T</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> U</span><span style=3D"color:#660">></span><span style=
=3D"color:#000"><br>std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">shared_ptr</span><span style=3D"color:#660"><</span><s=
pan style=3D"color:#000">T</span><span style=3D"color:#660">></span><spa=
n style=3D"color:#000"> const_pointer_cast</span><span style=3D"color:#660"=
>(</span><span style=3D"color:#008">const</span><span style=3D"color:#000">=
std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">s=
hared_ptr</span><span style=3D"color:#660"><</span><span style=3D"color:=
#000">U</span><span style=3D"color:#660">>&</span><span style=3D"col=
or:#000"> r</span><span style=3D"color:#660">)</span><span style=3D"color:#=
000"> noexcept</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br></span></code></span></code></span><code><span style=3D"color:#=
000"><br></span><span style=3D"color:#008">template</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660"><</span><span style=3D"colo=
r:#008">class</span><span style=3D"color:#000"> T</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">class</span><span style=3D"color:#000"> U</span><span style=3D"color:#66=
0">></span><span style=3D"color:#000"><br>std</span><span style=3D"color=
:#660">::</span><span style=3D"color:#000">shared_ptr</span><span style=3D"=
color:#660"><</span><span style=3D"color:#000">T</span><span style=3D"co=
lor:#660">></span><span style=3D"color:#000"> reinterpret_pointer_cast</=
span><span style=3D"color:#660">(</span><span style=3D"color:#008">const</s=
pan><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">shared_ptr</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#000">U</span><span style=3D"color:#660">>=
;&</span><span style=3D"color:#000"> r</span><span style=3D"color:#660"=
>)</span><span style=3D"color:#000"> noexcept</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br></span></code></div></code></div=
><br>If it were possible to overload dynamic_cast const_cast and reinterpre=
t_cast, this would have been unnecessary to have a different interface for =
shared pointers than for regular pointers.<br></div></blockquote><div><br>I=
f it were impossible to overload the reference operator, we wouldn't ne=
ed to use `std::addressof` in template programming. But we allowed that, an=
d therefore we have to write 99% of our `&value` statements as `std::ad=
dressof(value)` just to dodge those few users who unwisely overload `operat=
or&`.<br><br>There are some operations where overloading on user-define=
d types is reasonable. Casting is not one of them (and neither is `operator=
&`, but that ship has sailed). If you need to execute specialized code =
for a cast, then it's not a <i>cast</i> at all; it's simply a funct=
ion call.<br>=C2=A0</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/97df4987-b0ed-4080-b58d-fe48b532d1cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97df4987-b0ed-4080-b58d-fe48b532d1cf=
%40isocpp.org</a>.<br />
------=_Part_18522_882855502.1522159046543--
------=_Part_18521_1404379364.1522159046543--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 27 Mar 2018 16:17:56 -0700 (PDT)
Raw View
------=_Part_4095_396938688.1522192676957
Content-Type: multipart/alternative;
boundary="----=_Part_4096_194246022.1522192676957"
------=_Part_4096_194246022.1522192676957
Content-Type: text/plain; charset="UTF-8"
On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Persson wrote:
>
> On 2018-03-26 22:26, Myriachan wrote:
> > I would like to propose that C++ get a mechanism by which the magical
> > ability of std::complex<T> * to be reinterpret_cast to T * could be
> > allowed for other classes.
> >
> > A simple case of this is a vector4 type:
> >
> > struct vector3 { float x; float y; float z; float w; };
> >
> > The performance difference is strong enough that our project actually
> > gets a much larger performance /increase/ from using
> > -fno-strict-aliasing versus -fstrict-aliasing with the changes required
> > for compliance.
> >
>
> This is not what the std::complex magic requires from the compiler.
>
> At least one implementation (MSVC) instead stores a two element array,
> which does away with any potential padding and also makes pointer
> arithmetic reasonable.
>
The C++ Standard rules state that you can treat an array of
std::complex<float> as an array of float of double the number of elements.
That is, you can do pointer arithmetic on a float * that crosses
complex<float> objects. That cannot be done other than with compiler
magic. (Or compiler ignorance, which is how we've gotten away with it so
far.)
--
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/e85dfb30-f3ff-4769-90d2-373efceda1e6%40isocpp.org.
------=_Part_4096_194246022.1522192676957
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Persson =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-03-26 22:26, Myr=
iachan wrote:
<br>> I would like to propose that C++ get a mechanism by which the magi=
cal=20
<br>> ability of std::complex<T> * to be reinterpret_cast to T * c=
ould be=20
<br>> allowed for other classes.
<br>>=20
<br>> A simple case of this is a vector4 type:
<br>>=20
<br>> struct vector3 { float x; float y; float z; float w; };
<br>>=20
<br>> The performance difference is strong enough that our project actua=
lly=20
<br>> gets a much larger performance /increase/ from using=20
<br>> -fno-strict-aliasing versus -fstrict-aliasing with the changes req=
uired=20
<br>> for compliance.
<br>>=20
<br>
<br>This is not what the std::complex magic requires from the compiler.
<br>
<br>At least one implementation (MSVC) instead stores a two element array,=
=20
<br>which does away with any potential padding and also makes pointer=20
<br>arithmetic reasonable.
<br></blockquote><div><br>The C++ Standard rules state that you can treat a=
n array of std::complex<float> as an array of float of double the num=
ber of elements.=C2=A0 That is, you can do pointer arithmetic on a float * =
that crosses complex<float> objects.=C2=A0 That cannot be done other =
than with compiler magic.=C2=A0 (Or compiler ignorance, which is how we'=
;ve gotten away with it so far.)<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/e85dfb30-f3ff-4769-90d2-373efceda1e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e85dfb30-f3ff-4769-90d2-373efceda1e6=
%40isocpp.org</a>.<br />
------=_Part_4096_194246022.1522192676957--
------=_Part_4095_396938688.1522192676957--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Mar 2018 07:17:27 +0000
Raw View
--089e082d4ae844f16b056873cde2
Content-Type: text/plain; charset="UTF-8"
On Wed, 28 Mar 2018, 00:18 Myriachan, <myriachan@gmail.com> wrote:
> On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Persson wrote:
>>
>> On 2018-03-26 22:26, Myriachan wrote:
>> > I would like to propose that C++ get a mechanism by which the magical
>> > ability of std::complex<T> * to be reinterpret_cast to T * could be
>> > allowed for other classes.
>> >
>> > A simple case of this is a vector4 type:
>> >
>> > struct vector3 { float x; float y; float z; float w; };
>> >
>> > The performance difference is strong enough that our project actually
>> > gets a much larger performance /increase/ from using
>> > -fno-strict-aliasing versus -fstrict-aliasing with the changes required
>> > for compliance.
>> >
>>
>> This is not what the std::complex magic requires from the compiler.
>>
>> At least one implementation (MSVC) instead stores a two element array,
>> which does away with any potential padding and also makes pointer
>> arithmetic reasonable.
>>
>
> The C++ Standard rules state that you can treat an array of
> std::complex<float> as an array of float of double the number of elements.
> That is, you can do pointer arithmetic on a float * that crosses
> complex<float> objects. That cannot be done haveer than with compiler
> magic. (Or compiler ignorance, which is how we've gotten away with it so
> far.)
>
Right, so we can infer that MSVC allows treating an array of n struct of
array of m T as an array of n*m T. If that ever changes they will need to
add magic to their complex, but as it is MSVC's complex does not need
magic.
I suppose that means that they could expose the magic as a no-op, but how
would you expose that the required class formation is struct of array of m
T, rather than your (and clang's) struct of m T data members?
And as for gcc, libstdc++ complex gets its magic from C _Complex. That
means the magic it uses is already available to you, but is not useful to
you as it only works for the case of 2 components.
--
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/e85dfb30-f3ff-4769-90d2-373efceda1e6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e85dfb30-f3ff-4769-90d2-373efceda1e6%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOanFv25KDw0fMu%3D-pZ%3D%2BTfis1rzOHXR_eZXUJX9ezAeTg%40mail.gmail.com.
--089e082d4ae844f16b056873cde2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, 28 Mar 2018, 00:18 Myriachan, <<a href=3D"mailto:myriachan@gmail=
..com">myriachan@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Pe=
rsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-03-26 22:26, My=
riachan wrote:
<br>> I would like to propose that C++ get a mechanism by which the magi=
cal=20
<br>> ability of std::complex<T> * to be reinterpret_cast to T * c=
ould be=20
<br>> allowed for other classes.
<br>>=20
<br>> A simple case of this is a vector4 type:
<br>>=20
<br>> struct vector3 { float x; float y; float z; float w; };
<br>>=20
<br>> The performance difference is strong enough that our project actua=
lly=20
<br>> gets a much larger performance /increase/ from using=20
<br>> -fno-strict-aliasing versus -fstrict-aliasing with the changes req=
uired=20
<br>> for compliance.
<br>>=20
<br>
<br>This is not what the std::complex magic requires from the compiler.
<br>
<br>At least one implementation (MSVC) instead stores a two element array,=
=20
<br>which does away with any potential padding and also makes pointer=20
<br>arithmetic reasonable.
<br></blockquote><div><br>The C++ Standard rules state that you can treat a=
n array of std::complex<float> as an array of float of double the num=
ber of elements.=C2=A0 That is, you can do pointer arithmetic on a float * =
that crosses complex<float> objects.=C2=A0 That cannot be done haveer=
than with compiler magic.=C2=A0 (Or compiler ignorance, which is how we=
9;ve gotten away with it so far.)<br></div></div></blockquote></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Right, so we can infer that MS=
VC allows treating an array of n struct of array of m T as an array of n*m =
T. If that ever changes they will need to add magic to their complex, but a=
s it is MSVC's complex does not need magic.=C2=A0</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">I suppose that means that they could expose t=
he magic as a no-op, but how would you expose that the required class forma=
tion is struct of array of m T, rather than your (and clang's) struct o=
f m T data members?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">And as for gcc, libstdc++ complex gets its magic from C _Complex. That me=
ans the magic it uses is already available to you, but is not useful to you=
as it only works for the case of 2 components.=C2=A0</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/HpRRF7RWzTY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
oreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/e85dfb30-f3ff-4769-90d2-373efceda1e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/e85dfb30-f3ff-4769-90d2-373efceda1e6%40isocpp.org</a>.<br>
</blockquote></div></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/CAJnLdOanFv25KDw0fMu%3D-pZ%3D%2BTfis1=
rzOHXR_eZXUJX9ezAeTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOanFv=
25KDw0fMu%3D-pZ%3D%2BTfis1rzOHXR_eZXUJX9ezAeTg%40mail.gmail.com</a>.<br />
--089e082d4ae844f16b056873cde2--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 28 Mar 2018 12:34:59 +0200
Raw View
--000000000000235d610568768f78
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 1:17 AM, Myriachan <myriachan@gmail.com> wrote:
> The C++ Standard rules state that you can treat an array of
std::complex<float> as an array of float of double the number of elements.
That is, you can do pointer arithmetic on a float * that crosses
complex<float> objects. That cannot be done other than with compiler magic.
Only "if a is an expression of type cv complex<T>* and the expression a[i]
is well-defined for an integer expression i", which has to mean that we
have an array of complex objects. Given that each is required to be layout
compatible with T[2], reinterpreting the bigger array as T[2 * (i + 1)]
does not need any more magic.
Cheers,
V.
--
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/CAA7YVg2n1N_QrxC09Er4vLr%2BebwQ5GhkD-3isND76d4YJHwC0g%40mail.gmail.com.
--000000000000235d610568768f78
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 1:17 AM, Myriachan <span dir=3D"ltr"><<a href=3D"mai=
lto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></spa=
n> wrote:<br><div><br></div><div>> The C++ Standard rules state that you=
can treat an array of std::complex<float> as an array of float of do=
uble the number of elements.=C2=A0 That is, you can do pointer arithmetic o=
n a float * that crosses complex<float> objects.=C2=A0 That cannot be=
done other than with compiler magic.</div><div><br></div><div>Only "i=
f a is an expression of type cv complex<T>* and the expression a[i] i=
s well-defined for an integer expression i", which has to mean that we=
have an array of complex objects. Given that each is required to be layout=
compatible with T[2], reinterpreting the bigger array as T[2 * (i + 1)] do=
es not need any more magic.</div><div><br></div><div>Cheers,</div><div>V.</=
div><div><br></div></div></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/CAA7YVg2n1N_QrxC09Er4vLr%2BebwQ5GhkD-=
3isND76d4YJHwC0g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2n1N_Qrx=
C09Er4vLr%2BebwQ5GhkD-3isND76d4YJHwC0g%40mail.gmail.com</a>.<br />
--000000000000235d610568768f78--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Wed, 28 Mar 2018 06:24:19 -0700 (PDT)
Raw View
------=_Part_22928_1271282971.1522243459364
Content-Type: multipart/alternative;
boundary="----=_Part_22929_983829046.1522243459364"
------=_Part_22929_983829046.1522243459364
Content-Type: text/plain; charset="UTF-8"
On Wednesday, 28 March 2018 11:35:02 UTC+1, Viacheslav Usov wrote:
>
> On Wed, Mar 28, 2018 at 1:17 AM, Myriachan <myri...@gmail.com
> <javascript:>> wrote:
>
> > The C++ Standard rules state that you can treat an array of
> std::complex<float> as an array of float of double the number of elements.
> That is, you can do pointer arithmetic on a float * that crosses
> complex<float> objects. That cannot be done other than with compiler magic.
>
> Only "if a is an expression of type cv complex<T>* and the expression a[i]
> is well-defined for an integer expression i", which has to mean that we
> have an array of complex objects. Given that each is required to be layout
> compatible with T[2], reinterpreting the bigger array as T[2 * (i + 1)]
> does not need any more magic.
>
No, you need magic to perform aliasing between any kind of array types.
[expr.add]/4 does not permit aliasing, so any array arithmetic must remain
within the bounds of an array that actually exists.
> Cheers,
> V.
>
>
--
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/018c02d9-7c65-4451-acc1-c49196fc7622%40isocpp.org.
------=_Part_22929_983829046.1522243459364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, 28 March 2018 11:35:02 UTC+1, Viache=
slav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Mar 28, 2018 at 1:17 AM, Myriac=
han <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"44DtIOiiAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">myri...@gmail.com</a>></span> wrote:<br><div><br>=
</div><div>> The C++ Standard rules state that you can treat an array of=
std::complex<float> as an array of float of double the number of ele=
ments.=C2=A0 That is, you can do pointer arithmetic on a float * that cross=
es complex<float> objects.=C2=A0 That cannot be done other than with =
compiler magic.</div><div><br></div><div>Only "if a is an expression o=
f type cv complex<T>* and the expression a[i] is well-defined for an =
integer expression i", which has to mean that we have an array of comp=
lex objects. Given that each is required to be layout compatible with T[2],=
reinterpreting the bigger array as T[2 * (i + 1)] does not need any more m=
agic.</div></div></div></div></blockquote><div><br></div><div>No, you need =
magic to perform aliasing between any kind of array types. [expr.add]/4 doe=
s not permit aliasing, so any array arithmetic must remain within the bound=
s of an array that actually exists.</div><div>=C2=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><div></div><div>Cheers,</div><div>V.</div><div><br></div></div></div>=
</div>
</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/018c02d9-7c65-4451-acc1-c49196fc7622%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/018c02d9-7c65-4451-acc1-c49196fc7622=
%40isocpp.org</a>.<br />
------=_Part_22929_983829046.1522243459364--
------=_Part_22928_1271282971.1522243459364--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 28 Mar 2018 16:19:46 +0200
Raw View
--089e08256408018a0f056879b30e
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 3:24 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> No, you need magic to perform aliasing between any kind of array types.
[expr.add]/4 does not permit aliasing, so any array arithmetic must remain
within the bounds of an array that actually exists.
Let's tackle a simpler question first. Suppose:
int foo[5][2];
auto bar = reinterpret_cast<int*>(&foo[0][0]);
Are you saying that bar[2] is not well-defined?
Cheers,
V.
--
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/CAA7YVg1Tt-hwYej80qK_Cr2RxvBtP3aM%2BEZ7gqC4RKz6z9aGPw%40mail.gmail.com.
--089e08256408018a0f056879b30e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 3:24 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D=
"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>></span> w=
rote:<br><div><br></div><div>> No, you need magic to perform aliasing be=
tween any kind of array types. [expr.add]/4 does not permit aliasing, so an=
y array arithmetic must remain within the bounds of an array that actually =
exists.</div><div><br></div><div>Let's tackle a simpler question first.=
Suppose:</div><div><br></div><div>int foo[5][2];</div><div>auto bar =3D re=
interpret_cast<int*>(&foo[0][0]);</div><div><br></div><div>Are yo=
u saying that bar[2] is not well-defined?</div><div><br></div><div>Cheers,<=
/div><div>V.</div></div></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/CAA7YVg1Tt-hwYej80qK_Cr2RxvBtP3aM%2BE=
Z7gqC4RKz6z9aGPw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1Tt-hwYe=
j80qK_Cr2RxvBtP3aM%2BEZ7gqC4RKz6z9aGPw%40mail.gmail.com</a>.<br />
--089e08256408018a0f056879b30e--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Wed, 28 Mar 2018 07:42:54 -0700 (PDT)
Raw View
------=_Part_22308_2114014568.1522248174798
Content-Type: multipart/alternative;
boundary="----=_Part_22309_1419773551.1522248174798"
------=_Part_22309_1419773551.1522248174798
Content-Type: text/plain; charset="UTF-8"
On Wednesday, 28 March 2018 15:19:49 UTC+1, Viacheslav Usov wrote:
>
> On Wed, Mar 28, 2018 at 3:24 PM, Edward Catmur <e...@catmur.co.uk
> <javascript:>> wrote:
>
> > No, you need magic to perform aliasing between any kind of array types.
> [expr.add]/4 does not permit aliasing, so any array arithmetic must remain
> within the bounds of an array that actually exists.
>
> Let's tackle a simpler question first. Suppose:
>
> int foo[5][2];
> auto bar = reinterpret_cast<int*>(&foo[0][0]);
>
> Are you saying that bar[2] is not well-defined?
>
bar[2] is well-defined, but it refers to the past-the-end element of
foo[0], which cannot be accessed. It does not refer to foo[1][0], although
it has the same address.
This is because there is only one array of type int[N] containing
foo[0][0], and that is the array foo[0], which has only 2 elements.
bar[3] is not well-defined, and likewise the expression (bar + 3) has
undefined behavior.
Cheers,
> V.
>
--
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/1e25a8ae-4752-4fc0-8c89-639cef53121c%40isocpp.org.
------=_Part_22309_1419773551.1522248174798
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, 28 March 2018 15:19:49 UTC+1, Viache=
slav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Mar 28, 2018 at 3:24 PM, Edward=
Catmur <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"lP-KTSyvAwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">e...@catmur.co.uk</a>></span> wrote:<br><div><b=
r></div><div>> No, you need magic to perform aliasing between any kind o=
f array types. [expr.add]/4 does not permit aliasing, so any array arithmet=
ic must remain within the bounds of an array that actually exists.</div><di=
v><br></div><div>Let's tackle a simpler question first. Suppose:</div><=
div><br></div><div>int foo[5][2];</div><div>auto bar =3D reinterpret_cast&l=
t;int*>(&foo[0]<wbr>[0]);</div><div><br></div><div>Are you saying th=
at bar[2] is not well-defined?</div></div></div></div></blockquote><div><br=
></div><div>bar[2] is well-defined, but it refers to the past-the-end eleme=
nt of foo[0], which cannot be accessed. It does not refer to foo[1][0], alt=
hough it has the same address.</div><div><br></div><div>This is because the=
re is only one array of type int[N] containing foo[0][0], and that is the a=
rray foo[0], which has only 2 elements.</div><div><br></div><div>bar[3] is =
not well-defined, and likewise the expression (bar + 3) has undefined behav=
ior.</div><div><br></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"ltr"><div><div class=3D"gmail_quote"><div></div><div>Cheers,</div><d=
iv>V.</div></div></div></div>
</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/1e25a8ae-4752-4fc0-8c89-639cef53121c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e25a8ae-4752-4fc0-8c89-639cef53121c=
%40isocpp.org</a>.<br />
------=_Part_22309_1419773551.1522248174798--
------=_Part_22308_2114014568.1522248174798--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 28 Mar 2018 17:41:04 +0200
Raw View
--000000000000c1678605687ad548
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 4:42 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> bar[2] is well-defined, but it refers to the past-the-end element of
foo[0], which cannot be accessed. It does not refer to foo[1][0], although
it has the same address.
What does "not refer to" mean, exactly, given that "it has the same
address", and, obviously, the same type, to which [basic.compound]/3.4
"Pointers to layout-compatible types shall have the same value
representation and alignment requirements" trivially applies?
Are you saying that by doing
auto baz = reinterpret_cast<int*>(&foo[1][0]);
and then by doing (bar + 2) == baz you might encounter undefined behaviour
or get that evaluated as false, or, if not, that bar[2] is
undefined behaviour while baz[0] is not?
Cheers,
V.
--
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/CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq0gHmSNFgdRJo6yOb78Q-Q%40mail.gmail.com.
--000000000000c1678605687ad548
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 4:42 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D=
"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>></span> w=
rote:<br><div><br></div><div>> bar[2] is well-defined, but it refers to =
the past-the-end element of foo[0], which cannot be accessed. It does not r=
efer to foo[1][0], although it has the same address.</div><div><br></div><d=
iv>What does "not refer to" mean, exactly, given that "<span=
style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;=
font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-t=
ransform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,=
255,255);text-decoration-style:initial;text-decoration-color:initial;float:=
none;display:inline">it has the same address", and, obviously, the sam=
e type, to which=C2=A0=C2=A0</span>[basic.compound]/3.4=C2=A0 "Pointer=
s to layout-compatible types shall=C2=A0have the same value representation =
and alignment requirements" trivially applies?</div><div><br></div><di=
v>Are you saying that by doing</div><div><br></div><div>auto baz =3D
<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:1=
2.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">reinterpret_cast<int*>(&foo[1]</span><=
span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12=
..8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm=
al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb=
(255,255,255);text-decoration-style:initial;text-decoration-color:initial;f=
loat:none;display:inline"><wbr>[0]);</span>
</div><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;=
font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-varia=
nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgrou=
nd-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-col=
or:initial;float:none;display:inline"><br></span></div><div><span style=3D"=
font-size:12.8px">and then by doing (bar + 2) =3D=3D baz you might encounte=
r=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-c=
aps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px;background-c=
olor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:i=
nitial;float:none;display:inline">undefined=C2=A0behaviour</span>
or get that evaluated as false, or, if not, that bar[2] is undefined=C2=A0=
behaviour while baz[0] is not?</span></div><div><span style=3D"font-size:12=
..8px"><br></span></div><div>Cheers,</div><div>V.</div></div></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/CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq0gHmSNF=
gdRJo6yOb78Q-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1ZHes2s7mM=
GqGAgh0JTrNOq0gHmSNFgdRJo6yOb78Q-Q%40mail.gmail.com</a>.<br />
--000000000000c1678605687ad548--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Mar 2018 17:21:51 +0100
Raw View
--f403045f1c6a9d772f05687b6785
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 4:41 PM, Viacheslav Usov <via.usov@gmail.com> wrote:
> On Wed, Mar 28, 2018 at 4:42 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>
> > bar[2] is well-defined, but it refers to the past-the-end element of
> foo[0], which cannot be accessed. It does not refer to foo[1][0], although
> it has the same address.
>
> What does "not refer to" mean, exactly, given that "it has the same
> address", and, obviously, the same type, to which [basic.compound]/3.4
> "Pointers to layout-compatible types shall have the same value
> representation and alignment requirements" trivially applies?
>
> Are you saying that by doing
>
> auto baz = reinterpret_cast<int*>(&foo[1][0]);
>
> and then by doing (bar + 2) == baz you might encounter undefined behaviour
> or get that evaluated as false, or, if not, that bar[2] is
> undefined behaviour while baz[0] is not?
>
It's unspecified per [expr.eq]/2.1, so (bar + 2) == baz must have the value
true or false, but can be either and does not need to be consistently one
or the other; ((bar + 2) == baz) == ((bar + 2) == baz) can also be false.
At least it isn't undefined.
I think I was incorrect about the validity of bar[2] - looking at
[expr.unary.op]/1, I think that *(bar + 2) is undefined although (bar + 2)
is OK.
Cheers,
> V.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq
> 0gHmSNFgdRJo6yOb78Q-Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq0gHmSNFgdRJo6yOb78Q-Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdObRm%3DN%2BcYEaAV%2BK6_Nnvoc4ef9Efimw-YNrkFYMQothFg%40mail.gmail.com.
--f403045f1c6a9d772f05687b6785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Mar 28, 2018 at 4:41 PM, Viacheslav Usov <span dir=3D"ltr"><=
<a href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Mar 28, 2018 at=
4:42 PM, Edward Catmur <span dir=3D"ltr"><<a href=3D"mailto:ed@catmur.c=
o.uk" target=3D"_blank">ed@catmur.co.uk</a>></span> wrote:<br><div><br><=
/div><div>> bar[2] is well-defined, but it refers to the past-the-end el=
ement of foo[0], which cannot be accessed. It does not refer to foo[1][0], =
although it has the same address.</div><div><br></div><div>What does "=
not refer to" mean, exactly, given that "<span style=3D"color:rgb=
(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;f=
ont-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;lette=
r-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decor=
ation-style:initial;text-decoration-color:initial;float:none;display:inline=
">it has the same address", and, obviously, the same type, to which=C2=
=A0=C2=A0</span>[basic.compound]/3.4=C2=A0 "Pointers to layout-compati=
ble types shall=C2=A0have the same value representation and alignment requi=
rements" trivially applies?</div><div><br></div><div>Are you saying th=
at by doing</div><div><br></div><div>auto baz =3D
<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:1=
2.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:nor=
mal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px;background-color:rg=
b(255,255,255);text-decoration-style:initial;text-decoration-color:initial;=
float:none;display:inline">reinterpret_cast<int*>(&foo[1]</span><=
span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12=
..8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm=
al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb=
(255,255,255);text-decoration-style:initial;text-decoration-color:initial;f=
loat:none;display:inline"><wbr>[0]);</span>
</div><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;=
font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-varia=
nt-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgrou=
nd-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-col=
or:initial;float:none;display:inline"><br></span></div><div><span style=3D"=
font-size:12.8px">and then by doing (bar + 2) =3D=3D baz you might encounte=
r=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-c=
aps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px;background-c=
olor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:i=
nitial;float:none;display:inline">undefined=C2=A0behaviour</span>
or get that evaluated as false, or, if not, that bar[2] is undefined=C2=A0=
behaviour while baz[0] is not?</span></div></div></div></div></blockquote><=
div><br></div><div>It's unspecified per [expr.eq]/2.1, so (bar + 2) =3D=
=3D baz must have the value true or false, but can be either and does not n=
eed to be consistently one or the other; (<span style=3D"color:rgb(34,34,34=
);font-family:arial,sans-serif;font-size:small;font-style:normal;font-varia=
nt-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing=
:normal;text-align:start;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-sty=
le:initial;text-decoration-color:initial;float:none;display:inline">(bar + =
2) =3D=3D baz) =3D=3D=C2=A0<span style=3D"color:rgb(34,34,34);font-family:a=
rial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:no=
rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text=
-decoration-color:initial;float:none;display:inline">(</span><span style=3D=
"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-styl=
e:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight=
:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text=
-decoration-color:initial;background-color:rgb(255,255,255);float:none;disp=
lay:inline">(bar + 2) =3D=3D baz) can also be false. At least it isn't =
undefined.</span></span></div><div><br></div><div>I think I was incorrect a=
bout the validity of=C2=A0<span style=3D"color:rgb(34,34,34);font-family:ar=
ial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:no=
rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text=
-decoration-color:initial;float:none;display:inline">bar[2] - looking at [e=
xpr.unary.op]/1, I think that *(bar + 2) is undefined although (bar + 2) is=
OK.=C2=A0</span></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><span=
style=3D"font-size:12.8px"></span></div><div>Cheers,</div><div>V.</div></d=
iv></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/H=
pRRF7RWzTY/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq0gHmSNF=
gdRJo6yOb78Q-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CAA7YVg1ZHes2s7mMGqGAgh0JTrNOq<wbr>0gHmSNFgdRJo6yOb78Q-=
Q%40mail.<wbr>gmail.com</a>.<br>
</font></span></blockquote></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/CAJnLdObRm%3DN%2BcYEaAV%2BK6_Nnvoc4ef=
9Efimw-YNrkFYMQothFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObRm%=
3DN%2BcYEaAV%2BK6_Nnvoc4ef9Efimw-YNrkFYMQothFg%40mail.gmail.com</a>.<br />
--f403045f1c6a9d772f05687b6785--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 28 Mar 2018 18:28:43 +0200
Raw View
--089e0822221433591d05687b80d4
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 6:21 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> It's unspecified per [expr.eq]/2.1, so (bar + 2) == baz must have the
value true or false, but can be either and does not need to be consistently
one or the other; ((bar + 2) == baz) == ((bar + 2) == baz) can also be
false. At least it isn't undefined.
How about per [expr.eq]/2? To quote you again, "it has the same address".
Cheers,
V.
--
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/CAA7YVg20tNjDzVSiQpoutAcFSuTNf%2B71mrxHRA9gWRmXv5Ja6A%40mail.gmail.com.
--089e0822221433591d05687b80d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 6:21 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><div><br></div><div>> It's unspecified per [expr.eq]/2.1, so (bar =
+ 2) =3D=3D baz must have the value true or false, but can be either and do=
es not need to be consistently one or the other; ((bar + 2) =3D=3D baz) =3D=
=3D=C2=A0((bar + 2) =3D=3D baz) can also be false. At least it isn't un=
defined.</div><div><br></div><div>How about per=C2=A0[expr.eq]/2? To quote =
you again, "<span style=3D"color:rgb(34,34,34);font-family:arial,sans-=
serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-=
variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;bac=
kground-color:rgb(255,255,255);text-decoration-style:initial;text-decoratio=
n-color:initial;float:none;display:inline">it has the same address".</=
span></div><div><br></div><div>Cheers,</div><div>V.</div><div><br></div></d=
iv></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/CAA7YVg20tNjDzVSiQpoutAcFSuTNf%2B71mr=
xHRA9gWRmXv5Ja6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg20tNjDzV=
SiQpoutAcFSuTNf%2B71mrxHRA9gWRmXv5Ja6A%40mail.gmail.com</a>.<br />
--089e0822221433591d05687b80d4--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Mar 2018 17:38:50 +0100
Raw View
--94eb2c074a785cb96905687ba4c2
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 5:28 PM, Viacheslav Usov <via.usov@gmail.com> wrote:
> On Wed, Mar 28, 2018 at 6:21 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > It's unspecified per [expr.eq]/2.1, so (bar + 2) == baz must have the
> value true or false, but can be either and does not need to be consistently
> one or the other; ((bar + 2) == baz) == ((bar + 2) == baz) can also be
> false. At least it isn't undefined.
>
> How about per [expr.eq]/2? To quote you again, "it has the same address".
>
That's [expr.eq]/2.2, which comes after 2.1 and is guarded by an
"Otherwise". Are you perhaps looking at an old version of the Standard?
> Cheers,
> V.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAA7YVg20tNjDzVSiQpoutAcFSuTNf
> %2B71mrxHRA9gWRmXv5Ja6A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg20tNjDzVSiQpoutAcFSuTNf%2B71mrxHRA9gWRmXv5Ja6A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdObgKF5w_wGFFJXM6ALS3jS6E5di%2B_zKZHcwh67GDyZcXQ%40mail.gmail.com.
--94eb2c074a785cb96905687ba4c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 5:28 PM, Viacheslav Usov <span dir=3D"ltr"><<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Mar 2=
8, 2018 at 6:21 PM, 'Edward Catmur' via ISO C++ Standard - Future P=
roposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocpp.org" =
target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br><div><b=
r></div><div>> It's unspecified per [expr.eq]/2.1, so (bar + 2) =3D=
=3D baz must have the value true or false, but can be either and does not n=
eed to be consistently one or the other; ((bar + 2) =3D=3D baz) =3D=3D=C2=
=A0((bar + 2) =3D=3D baz) can also be false. At least it isn't undefine=
d.</div><div><br></div></span><div>How about per=C2=A0[expr.eq]/2? To quote=
you again, "<span style=3D"color:rgb(34,34,34);font-family:arial,sans=
-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font=
-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;ba=
ckground-color:rgb(255,255,255);text-decoration-style:initial;text-decorati=
on-color:initial;float:none;display:inline">it has the same address".<=
/span></div></div></div></div></blockquote><div><br></div><div>That's [=
expr.eq]/2.2, which comes after 2.1 and is guarded by an "Otherwise&qu=
ot;. Are you perhaps looking at an old version of the Standard?</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div></div><div>Cheers,</div><div>V.=
</div><div><br></div></div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/H=
pRRF7RWzTY/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg20tNjDzVSiQpoutAcFSuTNf%2B71mr=
xHRA9gWRmXv5Ja6A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/<wbr>CAA7YVg20tNjDzVSiQpoutAcFSuTNf<wbr>%2B71mrxHRA9gWRmXv=
5Ja6A%<wbr>40mail.gmail.com</a>.<br>
</blockquote></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/CAJnLdObgKF5w_wGFFJXM6ALS3jS6E5di%2B_=
zKZHcwh67GDyZcXQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObgKF5w_w=
GFFJXM6ALS3jS6E5di%2B_zKZHcwh67GDyZcXQ%40mail.gmail.com</a>.<br />
--94eb2c074a785cb96905687ba4c2--
.
Author: Hyman Rosen <hyman.rosen@gmail.com>
Date: Wed, 28 Mar 2018 15:12:35 -0400
Raw View
--001a114b3e7e6b5c4605687dcbda
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 12:38 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> That's [expr.eq]/2.2, which comes after 2.1 and is guarded by an
> "Otherwise".
>
In my copy of the Draft Standard, N4700, [expr.eq]/2.1 says
*If one pointer represents the address of a complete object,and another
pointer represents the address *
*one past thelast element of a different complete object, the result of
thecomparison is unspecified.*
A complete object is not a subobject of another object, therefore this
clause
does not apply to the array elements in question, which are perforce not
complete objects. So [expr.eq]/2.2 is active, and says
*Otherwise, if the pointers are both null, both point to the same function,
or both represent the same **address, they compare equal.*
--
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/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9DhLuAwMTDrJ%3D1RMA%40mail.gmail.com.
--001a114b3e7e6b5c4605687dcbda
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 12:38 PM, 'Edward Catmur' via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>That's [expr.eq]/2.2,=
which comes after 2.1 and is guarded by an "Otherwise".</div></d=
iv></div></div></blockquote><div><br>In my copy of the Draft Standard, N470=
0, [expr.eq]/2.1 says<br><br></div></div></div><blockquote style=3D"margin:=
0px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div><div><i>If one pointer represents the address of =
a complete object,<br>and another pointer represents the address=C2=A0</i><=
i>one past the<br>last element of a different complete object, the result o=
f the<br>comparison is unspecified.</i></div></div></div></div><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><br></div></div></div=
></div></blockquote>A complete object is not a subobject of another object,=
therefore this clause<br>does not apply to the array elements in question,=
which are perforce not<br>complete objects.=C2=A0 So [expr.eq]/2.2 is acti=
ve, and says<br><br><blockquote style=3D"margin:0px 0px 0px 40px;border:non=
e;padding:0px"><i>Otherwise, if the pointers are both null, both point to t=
he same<br> function, or both represent the same=C2=A0</i><i>address, they =
compare equal.</i></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/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9Dh=
LuAwMTDrJ%3D1RMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ9uOf3D1=
h4Eo61PV_jpsn6SUUzf9DhLuAwMTDrJ%3D1RMA%40mail.gmail.com</a>.<br />
--001a114b3e7e6b5c4605687dcbda--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 28 Mar 2018 19:17:20 +0000
Raw View
--f403045f1c6acbd85c05687ddb4f
Content-Type: text/plain; charset="UTF-8"
On Wed, 28 Mar 2018, 20:13 Hyman Rosen, <hyman.rosen@gmail.com> wrote:
> On Wed, Mar 28, 2018 at 12:38 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> That's [expr.eq]/2.2, which comes after 2.1 and is guarded by an
>> "Otherwise".
>>
>
> In my copy of the Draft Standard, N4700, [expr.eq]/2.1 says
>
>
> *If one pointer represents the address of a complete object,and another
> pointer represents the address *
>
> *one past thelast element of a different complete object, the result of
> thecomparison is unspecified.*
>
> A complete object is not a subobject of another object, therefore this
> clause
> does not apply to the array elements in question, which are perforce not
> complete objects. So [expr.eq]/2.2 is active, and says
>
>
> *Otherwise, if the pointers are both null, both point to the same
> function, or both represent the same **address, they compare equal.*
>
> --
>
Oh, I missed that. Thanks for the correction. I agree that in this case the
pointers are required to compare equal.
You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9DhLuAwMTDrJ%3D1RMA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9DhLuAwMTDrJ%3D1RMA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJnLdOb2-CwDFtfdFDFX3OxnL%2B3Qv2%3DDtk0noy54nZX3kZOpMA%40mail.gmail.com.
--f403045f1c6acbd85c05687ddb4f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, 28 Mar 2018, 20:13 Hyman Rosen, <<a href=3D"mailto:hyman.rosen@g=
mail.com">hyman.rosen@gmail.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">On Wed, Mar 28, 2018 at 12:38 PM, 'Edward Catmur' via ISO=
C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:st=
d-proposals@isocpp.org" target=3D"_blank" rel=3D"noreferrer">std-proposals@=
isocpp.org</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div>That's [expr.eq]/2.2, which comes after 2.1 and is guarded by a=
n "Otherwise".</div></div></div></div></blockquote><div><br>In my=
copy of the Draft Standard, N4700, [expr.eq]/2.1 says<br><br></div></div><=
/div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div><i>If one p=
ointer represents the address of a complete object,<br>and another pointer =
represents the address=C2=A0</i><i>one past the<br>last element of a differ=
ent complete object, the result of the<br>comparison is unspecified.</i></d=
iv></div></div></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div><div><br></div></div></div></div></blockquote>A complete object is not=
a subobject of another object, therefore this clause<br>does not apply to =
the array elements in question, which are perforce not<br>complete objects.=
=C2=A0 So [expr.eq]/2.2 is active, and says<br><br><blockquote style=3D"mar=
gin:0px 0px 0px 40px;border:none;padding:0px"><i>Otherwise, if the pointers=
are both null, both point to the same<br> function, or both represent the =
same=C2=A0</i><i>address, they compare equal.</i></blockquote></div>
<p></p>
-- <br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Oh, I missed that. Thanks for the correction. I agree that in this case =
the pointers are required to compare equal.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe" target=3D"_blan=
k" rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/HpRRF7RWzTY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
oreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9Dh=
LuAwMTDrJ%3D1RMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAHSYqdZ9uOf3D1h4Eo61PV_jpsn6SUUzf9DhLuAwMTDrJ%3D=
1RMA%40mail.gmail.com</a>.<br>
</blockquote></div></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/CAJnLdOb2-CwDFtfdFDFX3OxnL%2B3Qv2%3DD=
tk0noy54nZX3kZOpMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb2-CwD=
FtfdFDFX3OxnL%2B3Qv2%3DDtk0noy54nZX3kZOpMA%40mail.gmail.com</a>.<br />
--f403045f1c6acbd85c05687ddb4f--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 29 Mar 2018 08:17:23 +0200
Raw View
--000000000000b9e12c056887135e
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 28, 2018 at 6:38 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> That's [expr.eq]/2.2, which comes after 2.1 and is guarded by an
"Otherwise".
Per 2.2., "they compare equal" and your prior statements of unspecified
comparison are non sequitur.
So, now, we have pointers to int (bar + 2) and baz representing the same
address and comparing equal, and baz[0] is well defined.
What do you say about bar[2]?
Cheers,
V.
--
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/CAA7YVg3yg4tnv5W91LbRqV0Q7dx9EyWPuddfoRYANS__X2eiXA%40mail.gmail.com.
--000000000000b9e12c056887135e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 28, 2018 at 6:38 PM, 'Edward Catmur' via ISO C++ Standard -=
Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<b=
r><div><br></div><div>> That's [expr.eq]/2.2, which comes after 2.1 =
and is guarded by an "Otherwise".</div><div><br></div><div>Per 2.=
2., "they compare equal" and your prior statements of unspecified=
comparison are non sequitur.</div><div><br></div><div>So, now, we have poi=
nters to int (bar + 2) and baz representing the same address and comparing =
equal, and baz[0] is well defined.</div><div><br></div><div>What do you say=
about bar[2]?</div><div><br></div><div>Cheers,</div><div>V.</div></div></d=
iv></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/CAA7YVg3yg4tnv5W91LbRqV0Q7dx9EyWPuddf=
oRYANS__X2eiXA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3yg4tnv5W9=
1LbRqV0Q7dx9EyWPuddfoRYANS__X2eiXA%40mail.gmail.com</a>.<br />
--000000000000b9e12c056887135e--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 29 Mar 2018 08:35:16 -0700 (PDT)
Raw View
------=_Part_3023_132653232.1522337716286
Content-Type: multipart/alternative;
boundary="----=_Part_3024_140286881.1522337716286"
------=_Part_3024_140286881.1522337716286
Content-Type: text/plain; charset="UTF-8"
On Thursday, 29 March 2018 07:17:27 UTC+1, Viacheslav Usov wrote:
>
> On Wed, Mar 28, 2018 at 6:38 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
> > That's [expr.eq]/2.2, which comes after 2.1 and is guarded by an
> "Otherwise".
>
> Per 2.2., "they compare equal" and your prior statements of unspecified
> comparison are non sequitur.
>
> So, now, we have pointers to int (bar + 2) and baz representing the same
> address and comparing equal, and baz[0] is well defined.
>
> What do you say about bar[2]?
>
I think it's reasonably clear that bar[2] is UB, even though bar + 2
compares equal to baz and baz[0] is well defined. See [basic.compound]/3.
> Cheers,
> V.
>
--
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/9a9a7837-a014-4893-b0a0-75571921b3a3%40isocpp.org.
------=_Part_3024_140286881.1522337716286
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, 29 March 2018 07:17:27 UTC+1, Viaches=
lav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Wed, Mar 28, 2018 at 6:38 PM, 'Ed=
ward Catmur' via ISO C++ Standard - Future Proposals <span dir=3D"ltr">=
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"v28m=
LW7jAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>></span> wrote:<br><div><br></div><div>> That&=
#39;s [expr.eq]/2.2, which comes after 2.1 and is guarded by an "Other=
wise".</div><div><br></div><div>Per 2.2., "they compare equal&quo=
t; and your prior statements of unspecified comparison are non sequitur.</d=
iv><div><br></div><div>So, now, we have pointers to int (bar + 2) and baz r=
epresenting the same address and comparing equal, and baz[0] is well define=
d.</div><div><br></div><div>What do you say about bar[2]?</div></div></div>=
</div></blockquote><div><br></div><div>I think it's reasonably clear th=
at bar[2] is UB, even though bar + 2 compares equal to baz and baz[0] is we=
ll defined. See [basic.compound]/3.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div><br></div><div>Cheers,</div><div>V.</div></div></div></div>
</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/9a9a7837-a014-4893-b0a0-75571921b3a3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a9a7837-a014-4893-b0a0-75571921b3a3=
%40isocpp.org</a>.<br />
------=_Part_3024_140286881.1522337716286--
------=_Part_3023_132653232.1522337716286--
.