Topic: Is/Can it be well-defined to subtract
Author: "D. B." <db0451@gmail.com>
Date: Thu, 18 Aug 2016 11:53:52 +0100
Raw View
--001a114e3072ce0535053a566503
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <bop@gmb.dk> wrote:
> On 2016-08-18 10:58, D. B. wrote:
>
>> i.e. given
>>
>> * /auto const someBytePointer{ reinterpret_cast<unsigned char const
>> *>(&someObj.someMember) };/
>> * /std::ptrdiff_t myOffset{ someBytePointer -
>> reinterpret_cast<unsigned char const *>(&someObj) };/
>>
>> I want to be able to *guarantee *that myOffset *will *hold the *distance
>> in /unsigned char/* between /someObj.someMember/ and the base address of
>> /someObj/
>>
>
>
> I think this fails already here, because the reinterpret_cast is not
> guaranteed to work. For example, on a word addressed machine, a char
> pointer might need a part-word index in addition to the word address.
>
>
> Bo
>
Surely it must work, since the Standard provisions for char* and unsigned
char* to be able to alias any other type - which we must assume from
context is so that they can read object representation?
--
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/CACGiwhHA1aC7vmM_afNPwXWugxQdrrO53jgVdc9VQhiwS6Fw%3Dw%40mail.gmail.com.
--001a114e3072ce0535053a566503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <span dir=3D"ltr"><<a href=
=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span class=3D"">On 2016-08-18 10:58, D. B=
.. wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D""></span><span class=
=3D"">i.e. given<br>
<br></span>
=C2=A0 * /auto const someBytePointer{ reinterpret_cast<unsigned char con=
st<br>
=C2=A0 =C2=A0 *>(&someObj.someMember) };/<br>
=C2=A0 * /std::ptrdiff_t myOffset{ someBytePointer -<br>
=C2=A0 =C2=A0 reinterpret_cast<unsigned char const *>(&someObj) }=
;/<br>
<br>
I want to be able to *guarantee *that myOffset *will *hold the *distance<br=
>
in /unsigned char/* between /someObj.someMember/ and the base address of<br=
>
/someObj/<br>
</blockquote>
<br>
<br>
I think this fails already here, because the reinterpret_cast is not guaran=
teed to work. For example, on a word addressed machine, a char pointer migh=
t need a part-word index in addition to the word address.<br>
<br>
<br>
=C2=A0 =C2=A0 Bo<br></blockquote></div><br></div><div class=3D"gmail_extra"=
>Surely it must work, since the Standard provisions for char* and unsigned =
char* to be able to alias any other type - which we must assume from contex=
t is so that they can read object representation?<br><br><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/CACGiwhHA1aC7vmM_afNPwXWugxQdrrO53jgV=
dc9VQhiwS6Fw%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHA1aC7vm=
M_afNPwXWugxQdrrO53jgVdc9VQhiwS6Fw%3Dw%40mail.gmail.com</a>.<br />
--001a114e3072ce0535053a566503--
.
Author: "D. B." <db0451@gmail.com>
Date: Thu, 18 Aug 2016 15:26:52 +0100
Raw View
--001a1147284e88a0a0053a595fb5
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 18, 2016 at 2:32 PM, Bo Persson <bop@gmb.dk> wrote:
> On 2016-08-18 12:53, D. B. wrote:
>
>>
>> On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <bop@gmb.dk
>> <mailto:bop@gmb.dk>> wrote:
>>
>> I think this fails already here, because the reinterpret_cast is not
>> guaranteed to work. For example, on a word addressed machine, a char
>> pointer might need a part-word index in addition to the word address.
>>
>>
>> Bo
>>
>>
>> Surely it must work, since the Standard provisions for char* and
>> unsigned char* to be able to alias any other type - which we must assume
>> from context is so that they can read object representation?
>>
>>
> The missing guarantee is sizeof(&someObj) == sizeof(char*), which is not
> required.
>
> So if char* (and void*) is larger than int* or some_class*, a
> reinterpret_cast will likely not work.
>
>
>
> Bo Persson
>
Why would the Standard explicitly allow aliasing via *[unsigned] char*
lvalues to objects of different type, if it was UB to ever form such an
lvalue in the first place?
I'm not sure why the *sizeof* different pointer types matters. A
*reinterpret_cast
*should be capable of doing any manipulation it wants to the numerical
values of a pointer, as long as it ends up pointing to the same thing when
converted to the destination type (and back). I'm not sure the *sizeof* is
relevant. We can convert between other types with different sizes just
fine; why not pointers? As long as no information is lost that can't be
reconstituted between converting the numerical representations, I see no
problem. Assuming that's what you mean, can you elaborate on precisely
where such information could be lost irrecoverably?
--
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/CACGiwhFKdBrGMkdmR895A85KB2H9WxkBQ14L4-KX_mKx%3DYZvQg%40mail.gmail.com.
--001a1147284e88a0a0053a595fb5
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 T=
hu, Aug 18, 2016 at 2:32 PM, Bo Persson <span dir=3D"ltr"><<a href=3D"ma=
ilto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On 2016-08-18 12:53, D. B. wrot=
e:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
<br>
On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <<a href=3D"mailto:bop@gmb.=
dk" target=3D"_blank">bop@gmb.dk</a><br></span><span class=3D"">
<mailto:<a href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&g=
t;> wrote:<br>
<br>
=C2=A0 =C2=A0 I think this fails already here, because the reinterpret_cast=
is not<br>
=C2=A0 =C2=A0 guaranteed to work. For example, on a word addressed machine,=
a char<br>
=C2=A0 =C2=A0 pointer might need a part-word index in addition to the word =
address.<br>
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bo<br>
<br>
<br>
Surely it must work, since the Standard provisions for char* and<br>
unsigned char* to be able to alias any other type - which we must assume<br=
>
from context is so that they can read object representation?<br>
<br>
</span></blockquote>
<br>
The missing guarantee is sizeof(&someObj) =3D=3D sizeof(char*), which i=
s not required.<br>
<br>
So if char* (and void*) is larger than int* or some_class*, a reinterpret_c=
ast will likely not work.<span class=3D""><br>
<br>
<br>
<br>
=C2=A0 =C2=A0 Bo Persson<br></span></blockquote><div><br></div><div>Why wou=
ld the Standard explicitly allow aliasing via <i>[unsigned] char</i> lvalue=
s to objects of different type, if it was UB to ever form such an lvalue in=
the first place?<br><br></div><div>I'm not sure why the <i>sizeof</i> =
different pointer types matters. A <i>reinterpret_cast </i>should be capabl=
e of doing any manipulation it wants to the numerical values of a pointer, =
as long as it ends up pointing to the same thing when converted to the dest=
ination type (and back). I'm not sure the <i>sizeof</i> is relevant. We=
can convert between other types with different sizes just fine; why not po=
inters? As long as no information is lost that can't be reconstituted b=
etween converting the numerical representations, I see no problem. Assuming=
that's what you mean, can you elaborate on precisely where such inform=
ation could be lost irrecoverably?<br><br></div><div>=C2=A0</div></div><br>=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFKdBrGMkdmR895A85KB2H9WxkBQ14L=
4-KX_mKx%3DYZvQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFKdBrGMk=
dmR895A85KB2H9WxkBQ14L4-KX_mKx%3DYZvQg%40mail.gmail.com</a>.<br />
--001a1147284e88a0a0053a595fb5--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 18 Aug 2016 20:17:41 -0700 (PDT)
Raw View
------=_Part_2003_1499957029.1471576661617
Content-Type: multipart/alternative;
boundary="----=_Part_2004_1570715256.1471576661617"
------=_Part_2004_1570715256.1471576661617
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 18, 2016 at 7:27:03 AM UTC-7, D. B. wrote:
>
> On Thu, Aug 18, 2016 at 2:32 PM, Bo Persson <b...@gmb.dk <javascript:>>=
=20
> wrote:
>
>> On 2016-08-18 12:53, D. B. wrote:
>>
>>>
>>> On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <b...@gmb.dk <javascript:>
>>> <mailto:b...@gmb.dk <javascript:>>> wrote:
>>>
>>> I think this fails already here, because the reinterpret_cast is no=
t
>>> guaranteed to work. For example, on a word addressed machine, a cha=
r
>>> pointer might need a part-word index in addition to the word addres=
s.
>>>
>>> Surely it must work, since the Standard provisions for char* and
>>> unsigned char* to be able to alias any other type - which we must assum=
e
>>> from context is so that they can read object representation?
>>>
>>
>> The missing guarantee is sizeof(&someObj) =3D=3D sizeof(char*), which is=
not=20
>> required.
>>
>> So if char* (and void*) is larger than int* or some_class*, a=20
>> reinterpret_cast will likely not work.
>>
>
> Why would the Standard explicitly allow aliasing via *[unsigned] char*=20
> lvalues to objects of different type, if it was UB to ever form such an=
=20
> lvalue in the first place?
>
> I'm not sure why the *sizeof* different pointer types matters. A *reinter=
pret_cast=20
> *should be capable of doing any manipulation it wants to the numerical=20
> values of a pointer, as long as it ends up pointing to the same thing whe=
n=20
> converted to the destination type (and back). I'm not sure the *sizeof*=
=20
> is relevant. We can convert between other types with different sizes just=
=20
> fine; why not pointers? As long as no information is lost that can't be=
=20
> reconstituted between converting the numerical representations, I see no=
=20
> problem. Assuming that's what you mean, can you elaborate on precisely=20
> where such information could be lost irrecoverably?
>
Bo is talking about something different (and irrelevant).
5.2.10 [expr.reinterpret.cast] /7:
1.=20
=20
An object pointer can be explicitly converted to an object pointer of a=
=20
different type.72 When a prvalue v of object pointer type is converted=
=20
to the object pointer type =E2=80=9Cpointer to cv T=E2=80=9D, the result=
is static_cast<cv=20
T*>(static_cast<cv void*>(v)). Converting a prvalue of type =E2=80=9Cpoi=
nter to=20
T1=E2=80=9D to the type =E2=80=9Cpointer to T2=E2=80=9D=20
=20
(where T1 and T2 are object types and where the alignment requirements=
=20
of T2 are no stricter than those of T1) and back to its original type=20
yields the original pointer value.=20
=20
That is, reinterpret_cast<foo*>(mybarptr) is identical in meaning to=20
static_cast<foo*>(static_cast<void*>(mybarptr)).
What Bo was thinking of, probably, was
bar *mybarptr;
foo *myfooptr =3D reinterpret_cast<foo*&>(mybarptr);=20
which is equivalent to
foo *myfooptr =3D *static_cast<foo**>(static_cast<void *>(&mybarptr));=
=20
which of course does what you'd expect ONLY IF the two pointer types are=20
layout-compatible (and is undefined behavior in this case anyway because of=
=20
the type-punning, IIUC). This case is covered in 5.2.10=20
[expr.reinterpret.cast] /11:
1.=20
A glvalue expression of type T1 can be cast to the type =E2=80=9Creference =
to T2=E2=80=9D=20
if an expression of type =E2=80=9Cpointer to T1=E2=80=9D can be explicitly =
converted to the=20
type =E2=80=9Cpointer to T2=E2=80=9D using a reinterpret_cast. The result r=
efers to the=20
same object as the source glvalue, but with the specified type.=20
But this case is not at all what D.B. was talking about.
HTH,
=E2=80=93Arthur
--=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/ba14bf8f-640b-4c93-8473-eebfdbe56f9a%40isocpp.or=
g.
------=_Part_2004_1570715256.1471576661617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 18, 2016 at 7:27:03 AM UTC-7, D. B. wr=
ote:<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 clas=
s=3D"gmail_quote">On Thu, Aug 18, 2016 at 2:32 PM, Bo Persson <span dir=3D"=
ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"SZAbRYXkCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">b...@gmb.dk</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an>On 2016-08-18 12:53, D. B. wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span>
<br>
On Thu, Aug 18, 2016 at 11:47 AM, Bo Persson <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"SZAbRYXkCwAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">b...@gmb.dk</a><br></span><span=
>
<mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"SZAbRYXkCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">b...@gmb.dk</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 I think this fails already here, because the reinterpret_cast=
is not<br>
=C2=A0 =C2=A0 guaranteed to work. For example, on a word addressed machine,=
a char<br>
=C2=A0 =C2=A0 pointer might need a part-word index in addition to the word =
address.<br><br>
Surely it must work, since the Standard provisions for char* and<br>
unsigned char* to be able to alias any other type - which we must assume<br=
>
from context is so that they can read object representation?<br>
</span></blockquote>
<br>
The missing guarantee is sizeof(&someObj) =3D=3D sizeof(char*), which i=
s not required.<br>
<br>
So if char* (and void*) is larger than int* or some_class*, a reinterpret_c=
ast will likely not work.<span><br></span></blockquote><div><br></div><div>=
Why would the Standard explicitly allow aliasing via <i>[unsigned] char</i>=
lvalues to objects of different type, if it was UB to ever form such an lv=
alue in the first place?<br><br></div><div>I'm not sure why the <i>size=
of</i> different pointer types matters. A <i>reinterpret_cast </i>should be=
capable of doing any manipulation it wants to the numerical values of a po=
inter, as long as it ends up pointing to the same thing when converted to t=
he destination type (and back). I'm not sure the <i>sizeof</i> is relev=
ant. We can convert between other types with different sizes just fine; why=
not pointers? As long as no information is lost that can't be reconsti=
tuted between converting the numerical representations, I see no problem. A=
ssuming that's what you mean, can you elaborate on precisely where such=
information could be lost irrecoverably?<br></div></div></div></blockquote=
><div><br></div><div>Bo is talking about something different (and irrelevan=
t).</div><div><br></div><div>5.2.10 [expr.reinterpret.cast] /7:</div>
=09
=09
=09
<div class=3D"page" title=3D"Page 130">
<div class=3D"layoutArea">
<div class=3D"column">
<ol start=3D"5" style=3D"list-style-type: none">
<li>
<p><span style=3D"font-size: 10.000000pt; font-family: 'LMRoman1=
0'">An object pointer can be explicitly converted to an object pointer =
of a different type.</span><span style=3D"font-size: 7.000000pt; font-famil=
y: 'LMRoman7'; color: rgb(0.000000%, 0.000000%, 100.000000%); verti=
cal-align: 4.000000pt">72 </span><span style=3D"font-size: 10.000000pt; fon=
t-family: 'LMRoman10'">When a prvalue </span><span style=3D"font-si=
ze: 10.000000pt; font-family: 'LMMono10'">v </span><span style=3D"f=
ont-size: 10.000000pt; font-family: 'LMRoman10'">of
object pointer type is converted to the object pointer type =E2=80=9Cpointe=
r to </span><span style=3D"font-size: 10.000000pt; font-family: 'LMRoma=
n10'; font-style: italic">cv </span><span style=3D"font-size: 10.000000=
pt; font-family: 'LMMono10'">T</span><span style=3D"font-size: 10.0=
00000pt; font-family: 'LMRoman10'">=E2=80=9D, the result is </span>=
<span style=3D"font-size: 10.000000pt; font-family: 'LMMono10'">sta=
tic_cast<</span><span style=3D"font-size: 10.000000pt; font-family: '=
;LMMono10'; font-style: italic">cv
</span><span style=3D"font-size: 10.000000pt; font-family: 'LMMono10=
9;">T*>(static_cast<</span><span style=3D"font-size: 10.000000pt; fon=
t-family: 'LMMono10'; font-style: italic">cv </span><span style=3D"=
font-size: 10.000000pt; font-family: 'LMMono10'">void*>(v))</spa=
n><span style=3D"font-size: 10.000000pt; font-family: 'LMRoman10'">=
.. Converting a prvalue of type =E2=80=9Cpointer to </span><span style=3D"fo=
nt-size: 10.000000pt; font-family: 'LMMono10'">T1</span><span style=
=3D"font-size: 10.000000pt; font-family: 'LMRoman10'">=E2=80=9D to =
the type =E2=80=9Cpointer to </span><span style=3D"font-size: 10.000000pt; =
font-family: 'LMMono10'">T2</span><span style=3D"font-size: 10.0000=
00pt; font-family: 'LMRoman10'">=E2=80=9D
</span></p>
<p><span style=3D"font-size: 10.000000pt; font-family: 'LMRoman1=
0'">(where </span><span style=3D"font-size: 10.000000pt; font-family: &=
#39;LMMono10'">T1 </span><span style=3D"font-size: 10.000000pt; font-fa=
mily: 'LMRoman10'">and </span><span style=3D"font-size: 10.000000pt=
; font-family: 'LMMono10'">T2 </span><span style=3D"font-size: 10.0=
00000pt; font-family: 'LMRoman10'">are object types and where the a=
lignment requirements of </span><span style=3D"font-size: 10.000000pt; font=
-family: 'LMMono10'">T2 </span><span style=3D"font-size: 10.000000p=
t; font-family: 'LMRoman10'">are no stricter than those of
</span><span style=3D"font-size: 10.000000pt; font-family: 'LMMono10=
9;">T1</span><span style=3D"font-size: 10.000000pt; font-family: 'LMRom=
an10'">) and back to its original type yields the original pointer valu=
e.=C2=A0</span></p>
</li>
</ol>
</div>
</div>
</div><div>That is, reinterpret_cast<foo*>(mybarptr) is identical i=
n meaning to static_cast<foo*>(static_cast<void*>(mybarptr)).</=
div><div><br></div><div>What Bo was thinking of, probably, was</div><div><b=
r></div><div>=C2=A0 =C2=A0 bar *mybarptr;</div><div>=C2=A0 =C2=A0 foo *myfo=
optr =3D reinterpret_cast<foo*&>(mybarptr);=C2=A0<br></div><div><=
br></div><div>which is equivalent to</div><div><br></div><div><div>=C2=A0 =
=C2=A0 foo *myfooptr =3D *static_cast<foo**>(static_cast<void *>=
;(&mybarptr));=C2=A0<br></div></div><div><br></div><div>which of course=
does what you'd expect ONLY IF the two pointer types are layout-compat=
ible (and is undefined behavior in this case anyway because of the type-pun=
ning, IIUC). This case is covered in 5.2.10 [expr.reinterpret.cast] /11:</d=
iv><div><div class=3D"page" title=3D"Page 130"><div class=3D"layoutArea"><d=
iv class=3D"column"><ol start=3D"5" style=3D"list-style-type: none;"><li></=
li></ol></div></div></div></div><blockquote style=3D"margin: 0 0 0 40px; bo=
rder: none; padding: 0px;"><div><div class=3D"page" title=3D"Page 130"><div=
class=3D"layoutArea"><div class=3D"column"><p><span style=3D"font-size: 10=
..000000pt; font-family: 'LMRoman10'">A glvalue expression of type <=
/span><span style=3D"font-size: 10.000000pt; font-family: 'LMMono10'=
;">T1 </span><span style=3D"font-size: 10.000000pt; font-family: 'LMRom=
an10'">can be cast to the type =E2=80=9Creference to </span><span style=
=3D"font-size: 10.000000pt; font-family: 'LMMono10'">T2</span><span=
style=3D"font-size: 10.000000pt; font-family: 'LMRoman10'">=E2=80=
=9D if an expression of type =E2=80=9Cpointer to
</span><span style=3D"font-size: 10.000000pt; font-family: 'LMMono10=
9;">T1</span><span style=3D"font-size: 10.000000pt; font-family: 'LMRom=
an10'">=E2=80=9D can be explicitly converted to the type =E2=80=9Cpoint=
er to </span><span style=3D"font-size: 10.000000pt; font-family: 'LMMon=
o10'">T2</span><span style=3D"font-size: 10.000000pt; font-family: '=
;LMRoman10'">=E2=80=9D using a </span><span style=3D"font-size: 10.0000=
00pt; font-family: 'LMMono10'">reinterpret_cast</span><span style=
=3D"font-size: 10.000000pt; font-family: 'LMRoman10'">. The result =
refers to
the same object as the source glvalue, but with the specified type.=C2=A0</=
span></p></div></div></div></div></blockquote><div>
=09
=09
=09
<div class=3D"page" title=3D"Page 130">
<div class=3D"layoutArea">
<div class=3D"column">
<br>But this case is not at all what D.B. was talking about.</div><div=
class=3D"column"><br></div><div class=3D"column">HTH,</div><div class=3D"c=
olumn">=E2=80=93Arthur</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/ba14bf8f-640b-4c93-8473-eebfdbe56f9a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba14bf8f-640b-4c93-8473-eebfdbe56f9a=
%40isocpp.org</a>.<br />
------=_Part_2004_1570715256.1471576661617--
------=_Part_2003_1499957029.1471576661617--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 31 Aug 2016 18:27:25 +0100
Raw View
--089e010d89ea37e6af053b616987
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 31, 2016 at 6:21 PM, Chris Hallock <christopherhallock@gmail.com
> wrote:
> C++ allows accessing an object as a sequence of unsigned char, but
> (apparently?) not an *array* of unsigned char. If that's true, then it
> follows that you can't use pointer arithmetic on an unsigned char * to
> obtain offsets into the object.
>
> This can be worked around on platforms with flat memory models by
> emulating pointer arithmetic yourself:
> 1) reinterpret_cast the pointer to a large-enough integral type
> 2) offset the integer
> 3) reinterpret_cast back to unsigned char *
>
> But this is awkward and implementation-dependent (the casts are
> implementation-defined). It would be better to just straight up allow
> pointer arithmetic on an unsigned char * within the object representation
> of an object.
>
Right, and my question - and, previously unknown to me, that of issue 1701
- boils down to (A) what precisely is the distinction between *sequence*
and *array* and (B) can it be reduced/removed so that such arithmetic
would be OK.
I don't want to introduce pessimisations or exploitations in the process,
but by the same token, if the Standard really says my only defined way to
do this is to take the 2 pointers and increment the base one until it's
equal to the offset one, then that is... amusing at best! We know that for
trivially copyable types, the other allowances in the standard say such
arithmetic can only have 1 possible result - and that's the one that
compilers implement - and yet it's not codified.
--
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/CACGiwhG1DTWNHXm0O56N5RwPrpgCwkLh1doiosEM9Uz2foGNtw%40mail.gmail.com.
--089e010d89ea37e6af053b616987
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, Aug 31, 2016 at 6:21 PM, Chris Hallock <span dir=3D"ltr"><<a href=3D=
"mailto:christopherhallock@gmail.com" target=3D"_blank">christopherhallock@=
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">C++ allows accessing an object as a sequence of <span style=3D"fon=
t-family:courier new,monospace">unsigned char</span>, but (apparently?) not=
an <b>array</b> of <span style=3D"font-family:courier new,monospace">unsig=
ned char</span>. If that's true, then it follows that you can't use=
pointer arithmetic on an <span style=3D"font-family:courier new,monospace"=
>unsigned char *</span> to obtain offsets into the object.<br><br>This can =
be worked around on platforms with flat memory models by emulating pointer =
arithmetic yourself:<br>=C2=A0 1) <span style=3D"font-family:courier new,mo=
nospace">reinterpret_cast</span> the pointer to a large-enough integral typ=
e<br>=C2=A0 2) offset the integer<br>=C2=A0 3) <span style=3D"font-family:c=
ourier new,monospace">reinterpret_cast</span> back to <span style=3D"font-f=
amily:courier new,monospace">unsigned char *</span><br><br>But this is awkw=
ard and implementation-dependent (the casts are implementation-defined). It=
would be better to just straight up allow pointer arithmetic on an <span s=
tyle=3D"font-family:courier new,monospace">unsigned char *</span> within th=
e object representation of an object.<br></div><span class=3D"">
</span></blockquote><div><br><br></div><div>Right, and my question - and, p=
reviously unknown to me, that of issue 1701 - boils down to (A) what precis=
ely is the distinction between <i>sequence</i> and <i>array</i>=C2=A0 and (=
B) can it be reduced/removed so that such arithmetic would be OK.<br><br></=
div><div>I don't want to introduce pessimisations or exploitations in t=
he process, but by the same token, if the Standard really says my only defi=
ned way to do this is to take the 2 pointers and increment the base one unt=
il it's equal to the offset one, then that is... amusing at best! We kn=
ow that for trivially copyable types, the other allowances in the standard =
say such arithmetic can only have 1 possible result - and that's the on=
e that compilers implement - and yet it's not codified.<br><br><br></di=
v></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/CACGiwhG1DTWNHXm0O56N5RwPrpgCwkLh1doi=
osEM9Uz2foGNtw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG1DTWNHXm0=
O56N5RwPrpgCwkLh1doiosEM9Uz2foGNtw%40mail.gmail.com</a>.<br />
--089e010d89ea37e6af053b616987--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Wed, 31 Aug 2016 21:05:01 +0200
Raw View
--001a114021784f9e65053b62c6fa
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 31, 2016 at 7:21 PM, Chris Hallock <christopherhallock@gmail.com
> wrote:
> C++ allows accessing an object as a sequence of unsigned char, but
(apparently?) not an *array* of unsigned char. If that's true, then it
follows that you can't use pointer arithmetic on an unsigned char * to
obtain offsets into the object.
No, that does not follow. We are not accessing the object *at all*.
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/CAA7YVg0UXLSraOsdQ-U36O0uoAZ310THoAsJ8Ra1OcASs5p4gw%40mail.gmail.com.
--001a114021784f9e65053b62c6fa
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, Aug 31, 2016 at 7:21 PM, Chris Hallock <span dir=3D"ltr"><<a href=3D=
"mailto:christopherhallock@gmail.com" target=3D"_blank">christopherhallock@=
gmail.com</a>></span> wrote:</div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">> =C2=A0C++ allows accessing an object as a se=
quence of <span style=3D"font-family:"courier new",monospace">uns=
igned char</span>, but (apparently?) not an <b>array</b> of <span style=3D"=
font-family:"courier new",monospace">unsigned char</span>. If tha=
t's true, then it follows that you can't use pointer arithmetic on =
an <span style=3D"font-family:"courier new",monospace">unsigned c=
har *</span> to obtain offsets into the object.<div><br></div><div>No, that=
does not follow. We are not accessing the object <i>at all</i>.</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/CAA7YVg0UXLSraOsdQ-U36O0uoAZ310THoAsJ=
8Ra1OcASs5p4gw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0UXLSraOsd=
Q-U36O0uoAZ310THoAsJ8Ra1OcASs5p4gw%40mail.gmail.com</a>.<br />
--001a114021784f9e65053b62c6fa--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Thu, 1 Sep 2016 10:59:23 -0700 (PDT)
Raw View
------=_Part_2758_2015374511.1472752763361
Content-Type: multipart/alternative;
boundary="----=_Part_2759_1858114599.1472752763361"
------=_Part_2759_1858114599.1472752763361
Content-Type: text/plain; charset=UTF-8
>
> > C++ allows accessing an object as a sequence of unsigned char, but
> (apparently?) not an *array* of unsigned char. If that's true, then it
> follows that you can't use pointer arithmetic on an unsigned char * to
> obtain offsets into the object.
>
> No, that does not follow. We are not accessing the object *at all*.
>
True; s/accessing/treating/. To clarify, I'm referring to the definition of
adding or subtracting an integer from a pointer, 5.7/4 (emphasis mine):
"[...] If both the pointer operand and the result point to elements of the *same
array object*, or one past the last element of the array object, the
evaluation shall not produce an overflow; otherwise, the behavior is
undefined." In other words, pointer arithmetic (with integer operands
greater than 1) can only be done on array objects.
--
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/8013489a-71c2-496d-bac0-4d73c201ea48%40isocpp.org.
------=_Part_2759_1858114599.1472752763361
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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">> =C2=A0C++ allows accessing an obje=
ct as a sequence of <span style=3D"font-family:"courier new",mono=
space">unsigned char</span>, but (apparently?) not an <b>array</b> of <span=
style=3D"font-family:"courier new",monospace">unsigned char</spa=
n>. If that's true, then it follows that you can't use pointer arit=
hmetic on an <span style=3D"font-family:"courier new",monospace">=
unsigned char *</span> to obtain offsets into the object.<div><br></div><di=
v>No, that does not follow. We are not accessing the object <i>at all</i>.<=
/div></div></div></div></blockquote><div><br>True; s/accessing/treating/. T=
o clarify, I'm referring to the definition of adding or subtracting an =
integer from a pointer, 5.7/4 (emphasis mine): "[...] If both the poin=
ter operand and the result point to elements of the <b>same array object</b=
>, or one past the last element of the array object, the evaluation shall n=
ot produce an overflow; otherwise, the behavior is undefined." In othe=
r words, pointer arithmetic (with integer operands greater than 1) can only=
be done on array objects.<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/8013489a-71c2-496d-bac0-4d73c201ea48%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8013489a-71c2-496d-bac0-4d73c201ea48=
%40isocpp.org</a>.<br />
------=_Part_2759_1858114599.1472752763361--
------=_Part_2758_2015374511.1472752763361--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 2 Sep 2016 13:50:47 +0200
Raw View
--001a1142500e0a54c1053b84f12d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 1, 2016 at 7:59 PM, Chris Hallock <christopherhallock@gmail.com=
>
wrote:
> True; s/accessing/treating/. To clarify, I'm referring to the definition
of adding or subtracting an integer from a pointer, 5.7/4 (emphasis mine):
"[...] If both the pointer operand and the result point to elements of
the *same
array object*, or one past the last element of the array object, the
evaluation shall not produce an overflow; otherwise, the behavior is
undefined." In other words, pointer arithmetic (with integer operands
greater than 1) can only be done on array objects.
[expr.reinterpret.cast]/11 "A glvalue expression of type T1 can be cast to
the type =E2=80=9Creference to T2=E2=80=9D if an expression of type =E2=80=
=9Cpointer to T1=E2=80=9D can be
explicitly converted to the type =E2=80=9Cpointer to T2=E2=80=9D using a re=
interpret_cast.
The result refers to the same object as the source glvalue, *but with the
specified type*".
Cheers,
V.
--=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/CAA7YVg1qVw5HgNXZK3a_3OwU3keoBiYTKBHLRWJFMEk2y9H=
wZA%40mail.gmail.com.
--001a1142500e0a54c1053b84f12d
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 T=
hu, Sep 1, 2016 at 7:59 PM, Chris Hallock <span dir=3D"ltr"><<a href=3D"=
mailto:christopherhallock@gmail.com" target=3D"_blank">christopherhallock@g=
mail.com</a>></span> wrote:</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">> True; s/accessing/treating/. To clarify, I=
9;m referring to the definition of adding or subtracting an integer from a =
pointer, 5.7/4 (emphasis mine): "[...] If both the pointer operand and=
the result point to elements of the <b>same array object</b>, or one past =
the last element of the array object, the evaluation shall not produce an o=
verflow; otherwise, the behavior is undefined." In other words, pointe=
r arithmetic (with integer operands greater than 1) can only be done on arr=
ay objects.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">[expr.reinterpret.cast]/11=C2=A0"A glvalue expression of type T1=
can be cast to the type =E2=80=9Creference to T2=E2=80=9D if an expression=
of type =E2=80=9Cpointer to T1=E2=80=9D can be explicitly converted to the=
type =E2=80=9Cpointer to T2=E2=80=9D using a reinterpret_cast. The result =
refers to the same object as the source glvalue, <i>but with the specified =
type</i>".<br></div><div class=3D"gmail_quote"><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_q=
uote">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/CAA7YVg1qVw5HgNXZK3a_3OwU3keoBiYTKBHL=
RWJFMEk2y9HwZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1qVw5HgNXZ=
K3a_3OwU3keoBiYTKBHLRWJFMEk2y9HwZA%40mail.gmail.com</a>.<br />
--001a1142500e0a54c1053b84f12d--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Fri, 2 Sep 2016 10:30:57 -0700 (PDT)
Raw View
------=_Part_3410_1020648035.1472837457174
Content-Type: multipart/alternative;
boundary="----=_Part_3411_865028948.1472837457174"
------=_Part_3411_865028948.1472837457174
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> > True; s/accessing/treating/. To clarify, I'm referring to the definitio=
n=20
> of adding or subtracting an integer from a pointer, 5.7/4 (emphasis mine)=
:=20
> "[...] If both the pointer operand and the result point to elements of th=
e *same=20
> array object*, or one past the last element of the array object, the=20
> evaluation shall not produce an overflow; otherwise, the behavior is=20
> undefined." In other words, pointer arithmetic (with integer operands=20
> greater than 1) can only be done on array objects.
>
> [expr.reinterpret.cast]/11 "A glvalue expression of type T1 can be cast t=
o=20
> the type =E2=80=9Creference to T2=E2=80=9D if an expression of type =E2=
=80=9Cpointer to T1=E2=80=9D can be=20
> explicitly converted to the type =E2=80=9Cpointer to T2=E2=80=9D using a =
reinterpret_cast.=20
> The result refers to the same object as the source glvalue, *but with the=
=20
> specified type*".
>
Indeed, "the result refers to the *same* object". The *object*'s type is=20
unchanged. The "but with the specified type" clause refers to the=20
reinterpret_cast *expression*. reinterpret_cast does not change the=20
object's type, because an object's type is immutable.=20
reinterpret_cast<ArrayType&>(classObject) still refers to a class object,=
=20
not an array object, and it must be so because *no array object at that=20
location exists*.
--=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/bef77a1a-f519-4a55-9f9d-35707f604dbb%40isocpp.or=
g.
------=_Part_3411_865028948.1472837457174
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote">> True; s/accessing/treating/. To clarify, I'm re=
ferring to the definition of adding or subtracting an integer from a pointe=
r, 5.7/4 (emphasis mine): "[...] If both the pointer operand and the r=
esult point to elements of the <b>same array object</b>, or one past the la=
st element of the array object, the evaluation shall not produce an overflo=
w; otherwise, the behavior is undefined." In other words, pointer arit=
hmetic (with integer operands greater than 1) can only be done on array obj=
ects.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
[expr.reinterpret.cast]/11=C2=A0"A glvalue expression of type T1 can b=
e cast to the type =E2=80=9Creference to T2=E2=80=9D if an expression of ty=
pe =E2=80=9Cpointer to T1=E2=80=9D can be explicitly converted to the type =
=E2=80=9Cpointer to T2=E2=80=9D using a reinterpret_cast. The result refers=
to the same object as the source glvalue, <i>but with the specified type</=
i>".<br></div></div></div></blockquote><div><br>Indeed, "the resu=
lt refers to the <b>same</b> object". The <i>object</i>'s type is =
unchanged. The "but with the specified type" clause refers to the=
<span style=3D"font-family: courier new,monospace;">reinterpret_cast</span=
> <i>expression</i>. <span style=3D"font-family: courier new,monospace;">re=
interpret_cast</span> does not change the object's type, because an obj=
ect's type is immutable. <span style=3D"font-family: courier new,monosp=
ace;">reinterpret_cast<ArrayType&>(classObject)</span> still refe=
rs to a class object, not an array object, and it must be so because <i>no =
array object at that location exists</i>.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bef77a1a-f519-4a55-9f9d-35707f604dbb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bef77a1a-f519-4a55-9f9d-35707f604dbb=
%40isocpp.org</a>.<br />
------=_Part_3411_865028948.1472837457174--
------=_Part_3410_1020648035.1472837457174--
.