--001a114065c02b82a7053a560be8
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 18, 2016 at 10:58 AM, D. B. <db0451@gmail.com> wrote:

> However, I don't think the above guarantees specifically allow this. And
I'm not sure the wording elsewhere that any object can be considered as a '
*sequence*' of *unsigned char* - the object representation - formally
allows said sequence to be considered as an *array* in order to get around
the 1st allowed piece of arithmetic earlier... or that there's any other
allowance making this well-defined.

Per [intro.object]/5, "An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage."

Per [basic.types]/2, "For any object (other than a base-class subobject) of
trivially copyable type T, whether or not the object holds a valid value of
type T, the underlying bytes (1.7) making up the object can be copied into
an array of char or unsigned char. 42 If the content of the array of char
or unsigned char is copied back into the object, the object shall
subsequently hold its original value."

Per [basic.types]/9, (not quoting), an array of unsigned char is itself a
trivially copyable type, so it is contiguous.

I may still be mistaken, but for me that implies that pointers to at least
trivially copyable types can be recast as pointers into an array of
unsigned chars and operated safely while they stay within the storage
occupied by the object. This can probably be extended to cover
standard-layout types.

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/CAA7YVg1Gp1awFhEjKNwRtyPEvVpMswxj%3DY-CC5RjOFGBTOh%2B5A%40mail.gmail.com.

--001a114065c02b82a7053a560be8
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 10:58 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto=
:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:=
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; =
However, I don&#39;t think the above guarantees specifically allow this. An=
d I&#39;m not sure the wording elsewhere that any object can be considered =
as a &#39;<b>sequence</b>&#39; of <i>unsigned char</i> - the object represe=
ntation - formally allows said sequence to be considered as an <b>array</b>=
 in order to get around the 1st allowed piece of arithmetic earlier... or t=
hat there&#39;s any other allowance making this well-defined.</div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Per [intro.object]/=
5, &quot;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Per [basic.types]/2, =
&quot;For any object (other than a base-class subobject) of trivially copya=
ble type T, whether or not the object
holds a valid value of type T, the underlying bytes (1.7) making up the obj=
ect can be copied into an array of char or unsigned char.
42 If the content of the array of char or unsigned char is copied back into=
 the
object, the object shall subsequently hold its original value.&quot;</div><=
div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Per [basic.t=
ypes]/9, (not quoting), an array of unsigned char is itself a trivially cop=
yable type, so it is contiguous.</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">I may still be mistaken, but for me that implies=
 that pointers to at least trivially copyable types can be recast as pointe=
rs into an array of unsigned chars and operated safely while they stay with=
in the storage occupied by the object. This can probably be extended to cov=
er standard-layout types.</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">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&quot; 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/CAA7YVg1Gp1awFhEjKNwRtyPEvVpMswxj%3DY=
-CC5RjOFGBTOh%2B5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1Gp1aw=
FhEjKNwRtyPEvVpMswxj%3DY-CC5RjOFGBTOh%2B5A%40mail.gmail.com</a>.<br />

--001a114065c02b82a7053a560be8--

.

On 2016-08-18 10:58, D. B. wrote:
> Given this:
> https://www.securecoding.cert.org/confluence/display/c/ARR36-C.+Do+not+subtract+or+compare+two+pointers+that+do+not+refer+to+the+same+array
>
> We see the summary that, formally, the only pointer arithmetic
> operations that are defined are:
>
>   * taking the difference of 2 pointers *within the same array*
>   * comparing using < 2 pointers *within the same object*
>
> ...but what I want to do depends on being able to form *well-defined
> pointer subtractions* (to /std::ptrdiff_t/) *between bytes within the
> object representation in the same object*, or usually just between an
> arbitrary byte and the base address, 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 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/np43n8%244rj%241%40blaine.gmane.org.

.

--e89a8fb1ea8a2daab4053a568669
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Viacheslav,

On Thu, Aug 18, 2016 at 11:28 AM, Viacheslav Usov <via.usov@gmail.com>
wrote:

> On Thu, Aug 18, 2016 at 10:58 AM, D. B. <db0451@gmail.com> wrote:
>
> > However, I don't think the above guarantees specifically allow this. An=
d
> I'm not sure the wording elsewhere that any object can be considered as a=
 '
> *sequence*' of *unsigned char* - the object representation - formally
> allows said sequence to be considered as an *array* in order to get
> around the 1st allowed piece of arithmetic earlier... or that there's any
> other allowance making this well-defined.
>
> Per [intro.object]/5, "An object of trivially copyable or standard-layout
> type (3.9) shall occupy contiguous bytes of storage."
>
> Per [basic.types]/2, "For any object (other than a base-class subobject)
> of trivially copyable type T, whether or not the object holds a valid val=
ue
> of type T, the underlying bytes (1.7) making up the object can be copied
> into an array of char or unsigned char. 42 If the content of the array of
> char or unsigned char is copied back into the object, the object shall
> subsequently hold its original value."
>

You have reached many of the same parts of the Standard as me, but I felt
they didn't guarantee what I want.

In relation to the above, much of my doubt centres around some key
specifiers here: *can be copied into an array of char or unsigned
char* and *copied
back* =E2=80=93 not that the object itself, considered in place without cop=
ying,
*is* (can be treated as) such an array.

The wording about object representation only calls it a *sequence *of *unsi=
gned
char*. And there is no overt indication - as far as I can see - that such a
*sequence* is explicitly allowed to be operated on using pointer arithmetic
- only that *arrays *are. So my concern is that taking *char** pointers
into the object representation then doing offset arithmetic on them is
formally, if only by omission, UB.

Again, it works fine on my compiler and does what I expect - because the
compiler doesn't go out of its way to be capricious and just does the
intuitive thing... but I strive for perfectly formed code in everything
else, and the vagueness around this question is really bugging me now that
I've considered it in more depth than 'well, the object representation
is *kinda
like* an array'. ;-)


> I may still be mistaken, but for me that implies that pointers to at leas=
t
> trivially copyable types can be recast as pointers into an array of
> unsigned chars and operated safely while they stay within the storage
> occupied by the object. This can probably be extended to cover
> standard-layout types.
>

I'm not sure it follows from anything we've quoted, but I hope you're
right! This is the exact guarantee I want.

The objects I'm talking about are trivially copyable, of course - and at
the moment only consist of instances of *unsigned char* anyway - but with
various acrobatics going on around them, which mean I cannot (without
extreme toil) change them to be *arrays* of unsigned char.

Also, less selfishly, this seems - precisely because both you and I have
independently *inferred* similar guarantees, but can't point at any passage
that proves them - to be the kind of thing that users would expect, and
which other clauses in the Standard do seem to *indicate*, if not
explicitly... meaning that, as Martin Sebor said, it would be really
advantageous if the Standard explicitly allowed this. I'm sure all sane
implementations do, and the concept is probably widely assumed, but I worry
that gaps in the Standard are making it officially undefined.

Whew, I need to lie down.

--=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/CACGiwhHLb6L8KXbNGdykqhagfFVhcNde6PVNJooof9iozCX=
rZw%40mail.gmail.com.

--e89a8fb1ea8a2daab4053a568669
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">Hi V=
iacheslav,</div><div class=3D"gmail_quote"><br>On Thu, Aug 18, 2016 at 11:2=
8 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=3D"mailto:via.usov@gmai=
l.com" target=3D"_blank">via.usov@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><span class=3D""><div class=3D"gmail_quote">On Thu, Aug 18, 20=
16 at 10:58 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gmail.=
com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:</div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; However, I don=
&#39;t think the above guarantees specifically allow this. And I&#39;m not =
sure the wording elsewhere that any object can be considered as a &#39;<b>s=
equence</b>&#39; of <i>unsigned char</i> - the object representation - form=
ally allows said sequence to be considered as an <b>array</b> in order to g=
et around the 1st allowed piece of arithmetic earlier... or that there&#39;=
s any other allowance making this well-defined.</div><div class=3D"gmail_qu=
ote"><br></div></span><div class=3D"gmail_quote">Per [intro.object]/5, &quo=
t;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Per [basic.types]/2, =
&quot;For any object (other than a base-class subobject) of trivially copya=
ble type T, whether or not the object
holds a valid value of type T, the underlying bytes (1.7) making up the obj=
ect can be copied into an array of char or unsigned char.
42 If the content of the array of char or unsigned char is copied back into=
 the
object, the object shall subsequently hold its original value.&quot;</div><=
/div></div></blockquote><div><br></div><div>You have reached many of the sa=
me parts of the Standard as me, but I felt they didn&#39;t guarantee what I=
 want.<br></div><div><br></div><div>In relation to the above, much of my do=
ubt centres around some key specifiers here: <i>can be <b>copied </b>into a=
n array of char or unsigned char</i> and <i><b>copied </b>back</i> =E2=80=
=93 not that the object itself, considered in place without copying, <b>is<=
/b> (can be treated as) such an array.<br><br>The wording about object repr=
esentation only calls it a <b><i>sequence</i> </b>of <i>unsigned char</i>. =
And there is no overt indication - as far as I can see - that such a <i>seq=
uence</i> is explicitly allowed to be operated on using pointer arithmetic =
- only that <b><i>arrays</i> </b>are. So my concern is that taking <i>char*=
</i> pointers into the object representation then doing offset arithmetic o=
n them is formally, if only by omission, UB.<br><br>Again, it works fine on=
 my compiler and does what I expect - because the compiler doesn&#39;t go o=
ut of its way to be capricious and just does the intuitive thing... but I s=
trive for perfectly formed code in everything else, and the vagueness aroun=
d this question is really bugging me now that I&#39;ve considered it in mor=
e depth than &#39;well, the object representation is <i>kinda like</i> an a=
rray&#39;. ;-)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">I may still be mistaken, but for me that implies that pointers =
to at least trivially copyable types can be recast as pointers into an arra=
y of unsigned chars and operated safely while they stay within the storage =
occupied by the object. This can probably be extended to cover standard-lay=
out types.</div></div></div></blockquote><br></div>I&#39;m not sure it foll=
ows from anything we&#39;ve quoted, but I hope you&#39;re right! This is th=
e exact guarantee I want.<br><br></div><div class=3D"gmail_extra">The objec=
ts I&#39;m talking about are trivially copyable, of course - and at the mom=
ent only consist of instances of <i>unsigned char</i> anyway - but with var=
ious acrobatics going on around them, which mean I cannot (without extreme =
toil) change them to be <i>arrays</i> of unsigned char.<br><br></div><div c=
lass=3D"gmail_extra">Also, less selfishly, this seems - precisely because b=
oth you and I have independently <i>inferred</i> similar guarantees, but ca=
n&#39;t point at any passage that proves them - to be the kind of thing tha=
t users would expect, and which other clauses in the Standard do seem to <i=
>indicate</i>, if not explicitly... meaning that, as Martin Sebor said, it =
would be really advantageous if the Standard explicitly allowed this. I&#39=
;m sure all sane implementations do, and the concept is probably widely ass=
umed, but I worry that gaps in the Standard are making it officially undefi=
ned.<br><br></div><div class=3D"gmail_extra">Whew, I need to lie down.<br><=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CACGiwhHLb6L8KXbNGdykqhagfFVhcNde6PVN=
Jooof9iozCXrZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHLb6L8KXbN=
GdykqhagfFVhcNde6PVNJooof9iozCXrZw%40mail.gmail.com</a>.<br />

--e89a8fb1ea8a2daab4053a568669--

.

--001a114025cc2ef891053a574761
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 18, 2016 at 1:02 PM, D. B. <db0451@gmail.com> wrote:

> In relation to the above, much of my doubt centres around some key
specifiers here: *can be copied into an array of char or unsigned
char* and *copied
back* =E2=80=93 not that the object itself, considered in place without cop=
ying,
*is* (can be treated as) such an array.

reinterpret_cast between two pointer types (via the requirements imposed on
static_cast) results in "the same address as the original pointer value".
The result is also a safely derived pointer. It is therefore safe and well
defined to convert from any type (I am neglecting alignment complications
here and in what follows) to a pointer to an array of unsigned characters.
Then, assuming the original type trivially copyable, the "address" is that
of contiguous bytes of storage in both the original object and the array.
Any subobject must necessarily have an address within that same contiguous
region, and because the array is also contiguous, the reinterpret_cast of
the subobject's address is also a safely derived pointer to an element of
the array.

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/CAA7YVg1247J3u64yrqdZy%3DULBE5VoWmK-oC83J9zAiFHa=
jMHtQ%40mail.gmail.com.

--001a114025cc2ef891053a574761
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 1:02 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
/div><div class=3D"gmail_quote"><br><div>&gt; In relation to the above, muc=
h of my doubt centres around some key specifiers here: <i>can be <b>copied =
</b>into an array of char or unsigned char</i> and <i><b>copied </b>back</i=
> =E2=80=93 not that the object itself, considered in place without copying=
, <b>is</b> (can be treated as) such an array.</div><div><br></div><div>rei=
nterpret_cast between two pointer types (via the requirements imposed on st=
atic_cast) results in &quot;the same address as the original pointer value&=
quot;. The result is also a safely derived pointer. It is therefore safe an=
d well defined to convert from any type (I am neglecting alignment complica=
tions here and in what follows) to a pointer to an array of unsigned charac=
ters. Then, assuming the original type trivially copyable, the &quot;addres=
s&quot; is that of contiguous bytes of storage in both the original object =
and the array. Any subobject must necessarily have an address within that s=
ame contiguous region, and because the array is also contiguous, the reinte=
rpret_cast of the subobject&#39;s address is also a safely derived pointer =
to an element of the array.</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&quot; 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/CAA7YVg1247J3u64yrqdZy%3DULBE5VoWmK-o=
C83J9zAiFHajMHtQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1247J3u6=
4yrqdZy%3DULBE5VoWmK-oC83J9zAiFHajMHtQ%40mail.gmail.com</a>.<br />

--001a114025cc2ef891053a574761--

.

--001a1147284e7637ee053a577272
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 18, 2016 at 12:56 PM, Viacheslav Usov <via.usov@gmail.com>
wrote:

> On Thu, Aug 18, 2016 at 1:02 PM, D. B. <db0451@gmail.com> wrote:
>
> > In relation to the above, much of my doubt centres around some key
> specifiers here: *can be copied into an array of char or unsigned char*
> and *copied back* =E2=80=93 not that the object itself, considered in pla=
ce
> without copying, *is* (can be treated as) such an array.
>
> reinterpret_cast between two pointer types (via the requirements imposed
> on static_cast) results in "the same address as the original pointer
> value". The result is also a safely derived pointer.
>

I'm with you so far...


> It is therefore safe and well defined to convert from any type (I am
> neglecting alignment complications here and in what follows) to a pointer
> to an array of unsigned characters.
>

This is where it gets unclear for me. The aliasing rules make it clear that
we can convert a pointer to any object to an [*unsigned] char **, which by
inference is so that object representation can be read. But it never
specifically says that the resulting *char ** can be considered to be part
of a conceptual array of size *sizeof(Obj). *So, are we only allowed to
read that original 1 *char*? :-)

My gripe is with this lack of clarity. The fact *memcpy* exists indicates
that everyone else *infers* the resulting pointer is within a conceptual
array - or even that all of memory is one big array - else we would not be
allowed to simply increment and dereference to continue with the copy! But
we seem doomed to inference only, as there is no wording that specifically
guarantees this.

To be clear, I'm definitely not disagreeing with what you say in practical
terms, but I wish it were expressly allowed by the wording of the Standard,
as I can't see it in there. All I can do is infer from various other
passages - things like 'Well, they were *probably thinking* X' and 'The
existence of Y *implies *this is well-formed', and so on. It feels like
trying to put a jigsaw puzzle together!

But if I'm just being dense and missing the logic, please do keep
explaining until I get it. ;-)

--=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/CACGiwhGiw5Ss-UB6Xg4LeHEMq9WR9RhLUYQX%3D5ci23aKa=
oCeuQ%40mail.gmail.com.

--001a1147284e7637ee053a577272
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 12:56 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</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"><span class=3D""><div class=3D"gmail_quote">On Thu, Aug 1=
8, 2016 at 1:02 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gm=
ail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:</div></sp=
an><div class=3D"gmail_quote"><span class=3D""><br><div>&gt; In relation to=
 the above, much of my doubt centres around some key specifiers here: <i>ca=
n be <b>copied </b>into an array of char or unsigned char</i> and <i><b>cop=
ied </b>back</i> =E2=80=93 not that the object itself, considered in place =
without copying, <b>is</b> (can be treated as) such an array.</div><div><br=
></div></span><div>reinterpret_cast between two pointer types (via the requ=
irements imposed on static_cast) results in &quot;the same address as the o=
riginal pointer value&quot;. The result is also a safely derived pointer.</=
div></div></div></div></blockquote><div><br></div><div>I&#39;m with you so =
far...<br></div><div>=C2=A0</div><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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div>It is ther=
efore safe and well defined to convert from any type (I am neglecting align=
ment complications here and in what follows) to a pointer to an array of un=
signed characters.</div></div></div></div></blockquote><div><br></div><div>=
This is where it gets unclear for me. The aliasing rules make it clear that=
 we can convert a pointer to any object to an [<i>unsigned] char *</i>, whi=
ch by inference is so that object representation can be read. But it never =
specifically says that the resulting <i>char *</i> can be considered to be =
part of a conceptual array of size <i>sizeof(Obj). </i>So, are we only allo=
wed to read that original 1 <i>char</i>? :-)<br><i><br></i></div><div>My gr=
ipe is with this lack of clarity. The fact <i>memcpy</i> exists indicates t=
hat everyone else <i>infers</i> the resulting pointer is within a conceptua=
l array - or even that all of memory is one big array - else we would not b=
e allowed to simply increment and dereference to continue with the copy! Bu=
t we seem doomed to inference only, as there is no wording that specificall=
y guarantees this.<br>=C2=A0<br></div><div>To be clear, I&#39;m definitely =
not disagreeing with what you say in practical terms, but I wish it were ex=
pressly allowed by the wording of the Standard, as I can&#39;t see it in th=
ere. All I can do is infer from various other passages - things like &#39;W=
ell, they were <i>probably thinking</i> X&#39; and &#39;The existence of Y =
<i>implies </i>this is well-formed&#39;, and so on. It feels like trying to=
 put a jigsaw puzzle together!<br><br></div><div>But if I&#39;m just being =
dense and missing the logic, please do keep explaining until I get it. ;-)<=
br><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&quot; 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/CACGiwhGiw5Ss-UB6Xg4LeHEMq9WR9RhLUYQX=
%3D5ci23aKaoCeuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGiw5Ss-U=
B6Xg4LeHEMq9WR9RhLUYQX%3D5ci23aKaoCeuQ%40mail.gmail.com</a>.<br />

--001a1147284e7637ee053a577272--

.

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:
>
>     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?
>

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



--
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/np4dcj%2449r%241%40blaine.gmane.org.

.

--001a114035163cee4b053a593cf1
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 18, 2016 at 2:08 PM, D. B. <db0451@gmail.com> wrote:

> This is where it gets unclear for me. The aliasing rules make it clear
that we can convert a pointer to any object to an [*unsigned] char **,
which by inference is so that object representation can be read. But it
never specifically says that the resulting *char ** can be considered to be
part of a conceptual array of size *sizeof(Obj).*

That part is easy. We can convert that to a pointer to unsigned char[sizeof
object]. Then we can certainly access every element of that array.

The nasty part is that you want an offset, which means you would end up
with two pointers to arrays, *different* arrays, so you still cannot do
arithmetic with them directly. What I think you can do is take the address
of the complete object, cast it to pointer to array of unsigned chars, get
the address of the first element of that array, then increment the
resultant pointer until it becomes equal to the address of the member of
interest (that is cast to pointer to unsigned char).

That should work because each byte is required to have a unique address (so
different addresses cannot refer to the same byte), and the comparison for
equality of pointers compares the addresses they represent.

Either that, or the standard offsetof macro.

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/CAA7YVg0gwPLdE7TjGJd-EB7B1onvVmQarBDO9KiX0GAh4ddWLQ%40mail.gmail.com.

--001a114035163cee4b053a593cf1
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:08 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; This is where it gets unclear for me. The alias=
ing rules make it clear that we can convert a pointer to any object to an [=
<i>unsigned] char *</i>, which by inference is so that object representatio=
n can be read. But it never specifically says that the resulting <i>char *<=
/i> can be considered to be part of a conceptual array of size <i>sizeof(Ob=
j).</i></div><div><br></div><div><i></i>That part is easy. We can convert t=
hat to a pointer to unsigned char[sizeof object]. Then we can certainly acc=
ess every element of that array.</div><div><br></div><div>The nasty part is=
 that you want an offset, which means you would end up with two pointers to=
 arrays, <i>different</i>=C2=A0arrays, so you still cannot do arithmetic wi=
th them directly. What I think you can do is take the address of the comple=
te object, cast it to pointer to array of unsigned chars, get the address o=
f the first element of that array, then increment the resultant pointer unt=
il it becomes equal to the address of the member of interest (that is cast =
to pointer to unsigned char).</div><div><br></div><div>That should work bec=
ause each byte is required to have a unique address (so different addresses=
 cannot refer to the same byte), and the comparison for equality of pointer=
s compares the addresses they represent.</div><div><br></div><div>Either th=
at, or the standard offsetof macro.</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&quot; 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/CAA7YVg0gwPLdE7TjGJd-EB7B1onvVmQarBDO=
9KiX0GAh4ddWLQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0gwPLdE7Tj=
GJd-EB7B1onvVmQarBDO9KiX0GAh4ddWLQ%40mail.gmail.com</a>.<br />

--001a114035163cee4b053a593cf1--

.

------=_Part_63_346379638.1471610995610
Content-Type: multipart/alternative;
 boundary="----=_Part_64_1527203367.1471610995610"

------=_Part_64_1527203367.1471610995610
Content-Type: text/plain; charset=UTF-8

On Thursday, 18 August 2016 15:17:02 UTC+1, Viacheslav Usov wrote:
>
> On Thu, Aug 18, 2016 at 2:08 PM, D. B. <db0...@gmail.com <javascript:>>
> wrote:
>
> > This is where it gets unclear for me. The aliasing rules make it clear
> that we can convert a pointer to any object to an [*unsigned] char **,
> which by inference is so that object representation can be read. But it
> never specifically says that the resulting *char ** can be considered to
> be part of a conceptual array of size *sizeof(Obj).*
>
> That part is easy. We can convert that to a pointer to unsigned
> char[sizeof object]. Then we can certainly access every element of that
> array.
>
> The nasty part is that you want an offset, which means you would end up
> with two pointers to arrays, *different* arrays, so you still cannot do
> arithmetic with them directly. What I think you can do is take the address
> of the complete object, cast it to pointer to array of unsigned chars, get
> the address of the first element of that array, then increment the
> resultant pointer until it becomes equal to the address of the member of
> interest (that is cast to pointer to unsigned char).
>

Exactly; we can't use [expr.rel] or [expr.add] between a pointer to
complete object (or a pointer derived from a pointer to complete object)
and a pointer to subobject, but we can use [expr.eq]. It's O(n) in the size
of the complete object (before optimization), but if I understand correctly
the motivation is just that an Standard-compliant implementation should be
*possible*; on any *actual *system pointer arithmetic could be used.

That should work because each byte is required to have a unique address (so
> different addresses cannot refer to the same byte), and the comparison for
> equality of pointers compares the addresses they represent.
>

Yes, although it is possible for *equal but different* pointers to refer to
the same byte (that is, their value representation is distinct). This could
be the case on e.g. a segmented memory system, and provides one obvious
justification for the difference between the relational, arithmetic and
equality operators: the equality operator is required to canonicalize
segmented pointers (or, equally, compare them taking into account
segmentation) while the relational and arithmetic operators can assume the
pointers have the same segment id. Another possibility could be running C++
on top of an object-oriented machine (a Lisp machine, or a Javascript VM)
where a char pointer is a tuple of reference to native object (not
necessarily complete object) and byte offset.


> Either that, or the standard offsetof macro.
>

Which is however only conditionally supported for non-standard-layout types.

--
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/de639306-ff3e-4747-8cf8-3e0c42588e3c%40isocpp.org.

------=_Part_64_1527203367.1471610995610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 18 August 2016 15:17:02 UTC+1, Viacheslav Uso=
v  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote">On Thu, Aug 18, 2016 at 2:08 PM, D. B. <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"K6deg_njCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">db0...@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt;=
 This is where it gets unclear for me. The aliasing rules make it clear tha=
t we can convert a pointer to any object to an [<i>unsigned] char *</i>, wh=
ich by inference is so that object representation can be read. But it never=
 specifically says that the resulting <i>char *</i> can be considered to be=
 part of a conceptual array of size <i>sizeof(Obj).</i></div><div><br></div=
><div><i></i>That part is easy. We can convert that to a pointer to unsigne=
d char[sizeof object]. Then we can certainly access every element of that a=
rray.</div><div><br></div><div>The nasty part is that you want an offset, w=
hich means you would end up with two pointers to arrays, <i>different</i>=
=C2=A0arrays, so you still cannot do arithmetic with them directly. What I =
think you can do is take the address of the complete object, cast it to poi=
nter to array of unsigned chars, get the address of the first element of th=
at array, then increment the resultant pointer until it becomes equal to th=
e address of the member of interest (that is cast to pointer to unsigned ch=
ar).</div></div></div></div></blockquote><div><br></div><div>Exactly; we ca=
n&#39;t use [expr.rel] or [expr.add] between a pointer to complete object (=
or a pointer derived from a pointer to complete object) and a pointer to su=
bobject, but we can use [expr.eq]. It&#39;s O(n) in the size of the complet=
e object (before optimization), but if I understand correctly the motivatio=
n is just that an Standard-compliant implementation should be <i>possible</=
i>; on any <i>actual </i>system pointer arithmetic could be used.</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"><d=
iv><div class=3D"gmail_quote"><div></div><div>That should work because each=
 byte is required to have a unique address (so different addresses cannot r=
efer to the same byte), and the comparison for equality of pointers compare=
s the addresses they represent.</div></div></div></div></blockquote><div><b=
r></div><div>Yes, although it is possible for <i>equal but different</i> po=
inters to refer to the same byte (that is, their value representation is di=
stinct). This could be the case on e.g. a segmented memory system, and prov=
ides one obvious justification for the difference between the relational, a=
rithmetic and equality operators: the equality operator is required to cano=
nicalize segmented pointers (or, equally, compare them taking into account =
segmentation) while the relational and arithmetic operators can assume the =
pointers have the same segment id. Another possibility could be running C++=
 on top of an object-oriented machine (a Lisp machine, or a Javascript VM) =
where a char pointer is a tuple of reference to native object (not necessar=
ily complete object) and byte offset.</div><div>=C2=A0</div><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"><div class=3D"gmail_quote"><=
div></div><div>Either that, or the standard offsetof macro.</div></div></di=
v></blockquote><div><br></div><div>Which is however only conditionally supp=
orted for non-standard-layout types.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/de639306-ff3e-4747-8cf8-3e0c42588e3c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de639306-ff3e-4747-8cf8-3e0c42588e3c=
%40isocpp.org</a>.<br />

------=_Part_64_1527203367.1471610995610--

------=_Part_63_346379638.1471610995610--

.

--001a1142500eec88aa053a6ddb6c
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 2:49 PM, Edward Catmur <ed@catmur.co.uk> wrote:

> the equality operator is required to canonicalize segmented pointers (or,
equally, compare them taking into account segmentation)

Since the standard already requires normalisation for equality tests, any
comformant implementation must have the requisite machinery, so it should
not be too difficult to make that machinery available for pointer
arithmetic. For example, we could have

template<typename T> std::ptrdiff_t std::pointer_distance<T>(T *p, T *q);

that is well-defined whenever p and q (both of type T) point within the
same complete object (or the outermost array).

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/CAA7YVg2nnEMy0Kauo_CsxseWbG2UWfpHNZDv7dXJGnf_fqXHTw%40mail.gmail.com.

--001a1142500eec88aa053a6ddb6c
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 F=
ri, Aug 19, 2016 at 2:49 PM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</span> w=
rote:<br><div><br></div><div>&gt; the equality operator is required to cano=
nicalize segmented pointers (or, equally, compare them taking into account =
segmentation)</div><div><br></div><div>Since the standard already requires =
normalisation for equality tests, any comformant implementation must have t=
he requisite machinery, so it should not be too difficult to make that mach=
inery available for pointer arithmetic. For example, we could have<br></div=
><div><br></div><div>template&lt;typename T&gt; std::ptrdiff_t std::pointer=
_distance&lt;T&gt;(T *p, T *q);</div><div><br></div><div>that is well-defin=
ed whenever p and q (both of type T) point within the same complete object =
(or the outermost array).</div><div><br></div><div>Cheers,<br></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&quot; 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/CAA7YVg2nnEMy0Kauo_CsxseWbG2UWfpHNZDv=
7dXJGnf_fqXHTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2nnEMy0Kau=
o_CsxseWbG2UWfpHNZDv7dXJGnf_fqXHTw%40mail.gmail.com</a>.<br />

--001a1142500eec88aa053a6ddb6c--

.

--001a1147cc8e9ace70053a6ff98a
Content-Type: text/plain; charset=UTF-8

On 19 Aug 2016 3:53 p.m., "Viacheslav Usov" <via.usov@gmail.com> wrote:
>
> On Fri, Aug 19, 2016 at 2:49 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>
> > the equality operator is required to canonicalize segmented pointers
(or, equally, compare them taking into account segmentation)
>
> Since the standard already requires normalisation for equality tests, any
comformant implementation must have the requisite machinery, so it should
not be too difficult to make that machinery available for pointer
arithmetic. For example, we could have
>
> template<typename T> std::ptrdiff_t std::pointer_distance<T>(T *p, T *q);
>
> that is well-defined whenever p and q (both of type T) point within the
same complete object (or the outermost array).

Or we could require that the specialization of std::distance for pointer
types works for any two (aligned) pointers within the same region of
storage, not just within the same array. So your pointer_distance, but with
an existing name. This should be reasonably uncontroversial, seeing as we
already have std::less specialized on pointer types providing a stable,
equality-respecting order for any two pointers anywhere in memory.

As an aside, std::less<T*> means that you can find the offset of a member
in O(log n) i.e. O(sizeof(size_t)), using binary search!

--
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/CAJnLdOYd8obQNEYD3PYzGP3jDF3PzS4i_S-%3DwRbT8kaMjus5qQ%40mail.gmail.com.

--001a1147cc8e9ace70053a6ff98a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 19 Aug 2016 3:53 p.m., &quot;Viacheslav Usov&quot; &lt;<a=
 href=3D"mailto:via.usov@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Aug 19, 2016 at 2:49 PM, Edward Catmur &lt;<a href=3D"mailto:e=
d@catmur.co.uk">ed@catmur.co.uk</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; the equality operator is required to canonicalize segmented point=
ers (or, equally, compare them taking into account segmentation)<br>
&gt;<br>
&gt; Since the standard already requires normalisation for equality tests, =
any comformant implementation must have the requisite machinery, so it shou=
ld not be too difficult to make that machinery available for pointer arithm=
etic. For example, we could have<br>
&gt;<br>
&gt; template&lt;typename T&gt; std::ptrdiff_t std::pointer_distance&lt;T&g=
t;(T *p, T *q);<br>
&gt;<br>
&gt; that is well-defined whenever p and q (both of type T) point within th=
e same complete object (or the outermost array).</p>
<p dir=3D"ltr">Or we could require that the specialization of std::distance=
 for pointer types works for any two (aligned) pointers within the same reg=
ion of storage, not just within the same array. So your pointer_distance, b=
ut with an existing name. This should be reasonably uncontroversial, seeing=
 as we already have std::less specialized on pointer types providing a stab=
le, equality-respecting order for any two pointers anywhere in memory.</p>
<p dir=3D"ltr">As an aside, std::less&lt;T*&gt; means that you can find the=
 offset of a member in O(log n) i.e. O(sizeof(size_t)), using binary search=
!</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAJnLdOYd8obQNEYD3PYzGP3jDF3PzS4i_S-%=
3DwRbT8kaMjus5qQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYd8obQNE=
YD3PYzGP3jDF3PzS4i_S-%3DwRbT8kaMjus5qQ%40mail.gmail.com</a>.<br />

--001a1147cc8e9ace70053a6ff98a--

.

--001a11443ae4a976d3053a701aa5
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 6:24 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Or we could require that the specialization of std::distance for pointer
> types works for any two (aligned) pointers within the same region of
> storage, not just within the same array. So your pointer_distance, but with
> an existing name. This should be reasonably uncontroversial, seeing as we
> already have std::less specialized on pointer types providing a stable,
> equality-respecting order for any two pointers anywhere in memory.
>

Nice workarounds :-)  but would it not be easier just to formally define
the intuitive results of subtracting (aligned, preferably unsigned char)
pointers? If we are apparently allowed to 'fake it' using operator< and
iteration, ultimately arriving at the same number... what's the point of
requiring all that hoop-jumping just to be Standard-compliant?

How does memcpy() get around these vague rules anyway? By incrementing and
dereferencing within 2 regions of memory whose identity it doesn't know,
which rules does it rely on? Or doesn't it? Since users should pass it 2
pointers and a size that fall within well-defined arrays or objects on both
source and destination sides, it seems like another argument for defining
pointer arithmetic proper within a single trivially copyable (and perhaps
also standard layout?) object, not just within an array.

Anyway, appreciate all the thoughts. Keep them coming! :-)

--
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/CACGiwhHcL%3DA%2B3yGtM8yRu8nfVp36_C7uqO%3DpHAA2Ebb1rv_yVQ%40mail.gmail.com.

--001a11443ae4a976d3053a701aa5
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 F=
ri, Aug 19, 2016 at 6:24 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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""></span>Or we could requir=
e that the specialization of std::distance for pointer types works for any =
two (aligned) pointers within the same region of storage, not just within t=
he same array. So your pointer_distance, but with an existing name. This sh=
ould be reasonably uncontroversial, seeing as we already have std::less spe=
cialized on pointer types providing a stable, equality-respecting order for=
 any two pointers anywhere in memory.<br></blockquote><div><br></div>Nice w=
orkarounds :-)=C2=A0 but would it not be easier just to formally define the=
 intuitive results of subtracting (aligned, preferably unsigned char) point=
ers? If we are apparently allowed to &#39;fake it&#39; using operator&lt; a=
nd iteration, ultimately arriving at the same number... what&#39;s the poin=
t of requiring all that hoop-jumping just to be Standard-compliant?<br><br>=
</div><div class=3D"gmail_quote">How does memcpy() get around these vague r=
ules anyway? By incrementing and dereferencing within 2 regions of memory w=
hose identity it doesn&#39;t know, which rules does it rely on? Or doesn&#3=
9;t it? Since users should pass it 2 pointers and a size that fall within w=
ell-defined arrays or objects on both source and destination sides, it seem=
s like another argument for defining pointer arithmetic proper within a sin=
gle trivially copyable (and perhaps also standard layout?) object, not just=
 within an array.<br><br></div><div class=3D"gmail_quote">Anyway, appreciat=
e all the thoughts. Keep them coming! :-)<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CACGiwhHcL%3DA%2B3yGtM8yRu8nfVp36_C7u=
qO%3DpHAA2Ebb1rv_yVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHcL%=
3DA%2B3yGtM8yRu8nfVp36_C7uqO%3DpHAA2Ebb1rv_yVQ%40mail.gmail.com</a>.<br />

--001a11443ae4a976d3053a701aa5--

.

--001a114187e89da516053a703dac
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 7:24 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Or we could require that the specialization of std::distance for pointer
types works for any two (aligned) pointers within the same region of
storage, not just within the same array. So your pointer_distance, but with
an existing name.

I considered that, but rejected. My rationale was that when pointer
normalisation is expensive, existing code using std::distance with pointers
should not suffer. It can be argued, though, that existing code doing that
can only be correct when no normalisation is needed, so an implementation
could in principle be able to avoid extra costs. Then this is a QoI issue.

Another argument is that the fundamental issue deserves to be visible,
rather than being trivialised by a catch-all std::distance.

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/CAA7YVg2B1xj9AmNm-7-j9RKeW_u00F9S_OOddUiG3a3edKMDmQ%40mail.gmail.com.

--001a114187e89da516053a703dac
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 F=
ri, Aug 19, 2016 at 7:24 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><div><br></div><div>&gt; Or we could require that the specialization of s=
td::distance for pointer types works for any two (aligned) pointers within =
the same region of storage, not just within the same array. So your pointer=
_distance, but with an existing name.</div><div><br></div><div>I considered=
 that, but rejected. My rationale was that when pointer normalisation is ex=
pensive, existing code using std::distance with pointers should not suffer.=
 It can be argued, though, that existing code doing that can only be correc=
t when no normalisation is needed, so an implementation could in principle =
be able to avoid extra costs. Then this is a QoI issue.</div><div><br></div=
><div>Another argument is that the fundamental issue deserves to be visible=
, rather than being trivialised by a catch-all std::distance.</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&quot; 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/CAA7YVg2B1xj9AmNm-7-j9RKeW_u00F9S_OOd=
dUiG3a3edKMDmQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2B1xj9AmNm=
-7-j9RKeW_u00F9S_OOddUiG3a3edKMDmQ%40mail.gmail.com</a>.<br />

--001a114187e89da516053a703dac--

.

--001a113fb8742f62cc053a70493a
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 7:34 PM, D. B. <db0451@gmail.com> wrote:

> How does memcpy() get around these vague rules anyway?

It is part of the implementation, so, if it is itself implemented in C++,
it can exploit an implementation-defined behaviour, or it can be
implemented "magically" to begin with. It does not need to be portable.

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/CAA7YVg0SPnqyRtShanHcWS7W_ryN8kTZ7RKmE%2BhdPLSyqbSSuQ%40mail.gmail.com.

--001a113fb8742f62cc053a70493a
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 F=
ri, Aug 19, 2016 at 7:34 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; How does memcpy() get around these vague rules =
anyway?</div><div><br></div><div>It is part of the implementation, so, if i=
t is itself implemented in C++, it can exploit an implementation-defined be=
haviour, or it can be implemented &quot;magically&quot; to begin with. It d=
oes not need to be portable.</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&quot; 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/CAA7YVg0SPnqyRtShanHcWS7W_ryN8kTZ7RKm=
E%2BhdPLSyqbSSuQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0SPnqyRt=
ShanHcWS7W_ryN8kTZ7RKmE%2BhdPLSyqbSSuQ%40mail.gmail.com</a>.<br />

--001a113fb8742f62cc053a70493a--

.

--001a113fb874ecfce2053a706226
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 7:34 PM, D. B. <db0451@gmail.com> wrote:

> Nice workarounds :-)  but would it not be easier just to formally define
the intuitive results of subtracting (aligned, preferably unsigned char)
pointers?

I'm old enough to remember and have used "near", "far" and "huge" pointers.
On some ancient x86 architectures, huge pointers could address the whole 1
megabyte of RAM, and they behaved in this nice way you want. Problem is,
they were much slower than the far pointers, which could also address the
whole 1 megabyte of RAM, but were weird with respect to arithmetic and even
the equality comparison (they were not really comformant in this part).

So the performance/niceness tradeoff was quite real, and I think what we
see in the standard today was directly influenced by that. I do not think
this is likely to change, at least till the people who remember the same
story are on the committee :)

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/CAA7YVg0a8mHXPgatDCoH5m2ZcD6NCXGe1eh%3Dp6kuUrwMX7hvQA%40mail.gmail.com.

--001a113fb874ecfce2053a706226
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 F=
ri, Aug 19, 2016 at 7:34 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; Nice workarounds :-)=C2=A0 but would it not be =
easier just to formally define the intuitive results of subtracting (aligne=
d, preferably unsigned char) pointers?</div><div><br></div><div>I&#39;m old=
 enough to remember and have used &quot;near&quot;, &quot;far&quot; and &qu=
ot;huge&quot; pointers. On some ancient x86 architectures, huge pointers co=
uld address the whole 1 megabyte of RAM, and they behaved in this nice way =
you want. Problem is, they were much slower than the far pointers, which co=
uld also address the whole 1 megabyte of RAM, but were weird with respect t=
o arithmetic and even the equality comparison (they were not really comform=
ant in this part).</div><div><br></div><div>So the performance/niceness tra=
deoff was quite real, and I think what we see in the standard today was dir=
ectly influenced by that. I do not think this is likely to change, at least=
 till the people who remember the same story are on the committee :)</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&quot; 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/CAA7YVg0a8mHXPgatDCoH5m2ZcD6NCXGe1eh%=
3Dp6kuUrwMX7hvQA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0a8mHXPg=
atDCoH5m2ZcD6NCXGe1eh%3Dp6kuUrwMX7hvQA%40mail.gmail.com</a>.<br />

--001a113fb874ecfce2053a706226--

.

--94eb2c05c556751421053a72bafc
Content-Type: text/plain; charset=UTF-8

On 19 Aug 2016 6:54 p.m., "Viacheslav Usov" <via.usov@gmail.com> wrote:
>
> On Fri, Aug 19, 2016 at 7:34 PM, D. B. <db0451@gmail.com> wrote:
>
> > Nice workarounds :-)  but would it not be easier just to formally
define the intuitive results of subtracting (aligned, preferably unsigned
char) pointers?
>
> I'm old enough to remember and have used "near", "far" and "huge"
pointers. On some ancient x86 architectures, huge pointers could address
the whole 1 megabyte of RAM, and they behaved in this nice way you want.
Problem is, they were much slower than the far pointers, which could also
address the whole 1 megabyte of RAM, but were weird with respect to
arithmetic and even the equality comparison (they were not really
comformant in this part).
>
> So the performance/niceness tradeoff was quite real, and I think what we
see in the standard today was directly influenced by that. I do not think
this is likely to change, at least till the people who remember the same
story are on the committee :)
>

It's not solely of historical interest, though. Optimizers can and do take
advantage of the strict rules for pointer arithmetic and order comparison,
so I think there would be considerable resistance to relaxing them.

Also, flat memory might be in the ascendant now, but who knows what the
future holds? Perhaps strict pointer arithmetic and order comparison will
be of advantage programming future heterogeneous architectures.

--
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/CAJnLdOYE6AYOk4otXGpG%3DRSHx7tK1O9X4rJCAY822N_%2BuL%3DESA%40mail.gmail.com.

--94eb2c05c556751421053a72bafc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 19 Aug 2016 6:54 p.m., &quot;Viacheslav Usov&quot; &lt;<a=
 href=3D"mailto:via.usov@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Aug 19, 2016 at 7:34 PM, D. B. &lt;<a href=3D"mailto:db0451@gm=
ail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Nice workarounds :-)=C2=A0 but would it not be easier just to for=
mally define the intuitive results of subtracting (aligned, preferably unsi=
gned char) pointers?<br>
&gt;<br>
&gt; I&#39;m old enough to remember and have used &quot;near&quot;, &quot;f=
ar&quot; and &quot;huge&quot; pointers. On some ancient x86 architectures, =
huge pointers could address the whole 1 megabyte of RAM, and they behaved i=
n this nice way you want. Problem is, they were much slower than the far po=
inters, which could also address the whole 1 megabyte of RAM, but were weir=
d with respect to arithmetic and even the equality comparison (they were no=
t really comformant in this part).<br>
&gt;<br>
&gt; So the performance/niceness tradeoff was quite real, and I think what =
we see in the standard today was directly influenced by that. I do not thin=
k this is likely to change, at least till the people who remember the same =
story are on the committee :)<br>
&gt; </p>
<p dir=3D"ltr">It&#39;s not solely of historical interest, though. Optimize=
rs can and do take advantage of the strict rules for pointer arithmetic and=
 order comparison, so I think there would be considerable resistance to rel=
axing them. </p>
<p dir=3D"ltr">Also, flat memory might be in the ascendant now, but who kno=
ws what the future holds? Perhaps strict pointer arithmetic and order compa=
rison will be of advantage programming future heterogeneous architectures. =
</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAJnLdOYE6AYOk4otXGpG%3DRSHx7tK1O9X4r=
JCAY822N_%2BuL%3DESA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYE6A=
YOk4otXGpG%3DRSHx7tK1O9X4rJCAY822N_%2BuL%3DESA%40mail.gmail.com</a>.<br />

--94eb2c05c556751421053a72bafc--

.

--001a11440d469ffaa2053a72ccef
Content-Type: text/plain; charset=UTF-8

On 19 Aug 2016 6:43 p.m., "Viacheslav Usov" <via.usov@gmail.com> wrote:
>
> On Fri, Aug 19, 2016 at 7:24 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> > Or we could require that the specialization of std::distance for
pointer types works for any two (aligned) pointers within the same region
of storage, not just within the same array. So your pointer_distance, but
with an existing name.
>
> I considered that, but rejected. My rationale was that when pointer
normalisation is expensive, existing code using std::distance with pointers
should not suffer. It can be argued, though, that existing code doing that
can only be correct when no normalisation is needed, so an implementation
could in principle be able to avoid extra costs. Then this is a QoI issue.
>
> Another argument is that the fundamental issue deserves to be visible,
rather than being trivialised by a catch-all std::distance.
>

Thanks, I'm convinced by both your points.

I guess the difference between this and std::less<T*> is that the latter is
essential to disarm a landmine in the Library, namely using pointers as the
key type in associative containers, while computing offsets at runtime is
far more a niche use case.

--
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/CAJnLdOYGPiWDNcZj6YCBEthEbJEpFxTG%2BfamefN_ih8DYhEuAw%40mail.gmail.com.

--001a11440d469ffaa2053a72ccef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 19 Aug 2016 6:43 p.m., &quot;Viacheslav Usov&quot; &lt;<a=
 href=3D"mailto:via.usov@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Aug 19, 2016 at 7:24 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Or we could require that the specialization of std::distance for =
pointer types works for any two (aligned) pointers within the same region o=
f storage, not just within the same array. So your pointer_distance, but wi=
th an existing name.<br>
&gt;<br>
&gt; I considered that, but rejected. My rationale was that when pointer no=
rmalisation is expensive, existing code using std::distance with pointers s=
hould not suffer. It can be argued, though, that existing code doing that c=
an only be correct when no normalisation is needed, so an implementation co=
uld in principle be able to avoid extra costs. Then this is a QoI issue.<br=
>
&gt;<br>
&gt; Another argument is that the fundamental issue deserves to be visible,=
 rather than being trivialised by a catch-all std::distance.<br>
&gt;</p>
<p dir=3D"ltr">Thanks, I&#39;m convinced by both your points.</p>
<p dir=3D"ltr">I guess the difference between this and std::less&lt;T*&gt; =
is that the latter is essential to disarm a landmine in the Library, namely=
 using pointers as the key type in associative containers, while computing =
offsets at runtime is far more a niche use case. </p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAJnLdOYGPiWDNcZj6YCBEthEbJEpFxTG%2Bf=
amefN_ih8DYhEuAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYGPiWDNc=
Zj6YCBEthEbJEpFxTG%2BfamefN_ih8DYhEuAw%40mail.gmail.com</a>.<br />

--001a11440d469ffaa2053a72ccef--

.

On sexta-feira, 19 de agosto de 2016 21:46:56 PDT 'Edward Catmur' via ISO C++
Standard - Future Proposals wrote:
> I guess the difference between this and std::less<T*> is that the latter is
> essential to disarm a landmine in the Library, namely using pointers as the
> key type in associative containers, while computing offsets at runtime is
> far more a niche use case.

I've used this technique before: when looping over two arrays, instead of
advancing both pointers (two registers that need updating) or using an index
variable (three registers in use, of which one only needs updating), I found
it useful to compute the flat-memory offset of between the two pointers. Then I
had only two registers in use, with one only being updated in the loop.

I needed that because of register pressure on 32-bit x86 when doing string
comparisons with the PCMPESTRI instruction, which has too many input
arguments. It also read past the end of the strings. Fortunately, this code
was written in assembly, so no C++ rules were violated.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/1698836.Otm5Y4JP8b%40tjmaciei-mobl1.

.

--94eb2c075ada727544053a7d6951
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 9:41 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On 19 Aug 2016 6:54 p.m., "Viacheslav Usov" <via.usov@gmail.com> wrote:
> > On Fri, Aug 19, 2016 at 7:34 PM, D. B. <db0451@gmail.com> wrote:
> > > Nice workarounds :-)  but would it not be easier just to formally
> define the intuitive results of subtracting (aligned, preferably unsigned
> char) pointers?
> >
> > I'm old enough to remember and have used "near", "far" and "huge"
> pointers. On some ancient x86 architectures, huge pointers could address
> the whole 1 megabyte of RAM, and they behaved in this nice way you want.
> Problem is, they were much slower than the far pointers, which could also
> address the whole 1 megabyte of RAM, but were weird with respect to
> arithmetic and even the equality comparison (they were not really
> comformant in this part).
> >
> > So the performance/niceness tradeoff was quite real, and I think what we
> see in the standard today was directly influenced by that. I do not think
> this is likely to change, at least till the people who remember the same
> story are on the committee :)
> >
>
> It's not solely of historical interest, though. Optimizers can and do take
> advantage of the strict rules for pointer arithmetic and order comparison,
> so I think there would be considerable resistance to relaxing them.
>
> Also, flat memory might be in the ascendant now, but who knows what the
> future holds? Perhaps strict pointer arithmetic and order comparison will
> be of advantage programming future heterogeneous architectures.
>

I get all the points about different types of pointers, memory regions,
etc. - which are valid counterarguments for totally arbitrary subtractions.
But I don't don't grasp why such caveats should disallow (in fact: don't
logically allow) arithmetic within the same (trivially copyable/standard
layout) object.. Such an object must occupy a single, known region of
storage. Just as is true for arrays.

Could it not, then, be made well-defined to perform such arithmetic within
such objects too? If the argument is that the compiler can't know the
origin of the pointers - yet it *must* handle the same uncertainty properly
for pointers within arrays, but not objects... despite the latter being
formally representable as a "sequence" of unsigned char. If the Standard
already requires compilers to honour the array case, it seems like all the
required mechanisms already exist to support objects. Refine the definition
of said "sequence" by specifying that the object's base address can be cast
to an array of* unsigned char[ sizeof(T) ]*, and we seem to be there. But
it can't be that simple - right? ;-)

I'm not saying they should add this just because I have a relatively rare
use-case for it - well, I am, but also! - more that guarantees elsewhere in
the Standard already seem to make it practically possibly, and yet it's not
theoretically defined.

However, it's possible I'm still missing something, so I apologise if you
end up having to explain it yet again!

--
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/CACGiwhHv1rDt%2BSKLDzH4bj1OribiR5mgsqAHW2DBybm446Jg2w%40mail.gmail.com.

--94eb2c075ada727544053a7d6951
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 F=
ri, Aug 19, 2016 at 9:41 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</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""><p dir=3D"ltr"></p>
<p dir=3D"ltr">On 19 Aug 2016 6:54 p.m., &quot;Viacheslav Usov&quot; &lt;<a=
 href=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a=
>&gt; wrote:<br>
&gt; On Fri, Aug 19, 2016 at 7:34 PM, D. B. &lt;<a href=3D"mailto:db0451@gm=
ail.com" target=3D"_blank">db0451@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Nice workarounds :-)=C2=A0 but would it not be easier just to for=
mally define the intuitive results of subtracting (aligned, preferably unsi=
gned char) pointers?<br>
&gt;<br>
&gt; I&#39;m old enough to remember and have used &quot;near&quot;, &quot;f=
ar&quot; and &quot;huge&quot; pointers. On some ancient x86 architectures, =
huge pointers could address the whole 1 megabyte of RAM, and they behaved i=
n this nice way you want. Problem is, they were much slower than the far po=
inters, which could also address the whole 1 megabyte of RAM, but were weir=
d with respect to arithmetic and even the equality comparison (they were no=
t really comformant in this part).<br>
&gt;<br>
&gt; So the performance/niceness tradeoff was quite real, and I think what =
we see in the standard today was directly influenced by that. I do not thin=
k this is likely to change, at least till the people who remember the same =
story are on the committee :)<br>
&gt; </p>
</span><p dir=3D"ltr">It&#39;s not solely of historical interest, though. O=
ptimizers can and do take advantage of the strict rules for pointer arithme=
tic and order comparison, so I think there would be considerable resistance=
 to relaxing them. </p>
<p dir=3D"ltr">Also, flat memory might be in the ascendant now, but who kno=
ws what the future holds? Perhaps strict pointer arithmetic and order compa=
rison will be of advantage programming future heterogeneous architectures.<=
/p></blockquote><div><br>I get all the points about different types of poin=
ters, memory regions, etc. - which are valid counterarguments for totally a=
rbitrary subtractions. But I don&#39;t don&#39;t grasp why such caveats sho=
uld disallow (in fact: don&#39;t logically allow) arithmetic within the sam=
e (trivially copyable/standard layout) object.. Such an object must occupy =
a single, known region of storage. Just as is true for arrays.<br><br></div=
><div>Could it not, then, be made well-defined to perform such arithmetic w=
ithin such objects too? If the argument is that the compiler can&#39;t know=
 the origin of the pointers - yet it <i>must</i> handle the same uncertaint=
y properly for pointers within arrays, but not objects... despite the latte=
r being formally representable as a &quot;sequence&quot; of unsigned char. =
If the Standard already requires compilers to honour the array case, it see=
ms like all the required mechanisms already exist to support objects. Refin=
e the definition of said &quot;sequence&quot; by specifying that the object=
&#39;s base address can be cast to an array of<i> unsigned char[ sizeof(T) =
]</i>, and we seem to be there. But it can&#39;t be that simple - right? ;-=
)<br><br></div><div>I&#39;m not saying they should add this just because I =
have a relatively rare use-case for it - well, I am, but also! - more that =
guarantees elsewhere in the Standard already seem to make it practically po=
ssibly, and yet it&#39;s not theoretically defined.<br><br></div><div>Howev=
er, it&#39;s possible I&#39;m still missing something, so I apologise if yo=
u end up having to explain it yet again!<br><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&quot; 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/CACGiwhHv1rDt%2BSKLDzH4bj1OribiR5mgsq=
AHW2DBybm446Jg2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHv1rDt%2=
BSKLDzH4bj1OribiR5mgsqAHW2DBybm446Jg2w%40mail.gmail.com</a>.<br />

--94eb2c075ada727544053a7d6951--

.

--001a1143e958d1e8ab053a7fa201
Content-Type: text/plain; charset=UTF-8

On 20 Aug 2016 10:26 a.m., "D. B." <db0451@gmail.com> wrote:
>
> On Fri, Aug 19, 2016 at 9:41 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>>
>> On 19 Aug 2016 6:54 p.m., "Viacheslav Usov" <via.usov@gmail.com> wrote:
>> > On Fri, Aug 19, 2016 at 7:34 PM, D. B. <db0451@gmail.com> wrote:
>> > > Nice workarounds :-)  but would it not be easier just to formally
define the intuitive results of subtracting (aligned, preferably unsigned
char) pointers?
>> >
>> > I'm old enough to remember and have used "near", "far" and "huge"
pointers. On some ancient x86 architectures, huge pointers could address
the whole 1 megabyte of RAM, and they behaved in this nice way you want.
Problem is, they were much slower than the far pointers, which could also
address the whole 1 megabyte of RAM, but were weird with respect to
arithmetic and even the equality comparison (they were not really
comformant in this part).
>> >
>> > So the performance/niceness tradeoff was quite real, and I think what
we see in the standard today was directly influenced by that. I do not
think this is likely to change, at least till the people who remember the
same story are on the committee :)
>> >
>>
>> It's not solely of historical interest, though. Optimizers can and do
take advantage of the strict rules for pointer arithmetic and order
comparison, so I think there would be considerable resistance to relaxing
them.
>>
>> Also, flat memory might be in the ascendant now, but who knows what the
future holds? Perhaps strict pointer arithmetic and order comparison will
be of advantage programming future heterogeneous architectures.
>
>
> I get all the points about different types of pointers, memory regions,
etc. - which are valid counterarguments for totally arbitrary subtractions.
But I don't don't grasp why such caveats should disallow (in fact: don't
logically allow) arithmetic within the same (trivially copyable/standard
layout) object.. Such an object must occupy a single, known region of
storage. Just as is true for arrays.
>
> Could it not, then, be made well-defined to perform such arithmetic
within such objects too? If the argument is that the compiler can't know
the origin of the pointers - yet it must handle the same uncertainty
properly for pointers within arrays, but not objects... despite the latter
being formally representable as a "sequence" of unsigned char. If the
Standard already requires compilers to honour the array case, it seems like
all the required mechanisms already exist to support objects. Refine the
definition of said "sequence" by specifying that the object's base address
can be cast to an array of unsigned char[ sizeof(T) ], and we seem to be
there. But it can't be that simple - right? ;-)
>
> I'm not saying they should add this just because I have a relatively rare
use-case for it - well, I am, but also! - more that guarantees elsewhere in
the Standard already seem to make it practically possibly, and yet it's not
theoretically defined.
>
> However, it's possible I'm still missing something, so I apologise if you
end up having to explain it yet again!
>

If we're talking pointers of arbitrary type, there's the optimization
issue, but also that one of the pointers might not be aligned - think
#pragma pack.  If on the other hand you're only concerned about character
pointers, then optimization and alignment cease to be issues.

Also consider that currently it would be allowable for the largest possible
object to be larger than the largest possible array of non-character type.
That would no longer work the same if we were able to subtract and compare
arbitrary non-character pointers within the same object.

Note that if your object is constructed into user-visible storage then
there already exists a character array beneath it and you can use
std::launder on appropriate character pointers to retrieve pointers into
the character array.

--
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/CAJnLdOY4SFZAQYGzr8PJpv2TqFAS1hmYYRS4eBywT4Vt520zXg%40mail.gmail.com.

--001a1143e958d1e8ab053a7fa201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 20 Aug 2016 10:26 a.m., &quot;D. B.&quot; &lt;<a href=3D"=
mailto:db0451@gmail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Aug 19, 2016 at 9:41 PM, &#39;Edward Catmur&#39; via ISO C++ S=
tandard - Future Proposals &lt;<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 19 Aug 2016 6:54 p.m., &quot;Viacheslav Usov&quot; &lt;<a href=
=3D"mailto:via.usov@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; On Fri, Aug 19, 2016 at 7:34 PM, D. B. &lt;<a href=3D"mailto:=
db0451@gmail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt; Nice workarounds :-)=C2=A0 but would it not be easier ju=
st to formally define the intuitive results of subtracting (aligned, prefer=
ably unsigned char) pointers?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I&#39;m old enough to remember and have used &quot;near&quot;=
, &quot;far&quot; and &quot;huge&quot; pointers. On some ancient x86 archit=
ectures, huge pointers could address the whole 1 megabyte of RAM, and they =
behaved in this nice way you want. Problem is, they were much slower than t=
he far pointers, which could also address the whole 1 megabyte of RAM, but =
were weird with respect to arithmetic and even the equality comparison (the=
y were not really comformant in this part).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; So the performance/niceness tradeoff was quite real, and I th=
ink what we see in the standard today was directly influenced by that. I do=
 not think this is likely to change, at least till the people who remember =
the same story are on the committee :)<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s not solely of historical interest, though. Optimizers can=
 and do take advantage of the strict rules for pointer arithmetic and order=
 comparison, so I think there would be considerable resistance to relaxing =
them.<br>
&gt;&gt;<br>
&gt;&gt; Also, flat memory might be in the ascendant now, but who knows wha=
t the future holds? Perhaps strict pointer arithmetic and order comparison =
will be of advantage programming future heterogeneous architectures.<br>
&gt;<br>
&gt;<br>
&gt; I get all the points about different types of pointers, memory regions=
, etc. - which are valid counterarguments for totally arbitrary subtraction=
s. But I don&#39;t don&#39;t grasp why such caveats should disallow (in fac=
t: don&#39;t logically allow) arithmetic within the same (trivially copyabl=
e/standard layout) object.. Such an object must occupy a single, known regi=
on of storage. Just as is true for arrays.<br>
&gt;<br>
&gt; Could it not, then, be made well-defined to perform such arithmetic wi=
thin such objects too? If the argument is that the compiler can&#39;t know =
the origin of the pointers - yet it must handle the same uncertainty proper=
ly for pointers within arrays, but not objects... despite the latter being =
formally representable as a &quot;sequence&quot; of unsigned char. If the S=
tandard already requires compilers to honour the array case, it seems like =
all the required mechanisms already exist to support objects. Refine the de=
finition of said &quot;sequence&quot; by specifying that the object&#39;s b=
ase address can be cast to an array of unsigned char[ sizeof(T) ], and we s=
eem to be there. But it can&#39;t be that simple - right? ;-)<br>
&gt;<br>
&gt; I&#39;m not saying they should add this just because I have a relative=
ly rare use-case for it - well, I am, but also! - more that guarantees else=
where in the Standard already seem to make it practically possibly, and yet=
 it&#39;s not theoretically defined.<br>
&gt;<br>
&gt; However, it&#39;s possible I&#39;m still missing something, so I apolo=
gise if you end up having to explain it yet again!<br>
&gt;</p>
<p dir=3D"ltr">If we&#39;re talking pointers of arbitrary type, there&#39;s=
 the optimization issue, but also that one of the pointers might not be ali=
gned - think #pragma pack.=C2=A0 If on the other hand you&#39;re only conce=
rned about character pointers, then optimization and alignment cease to be =
issues. </p>
<p dir=3D"ltr">Also consider that currently it would be allowable for the l=
argest possible object to be larger than the largest possible array of non-=
character type. That would no longer work the same if we were able to subtr=
act and compare arbitrary non-character pointers within the same object. </=
p>
<p dir=3D"ltr">Note that if your object is constructed into user-visible st=
orage then there already exists a character array beneath it and you can us=
e std::launder on appropriate character pointers to retrieve pointers into =
the character array. </p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAJnLdOY4SFZAQYGzr8PJpv2TqFAS1hmYYRS4=
eBywT4Vt520zXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY4SFZAQYGz=
r8PJpv2TqFAS1hmYYRS4eBywT4Vt520zXg%40mail.gmail.com</a>.<br />

--001a1143e958d1e8ab053a7fa201--

.

--001a114e3072d571d6053a802018
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 20, 2016 at 1:05 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> If we're talking pointers of arbitrary type, there's the optimization
> issue, but also that one of the pointers might not be aligned - think
> #pragma pack.  If on the other hand you're only concerned about character
> pointers, then optimization and alignment cease to be issues
>
Indeed - I am only worried about *unsigned char ** pointers. I tend to work
with byte buffers, both out of necessity and the fact that they just make
more sense to me. More importantly, because only these pointers have so
many already-defined privileges wrt object representation, aliasing, etc.


> Also consider that currently it would be allowable for the largest
> possible object to be larger than the largest possible array of
> non-character type. That would no longer work the same if we were able to
> subtract and compare arbitrary non-character pointers within the same object
>
No issue, as above. :-)


It sounds like maybe this is a reasonable idea to put forward for a wording
change/enhancement, then? Your comments here make me quite optimistic, at
least...


Lastly:

> Note that if your object is constructed into user-visible storage then
> there already exists a character array beneath it and you can use
> std::launder on appropriate character pointers to retrieve pointers into
> the character array.
>
> Sorry, could you explain what you mean by *user-visible storage* and how
it means there's already such an array, and how *launder* would contribute?

--
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/CACGiwhEihJ%3DFfiYEA3wqyWwJJfXc6sjsrcVpnJ%3DqtvoK%3DfuyCA%40mail.gmail.com.

--001a114e3072d571d6053a802018
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 S=
at, Aug 20, 2016 at 1:05 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><p=
 dir=3D"ltr"></p>
<p dir=3D"ltr"></p>
</div></div><p dir=3D"ltr">If we&#39;re talking pointers of arbitrary type,=
 there&#39;s the optimization issue, but also that one of the pointers migh=
t not be aligned - think #pragma pack.=C2=A0 If on the other hand you&#39;r=
e only concerned about character pointers, then optimization and alignment =
cease to be issues</p></blockquote><div>Indeed - I am only worried about <i=
>unsigned char *</i> pointers. I tend to work with byte buffers, both out o=
f necessity and the fact that they just make more sense to me. More importa=
ntly, because only these pointers have so many already-defined privileges w=
rt object representation, aliasing, etc.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">Also consider that currently it would be allowable for the l=
argest possible object to be larger than the largest possible array of non-=
character type. That would no longer work the same if we were able to subtr=
act and compare arbitrary non-character pointers within the same object</p>=
</blockquote><div>No issue, as above. :-) <br><br><br></div><div>It sounds =
like maybe this is a reasonable idea to put forward for a wording change/en=
hancement, then? Your comments here make me quite optimistic, at least...<b=
r><br>=C2=A0<br></div><div>Lastly:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<p dir=3D"ltr"> </p>
<p dir=3D"ltr">Note that if your object is constructed into user-visible st=
orage then there already exists a character array beneath it and you can us=
e std::launder on appropriate character pointers to retrieve pointers into =
the character array. </p><span class=3D"">

<p></p>

</span></blockquote><div>Sorry, could you explain what you mean by <i>user-=
visible storage</i> and how it means there&#39;s already such an array, and=
 how <i>launder</i> would contribute?<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&quot; 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/CACGiwhEihJ%3DFfiYEA3wqyWwJJfXc6sjsrc=
VpnJ%3DqtvoK%3DfuyCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEihJ=
%3DFfiYEA3wqyWwJJfXc6sjsrcVpnJ%3DqtvoK%3DfuyCA%40mail.gmail.com</a>.<br />

--001a114e3072d571d6053a802018--

.

--001a114b4444f36c94053a805731
Content-Type: text/plain; charset=UTF-8

Looking at this about* launder* et al:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html

This addition is intriguing:

[ *Footnote*: An object that is not an array element is considered to
> belong to a single-element array for this purpose; see 5.3.1. A pointer
> past the end of the last element of an array of *n* elements is
> considered to point to a hypothetical element *n* for this purpose; see
> 3.9.2. ],
>

So, does this mean that...

   - We can cast an object to *unsigned char **, either - adjust to taste -
   because said object contains an *unsigned char* in 1st member position,
   or by some interpretation of the object rep/aliasing rules
   - So we now have an
*unsigned char* p *
   - *...*which is an *unsigned char p[0]*
   - *...*to which we can point 1-past the end and get something that acts
   like *unsigned char p[1]*
   - ...from which we can point 1-past the end and get something that acts
   like *unsigned char p[2]*
   - *...*and repeat indefinitely?

 I might be misreading, but... does anyone else think we can extrapolate
this so far that any object can ultimately be treated as an array of *unsigned
char[sizeof(T)]* after all?

I'm trying to work out whether what I want (which already seemed kinda
implicit in C++14) has now been made explicit via deduction through the
above.

--
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/CACGiwhE7Y9L%2Boa%3Dra6jbKAZXUsRBD_v6eRXhRgiOv1Ts3ev-QQ%40mail.gmail.com.

--001a114b4444f36c94053a805731
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Looking at this about<i> launder</i> et al:<br><br><a=
 href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html=
">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html</a><br=
><br></div>This addition is intriguing:<br><div><br><blockquote style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex" class=3D"gmail_quote">[=C2=A0<i>Footnote</i>:
An object that is not an array element is considered to belong to a single-=
element array for this purpose; see 5.3.1.
A pointer past the end of the last element of an array of <i>n</i> elements
is considered to point to a hypothetical element <i>n</i> for this purpose;=
 see 3.9.2.
],<br></blockquote><div><br></div><div>So, does this mean that...<br><ul><l=
i>We can cast an object to <i>unsigned char *</i>, either - adjust to taste=
 - because said object contains an <i>unsigned char</i> in 1st member posit=
ion, or by some interpretation of the object rep/aliasing rules</li><li>So =
we now have an <i>unsigned char* p<br></i></li><li><i>...</i>which is an <i=
>unsigned char p[0]</i></li><li><i>...</i>to which we can point 1-past the =
end and get something that acts like <i>unsigned char p[1]</i></li><li>...f=
rom which we can point 1-past the end and get something that acts like <i>u=
nsigned char p[2]</i><br></li><li><i>...</i>and repeat indefinitely?</li></=
ul>=C2=A0I might be misreading, but... does anyone else think we can extrap=
olate this so far that any object can ultimately be treated as an array of =
<i>unsigned char[sizeof(T)]</i> after all?<br><br></div><div>I&#39;m trying=
 to work out whether what I want (which already seemed kinda implicit in C+=
+14) has now been made explicit via deduction through the above.<br><br></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&quot; 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/CACGiwhE7Y9L%2Boa%3Dra6jbKAZXUsRBD_v6=
eRXhRgiOv1Ts3ev-QQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhE7Y9L%=
2Boa%3Dra6jbKAZXUsRBD_v6eRXhRgiOv1Ts3ev-QQ%40mail.gmail.com</a>.<br />

--001a114b4444f36c94053a805731--

.

--001a1147284e9fcd4e053a807248
Content-Type: text/plain; charset=UTF-8

2 fixes:

On Sat, Aug 20, 2016 at 1:56 PM, D. B. <db0451@gmail.com> wrote:

> Looking at this about* launder* et al:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html
>
> This addition is intriguing:
>
> [ *Footnote*: An object that is not an array element is considered to
>> belong to a single-element array for this purpose; see 5.3.1. A pointer
>> past the end of the last element of an array of *n* elements is
>> considered to point to a hypothetical element *n* for this purpose; see
>> 3.9.2. ],
>>
>
This is marked as "Change in 5.7 (expr.add) paragraph 4"


Hard to explain the below but a correction to the 1st array size and some
attempted clarifications:

So, does this mean that...
>
>    - We can cast an object to *unsigned char **, either - adjust to taste
>    - because said object contains an *unsigned char* in 1st member
>    position, or by some interpretation of the object rep/aliasing rules
>    - So we now have an
> *unsigned char* p *
>    - *...*which can act like an *unsigned char q[1], so we now have &q[0]
>    == *(p + 1)*
>    - *...*to which we can point 1-past the end and get a conceptual
>    larger array, having 2 elements, in which &*q[1] == *(p + 2)*
>    - ...from which we can point 1-past the end ...*etc*.... *&q[2] == *(p
>    + 3)*
>    - *...*and repeat indefinitely?
>
>
Having said all that, whether in Standardese it directly follows - without
literally iterating every element along the way - that we have an
array of *unsigned
char[sizeof(T)]*... I can't quite make out. But it seems mildly
encouraging, at least...

--
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/CACGiwhFL8RFeDdEMh2UqzOE58hEmOx_Gibcj9qp8ysz7wWN%3DXQ%40mail.gmail.com.

--001a1147284e9fcd4e053a807248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2 fixes:<br><div><div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Sat, Aug 20, 2016 at 1:56 PM, D. B. <span dir=3D"l=
tr">&lt;<a href=3D"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>Looking at this about<i> launder</i> et al:<br><b=
r><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.=
html" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/pa=
pers/2015/<wbr>n4430.html</a><br><br></div>This addition is intriguing:<br>=
<div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">[=C2=A0<i>Footno=
te</i>:
An object that is not an array element is considered to belong to a single-=
element array for this purpose; see 5.3.1.
A pointer past the end of the last element of an array of <i>n</i> elements
is considered to point to a hypothetical element <i>n</i> for this purpose;=
 see 3.9.2.
],<br></blockquote></div></div></blockquote><div><br></div><div>This is mar=
ked as &quot;Change in 5.7 (expr.add) paragraph 4&quot;<br><br><br></div><d=
iv>Hard to explain the below but a correction to the 1st array size and som=
e attempted clarifications:<br></div><div><br>
 </div><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"ltr"><=
div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex" class=3D"gmail_quote"></blockquote><div>So,=
 does this mean that...<br><ul><li>We can cast an object to <i>unsigned cha=
r *</i>, either - adjust to taste - because said object contains an <i>unsi=
gned char</i> in 1st member position, or by some interpretation of the obje=
ct rep/aliasing rules</li><li>So we now have an <i>unsigned char* p<br></i>=
</li><li><i>...</i>which can act like an <i>unsigned char <b>q[1]</b>, so w=
e now have &amp;q[0] =3D=3D *(p + 1)</i><br></li><li><i>...</i>to which we =
can point 1-past the end and get a conceptual larger array, having 2 elemen=
ts, in which &amp;<i>q[1] =3D=3D *(p + 2)</i></li><li>...from which we can =
point 1-past the end ...<i>etc</i>.... <i>&amp;q[2] =3D=3D *(p + 3)</i><br>=
</li><li><i>...</i>and repeat indefinitely?<br></li></ul></div></div></div>=
</blockquote><div><br></div><div>Having said all that, whether in Standarde=
se it directly follows - without literally iterating every element along th=
e way - that we have an array of <i>unsigned char[sizeof(T)]</i>... I can&#=
39;t quite make out. But it seems mildly encouraging, at least...<br></div>=
</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&quot; 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/CACGiwhFL8RFeDdEMh2UqzOE58hEmOx_Gibcj=
9qp8ysz7wWN%3DXQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFL8RFeDd=
EMh2UqzOE58hEmOx_Gibcj9qp8ysz7wWN%3DXQ%40mail.gmail.com</a>.<br />

--001a1147284e9fcd4e053a807248--

.

--94eb2c0376c86ecbf6053a815259
Content-Type: text/plain; charset=UTF-8

On 20 Aug 2016 2:04 p.m., "D. B." <db0451@gmail.com> wrote:
>
> 2 fixes:
>
> On Sat, Aug 20, 2016 at 1:56 PM, D. B. <db0451@gmail.com> wrote:
>>
>> Looking at this about launder et al:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.html
>>
>> This addition is intriguing:
>>
>>> [ Footnote: An object that is not an array element is considered to
belong to a single-element array for this purpose; see 5.3.1. A pointer
past the end of the last element of an array of n elements is considered to
point to a hypothetical element n for this purpose; see 3.9.2. ],
>
>
> This is marked as "Change in 5.7 (expr.add) paragraph 4"
>
>
> Hard to explain the below but a correction to the 1st array size and some
attempted clarifications:
>
>> So, does this mean that...
>> We can cast an object to unsigned char *, either - adjust to taste -
because said object contains an unsigned char in 1st member position, or by
some interpretation of the object rep/aliasing rules
>> So we now have an unsigned char* p
>> ...which can act like an unsigned char q[1], so we now have &q[0] == *(p
+ 1)
>> ...to which we can point 1-past the end and get a conceptual larger
array, having 2 elements, in which &q[1] == *(p + 2)
>> ...from which we can point 1-past the end ...etc.... &q[2] == *(p + 3)
>> ...and repeat indefinitely?
>
>
> Having said all that, whether in Standardese it directly follows -
without literally iterating every element along the way - that we have an
array of unsigned char[sizeof(T)]... I can't quite make out. But it seems
mildly encouraging, at least...
>

No, sorry. What you have is a contiguous sequence of unsigned char[1], as
e.g. if they were adjacent data members of a struct.

That is, unless such an array of characters already exists as it would if
e.g. your object were constructed in storage provided by
std::aligned_storage, or by a user-defined allocator.

--
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/CAJnLdOaUZKErKhRh%3Dj3STHrPCsyezJNuneMAQ6H%2BN_FYLCDcnA%40mail.gmail.com.

--94eb2c0376c86ecbf6053a815259
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On 20 Aug 2016 2:04 p.m., &quot;D. B.&quot; &lt;<a href=3D"m=
ailto:db0451@gmail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; 2 fixes:<br>
&gt;<br>
&gt; On Sat, Aug 20, 2016 at 1:56 PM, D. B. &lt;<a href=3D"mailto:db0451@gm=
ail.com">db0451@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Looking at this about launder et al:<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015=
/n4430.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4430.=
html</a><br>
&gt;&gt;<br>
&gt;&gt; This addition is intriguing:<br>
&gt;&gt;<br>
&gt;&gt;&gt; [=C2=A0Footnote: An object that is not an array element is con=
sidered to belong to a single-element array for this purpose; see 5.3.1. A =
pointer past the end of the last element of an array of n elements is consi=
dered to point to a hypothetical element n for this purpose; see 3.9.2. ],<=
br>
&gt;<br>
&gt;<br>
&gt; This is marked as &quot;Change in 5.7 (expr.add) paragraph 4&quot;<br>
&gt;<br>
&gt;<br>
&gt; Hard to explain the below but a correction to the 1st array size and s=
ome attempted clarifications:<br>
&gt;<br>
&gt;&gt; So, does this mean that...<br>
&gt;&gt; We can cast an object to unsigned char *, either - adjust to taste=
 - because said object contains an unsigned char in 1st member position, or=
 by some interpretation of the object rep/aliasing rules<br>
&gt;&gt; So we now have an unsigned char* p<br>
&gt;&gt; ...which can act like an unsigned char q[1], so we now have &amp;q=
[0] =3D=3D *(p + 1)<br>
&gt;&gt; ...to which we can point 1-past the end and get a conceptual large=
r array, having 2 elements, in which &amp;q[1] =3D=3D *(p + 2)<br>
&gt;&gt; ...from which we can point 1-past the end ...etc.... &amp;q[2] =3D=
=3D *(p + 3)<br>
&gt;&gt; ...and repeat indefinitely?<br>
&gt;<br>
&gt;<br>
&gt; Having said all that, whether in Standardese it directly follows - wit=
hout literally iterating every element along the way - that we have an arra=
y of unsigned char[sizeof(T)]... I can&#39;t quite make out. But it seems m=
ildly encouraging, at least...<br>
&gt;</p>
<p dir=3D"ltr">No, sorry. What you have is a contiguous sequence of unsigne=
d char[1], as e.g. if they were adjacent data members of a struct.</p>
<p dir=3D"ltr">That is, unless such an array of characters already exists a=
s it would if e.g. your object were constructed in storage provided by std:=
:aligned_storage, or by a user-defined allocator. </p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAJnLdOaUZKErKhRh%3Dj3STHrPCsyezJNune=
MAQ6H%2BN_FYLCDcnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaUZKEr=
KhRh%3Dj3STHrPCsyezJNuneMAQ6H%2BN_FYLCDcnA%40mail.gmail.com</a>.<br />

--94eb2c0376c86ecbf6053a815259--

.

--001a11443ae4bafb35053a8188fc
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 20, 2016 at 3:06 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> No, sorry. What you have is a contiguous sequence of unsigned char[1], as
> e.g. if they were adjacent data members of a struct.
>
> That is, unless such an array of characters already exists as it would if
> e.g. your object were constructed in storage provided by
> std::aligned_storage, or by a user-defined allocator.
>

I really appreciate your efforts to think of legal loopholes that *might*
be able to make this well-defined for me. :-) Is *std::aligned_storage*
defined to use an array of *char, *or can it do any implementation-defined
acrobatics it wishes? If the answer is affirmative, that would be a lot
easier than writing a custom allocator just to stay on the Standard's good
side...

....but I might if I have to, at least until I can refactor the current
setup to use an array directly... a thought that fills me with horror. As
far as UB goes, I don't feel 100% bad about this bit due to how obtuse an
implementation would have to be to subvert my intuition... only 99% bad. ;-)

--
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/CACGiwhGRDw1PQMPnA2A56NYvXSgXCRW_aCdPfwnNcU-PdTGDYA%40mail.gmail.com.

--001a11443ae4bafb35053a8188fc
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 S=
at, Aug 20, 2016 at 3:06 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">No, sorry. What you have is=
 a contiguous sequence of unsigned char[1], as e.g. if they were adjacent d=
ata members of a struct.</p>
<p dir=3D"ltr">That is, unless such an array of characters already exists a=
s it would if e.g. your object were constructed in storage provided by std:=
:aligned_storage, or by a user-defined allocator. </p><span class=3D"">

</span></blockquote><div><br>I really appreciate your efforts to think of l=
egal loopholes that <i>might</i> be able to make this well-defined for me. =
:-) Is <i>std::aligned_storage</i> defined to use an array of <i>char, </i>=
or can it do any implementation-defined acrobatics it wishes? If the answer=
 is affirmative, that would be a lot easier than writing a custom allocator=
 just to stay on the Standard&#39;s good side...<br><br></div><div>...but I=
 might if I have to, at least until I can refactor the current setup to use=
 an array directly... a thought that fills me with horror. As far as UB goe=
s, I don&#39;t feel 100% bad about this bit due to how obtuse an implementa=
tion would have to be to subvert my intuition... only 99% bad. ;-)<br><br><=
/div><div>=C2=A0</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&quot; 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/CACGiwhGRDw1PQMPnA2A56NYvXSgXCRW_aCdP=
fwnNcU-PdTGDYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGRDw1PQMPn=
A2A56NYvXSgXCRW_aCdPfwnNcU-PdTGDYA%40mail.gmail.com</a>.<br />

--001a11443ae4bafb35053a8188fc--

.

--001a114a967a22f6b4053a824210
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 20, 2016 at 3:21 PM, D. B. <db0451@gmail.com> wrote:

> On Sat, Aug 20, 2016 at 3:06 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> No, sorry. What you have is a contiguous sequence of unsigned char[1], as
>> e.g. if they were adjacent data members of a struct.
>>
>> That is, unless such an array of characters already exists as it would if
>> e.g. your object were constructed in storage provided by
>> std::aligned_storage, or by a user-defined allocator.
>>
>
> I really appreciate your efforts to think of legal loopholes that *might*
> be able to make this well-defined for me. :-) Is *std::aligned_storage*
> defined to use an array of *char, *or can it do any
> implementation-defined acrobatics it wishes? If the answer is affirmative,
> that would be a lot easier than writing a custom allocator just to stay on
> the Standard's good side...
>

Ah. No, it can be any POD. However, writing your own aligned_storage is
easy if somewhat recursive (for "default-alignment"):

template<std::size_t <http://en.cppreference.com/w/cpp/types/size_t>
Len, std::size_t <http://en.cppreference.com/w/cpp/types/size_t> Align
= alignof(std::aligned_storage_t<Len>)>struct my_aligned_storage {
    typedef struct {
        alignas(Align) unsigned char data[Len];
    } type;};

--
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/CAJnLdOZ_orON0Da5XgWyDFH7fmcc34daRKOr%3DKW%2BuxR0DbyPQw%40mail.gmail.com.

--001a114a967a22f6b4053a824210
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Aug 20, 2016 at 3:21 PM, D. B. <span dir=3D"ltr">&=
lt;<a href=3D"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Sat, Aug 20, 2016 at 3:06 PM, &#39;Edward Catmur&#39; v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><p dir=3D"ltr">No, sorry. What you =
have is a contiguous sequence of unsigned char[1], as e.g. if they were adj=
acent data members of a struct.</p>
<p dir=3D"ltr">That is, unless such an array of characters already exists a=
s it would if e.g. your object were constructed in storage provided by std:=
:aligned_storage, or by a user-defined allocator. </p><span>

</span></blockquote><div><br>I really appreciate your efforts to think of l=
egal loopholes that <i>might</i> be able to make this well-defined for me. =
:-) Is <i>std::aligned_storage</i> defined to use an array of <i>char, </i>=
or can it do any implementation-defined acrobatics it wishes? If the answer=
 is affirmative, that would be a lot easier than writing a custom allocator=
 just to stay on the Standard&#39;s good side...<br></div></div></div></div=
></blockquote><div><br></div><div>Ah. No, it can be any POD. However, writi=
ng your own aligned_storage is easy if somewhat recursive (for &quot;defaul=
t-alignment&quot;):</div><div><br></div><div><pre class=3D"de1" style=3D"pa=
dding:0px;border:0px none white;color:rgb(0,0,0);line-height:1.2em;border-t=
op-left-radius:5px;border-top-right-radius:5px;border-bottom-right-radius:5=
px;border-bottom-left-radius:5px;margin-top:0px;margin-bottom:0px;width:55e=
m;overflow:auto;font-size:13px;background-image:none;vertical-align:top;fon=
t-family:DejaVuSansMono,&#39;DejaVu Sans Mono&#39;,courier,monospace!import=
ant"><span class=3D"kw1" style=3D"color:rgb(0,0,221)">template</span><span =
class=3D"sy1" style=3D"color:rgb(0,0,128)">&lt;</span><a href=3D"http://en.=
cppreference.com/w/cpp/types/size_t" style=3D"text-decoration:none;color:rg=
b(0,48,128);background-image:none;background-position:initial initial;backg=
round-repeat:initial initial"><span class=3D"kw100">std::<span class=3D"me2=
">size_t</span></span></a> Len, <a href=3D"http://en.cppreference.com/w/cpp=
/types/size_t" style=3D"text-decoration:none;color:rgb(0,48,128);background=
-image:none;background-position:initial initial;background-repeat:initial i=
nitial"><span class=3D"kw100">std::<span class=3D"me2">size_t</span></span>=
</a> Align =3D alignof(std::aligned_storage_t&lt;Len&gt;)<span class=3D"sy1=
" style=3D"color:rgb(0,0,128)">&gt;</span>
<span class=3D"kw1" style=3D"color:rgb(0,0,221)">struct</span> my_aligned_s=
torage <span class=3D"br0" style=3D"color:rgb(0,128,0)">{</span>
    <span class=3D"kw1" style=3D"color:rgb(0,0,221)">typedef</span> <span c=
lass=3D"kw1" style=3D"color:rgb(0,0,221)">struct</span> <span class=3D"br0"=
 style=3D"color:rgb(0,128,0)">{</span>
        alignas<span class=3D"br0" style=3D"color:rgb(0,128,0)">(</span>Ali=
gn<span class=3D"br0" style=3D"color:rgb(0,128,0)">)</span> <span class=3D"=
kw4" style=3D"color:rgb(0,0,255)">unsigned</span> <span class=3D"kw4" style=
=3D"color:rgb(0,0,255)">char</span> data<span class=3D"br0" style=3D"color:=
rgb(0,128,0)">[</span>Len<span class=3D"br0" style=3D"color:rgb(0,128,0)">]=
</span><span class=3D"sy4" style=3D"color:rgb(0,128,128)">;</span>
    <span class=3D"br0" style=3D"color:rgb(0,128,0)">}</span> type<span cla=
ss=3D"sy4" style=3D"color:rgb(0,128,128)">;</span>
<span class=3D"br0" style=3D"color:rgb(0,128,0)">}</span><span class=3D"sy4=
" style=3D"color:rgb(0,128,128)">;</span></pre></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&quot; 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/CAJnLdOZ_orON0Da5XgWyDFH7fmcc34daRKOr=
%3DKW%2BuxR0DbyPQw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ_orON=
0Da5XgWyDFH7fmcc34daRKOr%3DKW%2BuxR0DbyPQw%40mail.gmail.com</a>.<br />

--001a114a967a22f6b4053a824210--

.

--001a1142c104aa8cfe053af8d816
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 20, 2016 at 11:26 AM, D. B. <db0451@gmail.com> wrote:

> I get all the points about different types of pointers, memory regions,
etc. - which are valid counterarguments for totally arbitrary subtractions.
But I don't don't grasp why such caveats should disallow (in fact: don't
logically allow) arithmetic within the same (trivially copyable/standard
layout) object.. Such an object must occupy a single, known region of
storage. Just as is true for arrays.

Let me try again.

(0) [intro.memory]/1 "Every byte has a unique address."

(1) [intro.object]/5 "An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage."

(2) [basic.compound]/3 "If an object of type T is located at an address A,
a pointer of type cv T* whose value is the address A is said to point to
that object, regardless of how the value was obtained."

(3) [basic.types]/9 "Scalar types, standard-layout class types (Clause 9),
arrays of such types and cv-qualified versions of these types (3.9.3) are
collectively called standard-layout types."

(4) [basic.align]/6 "Furthermore, the narrow character types (3.9.1) shall
have the weakest alignment requirement."

(5) [conv.ptr]/2 "A prvalue of type =E2=80=9Cpointer to cv T=E2=80=9D, wher=
e T is an object
type, can be converted to a prvalue of type =E2=80=9Cpointer to cv void=E2=
=80=9D. The
result of converting a non-null pointer value of a pointer to object type
to a =E2=80=9Cpointer to cv void=E2=80=9D represents the address of the sam=
e byte in memory
as the original pointer value"

(6) [expr.static.cast]/13 "A prvalue of type =E2=80=9Cpointer to cv1 void=
=E2=80=9D can be
converted to a prvalue of type =E2=80=9Cpointer to cv2 T=E2=80=9D, where T =
is an object
type and cv2 is the same cv-qualification as, or greater cv-qualification
than, cv1. The null pointer value is converted to the null pointer value of
the destination type. If the original pointer value represents the address
A of a byte in memory and A satisfies the alignment requirement of T, then
the resulting pointer value represents the same address as the original
pointer value, that is, A"

(7) [expr.reinterpret.cast]/7 "An object pointer can be explicitly
converted to an object pointer of a different type. When a prvalue v of
object pointer type is converted to the object pointer type =E2=80=9Cpointe=
r to cv
T=E2=80=9D, the result is static_cast<cv T*>(static_cast<cv void*>(v))."

(8) [expr.sizeof] "The sizeof operator yields the number of bytes in the
object representation of its operand. The operand is either an expression,
which is an unevaluated operand (Clause 5), or a parenthesized type-id. The
sizeof operator shall not be applied to an expression that has function or
incomplete type, to the parenthesized name of such types, or to a glvalue
that designates a bit-field. sizeof(char), sizeof(signed char) and
sizeof(unsigned char) are 1."

Assume types A and C are trivially copyable or standard-layout types, type
C has field a of type A, which is not a bit-field.

Per (5), (6) & (7), pac defined via

auto pac =3D reinterpret_cast<unsigned char(*)[sizeof (C)]>(&c);

is a pointer representing the address of the first byte of c.

Per (2), pc defined via

auto pc =3D &(*pac)[0]

is a pointer to the first unsigned char in the array pointed to by pac, and
it represents the address of c.

Per (5), (6) & (7), pa defined via

auto pa =3D reinterpret_cast<unsigned char*>(&c.a);

is a pointer representing address X of the first byte of c.a.

Per (0) & (1), X is an address of a byte somewhere in the storage occupied
by the array pointed to by pac. There must therefore be an unsigned char in
the array pointed to by pac, with address X. Assume the latter is not true,
then, per (8), there is exactly one byte per any unsigned character,
therefore the byte at address X does not correspond to any byte
representing any unsigned char in the array pointed by pac, which
contradicts either (1) or (4). Therefore, an unsigned char in the array
pointed to by pac exists at address X. Per (2), pa, representing address X,
points to an unsigned char in the array pointed to by pac.

Therefore, pc and pa are both pointers to unsigned chars in the array
pointed to by pac.

Per (2), we should achieve the same if pc is defined directly via

auto pc =3D reinterpret_cast<unsigned char*>(&c);

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/CAA7YVg1CjSh4tn0%2BG5b0dHi_RExHdDPESFLm-Qmhe9x_7=
6PmTQ%40mail.gmail.com.

--001a1142c104aa8cfe053af8d816
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 S=
at, Aug 20, 2016 at 11:26 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto=
:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:=
<br><div><br></div><div>&gt; I get all the points about different types of =
pointers, memory regions, etc. - which are valid counterarguments for total=
ly arbitrary subtractions. But I don&#39;t don&#39;t grasp why such caveats=
 should disallow (in fact: don&#39;t logically allow) arithmetic within the=
 same (trivially copyable/standard layout) object.. Such an object must occ=
upy a single, known region of storage. Just as is true for arrays.</div><di=
v><br></div><div>Let me try again.</div><div><br></div><div>(0)=C2=A0[intro=
..memory]/1 &quot;Every
byte has a unique address.&quot;</div><div><br></div><div>(1) [intro.object=
]/5 &quot;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div><br></=
div><div><span style=3D"font-size:12.8px">(2) [basic.compound]/3 &quot;</sp=
an>If an object of type T is located at an address A, a pointer of type cv =
T* whose value is the address A is said to point to that object,=C2=A0regar=
dless of how the value was obtained.<span style=3D"font-size:12.8px">&quot;=
</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>(3=
) [basic.types]/9 &quot;Scalar types, standard-layout class types (Clause 9=
), arrays of such types and
cv-qualified versions of these types (3.9.3) are collectively called standa=
rd-layout types.&quot;<br></div><div><br></div><div>(4) [basic.align]/6 &qu=
ot;Furthermore,
the narrow character types (3.9.1) shall have the weakest alignment require=
ment.&quot;<br></div><div><br></div><div>(5) [conv.ptr]/2 &quot;A prvalue o=
f type =E2=80=9Cpointer to cv T=E2=80=9D, where T is an object type, can be=
 converted to a prvalue of type =E2=80=9Cpointer
to cv void=E2=80=9D. The result of converting a non-null pointer value of a=
 pointer to object type to a =E2=80=9Cpointer to cv
void=E2=80=9D represents the address of the same byte in memory as the orig=
inal pointer value&quot;<br></div><div><br></div><div><div>(6) [expr.static=
..cast]/13 &quot;A prvalue of type =E2=80=9Cpointer to cv1 void=E2=80=9D can=
 be converted to a prvalue of type =E2=80=9Cpointer to cv2 T=E2=80=9D, wher=
e T is an object type and cv2 is the same cv-qualification as, or greater c=
v-qualification than, cv1. The null pointer value is converted to the null =
pointer value of the destination type. If the original pointer value repres=
ents the address A of a byte in memory and A satisfies the alignment requir=
ement of T, then the resulting pointer value represents the same address as=
 the original pointer value, that is, A&quot;<br></div><div><br></div></div=
><div>(7) [expr.reinterpret.cast]/7 &quot;An object pointer can be explicit=
ly converted to an object pointer of a different type. When a prvalue v of
object pointer type is converted to the object pointer type =E2=80=9Cpointe=
r to cv T=E2=80=9D, the result is static_cast&lt;cv T*&gt;(static_cast&lt;c=
v void*&gt;(v)).&quot;<br></div><div><br></div><div>(8)=C2=A0[expr.sizeof] =
&quot;The sizeof operator yields the number of bytes in the object represen=
tation of its operand. The operand is
either an expression, which is an unevaluated operand (Clause 5), or a pare=
nthesized type-id. The sizeof
operator shall not be applied to an expression that has function or incompl=
ete type, to the parenthesized
name of such types, or to a glvalue that designates a bit-field. sizeof(cha=
r), sizeof(signed char) and
sizeof(unsigned char) are 1.&quot;</div><div><br></div><div>Assume types A =
and C are trivially copyable or standard-layout types, type C has field a o=
f type A, which is not a bit-field.</div><div><br></div><div>Per (5), (6) &=
amp; (7), pac defined via</div><div><br></div><div>auto pac =3D reinterpret=
_cast&lt;unsigned char(*)[sizeof (C)]&gt;(&amp;c);</div><div><br></div><div=
>is a pointer representing the address of the first byte of c.</div><div><b=
r></div><div>Per (2), pc defined via<br></div><div><br></div><div>auto pc =
=3D &amp;(*pac)[0]</div><div><br></div><div>is a pointer to the first unsig=
ned char in the array pointed to by pac, and it=C2=A0represents=C2=A0the ad=
dress of c.</div><div><br></div><div>Per=C2=A0(5), (6) &amp; (7),=C2=A0pa d=
efined via<br></div><div><div><br></div><div>auto pa =3D reinterpret_cast&l=
t;unsigned char*&gt;(&amp;c.a);</div><div><br></div><div>is a pointer=C2=A0=
representing=C2=A0address X of the first byte of c.a.</div><div><br></div><=
div>Per (0) &amp; (1), X is an address of a byte somewhere in the storage o=
ccupied by the array pointed to by pac. There must therefore be an unsigned=
 char in the array pointed to by pac, with address X. Assume the latter is =
not true, then, per (8), there is exactly one byte per any unsigned charact=
er, therefore the byte at address X does not correspond to any byte represe=
nting any unsigned char in the array pointed by pac, which contradicts eith=
er (1) or (4). Therefore, an unsigned char in the array pointed to by pac e=
xists at address X. Per (2), pa, representing address X, points to an unsig=
ned char in the array pointed to by pac.</div><div><br></div><div>Therefore=
, pc and pa are both pointers to unsigned chars in the array pointed to by =
pac.<br></div><div><br></div></div><div><div>Per (2), we should achieve the=
 same if pc is defined directly via</div><div><br></div><div>auto pc =3D re=
interpret_cast&lt;unsigned char*&gt;(&amp;c);</div></div><div><br></div><di=
v>Cheers,<br></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&quot; 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/CAA7YVg1CjSh4tn0%2BG5b0dHi_RExHdDPESF=
Lm-Qmhe9x_76PmTQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1CjSh4tn=
0%2BG5b0dHi_RExHdDPESFLm-Qmhe9x_76PmTQ%40mail.gmail.com</a>.<br />

--001a1142c104aa8cfe053af8d816--

.

--e89a8fb1ea8a80c11d053af931ea
Content-Type: text/plain; charset=UTF-8

Whew! That explanation is so logical, it makes my head hurt... ;-)

So you think that doing &c.a - &c is defined behaviour, via these rules? I
know you originally said this (but in much less detail :-) but got the
impression from some of your later messages that you had changed your
mind/interpretation.

Specifically, this:

That part is easy. We can convert that to a pointer to unsigned char[sizeof
> object]. Then we can certainly access every element of that array.
>
> The nasty part is that you want an offset, which means you would end up
> with two pointers to arrays, *different* arrays, so you still cannot do
> arithmetic with them directly.
>

Am I correct that you no longer think the 2nd paragraph is a barrier to
this subtraction being defined, considering the steps you've shown?

If so, then by simply 'imagining' an array pointed at be *pac*, combined
with the rules for converting/casting addresses, would mean that *pa* and
*pc* must be formally subtractable, although they were not directly
obtained from an array. I hope I've read this right...

Thanks again!

--
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/CACGiwhGmA0w6EZqeTEzqw0gwXXrRLRMoSq2v6MijLosqByh5Dw%40mail.gmail.com.

--e89a8fb1ea8a80c11d053af931ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Whew! That explanation is so logical, it makes m=
y head hurt... ;-)<br><br></div>So you think that doing &amp;c.a - &amp;c i=
s defined behaviour, via these rules? I know you originally said this (but =
in much less detail :-) but got the impression from some of your later mess=
ages that you had changed your mind/interpretation.<br><br></div><div>Speci=
fically, this:<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Tha=
t part is easy. We can convert that to a pointer to unsigned=20
char[sizeof object]. Then we can certainly access every element of that=20
array.<div><br></div>The nasty part is that you want an offset, which means=
 you would end up with two pointers to arrays, <i>different</i>=C2=A0arrays=
, so you still cannot do arithmetic with them directly.<br></blockquote><br=
>Am I correct that you no longer think the 2nd paragraph is a barrier to th=
is subtraction being defined, considering the steps you&#39;ve shown?<br><b=
r>If so, then by simply &#39;imagining&#39; an array pointed at be <i>pac</=
i>, combined with the rules for converting/casting addresses, would mean th=
at <i>pa</i> and <i>pc</i> must be formally subtractable, although they wer=
e not directly obtained from an array. I hope I&#39;ve read this right...<b=
r></div><div><br></div>Thanks again!<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CACGiwhGmA0w6EZqeTEzqw0gwXXrRLRMoSq2v=
6MijLosqByh5Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGmA0w6EZqe=
TEzqw0gwXXrRLRMoSq2v6MijLosqByh5Dw%40mail.gmail.com</a>.<br />

--e89a8fb1ea8a80c11d053af931ea--

.

--001a1144831ee9897a053af957be
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2016 at 1:42 PM, Viacheslav Usov <via.usov@gmail.com> wrote=
:

> On Sat, Aug 20, 2016 at 11:26 AM, D. B. <db0451@gmail.com> wrote:
>
> > I get all the points about different types of pointers, memory regions,
> etc. - which are valid counterarguments for totally arbitrary subtraction=
s.
> But I don't don't grasp why such caveats should disallow (in fact: don't
> logically allow) arithmetic within the same (trivially copyable/standard
> layout) object.. Such an object must occupy a single, known region of
> storage. Just as is true for arrays.
>
> Let me try again.
>
> (0) [intro.memory]/1 "Every byte has a unique address."
>
> (1) [intro.object]/5 "An object of trivially copyable or standard-layout
> type (3.9) shall occupy contiguous bytes of storage."
>
> (2) [basic.compound]/3 "If an object of type T is located at an address
> A, a pointer of type cv T* whose value is the address A is said to point =
to
> that object, regardless of how the value was obtained."
>

Not since P0137R1. But I'll assume that you're either working within C++14
as written (although no implementation conforms to that as written) or are
inserting calls to std::launder where required.


> (3) [basic.types]/9 "Scalar types, standard-layout class types (Clause 9)=
,
> arrays of such types and cv-qualified versions of these types (3.9.3) are
> collectively called standard-layout types."
>
> (4) [basic.align]/6 "Furthermore, the narrow character types (3.9.1) shal=
l
> have the weakest alignment requirement."
>
> (5) [conv.ptr]/2 "A prvalue of type =E2=80=9Cpointer to cv T=E2=80=9D, wh=
ere T is an
> object type, can be converted to a prvalue of type =E2=80=9Cpointer to cv=
 void=E2=80=9D.
> The result of converting a non-null pointer value of a pointer to object
> type to a =E2=80=9Cpointer to cv void=E2=80=9D represents the address of =
the same byte in
> memory as the original pointer value"
>
> (6) [expr.static.cast]/13 "A prvalue of type =E2=80=9Cpointer to cv1 void=
=E2=80=9D can be
> converted to a prvalue of type =E2=80=9Cpointer to cv2 T=E2=80=9D, where =
T is an object
> type and cv2 is the same cv-qualification as, or greater cv-qualification
> than, cv1. The null pointer value is converted to the null pointer value =
of
> the destination type. If the original pointer value represents the addres=
s
> A of a byte in memory and A satisfies the alignment requirement of T, the=
n
> the resulting pointer value represents the same address as the original
> pointer value, that is, A"
>
> (7) [expr.reinterpret.cast]/7 "An object pointer can be explicitly
> converted to an object pointer of a different type. When a prvalue v of
> object pointer type is converted to the object pointer type =E2=80=9Cpoin=
ter to cv
> T=E2=80=9D, the result is static_cast<cv T*>(static_cast<cv void*>(v))."
>
> (8) [expr.sizeof] "The sizeof operator yields the number of bytes in the
> object representation of its operand. The operand is either an expression=
,
> which is an unevaluated operand (Clause 5), or a parenthesized type-id. T=
he
> sizeof operator shall not be applied to an expression that has function o=
r
> incomplete type, to the parenthesized name of such types, or to a glvalue
> that designates a bit-field. sizeof(char), sizeof(signed char) and
> sizeof(unsigned char) are 1."
>
> Assume types A and C are trivially copyable or standard-layout types, typ=
e
> C has field a of type A, which is not a bit-field.
>
> Per (5), (6) & (7), pac defined via
>
> auto pac =3D reinterpret_cast<unsigned char(*)[sizeof (C)]>(&c);
>
> is a pointer representing the address of the first byte of c.
>
> Per (2), pc defined via
>
> auto pc =3D &(*pac)[0]
>
> is a pointer to the first unsigned char in the array pointed to by pac,
> and it represents the address of c.
>

pac does not point to an array of unsigned char (even assuming the use of
std::launder) because such an array does not exist, unless it has
previously been caused to exist.

Per (5), (6) & (7), pa defined via
>
> auto pa =3D reinterpret_cast<unsigned char*>(&c.a);
>
> is a pointer representing address X of the first byte of c.a.
>
> Per (0) & (1), X is an address of a byte somewhere in the storage occupie=
d
> by the array pointed to by pac. There must therefore be an unsigned char =
in
> the array pointed to by pac, with address X. Assume the latter is not tru=
e,
> then, per (8), there is exactly one byte per any unsigned character,
> therefore the byte at address X does not correspond to any byte
> representing any unsigned char in the array pointed by pac, which
> contradicts either (1) or (4). Therefore, an unsigned char in the array
> pointed to by pac exists at address X. Per (2), pa, representing address =
X,
> points to an unsigned char in the array pointed to by pac.
>
> Therefore, pc and pa are both pointers to unsigned chars in the array
> pointed to by pac.
>
> Per (2), we should achieve the same if pc is defined directly via
>
> auto pc =3D reinterpret_cast<unsigned char*>(&c);
>

This would all be fine if such an array of unsigned char were guaranteed to
exist. There is no such guarantee.

--=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/CAJnLdOZSbAV%2BwSJ9ag7k%3D53E18%3DVWNhx2vX5srZpM=
yHuF%3D8-og%40mail.gmail.com.

--001a1144831ee9897a053af957be
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 F=
ri, Aug 26, 2016 at 1:42 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">On Sat, Aug 20, 2016 at 11:26 AM, D. B. <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:db0451@gmail.com" target=3D"_blank">db0=
451@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; I get all t=
he points about different types of pointers, memory regions, etc. - which a=
re valid counterarguments for totally arbitrary subtractions. But I don&#39=
;t don&#39;t grasp why such caveats should disallow (in fact: don&#39;t log=
ically allow) arithmetic within the same (trivially copyable/standard layou=
t) object.. Such an object must occupy a single, known region of storage. J=
ust as is true for arrays.</div><div><br></div><div>Let me try again.</div>=
<div><br></div><div>(0)=C2=A0[intro.memory]/1 &quot;Every
byte has a unique address.&quot;</div><div><br></div><div>(1) [intro.object=
]/5 &quot;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div><br></=
div><div><span style=3D"font-size:12.8px">(2) [basic.compound]/3 &quot;</sp=
an>If an object of type T is located at an address A, a pointer of type cv =
T* whose value is the address A is said to point to that object,=C2=A0regar=
dless of how the value was obtained.<span style=3D"font-size:12.8px">&quot;=
</span></div></div></div></div></blockquote><div><br></div><div>Not since P=
0137R1. But I&#39;ll assume that you&#39;re either working within C++14 as =
written (although no implementation conforms to that as written) or are ins=
erting calls to std::launder where required.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><div><span style=3D"font-size:12.8px"></span></div><div>(3) [basic.typ=
es]/9 &quot;Scalar types, standard-layout class types (Clause 9), arrays of=
 such types and
cv-qualified versions of these types (3.9.3) are collectively called standa=
rd-layout types.&quot;<br></div><div><br></div><div>(4) [basic.align]/6 &qu=
ot;Furthermore,
the narrow character types (3.9.1) shall have the weakest alignment require=
ment.&quot;<br></div><div><br></div><div>(5) [conv.ptr]/2 &quot;A prvalue o=
f type =E2=80=9Cpointer to cv T=E2=80=9D, where T is an object type, can be=
 converted to a prvalue of type =E2=80=9Cpointer
to cv void=E2=80=9D. The result of converting a non-null pointer value of a=
 pointer to object type to a =E2=80=9Cpointer to cv
void=E2=80=9D represents the address of the same byte in memory as the orig=
inal pointer value&quot;<br></div><div><br></div><div><div>(6) [expr.static=
..cast]/13 &quot;A prvalue of type =E2=80=9Cpointer to cv1 void=E2=80=9D can=
 be converted to a prvalue of type =E2=80=9Cpointer to cv2 T=E2=80=9D, wher=
e T is an object type and cv2 is the same cv-qualification as, or greater c=
v-qualification than, cv1. The null pointer value is converted to the null =
pointer value of the destination type. If the original pointer value repres=
ents the address A of a byte in memory and A satisfies the alignment requir=
ement of T, then the resulting pointer value represents the same address as=
 the original pointer value, that is, A&quot;<br></div><div><br></div></div=
><div>(7) [expr.reinterpret.cast]/7 &quot;An object pointer can be explicit=
ly converted to an object pointer of a different type. When a prvalue v of
object pointer type is converted to the object pointer type =E2=80=9Cpointe=
r to cv T=E2=80=9D, the result is static_cast&lt;cv T*&gt;(static_cast&lt;c=
v void*&gt;(v)).&quot;<br></div><div><br></div><div>(8)=C2=A0[expr.sizeof] =
&quot;The sizeof operator yields the number of bytes in the object represen=
tation of its operand. The operand is
either an expression, which is an unevaluated operand (Clause 5), or a pare=
nthesized type-id. The sizeof
operator shall not be applied to an expression that has function or incompl=
ete type, to the parenthesized
name of such types, or to a glvalue that designates a bit-field. sizeof(cha=
r), sizeof(signed char) and
sizeof(unsigned char) are 1.&quot;</div><div><br></div><div>Assume types A =
and C are trivially copyable or standard-layout types, type C has field a o=
f type A, which is not a bit-field.</div><div><br></div><div>Per (5), (6) &=
amp; (7), pac defined via</div><div><br></div><div>auto pac =3D reinterpret=
_cast&lt;unsigned char(*)[sizeof (C)]&gt;(&amp;c);</div><div><br></div><div=
>is a pointer representing the address of the first byte of c.</div><div><b=
r></div><div>Per (2), pc defined via<br></div><div><br></div><div>auto pc =
=3D &amp;(*pac)[0]</div><div><br></div><div>is a pointer to the first unsig=
ned char in the array pointed to by pac, and it=C2=A0represents=C2=A0the ad=
dress of c.</div></div></div></div></blockquote><div><br></div><div>pac doe=
s not point to an array of unsigned char (even assuming the use of std::lau=
nder) because such an array does not exist, unless it has previously been c=
aused to exist.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Per=C2=A0(5), (6) &am=
p; (7),=C2=A0pa defined via<br></div><div><div><br></div><div>auto pa =3D r=
einterpret_cast&lt;unsigned char*&gt;(&amp;c.a);</div><div><br></div><div>i=
s a pointer=C2=A0representing=C2=A0address X of the first byte of c.a.</div=
><div><br></div><div>Per (0) &amp; (1), X is an address of a byte somewhere=
 in the storage occupied by the array pointed to by pac. There must therefo=
re be an unsigned char in the array pointed to by pac, with address X. Assu=
me the latter is not true, then, per (8), there is exactly one byte per any=
 unsigned character, therefore the byte at address X does not correspond to=
 any byte representing any unsigned char in the array pointed by pac, which=
 contradicts either (1) or (4). Therefore, an unsigned char in the array po=
inted to by pac exists at address X. Per (2), pa, representing address X, p=
oints to an unsigned char in the array pointed to by pac.</div><div><br></d=
iv><div>Therefore, pc and pa are both pointers to unsigned chars in the arr=
ay pointed to by pac.<br></div><div><br></div></div><div><div>Per (2), we s=
hould achieve the same if pc is defined directly via</div><div><br></div><d=
iv>auto pc =3D reinterpret_cast&lt;unsigned char*&gt;(&amp;c);</div></div><=
/div></div></div></blockquote><div><br></div><div>This would all be fine if=
 such an array of unsigned char were guaranteed to exist. There is no such =
guarantee.</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&quot; 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/CAJnLdOZSbAV%2BwSJ9ag7k%3D53E18%3DVWN=
hx2vX5srZpMyHuF%3D8-og%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZS=
bAV%2BwSJ9ag7k%3D53E18%3DVWNhx2vX5srZpMyHuF%3D8-og%40mail.gmail.com</a>.<br=
 />

--001a1144831ee9897a053af957be--

.

--001a114065c00e623c053af97053
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 26, 2016 at 3:07 PM, D. B. <db0451@gmail.com> wrote:

> So you think that doing &c.a - &c is defined behaviour, via these rules?
I know you originally said this (but in much less detail :-) but got the
impression from some of your later messages that you had changed your
mind/interpretation.

Indeed I got carried away chasing my own far pointer red herring.

> Am I correct that you no longer think the 2nd paragraph is a barrier to
this subtraction being defined, considering the steps you've shown?

The paragraph is partially correct, because formally you do get pointers to
formally different arrays. What I was missing when I wrote that was (2)
from my previous email, which is a very strong constraint on the weirdness
pointers may have.

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/CAA7YVg3Pvzev0gNkRirMYFeHv7%3DQ9OENgfMrfaqs5KD_N2FPdg%40mail.gmail.com.

--001a114065c00e623c053af97053
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 F=
ri, Aug 26, 2016 at 3:07 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; So you think that doing &amp;c.a - &amp;c is de=
fined behaviour, via these rules? I know you originally said this (but in m=
uch less detail :-) but got the impression from some of your later messages=
 that you had changed your mind/interpretation.</div><div><br></div><div>In=
deed I got carried away chasing my own far pointer red herring.</div><div><=
br></div><div>&gt; Am I correct that you no longer think the 2nd paragraph =
is a barrier to this subtraction being defined, considering the steps you&#=
39;ve shown?</div><div><br></div><div>The paragraph is partially correct, b=
ecause formally you do get pointers to formally different arrays. What I wa=
s missing when I wrote that was (2) from my previous email, which is a very=
 strong constraint on the weirdness pointers may have.</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&quot; 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/CAA7YVg3Pvzev0gNkRirMYFeHv7%3DQ9OENgf=
Mrfaqs5KD_N2FPdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3Pvzev0g=
NkRirMYFeHv7%3DQ9OENgfMrfaqs5KD_N2FPdg%40mail.gmail.com</a>.<br />

--001a114065c00e623c053af97053--

.

--001a114065c0fe9d00053af98e57
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 26, 2016 at 3:17 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Not since P0137R1. But I'll assume that you're either working within
C++14 as written (although no implementation conforms to that as written)
or are inserting calls to std::launder where required.

I'll look into those details and will probably have something to say later.

> pac does not point to an array of unsigned char (even assuming the use of
std::launder) because such an array does not exist, unless it has
previously been caused to exist.

I do not understand what you mean by this. Or, more precisely, what you
mean by "exists". We are talking about storage within its duration;
alignment requirements for narrow chars are met per (4); an array of narrow
chars has vacuous initialisation; per [basic.life]/1, the lifetime of an
array of narrow chars within that storage has begun. How is that different
from "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/CAA7YVg33nFkhWm6Hupe5jg3rS91BZndhbJeSmHiseJNnZLQ6pg%40mail.gmail.com.

--001a114065c0fe9d00053af98e57
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 F=
ri, Aug 26, 2016 at 3:17 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><div><br></div><div>&gt; Not since P0137R1. But I&#39;ll assume that you&=
#39;re either working within C++14 as written (although no implementation c=
onforms to that as written) or are inserting calls to std::launder where re=
quired.</div><div><br></div><div>I&#39;ll look into those details and will =
probably have something to say later.</div><div><br></div><div>&gt; pac doe=
s not point to an array of unsigned char (even assuming the use of std::lau=
nder) because such an array does not exist, unless it has previously been c=
aused to exist.</div><div><br></div><div>I do not understand what you mean =
by this. Or, more precisely, what you mean by &quot;exists&quot;. We are ta=
lking about storage within its duration; alignment requirements for narrow =
chars are met per (4); an array of narrow chars has vacuous initialisation;=
 per [basic.life]/1, the lifetime of an array of narrow chars within that s=
torage has begun. How is that different from &quot;exists&quot;?</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&quot; 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/CAA7YVg33nFkhWm6Hupe5jg3rS91BZndhbJeS=
mHiseJNnZLQ6pg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg33nFkhWm6H=
upe5jg3rS91BZndhbJeSmHiseJNnZLQ6pg%40mail.gmail.com</a>.<br />

--001a114065c0fe9d00053af98e57--

.

--001a1146ed6e4e9c24053afa5c78
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 26, 2016 at 2:33 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 3:17 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > Not since P0137R1. But I'll assume that you're either working within
> C++14 as written (although no implementation conforms to that as written)
> or are inserting calls to std::launder where required.
>
> I'll look into those details and will probably have something to say later.
>
> > pac does not point to an array of unsigned char (even assuming the use
> of std::launder) because such an array does not exist, unless it has
> previously been caused to exist.
>
> I do not understand what you mean by this. Or, more precisely, what you
> mean by "exists". We are talking about storage within its duration;
> alignment requirements for narrow chars are met per (4); an array of narrow
> chars has vacuous initialisation; per [basic.life]/1, the lifetime of an
> array of narrow chars within that storage has begun. How is that different
> from "exists"?
>

Until you've read P0137R1 (and, unless you're smarter than me, reread it
multiple times) what I have to say here will be surprising, so please bear
that in mind. Per [intro.object]/1 and the associated drafting note, an
array of N unsigned char is *not* created when you obtain storage for an
object type T, sizeof(T) == N. This qualifies [basic.life]/1, since if an
object is not created, its lifetime cannot begin even though appropriate
storage has been obtained.

I can't find the conversation where this was discussed, but the gist was
that we need to preclude any possibility that merely obtaining storage
(i.e. malloc) causes a panoply of trivial objects to flash into existence
at that memory location, while still allowing the use of that storage as an
lvalue (i.e. `*(int*)malloc(sizeof(int)) = 42`).

--
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/CAJnLdOY7nfAV29d187iFCVdds%2BgGiLCV%2B-5x3SQSOyjPU_bAkw%40mail.gmail.com.

--001a1146ed6e4e9c24053afa5c78
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 F=
ri, Aug 26, 2016 at 2:33 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">On Fri, Aug 26, 2016 at 3:17 PM, &#39;Edward=
 Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;=
<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals=
@isocpp.org</a>&gt;</span> wrote:<br><div><br></div><div>&gt; Not since P01=
37R1. But I&#39;ll assume that you&#39;re either working within C++14 as wr=
itten (although no implementation conforms to that as written) or are inser=
ting calls to std::launder where required.</div><div><br></div><div>I&#39;l=
l look into those details and will probably have something to say later.</d=
iv><div><br></div><div>&gt; pac does not point to an array of unsigned char=
 (even assuming the use of std::launder) because such an array does not exi=
st, unless it has previously been caused to exist.</div><div><br></div><div=
>I do not understand what you mean by this. Or, more precisely, what you me=
an by &quot;exists&quot;. We are talking about storage within its duration;=
 alignment requirements for narrow chars are met per (4); an array of narro=
w chars has vacuous initialisation; per [basic.life]/1, the lifetime of an =
array of narrow chars within that storage has begun. How is that different =
from &quot;exists&quot;?</div></div></div></div></blockquote><div><br></div=
><div>Until you&#39;ve read P0137R1 (and, unless you&#39;re smarter than me=
, reread it multiple times) what I have to say here will be surprising, so =
please bear that in mind. Per [intro.object]/1 and the associated drafting =
note, an array of N unsigned char is *not* created when you obtain storage =
for an object type T, sizeof(T) =3D=3D N. This qualifies [basic.life]/1, si=
nce if an object is not created, its lifetime cannot begin even though appr=
opriate storage has been obtained.</div><div><br></div><div>I can&#39;t fin=
d the conversation where this was discussed, but the gist was that we need =
to preclude any possibility that merely obtaining storage (i.e. malloc) cau=
ses a panoply of trivial objects to flash into existence at that memory loc=
ation, while still allowing the use of that storage as an lvalue (i.e. `*(i=
nt*)malloc(sizeof(int)) =3D 42`).</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&quot; 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/CAJnLdOY7nfAV29d187iFCVdds%2BgGiLCV%2=
B-5x3SQSOyjPU_bAkw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOY7nfAV=
29d187iFCVdds%2BgGiLCV%2B-5x3SQSOyjPU_bAkw%40mail.gmail.com</a>.<br />

--001a1146ed6e4e9c24053afa5c78--

.

--001a11410242d4d8d4053afc4d6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2016 at 4:30 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Until you've read P0137R1 (and, unless you're smarter than me, reread it
multiple times) what I have to say here will be surprising, so please bear
that in mind. Per [intro.object]/1 and the associated drafting note, an
array of N unsigned char is *not* created when you obtain storage for an
object type T, sizeof(T) =3D=3D N. This qualifies [basic.life]/1, since if =
an
object is not created, its lifetime cannot begin even though appropriate
storage has been obtained.

The current standard says there "An object is a region of storage", so
creating an object means "creating a region of storage", it does not mean
creating a "type", which suggests that the type is subject to
interpretation of the storage. The interpretation is reinforced by
[expr.reinterpret.cast]/11, which says: "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, but with the specified type. [...] No temporary is created, no
copy is made, and constructors (12.1) or conversion functions (12.3) are
not called."

Observe that with the current definition "object is storage", there is no
contradiction, because we can meaningfully speak of "same object, different
type". This is why pac in my previous messages exists (in the current
standard) even though it was not created as an object of an array type.

P0137R1 changes that to "An object *occupies* a region of storage...", and
it is not clear what "creates" means. We do not know what an object
*is. *That's
a pretty big defect, I'd say. This creates a problem with
[expr.reinterpret.cast]/11 cited above, because it is impossible to say
what it means and whether it really means anything.

Note finally that in C the notion of the object is consistent with the
current C++:

3.15

1 object
region of data storage in the execution environment, the contents of which
can represent values

2 NOTE When referenced, an object may be interpreted as having a particular
type; see 6.3.2.1.

(end)

It says very clearly that the type is an interpretation (I wish we had the
same clarity in C++). Given that standard-layout types are for
compatibility with C and other languages, I do not see how P0137R1 could
change that.

I would say P0137R1 is half-baked at this point, and we cannot use it to
justify anything.

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/CAA7YVg0uSONt%2BMOoa4p933S-0H_vAvZTro00_ZHnr4ugZ=
rsV4A%40mail.gmail.com.

--001a11410242d4d8d4053afc4d6e
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 F=
ri, Aug 26, 2016 at 4:30 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><div><br></div><div>&gt; Until you&#39;ve read P0137R1 (and, unless you&#=
39;re smarter than me, reread it multiple times) what I have to say here wi=
ll be surprising, so please bear that in mind. Per [intro.object]/1 and the=
 associated drafting note, an array of N unsigned char is *not* created whe=
n you obtain storage for an object type T, sizeof(T) =3D=3D N. This qualifi=
es [basic.life]/1, since if an object is not created, its lifetime cannot b=
egin even though appropriate storage has been obtained.</div><div><br></div=
><div>The current standard says there &quot;An object is a
region of storage&quot;, so creating an object means &quot;creating a regio=
n of storage&quot;, it does not mean creating a &quot;type&quot;, which sug=
gests that the type is subject to interpretation of the storage. The interp=
retation is reinforced by [expr.reinterpret.cast]/11, which says: &quot;A g=
lvalue 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 r=
einterpret_cast. The result refers to=C2=A0the same object as the source gl=
value, but with the specified type. [...] No temporary is created, no copy =
is made, and constructors (12.1) or conversion functions (12.3) are not cal=
led.&quot;<br></div><div><br></div><div><div>Observe that with the current =
definition &quot;object is storage&quot;, there is no contradiction, becaus=
e we can meaningfully speak of &quot;same object, different type&quot;. Thi=
s is why pac in my previous messages exists (in the current standard) even =
though it was not created as an object of an array type.=C2=A0</div></div><=
div><br></div><div>P0137R1 changes that to &quot;An object <i>occupies</i> =
a region of storage...&quot;, and it is not clear what &quot;creates&quot; =
means. We do not know what an object <i>is. </i>That&#39;s a pretty big def=
ect, I&#39;d say.=C2=A0This=C2=A0creates a problem with [expr.reinterpret.c=
ast]/11 cited above, because it is impossible to say what it means and whet=
her it really means anything.</div><div><br></div><div>Note finally that in=
 C the notion of the object is consistent with the current C++:</div><div><=
br></div><div>3.15</div><div><br></div><div>1 object</div><div>region of da=
ta storage in the execution environment, the contents of which can represen=
t
values</div><div><br></div><div>2 NOTE When referenced, an object may be in=
terpreted as having a particular type; see 6.3.2.1.<br></div><div><br></div=
><div>(end)</div><div><br></div><div>It says very clearly that the type is =
an interpretation (I wish we had the same clarity in C++). Given that stand=
ard-layout types are for compatibility with C and other languages, I do not=
 see how P0137R1 could change that.</div><div><br></div><div>I would say P0=
137R1 is half-baked at this point, and we cannot use it to justify anything=
..</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&quot; 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/CAA7YVg0uSONt%2BMOoa4p933S-0H_vAvZTro=
00_ZHnr4ugZrsV4A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0uSONt%2=
BMOoa4p933S-0H_vAvZTro00_ZHnr4ugZrsV4A%40mail.gmail.com</a>.<br />

--001a11410242d4d8d4053afc4d6e--

.

--047d7bf0dbf045300b053afc68bf
Content-Type: text/plain; charset=UTF-8

I'll simply say thank you to both of you for continuing to ponder and
debate this! It makes for intriguing reading about something I'm interested
in, and raises some interesting questions about definitions and concepts in
the Standard. Perhaps those questions can even lead to clearer Standardese
some day, one way or another...

For now, I'll just take some time to process the last few messages and
whatever you write next... at least until/if I can think of any useful
input. :-)

Cheers!

--
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/CACGiwhFTmY2W7FCFRGz%3Dojf%3DxTLGuUgnJqm1GgkwSOmdXCnGfg%40mail.gmail.com.

--047d7bf0dbf045300b053afc68bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;ll simply say thank you to both of you for cont=
inuing to ponder and debate this! It makes for intriguing reading about som=
ething I&#39;m interested in, and raises some interesting questions about d=
efinitions and concepts in the Standard. Perhaps those questions can even l=
ead to clearer Standardese some day, one way or another...<br><br></div><di=
v>For now, I&#39;ll just take some time to process the last few messages an=
d whatever you write next... at least until/if I can think of any useful in=
put. :-)<br><br></div><div>Cheers!<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&quot; 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/CACGiwhFTmY2W7FCFRGz%3Dojf%3DxTLGuUgn=
Jqm1GgkwSOmdXCnGfg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFTmY2W=
7FCFRGz%3Dojf%3DxTLGuUgnJqm1GgkwSOmdXCnGfg%40mail.gmail.com</a>.<br />

--047d7bf0dbf045300b053afc68bf--

.

--047d7b66fcc380426e053afcd628
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2016 at 6:49 PM Viacheslav Usov <via.usov@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 4:30 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > Until you've read P0137R1 (and, unless you're smarter than me, reread i=
t
> multiple times) what I have to say here will be surprising, so please bea=
r
> that in mind. Per [intro.object]/1 and the associated drafting note, an
> array of N unsigned char is *not* created when you obtain storage for an
> object type T, sizeof(T) =3D=3D N. This qualifies [basic.life]/1, since i=
f an
> object is not created, its lifetime cannot begin even though appropriate
> storage has been obtained.
>
> The current standard says there "An object is a region of storage", so
> creating an object means "creating a region of storage", it does not mean
> creating a "type", which suggests that the type is subject to
> interpretation of the storage. The interpretation is reinforced by
> [expr.reinterpret.cast]/11, which says: "A glvalue expression of type T1
> can be cast to the type =E2=80=9Creference to T2=E2=80=9D if an expressio=
n of type =E2=80=9Cpointer
> to T1=E2=80=9D can be explicitly converted to the type =E2=80=9Cpointer t=
o T2=E2=80=9D using a
> reinterpret_cast. The result refers to the same object as the source
> glvalue, but with the specified type. [...] No temporary is created, no
> copy is made, and constructors (12.1) or conversion functions (12.3) are
> not called."
>
> Observe that with the current definition "object is storage", there is no
> contradiction, because we can meaningfully speak of "same object, differe=
nt
> type". This is why pac in my previous messages exists (in the current
> standard) even though it was not created as an object of an array type.
>
> P0137R1 changes that to "An object *occupies* a region of storage...",
> and it is not clear what "creates" means. We do not know what an object *=
is.
> *That's a pretty big defect, I'd say. This creates a problem with
> [expr.reinterpret.cast]/11 cited above, because it is impossible to say
> what it means and whether it really means anything.
>

No, the change is (and this entire thing is the definition, not just the
sentence that was there and is now in the middle of it):

An *object* is created by a *definition* (3.1), by a *new-expression* (5.3.=
4),
when implicitly changing the active member of a union ([class.union]), or
when a temporary object is created ([conv.rval], [class.temporary]). An
*object* isobject occupies a region of storage in its period of
construction (12.7 class.cdtor), throughout its lifetime (3.8 basic.life),
and in its period of destruction (12.7 class.cdtor).

The intent here is to describe what an object is, instead of giving a
straight definition, because I honestly can't say how to word this in a way
that'd give you a straight definition and not a description of what are the
properties of an object.

Furthermore, it clearly states that objects are *created* (that'd be the
word using the *English* definition of it, I imagine) by a number of
language constructs that are listed there, which defines what "create an
object" means (it means "use one of those language constructs).

Also I don't believe there's any problem with the wording w.r.t.
[expr.reinterpret.cast]/11. That paragraph keeps meaning the exact same
thing as before. The only thing that changes is when the objects comes into
existence and when it stops being an object.


>
> Note finally that in C the notion of the object is consistent with the
> current C++:
>
> 3.15
>
> 1 object
> region of data storage in the execution environment, the contents of whic=
h
> can represent values
>
> 2 NOTE When referenced, an object may be interpreted as having a
> particular type; see 6.3.2.1.
>
> (end)
>
> It says very clearly that the type is an interpretation (I wish we had th=
e
> same clarity in C++). Given that standard-layout types are for
> compatibility with C and other languages, I do not see how P0137R1 could
> change that.
>

I do not believe there's any problem with that. The C++ standard will
specify how it works on the C++ side, other sides are unaffected, though
someone more versed with how a program with two different abstract machines
is supposed to work (...and this would be the CWG, which has been reviewing
this paper for what I believe is 3 last meetings).


> I would say P0137R1 is half-baked at this point, and we cannot use it to
> justify anything.
>

Whether you consider it half-baked or not, it's a part of the working draft
now, it's in the CD ballot, and then unless a NB comment removes it, it'll
be in the next ballot and then in the international standard ISO 14882:2017
(...assuming we arrive on time...), so this is exactly the point where we
start using it to explain how the language is going to work since C++17.

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/CAA7YVg0uSON=
t%2BMOoa4p933S-0H_vAvZTro00_ZHnr4ugZrsV4A%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0uSO=
Nt%2BMOoa4p933S-0H_vAvZTro00_ZHnr4ugZrsV4A%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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/CAPCFJdRcC%2Bv_%2BwnCDrrbs4rUcXFVkqep1jHe-R3iQ97=
SzUBLOA%40mail.gmail.com.

--047d7b66fcc380426e053afcd628
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Au=
g 26, 2016 at 6:49 PM Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.=
com">via.usov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Fri, Aug 26, 2016 at 4:30 PM, &#39;Edward Catmur&#39; via ISO C++ Standa=
rd - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals=
@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrot=
e:<br><div><br></div><div>&gt; Until you&#39;ve read P0137R1 (and, unless y=
ou&#39;re smarter than me, reread it multiple times) what I have to say her=
e will be surprising, so please bear that in mind. Per [intro.object]/1 and=
 the associated drafting note, an array of N unsigned char is *not* created=
 when you obtain storage for an object type T, sizeof(T) =3D=3D N. This qua=
lifies [basic.life]/1, since if an object is not created, its lifetime cann=
ot begin even though appropriate storage has been obtained.</div><div><br><=
/div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div>The current standard says there &quot;An object is =
a
region of storage&quot;, so creating an object means &quot;creating a regio=
n of storage&quot;, it does not mean creating a &quot;type&quot;, which sug=
gests that the type is subject to interpretation of the storage. The interp=
retation is reinforced by [expr.reinterpret.cast]/11, which says: &quot;A g=
lvalue 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 r=
einterpret_cast. The result refers to=C2=A0the same object as the source gl=
value, but with the specified type. [...] No temporary is created, no copy =
is made, and constructors (12.1) or conversion functions (12.3) are not cal=
led.&quot;<br></div><div><br></div><div><div>Observe that with the current =
definition &quot;object is storage&quot;, there is no contradiction, becaus=
e we can meaningfully speak of &quot;same object, different type&quot;. Thi=
s is why pac in my previous messages exists (in the current standard) even =
though it was not created as an object of an array type.=C2=A0</div></div><=
div><br></div><div>P0137R1 changes that to &quot;An object <i>occupies</i> =
a region of storage...&quot;, and it is not clear what &quot;creates&quot; =
means. We do not know what an object <i>is. </i>That&#39;s a pretty big def=
ect, I&#39;d say.=C2=A0This=C2=A0creates a problem with [expr.reinterpret.c=
ast]/11 cited above, because it is impossible to say what it means and whet=
her it really means anything.</div></div></div></div></blockquote><div><br>=
</div><div>No, the change is (and this entire thing is the definition, not =
just the sentence that was there and is now in the middle of it):</div><div=
><br></div><div><ins style=3D"text-decoration:none;font-weight:bold;font-fa=
mily:&quot;times new roman&quot;;font-size:medium;line-height:normal;backgr=
ound-color:rgb(160,255,160)">An<span class=3D"inbox-inbox-Apple-converted-s=
pace">=C2=A0</span><em>object</em><span class=3D"inbox-inbox-Apple-converte=
d-space">=C2=A0</span>is created by a<span class=3D"inbox-inbox-Apple-conve=
rted-space">=C2=A0</span><em>definition</em><span class=3D"inbox-inbox-Appl=
e-converted-space">=C2=A0</span>(3.1), by a<span class=3D"inbox-inbox-Apple=
-converted-space">=C2=A0</span><em>new-expression</em><span class=3D"inbox-=
inbox-Apple-converted-space">=C2=A0</span>(5.3.4), when implicitly changing=
 the active member of a union ([class.union]), or when a temporary object i=
s created ([conv.rval], [class.temporary]).<span class=3D"inbox-inbox-Apple=
-converted-space">=C2=A0</span></ins><span style=3D"font-family:&quot;times=
 new roman&quot;;font-size:medium;line-height:normal;background-color:rgb(2=
41,241,241)">An<span class=3D"inbox-inbox-Apple-converted-space">=C2=A0</sp=
an></span><del style=3D"font-family:&quot;times new roman&quot;;font-size:m=
edium;line-height:normal;background-color:rgb(255,160,160)"><em>object</em>=
<span class=3D"inbox-inbox-Apple-converted-space">=C2=A0</span>is</del><ins=
 style=3D"text-decoration:none;font-weight:bold;font-family:&quot;times new=
 roman&quot;;font-size:medium;line-height:normal;background-color:rgb(160,2=
55,160)">object occupies</ins><span style=3D"font-family:&quot;times new ro=
man&quot;;font-size:medium;line-height:normal;background-color:rgb(241,241,=
241)"><span class=3D"inbox-inbox-Apple-converted-space">=C2=A0</span>a regi=
on of storage<span class=3D"inbox-inbox-Apple-converted-space">=C2=A0</span=
></span><ins style=3D"text-decoration:none;font-weight:bold;font-family:&qu=
ot;times new roman&quot;;font-size:medium;line-height:normal;background-col=
or:rgb(160,255,160)">in its period of construction (12.7 class.cdtor), thro=
ughout its lifetime (3.8 basic.life), and in its period of destruction (12.=
7 class.cdtor)</ins><span style=3D"font-family:&quot;times new roman&quot;;=
font-size:medium;line-height:normal;background-color:rgb(241,241,241)">.</s=
pan><br></div><div><br></div><div>The intent here is to describe what an ob=
ject is, instead of giving a straight definition, because I honestly can&#3=
9;t say how to word this in a way that&#39;d give you a straight definition=
 and not a description of what are the properties of an object.</div><div><=
br></div><div>Furthermore, it clearly states that objects are <i>created</i=
>=C2=A0(that&#39;d be the word using the <i>English</i>=C2=A0definition of =
it, I imagine) by a number of language constructs that are listed there, wh=
ich defines what &quot;create an object&quot; means (it means &quot;use one=
 of those language constructs).</div><div><br></div><div>Also I don&#39;t b=
elieve there&#39;s any problem with the wording w.r.t. [expr.reinterpret.ca=
st]/11. That paragraph keeps meaning the exact same thing as before. The on=
ly thing that changes is when the objects comes into existence and when it =
stops being an object.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><di=
v><br></div><div>Note finally that in C the notion of the object is consist=
ent with the current C++:</div><div><br></div><div>3.15</div><div><br></div=
><div>1 object</div><div>region of data storage in the execution environmen=
t, the contents of which can represent
values</div><div><br></div><div>2 NOTE When referenced, an object may be in=
terpreted as having a particular type; see 6.3.2.1.<br></div><div><br></div=
><div>(end)</div><div><br></div><div>It says very clearly that the type is =
an interpretation (I wish we had the same clarity in C++). Given that stand=
ard-layout types are for compatibility with C and other languages, I do not=
 see how P0137R1 could change that.</div></div></div></div></blockquote><di=
v><br></div><div>I do not believe there&#39;s any problem with that. The C+=
+ standard will specify how it works on the C++ side, other sides are unaff=
ected, though someone more versed with how a program with two different abs=
tract machines is supposed to work (...and this would be the CWG, which has=
 been reviewing this paper for what I believe is 3 last meetings).</div><di=
v>=C2=A0</div><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 class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div></div><div>I would say P0137R=
1 is half-baked at this point, and we cannot use it to justify anything.</d=
iv></div></div></div></blockquote><div><br></div><div>Whether you consider =
it half-baked or not, it&#39;s a part of the working draft now, it&#39;s in=
 the CD ballot, and then unless a NB comment removes it, it&#39;ll be in th=
e next ballot and then in the international standard ISO 14882:2017 (...ass=
uming we arrive on time...), so this is exactly the point where we start us=
ing it to explain how the language is going to work since C++17.=C2=A0</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>Cheers,</div><d=
iv>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&quot; 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">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">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/CAA7YVg0uSONt%2BMOoa4p933S-0H_vAvZTro=
00_ZHnr4ugZrsV4A%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAA7YVg0uSONt%2BMOoa4p933S-0H_vAvZTro00_ZHnr4ugZrsV4A%40mail.gmail.c=
om</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&quot; 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/CAPCFJdRcC%2Bv_%2BwnCDrrbs4rUcXFVkqep=
1jHe-R3iQ97SzUBLOA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRcC%2B=
v_%2BwnCDrrbs4rUcXFVkqep1jHe-R3iQ97SzUBLOA%40mail.gmail.com</a>.<br />

--047d7b66fcc380426e053afcd628--

.

------=_Part_3193_1998183508.1472245134014
Content-Type: multipart/alternative;
 boundary="----=_Part_3194_1616687636.1472245134014"

------=_Part_3194_1616687636.1472245134014
Content-Type: text/plain; charset=UTF-8

On Friday, August 26, 2016 at 6:18:01 AM UTC-7, Edward Catmur wrote:
>
> On Fri, Aug 26, 2016 at 1:42 PM, Viacheslav Usov <via....@gmail.com
> <javascript:>> wrote:
>
>> On Sat, Aug 20, 2016 at 11:26 AM, D. B. <db0...@gmail.com <javascript:>>
>> wrote:
>>
>> > I get all the points about different types of pointers, memory regions,
>> etc. - which are valid counterarguments for totally arbitrary subtractions.
>> But I don't don't grasp why such caveats should disallow (in fact: don't
>> logically allow) arithmetic within the same (trivially copyable/standard
>> layout) object.. Such an object must occupy a single, known region of
>> storage. Just as is true for arrays.
>>
>> Let me try again.
>>
>> (0) [intro.memory]/1 "Every byte has a unique address."
>>
>> (1) [intro.object]/5 "An object of trivially copyable or standard-layout
>> type (3.9) shall occupy contiguous bytes of storage."
>>
>> (2) [basic.compound]/3 "If an object of type T is located at an address
>> A, a pointer of type cv T* whose value is the address A is said to point to
>> that object, regardless of how the value was obtained."
>>
>
> Not since P0137R1. But I'll assume that you're either working within C++14
> as written (although no implementation conforms to that as written) or are
> inserting calls to std::launder where required.
>
>
P0137R1 horribly breaks the language in ways that will bite people later.

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/73160ad3-ee21-473d-8362-f39203217f7f%40isocpp.org.

------=_Part_3194_1616687636.1472245134014
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, August 26, 2016 at 6:18:01 AM UTC-7, Edward Cat=
mur 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"><di=
v><div class=3D"gmail_quote">On Fri, Aug 26, 2016 at 1:42 PM, Viacheslav Us=
ov <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"rYmHkcjZEAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">via....@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Aug 20, 2016 =
at 11:26 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"rYmHkcjZEAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">db0...@gmail.com</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; I get all the points about different types of p=
ointers, memory regions, etc. - which are valid counterarguments for totall=
y arbitrary subtractions. But I don&#39;t don&#39;t grasp why such caveats =
should disallow (in fact: don&#39;t logically allow) arithmetic within the =
same (trivially copyable/standard layout) object.. Such an object must occu=
py a single, known region of storage. Just as is true for arrays.</div><div=
><br></div><div>Let me try again.</div><div><br></div><div>(0)=C2=A0[intro.=
memory]/1 &quot;Every
byte has a unique address.&quot;</div><div><br></div><div>(1) [intro.object=
]/5 &quot;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div><br></=
div><div><span style=3D"font-size:12.8px">(2) [basic.compound]/3 &quot;</sp=
an>If an object of type T is located at an address A, a pointer of type cv =
T* whose value is the address A is said to point to that object,=C2=A0regar=
dless of how the value was obtained.<span style=3D"font-size:12.8px">&quot;=
</span></div></div></div></div></blockquote><div><br></div><div>Not since P=
0137R1. But I&#39;ll assume that you&#39;re either working within C++14 as =
written (although no implementation conforms to that as written) or are ins=
erting calls to std::launder where required.</div><br></div></div></div></b=
lockquote><div><br>P0137R1 horribly breaks the language in ways that will b=
ite people later.<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&quot; 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/73160ad3-ee21-473d-8362-f39203217f7f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73160ad3-ee21-473d-8362-f39203217f7f=
%40isocpp.org</a>.<br />

------=_Part_3194_1616687636.1472245134014--

------=_Part_3193_1998183508.1472245134014--

.

--047d7bfcf2f6277013053b0024d2
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 26, 2016 at 10:58 PM Myriachan <myriachan@gmail.com> wrote:

> On Friday, August 26, 2016 at 6:18:01 AM UTC-7, Edward Catmur wrote:
>>
>> On Fri, Aug 26, 2016 at 1:42 PM, Viacheslav Usov <via....@gmail.com>
>> wrote:
>>
>
>> On Sat, Aug 20, 2016 at 11:26 AM, D. B. <db0...@gmail.com> wrote:
>>>
>>> > I get all the points about different types of pointers, memory
>>> regions, etc. - which are valid counterarguments for totally arbitrary
>>> subtractions. But I don't don't grasp why such caveats should disallow (in
>>> fact: don't logically allow) arithmetic within the same (trivially
>>> copyable/standard layout) object.. Such an object must occupy a single,
>>> known region of storage. Just as is true for arrays.
>>>
>>> Let me try again.
>>>
>>> (0) [intro.memory]/1 "Every byte has a unique address."
>>>
>>> (1) [intro.object]/5 "An object of trivially copyable or standard-layout
>>> type (3.9) shall occupy contiguous bytes of storage."
>>>
>>> (2) [basic.compound]/3 "If an object of type T is located at an address
>>> A, a pointer of type cv T* whose value is the address A is said to point to
>>> that object, regardless of how the value was obtained."
>>>
>>
>> Not since P0137R1. But I'll assume that you're either working within
>> C++14 as written (although no implementation conforms to that as written)
>> or are inserting calls to std::launder where required.
>>
>>
> P0137R1 horribly breaks the language in ways that will bite people later.
>
> Melissa
>

Well then, please do write a paper about it, submit it to a mailing and get
a NB to consider it as a NB commet for the current ballot. I'm assuming
you're talking as someone having some examples of how it'll bite us, and
not just saying so because of some sort of intuition? :)

--
> 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/73160ad3-ee21-473d-8362-f39203217f7f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73160ad3-ee21-473d-8362-f39203217f7f%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/CAPCFJdQj-FxcJidJUzzhFN99xNX6kS7udwCfFj%3Doph8Xj3HgkQ%40mail.gmail.com.

--047d7bfcf2f6277013053b0024d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Aug 26=
, 2016 at 10:58 PM Myriachan &lt;<a href=3D"mailto:myriachan@gmail.com">myr=
iachan@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">On Friday, August 26, 2016 at 6:18:01 AM UTC-7, Edward Catmur=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote">On Fri, Aug 26, 2016 at 1:42 PM, Viacheslav Usov <span=
 dir=3D"ltr">&lt;<a rel=3D"nofollow">via....@gmail.com</a>&gt;</span> wrote=
:</div></div></div></blockquote></div><div dir=3D"ltr"><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sat, Aug=
 20, 2016 at 11:26 AM, D. B. <span dir=3D"ltr">&lt;<a rel=3D"nofollow">db0.=
...@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; I get all th=
e points about different types of pointers, memory regions, etc. - which ar=
e valid counterarguments for totally arbitrary subtractions. But I don&#39;=
t don&#39;t grasp why such caveats should disallow (in fact: don&#39;t logi=
cally allow) arithmetic within the same (trivially copyable/standard layout=
) object.. Such an object must occupy a single, known region of storage. Ju=
st as is true for arrays.</div><div><br></div><div>Let me try again.</div><=
div><br></div><div>(0)=C2=A0[intro.memory]/1 &quot;Every
byte has a unique address.&quot;</div><div><br></div><div>(1) [intro.object=
]/5 &quot;An object of trivially copyable or standard-layout
type (3.9) shall occupy contiguous bytes of storage.&quot;</div><div><br></=
div><div><span style=3D"font-size:12.8px">(2) [basic.compound]/3 &quot;</sp=
an>If an object of type T is located at an address A, a pointer of type cv =
T* whose value is the address A is said to point to that object,=C2=A0regar=
dless of how the value was obtained.<span style=3D"font-size:12.8px">&quot;=
</span></div></div></div></div></blockquote><div><br></div><div>Not since P=
0137R1. But I&#39;ll assume that you&#39;re either working within C++14 as =
written (although no implementation conforms to that as written) or are ins=
erting calls to std::launder where required.</div><br></div></div></div></b=
lockquote></div><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"></div></div></div></blockquo=
te><div><br>P0137R1 horribly breaks the language in ways that will bite peo=
ple later.<br><br>Melissa<br></div></div></blockquote><div><br></div><div>W=
ell then, please do write a paper about it, submit it to a mailing and get =
a NB to consider it as a NB commet for the current ballot. I&#39;m assuming=
 you&#39;re talking as someone having some examples of how it&#39;ll bite u=
s, and not just saying so because of some sort of intuition? :)</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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">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">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/73160ad3-ee21-473d-8362-f39203217f7f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73160ad3-ee21-=
473d-8362-f39203217f7f%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&quot; 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/CAPCFJdQj-FxcJidJUzzhFN99xNX6kS7udwCf=
Fj%3Doph8Xj3HgkQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQj-FxcJi=
dJUzzhFN99xNX6kS7udwCfFj%3Doph8Xj3HgkQ%40mail.gmail.com</a>.<br />

--047d7bfcf2f6277013053b0024d2--

.

--001a114025cc45f86b053b0c21b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2016 at 7:27 PM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:

> The intent here is to describe what an object is, instead of giving a
straight definition, because I honestly can't say how to word this in a way
that'd give you a straight definition and not a description of what are the
properties of an object.

And, as I said, it fails to deliver on that intent. With the current "an
object is a region of storage", we can tell that it is essentially the same
definition as in C. We can infer that "type" is a just an interpretation,
which can be changed without affecting other interpretations. With P0137R1,
that is not clear. I do not think you said explicitly whether "type is just
an interpretation, which can be changed without affecting other
interpretations" is what you think we will have post-P0137R1, but it is
evident just from this thread that there are people who think otherwise.

> Also I don't believe there's any problem with the wording w.r.t.
[expr.reinterpret.cast]/11. That paragraph keeps meaning the exact same
thing as before. The only thing that changes is when the objects comes into
existence and when it stops being an object.

I hope that's what the authors of P0137R1 really have in mind. I hope that
we will still have objects as merely a shorthand for "a region of storage",
which we can interpret as any data type without having to "create" and
"destroy" anything when the interpretation changes. Unfortunately, the
message that P0137R1 sends to me (and other commenters) is different.

> I do not believe there's any problem with that. The C++ standard will
specify how it works on the C++ side

If the eventual outcome of P0137R1 will be compatible (for standard-layout
types) with "object is a region of storage" and "type is just an
interpretation, which can be changed without affecting other
interpretations", then this is all moot. If not, then we will have a major
problem.

> Whether you consider it half-baked or not, it's a part of the working
draft now, it's in the CD ballot, and then unless a NB comment removes it,
it'll be in the next ballot and then in the international standard ISO
14882:2017 (...assuming we arrive on time...), so this is exactly the point
where we start using it to explain how the language is going to work since
C++17.

Oh, I am pretty sure we can end up with a defective international standard.
We have seen that happen many, many times.

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/CAA7YVg0Y3On8HE05W9XS_UtJSL4YV6pMWtPYsooa5%3DALw=
M-48g%40mail.gmail.com.

--001a114025cc45f86b053b0c21b5
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 F=
ri, Aug 26, 2016 at 7:27 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt; The intent here is to descri=
be what an object is, instead of giving a straight definition, because I ho=
nestly can&#39;t say how to word this in a way that&#39;d give you a straig=
ht definition and not a description of what are the properties of an object=
..</div><div><br></div><div>And, as I said, it fails to deliver on that inte=
nt. With the current &quot;an object is a region of storage&quot;, we can t=
ell that it is essentially the same definition as in C. We can infer that &=
quot;type&quot; is a just an interpretation, which can be changed without a=
ffecting other interpretations. With=C2=A0P0137R1, that is not clear. I do =
not think you said explicitly whether &quot;type is just an interpretation,=
 which can be changed without affecting other interpretations&quot; is what=
 you think we=C2=A0will have post-P0137R1, but it is evident just from this=
 thread that there are people who think otherwise.</div><div><br></div><div=
>&gt; Also I don&#39;t believe there&#39;s any problem with the wording w.r=
..t. [expr.reinterpret.cast]/11. That paragraph keeps meaning the exact same=
 thing as before. The only thing that changes is when the objects comes int=
o existence and when it stops being an object.</div><div><br></div><div>I h=
ope that&#39;s what the authors of P0137R1 really have in mind. I hope that=
 we will still have objects as merely a shorthand for &quot;a region of sto=
rage&quot;, which we can interpret as any data type without having to &quot=
;create&quot; and &quot;destroy&quot; anything when the interpretation chan=
ges. Unfortunately, the message that P0137R1 sends to me (and other comment=
ers) is different.</div><div><br></div><div>&gt; I do not believe there&#39=
;s any problem with that. The C++ standard will specify how it works on the=
 C++ side</div><div><br></div><div>If the eventual outcome of P0137R1 will =
be compatible (for standard-layout types) with &quot;object is a region of =
storage&quot; and &quot;type is just an interpretation, which can be change=
d without affecting other interpretations&quot;, then this is all moot. If =
not, then we will have a major problem.</div><div><br></div><div>&gt; Wheth=
er you consider it half-baked or not, it&#39;s a part of the working draft =
now, it&#39;s in the CD ballot, and then unless a NB comment removes it, it=
&#39;ll be in the next ballot and then in the international standard ISO 14=
882:2017 (...assuming we arrive on time...), so this is exactly the point w=
here we start using it to explain how the language is going to work since C=
++17.=C2=A0</div><div><br></div><div>Oh, I am pretty sure we can end up wit=
h a defective international standard. We have seen that happen many, many t=
imes.</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&quot; 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/CAA7YVg0Y3On8HE05W9XS_UtJSL4YV6pMWtPY=
sooa5%3DALwM-48g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0Y3On8HE=
05W9XS_UtJSL4YV6pMWtPYsooa5%3DALwM-48g%40mail.gmail.com</a>.<br />

--001a114025cc45f86b053b0c21b5--

.

--047d7b66fcc3990637053b0ccb2f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 1:42 PM Viacheslav Usov <via.usov@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 7:27 PM, Micha=C5=82 Dominiak <griwes@griwes.info=
>
> wrote:
>
> > The intent here is to describe what an object is, instead of giving a
> straight definition, because I honestly can't say how to word this in a w=
ay
> that'd give you a straight definition and not a description of what are t=
he
> properties of an object.
>
> And, as I said, it fails to deliver on that intent. With the current "an
> object is a region of storage", we can tell that it is essentially the sa=
me
> definition as in C. We can infer that "type" is a just an interpretation,
> which can be changed without affecting other interpretations. With P0137R=
1,
> that is not clear. I do not think you said explicitly whether "type is ju=
st
> an interpretation, which can be changed without affecting other
> interpretations" is what you think we will have post-P0137R1, but it is
> evident just from this thread that there are people who think otherwise.
>
> > Also I don't believe there's any problem with the wording w.r.t.
> [expr.reinterpret.cast]/11. That paragraph keeps meaning the exact same
> thing as before. The only thing that changes is when the objects comes in=
to
> existence and when it stops being an object.
>
> I hope that's what the authors of P0137R1 really have in mind. I hope tha=
t
> we will still have objects as merely a shorthand for "a region of storage=
",
> which we can interpret as any data type without having to "create" and
> "destroy" anything when the interpretation changes. Unfortunately, the
> message that P0137R1 sends to me (and other commenters) is different.
>

The standard says this (and it has not been touched by P0137R1):

An object has a *type* ([basic.types] <http://eel.is/c++draft/basic.types>)=
..
The term *object type* refers to the type with which the object is created.

And immediately after (*still* not touched by P0137R1):

Some objects are *polymorphic* ([class.virtual]
<http://eel.is/c++draft/class.virtual>); the implementation generates
information associated with each such object that makes it possible to
determine that object's type during program execution. For other objects,
the interpretation of the values found therein is determined by the type of
the *expressions <http://eel.is/c++draft/expr.comma#expression>* (Clause
[expr] <http://eel.is/c++draft/expr>) used to access them.
Please help me understand your paragraph starting with "I hope" in the
context of this quote ([intro.object]/1). Seriously, this and your
statements seem not to ccompute.

The way I'm reading this, P0137R1 doesn't change anything w.r.t. rules of
interpreting the object types or their values, and essentially only
redefines the lifetime of an object to start when it's created and end when
it's destroyed, instead of being bound to the lifetime of its storage. I
don't see any of the problems you're talking about after this change.

To reiterate: as far as I understand this, the changes of P0137R1
essentially makes the object-storage association slightly weaker; namely,
instead of object=3Dstorage, we now have "object must have storage; storage
may have an object".

Let's wait from someone from CWG to confirm this. (I'm somewhat tempted to
CC Richard to this thread...).


> > I do not believe there's any problem with that. The C++ standard will
> specify how it works on the C++ side
>
> If the eventual outcome of P0137R1 will be compatible (for standard-layou=
t
> types) with "object is a region of storage" and "type is just an
> interpretation, which can be changed without affecting other
> interpretations", then this is all moot. If not, then we will have a majo=
r
> problem.
>
> > Whether you consider it half-baked or not, it's a part of the working
> draft now, it's in the CD ballot, and then unless a NB comment removes it=
,
> it'll be in the next ballot and then in the international standard ISO
> 14882:2017 (...assuming we arrive on time...), so this is exactly the poi=
nt
> where we start using it to explain how the language is going to work sinc=
e
> C++17.
>
> Oh, I am pretty sure we can end up with a defective international
> standard. We have seen that happen many, many times.
>

As I said before: do you believe it's a defect? *Do write a paper.* If
anybody on the committee considers it a defect too, there will be
discussion, possibly NB comments, and possibly the lack of the defect in
the standard.

Nothing will come from just writing on a mailing list.

Just keep in mind that, as far as I understand, removing this also means
that `std::optional` and `std::variant` don't *actually* work for all the
types you want them to work with.


> 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/CAA7YVg0Y3On=
8HE05W9XS_UtJSL4YV6pMWtPYsooa5%3DALwM-48g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0Y3O=
n8HE05W9XS_UtJSL4YV6pMWtPYsooa5%3DALwM-48g%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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/CAPCFJdQnT_NrKNaXfGUKkbVTF6GhYuYBkV9%3DvS6SPBHSR=
GoaYA%40mail.gmail.com.

--047d7b66fcc3990637053b0ccb2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 27=
, 2016 at 1:42 PM Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.com"=
>via.usov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Aug 26, 2016 at 7:27 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt; The intent here is to descri=
be what an object is, instead of giving a straight definition, because I ho=
nestly can&#39;t say how to word this in a way that&#39;d give you a straig=
ht definition and not a description of what are the properties of an object=
..</div><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><div>And, as I said, it fails to delive=
r on that intent. With the current &quot;an object is a region of storage&q=
uot;, we can tell that it is essentially the same definition as in C. We ca=
n infer that &quot;type&quot; is a just an interpretation, which can be cha=
nged without affecting other interpretations. With=C2=A0P0137R1, that is no=
t clear. I do not think you said explicitly whether &quot;type is just an i=
nterpretation, which can be changed without affecting other interpretations=
&quot; is what you think we=C2=A0will have post-P0137R1, but it is evident =
just from this thread that there are people who think otherwise.</div></div=
></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div><br></div><div>&gt; Also I don&#39;t believe there&#39;s any =
problem with the wording w.r.t. [expr.reinterpret.cast]/11. That paragraph =
keeps meaning the exact same thing as before. The only thing that changes i=
s when the objects comes into existence and when it stops being an object.<=
/div><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>I hope that&#39;s what the authors o=
f P0137R1 really have in mind. I hope that we will still have objects as me=
rely a shorthand for &quot;a region of storage&quot;, which we can interpre=
t as any data type without having to &quot;create&quot; and &quot;destroy&q=
uot; anything when the interpretation changes. Unfortunately, the message t=
hat P0137R1 sends to me (and other commenters) is different.</div></div></d=
iv></div></blockquote><div><br></div><div>The standard says this (and it ha=
s not been touched by P0137R1):</div><div><br></div><div><span style=3D"fon=
t-family:&quot;times new roman&quot;;font-size:medium;line-height:normal;te=
xt-align:justify">An object has a<span class=3D"inbox-inbox-Apple-converted=
-space">=C2=A0</span></span><i style=3D"font-family:&quot;times new roman&q=
uot;;font-size:medium;line-height:normal;text-align:justify">type</i><span =
style=3D"font-family:&quot;times new roman&quot;;font-size:medium;line-heig=
ht:normal;text-align:justify"><span class=3D"inbox-inbox-Apple-converted-sp=
ace">=C2=A0</span>(</span><a href=3D"http://eel.is/c++draft/basic.types" st=
yle=3D"text-decoration:none;font-family:&quot;times new roman&quot;;font-si=
ze:medium;line-height:normal;text-align:justify">[basic.types]</a><span sty=
le=3D"font-family:&quot;times new roman&quot;;font-size:medium;line-height:=
normal;text-align:justify">). The term<span class=3D"inbox-inbox-Apple-conv=
erted-space">=C2=A0</span></span><a id=3D"inbox-inbox-object type" style=3D=
"color:rgb(0,0,0);font-family:&quot;times new roman&quot;;font-size:medium;=
line-height:normal;text-align:justify"><i>object type</i></a><span style=3D=
"font-family:&quot;times new roman&quot;;font-size:medium;line-height:norma=
l;text-align:justify"><span class=3D"inbox-inbox-Apple-converted-space">=C2=
=A0</span>refers to the type with which the object is created.</span><br></=
div><div><br></div><div>And immediately after (<i>still</i>=C2=A0not touche=
d by P0137R1):</div><div><div class=3D"inbox-inbox-para" id=3D"inbox-inbox-=
1" style=3D"text-align:justify;font-family:&quot;times new roman&quot;;font=
-size:medium;line-height:normal"><p>Some objects are<span class=3D"inbox-in=
box-Apple-converted-space">=C2=A0</span><i>polymorphic</i><span class=3D"in=
box-inbox-Apple-converted-space">=C2=A0</span>(<a href=3D"http://eel.is/c++=
draft/class.virtual" style=3D"text-decoration:none">[class.virtual]</a>); t=
he implementation generates information associated with each such object th=
at makes it possible to determine that object&#39;s type during program exe=
cution. For other objects, the interpretation of the values found therein i=
s determined by the type of the<span class=3D"inbox-inbox-Apple-converted-s=
pace">=C2=A0</span><i><a href=3D"http://eel.is/c++draft/expr.comma#expressi=
on" style=3D"text-decoration:none">expressions</a></i><span class=3D"inbox-=
inbox-Apple-converted-space">=C2=A0</span>(Clause<span class=3D"inbox-inbox=
-Apple-converted-space">=C2=A0</span><a href=3D"http://eel.is/c++draft/expr=
" style=3D"text-decoration:none">[expr]</a>) used to access them.</p></div>=
<div class=3D"inbox-inbox-para" id=3D"inbox-inbox-2" style=3D"text-align:ju=
stify;font-family:&quot;times new roman&quot;;font-size:medium;line-height:=
normal"><div class=3D"inbox-inbox-marginalizedparent" style=3D"left: -2em;"=
><span style=3D"font-family:sans-serif;line-height:1.5;font-size:small">Ple=
ase help me understand your paragraph starting with &quot;I hope&quot; in t=
he context of this quote ([intro.object]/1). Seriously, this and your state=
ments seem not to ccompute.</span><br></div><div class=3D"inbox-inbox-margi=
nalizedparent" style=3D"left: -2em;"><span style=3D"font-family:sans-serif;=
line-height:1.5;font-size:small"><br></span></div><div style=3D"font-family=
:sans-serif;font-size:small;line-height:19.5px;text-align:start">The way I&=
#39;m reading this, P0137R1 doesn&#39;t change anything w.r.t. rules of int=
erpreting the object types or their values, and essentially only redefines =
the lifetime of an object to start when it&#39;s created and end when it&#3=
9;s destroyed, instead of being bound to the lifetime of its storage. I don=
&#39;t see any of the problems you&#39;re talking about after this change.<=
/div><div style=3D"font-family:sans-serif;font-size:small;line-height:19.5p=
x;text-align:start"><br></div><div style=3D"font-family:sans-serif;font-siz=
e:small;line-height:19.5px;text-align:start">To reiterate: as far as I unde=
rstand this, the changes of P0137R1 essentially makes the object-storage as=
sociation slightly weaker; namely, instead of object=3Dstorage, we now have=
 &quot;object must have storage; storage may have an object&quot;.</div><di=
v style=3D"font-family:sans-serif;font-size:small;line-height:19.5px;text-a=
lign:start"><br></div><div style=3D"font-family:sans-serif;font-size:small;=
line-height:19.5px;text-align:start">Let&#39;s wait from someone from CWG t=
o confirm this. (I&#39;m somewhat tempted to CC Richard to this thread...).=
</div><div class=3D"inbox-inbox-marginalizedparent" style=3D"left: -2em;"><=
span style=3D"font-family:sans-serif;line-height:1.5;font-size:small">=C2=
=A0</span><br></div></div></div><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 class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>=
&gt; I do not believe there&#39;s any problem with that. The C++ standard w=
ill specify how it works on the C++ side</div><div><br></div></div></div></=
div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div>If the eventual outcome of P0137R1 will be compatible (for standard-la=
yout types) with &quot;object is a region of storage&quot; and &quot;type i=
s just an interpretation, which can be changed without affecting other inte=
rpretations&quot;, then this is all moot. If not, then we will have a major=
 problem.</div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div><br></div><div>&gt; Whether you consider =
it half-baked or not, it&#39;s a part of the working draft now, it&#39;s in=
 the CD ballot, and then unless a NB comment removes it, it&#39;ll be in th=
e next ballot and then in the international standard ISO 14882:2017 (...ass=
uming we arrive on time...), so this is exactly the point where we start us=
ing it to explain how the language is going to work since C++17.=C2=A0</div=
><div><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div>Oh, I am pretty sure we can end up with =
a defective international standard. We have seen that happen many, many tim=
es.</div></div></div></div></blockquote><div><br></div><div>As I said befor=
e: do you believe it&#39;s a defect? <i>Do write a paper.</i>=C2=A0If anybo=
dy on the committee considers it a defect too, there will be discussion, po=
ssibly NB comments, and possibly the lack of the defect in the standard.</d=
iv><div><br></div><div>Nothing will come from just writing on a mailing lis=
t.</div><div><br></div><div>Just keep in mind that, as far as I understand,=
 removing this also means that `std::optional` and `std::variant` don&#39;t=
 <i>actually</i>=C2=A0work for all the types you want them to work with.</d=
iv><div>=C2=A0</div><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 cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div>Cheers,</div><div>V.</d=
iv></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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">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">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/CAA7YVg0Y3On8HE05W9XS_UtJSL4YV6pMWtPY=
sooa5%3DALwM-48g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAA7YVg0Y3On8HE05W9XS_UtJSL4YV6pMWtPYsooa5%3DALwM-48g%40mail.gmail.c=
om</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&quot; 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/CAPCFJdQnT_NrKNaXfGUKkbVTF6GhYuYBkV9%=
3DvS6SPBHSRGoaYA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQnT_NrKN=
aXfGUKkbVTF6GhYuYBkV9%3DvS6SPBHSRGoaYA%40mail.gmail.com</a>.<br />

--047d7b66fcc3990637053b0ccb2f--

.

--001a114187e8fd6143053b0e2e0b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 2:30 PM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:

> Please help me understand your paragraph starting with "I hope" in the
context of this quote ([intro.object]/1). Seriously, this and your
statements seem not to ccompute.

I do not see why. The language you quoted says, with more details and
nuances, that "type is a just an interpretation, which can be changed
without affecting other interpretations".

> The way I'm reading this, P0137R1 doesn't change anything w.r.t. rules of
interpreting the object types or their values, and essentially only
redefines the lifetime of an object to start when it's created and end when
it's destroyed, instead of being bound to the lifetime of its storage. I
don't see any of the problems you're talking about after this change.

We can have imaginary problems, too. Here is what Edward wrote: "Per
[intro.object]/1 and the associated drafting note, an array of N unsigned
char is *not* created when you obtain storage for an object type T,
sizeof(T) =3D=3D N." I then read the new language, as suggested, many times
over, and it may be that I was trying just too hard. At some point I felt
that, because in the new definition an object is *not* storage, some
additional "create" event is required to reinterpret the storage. What
would you say to this?

It may be that Edward says something that cannot really be said with the
current or future standard terms, which is why we end up with those
problems. Specifically, he says "array of N unsigned char is *not* created"=
..
But, indeed, it is not an array that is created, it is an object that is
(or occupies) a region of storage. And being an array (or not) is still
just an interpretation of that storage.

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/CAA7YVg26Zc7%3DET-UdBnAMvWq%3DC851dDsBajOChDJ%3D=
xM8ZuFSAw%40mail.gmail.com.

--001a114187e8fd6143053b0e2e0b
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 S=
at, Aug 27, 2016 at 2:30 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt;=C2=A0<span style=3D"font-fam=
ily:sans-serif;line-height:1.5;text-align:justify">Please help me understan=
d your paragraph starting with &quot;I hope&quot; in the context of this qu=
ote ([intro.object]/1). Seriously, this and your statements seem not to cco=
mpute.</span></div><div><span style=3D"font-family:sans-serif;line-height:1=
..5;text-align:justify"><br></span></div><div><span style=3D"font-family:san=
s-serif;line-height:1.5;text-align:justify">I do not see why. The language =
you quoted says, with more details and nuances, that &quot;</span><span sty=
le=3D"font-size:12.8px">type is a just an interpretation, which can be chan=
ged without affecting other interpretations&quot;.</span></div><div><span s=
tyle=3D"font-family:sans-serif;line-height:1.5;text-align:justify"><br></sp=
an></div><div><span style=3D"font-family:sans-serif;line-height:1.5;text-al=
ign:justify">&gt;=C2=A0</span><span style=3D"font-family:sans-serif;line-he=
ight:19.5px">The way I&#39;m reading this, P0137R1 doesn&#39;t change anyth=
ing w.r.t. rules of interpreting the object types or their values, and esse=
ntially only redefines the lifetime of an object to start when it&#39;s cre=
ated and end when it&#39;s destroyed, instead of being bound to the lifetim=
e of its storage. I don&#39;t see any of the problems you&#39;re talking ab=
out after this change.</span></div><div><span style=3D"font-family:sans-ser=
if;line-height:19.5px"><br></span></div><div><span style=3D"font-family:san=
s-serif;line-height:19.5px">We can have imaginary problems, too. Here is wh=
at Edward wrote: &quot;</span><span style=3D"font-size:12.8px">Per [intro.o=
bject]/1 and the associated drafting note, an array of N unsigned char is *=
not* created when you obtain storage for an object type T, sizeof(T) =3D=3D=
 N.&quot; I then read the new language, as suggested, many times over, and =
it may be that I was trying just too hard. At some point I felt that, becau=
se in the new=C2=A0definition=C2=A0an object is </span><i style=3D"font-siz=
e:12.8px">not</i><span style=3D"font-size:12.8px">=C2=A0storage, some addit=
ional &quot;create&quot; event is required to=C2=A0reinterpret=C2=A0the sto=
rage.=C2=A0</span><span style=3D"font-family:sans-serif;line-height:19.5px"=
>What would you say to this?</span></div><div><span style=3D"font-family:sa=
ns-serif;line-height:19.5px"><br></span></div><div><font face=3D"sans-serif=
"><span style=3D"line-height:19.5px">It may be that Edward says something t=
hat cannot really be said with the current or future standard terms, which =
is why we end up with those problems. Specifically, he says &quot;</span></=
font><span style=3D"font-size:12.8px">array of N unsigned char is *not* cre=
ated</span><span style=3D"font-size:12.8px">&quot;. But, indeed, it is not =
an array that is created, it is an object that is (or occupies) a region of=
 storage. And being an array (or not) is still just an interpretation of th=
at storage.</span></div><div><span style=3D"font-size:12.8px"><br></span></=
div><div><span style=3D"font-family:sans-serif;line-height:19.5px">Cheers,<=
/span></div><div><span style=3D"font-family:sans-serif;line-height:19.5px">=
V.</span></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&quot; 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/CAA7YVg26Zc7%3DET-UdBnAMvWq%3DC851dDs=
BajOChDJ%3DxM8ZuFSAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg26Zc=
7%3DET-UdBnAMvWq%3DC851dDsBajOChDJ%3DxM8ZuFSAw%40mail.gmail.com</a>.<br />

--001a114187e8fd6143053b0e2e0b--

.

--047d7bf0d43421ebb5053b0e6bf7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 4:09 PM Viacheslav Usov <via.usov@gmail.com> wrote:

> On Sat, Aug 27, 2016 at 2:30 PM, Micha=C5=82 Dominiak <griwes@griwes.info=
>
> wrote:
>
> > Please help me understand your paragraph starting with "I hope" in the
> context of this quote ([intro.object]/1). Seriously, this and your
> statements seem not to ccompute.
>
> I do not see why. The language you quoted says, with more details and
> nuances, that "type is a just an interpretation, which can be changed
> without affecting other interpretations".
>
> > The way I'm reading this, P0137R1 doesn't change anything w.r.t. rules
> of interpreting the object types or their values, and essentially only
> redefines the lifetime of an object to start when it's created and end wh=
en
> it's destroyed, instead of being bound to the lifetime of its storage. I
> don't see any of the problems you're talking about after this change.
>
> We can have imaginary problems, too. Here is what Edward wrote: "Per
> [intro.object]/1 and the associated drafting note, an array of N unsigned
> char is *not* created when you obtain storage for an object type T,
> sizeof(T) =3D=3D N." I then read the new language, as suggested, many tim=
es
> over, and it may be that I was trying just too hard. At some point I felt
> that, because in the new definition an object is *not* storage, some
> additional "create" event is required to reinterpret the storage. What
> would you say to this?
>

I say "there's literally no reason to feel that". Please quote the parts of
the new working draft that together lead you to that conclusion. So far
there's only "a region of storage is not an object until it's created", and
reinterpreting the object just needs an alive object. Nowhere in the
normative text there's *anything* to imply that reinterpreting an object
requires another "create" event. Nowhere. (Specifically becasue the text
for reinterpreting objects *does not change.*)


> It may be that Edward says something that cannot really be said with the
> current or future standard terms, which is why we end up with those
> problems. Specifically, he says "array of N unsigned char is *not* create=
d".
> But, indeed, it is not an array that is created, it is an object that is
> (or occupies) a region of storage. And being an array (or not) is still
> just an interpretation of that storage.
>

The object that is being created is an object of the type that is created,
not of other type (and if you feel like reading a tautology while reading
this sentence, that feeling is correct, because it is a tautology).
Obviously a char array isn't created. But this *does not *change the rule
about using `char *` or `unsigned char *` obtained by reinterpreting the
created object's address to examine the representation of the object.

Now, the thing that *is *somewhat problematic with P0137R1 is that before
it, you could reinterpret a `char` array as a POD object *without creating
it*; now, it's either 1) you cannot do that, because there was never any
object at that storage in the first place, or 2) you can do that, because
there *was* a char array that you've read data into, and you're just
reinterpreting that as a POD. Frankly I'm not sure what the correct
interpretation in this case is; could someone lend me their brain for a
second to clear this up?


> 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/CAA7YVg26Zc7=
%3DET-UdBnAMvWq%3DC851dDsBajOChDJ%3DxM8ZuFSAw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg26Zc=
7%3DET-UdBnAMvWq%3DC851dDsBajOChDJ%3DxM8ZuFSAw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter>
> .
>

--=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/CAPCFJdR363ALJVGVJUM8zejv6TanQUVSN%3DmMTRureeRCH=
9FUMw%40mail.gmail.com.

--047d7bf0d43421ebb5053b0e6bf7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 27=
, 2016 at 4:09 PM Viacheslav Usov &lt;<a href=3D"mailto:via.usov@gmail.com"=
>via.usov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 27, 2016 at 2:30 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt;=C2=A0<span style=3D"font-fam=
ily:sans-serif;line-height:1.5;text-align:justify">Please help me understan=
d your paragraph starting with &quot;I hope&quot; in the context of this qu=
ote ([intro.object]/1). Seriously, this and your statements seem not to cco=
mpute.</span></div><div><span style=3D"font-family:sans-serif;line-height:1=
..5;text-align:justify"><br></span></div></div></div></div><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><span style=3D"f=
ont-family:sans-serif;line-height:1.5;text-align:justify">I do not see why.=
 The language you quoted says, with more details and nuances, that &quot;</=
span><span style=3D"font-size:12.8px">type is a just an interpretation, whi=
ch can be changed without affecting other interpretations&quot;.</span></di=
v></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><span style=3D"font-family:sans-serif;line-height:1.5=
;text-align:justify"><br></span></div><div><span style=3D"font-family:sans-=
serif;line-height:1.5;text-align:justify">&gt;=C2=A0</span><span style=3D"f=
ont-family:sans-serif;line-height:19.5px">The way I&#39;m reading this, P01=
37R1 doesn&#39;t change anything w.r.t. rules of interpreting the object ty=
pes or their values, and essentially only redefines the lifetime of an obje=
ct to start when it&#39;s created and end when it&#39;s destroyed, instead =
of being bound to the lifetime of its storage. I don&#39;t see any of the p=
roblems you&#39;re talking about after this change.</span></div><div><span =
style=3D"font-family:sans-serif;line-height:19.5px"><br></span></div></div>=
</div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div><span style=3D"font-family:sans-serif;line-height:19.5px">We c=
an have imaginary problems, too. Here is what Edward wrote: &quot;</span><s=
pan style=3D"font-size:12.8px">Per [intro.object]/1 and the associated draf=
ting note, an array of N unsigned char is *not* created when you obtain sto=
rage for an object type T, sizeof(T) =3D=3D N.&quot; I then read the new la=
nguage, as suggested, many times over, and it may be that I was trying just=
 too hard. At some point I felt that, because in the new=C2=A0definition=C2=
=A0an object is </span><i style=3D"font-size:12.8px">not</i><span style=3D"=
font-size:12.8px">=C2=A0storage, some additional &quot;create&quot; event i=
s required to=C2=A0reinterpret=C2=A0the storage.=C2=A0</span><span style=3D=
"font-family:sans-serif;line-height:19.5px">What would you say to this?</sp=
an></div></div></div></div></blockquote><div><br></div><div>I say &quot;the=
re&#39;s literally no reason to feel that&quot;. Please quote the parts of =
the new working draft that together lead you to that conclusion. So far the=
re&#39;s only &quot;a region of storage is not an object until it&#39;s cre=
ated&quot;, and reinterpreting the object just needs an alive object. Nowhe=
re in the normative text there&#39;s <i>anything</i>=C2=A0to imply that rei=
nterpreting an object requires another &quot;create&quot; event. Nowhere. (=
Specifically becasue the text for reinterpreting objects <i>does not change=
..</i>)</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font face=3D"=
sans-serif"><span style=3D"line-height:19.5px">It may be that Edward says s=
omething that cannot really be said with the current or future standard ter=
ms, which is why we end up with those problems. Specifically, he says &quot=
;</span></font><span style=3D"font-size:12.8px">array of N unsigned char is=
 *not* created</span><span style=3D"font-size:12.8px">&quot;. But, indeed, =
it is not an array that is created, it is an object that is (or occupies) a=
 region of storage. And being an array (or not) is still just an interpreta=
tion of that storage.</span></div></div></div></div></blockquote><div><br><=
/div><div>The object that is being created is an object of the type that is=
 created, not of other type (and if you feel like reading a tautology while=
 reading this sentence, that feeling is correct, because it is a tautology)=
.. Obviously a char array isn&#39;t created. But this <i>does not </i>change=
 the rule about using `char *` or `unsigned char *` obtained by reinterpret=
ing the created object&#39;s address to examine the representation of the o=
bject.</div><div><br></div><div>Now, the thing that <i>is </i>somewhat prob=
lematic with P0137R1 is that before it, you could reinterpret a `char` arra=
y as a POD object <i>without creating it</i>; now, it&#39;s either 1) you c=
annot do that, because there was never any object at that storage in the fi=
rst place, or 2) you can do that, because there <i>was</i>=C2=A0a char arra=
y that you&#39;ve read data into, and you&#39;re just reinterpreting that a=
s a POD. Frankly I&#39;m not sure what the correct interpretation in this c=
ase is; could someone lend me their brain for a second to clear this up?</d=
iv><div>=C2=A0</div><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 cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div><span style=3D"font-fam=
ily:sans-serif;line-height:19.5px">Cheers,</span></div><div><span style=3D"=
font-family:sans-serif;line-height:19.5px">V.</span></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&quot; 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">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">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/CAA7YVg26Zc7%3DET-UdBnAMvWq%3DC851dDs=
BajOChDJ%3DxM8ZuFSAw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAA7YVg26Zc7%3DET-UdBnAMvWq%3DC851dDsBajOChDJ%3DxM8ZuFSAw%40mail=
..gmail.com</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&quot; 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/CAPCFJdR363ALJVGVJUM8zejv6TanQUVSN%3D=
mMTRureeRCH9FUMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR363ALJV=
GVJUM8zejv6TanQUVSN%3DmMTRureeRCH9FUMw%40mail.gmail.com</a>.<br />

--047d7bf0d43421ebb5053b0e6bf7--

.

--001a11403516ed8e44053b0f7908
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 4:26 PM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:

> Now, the thing that *is *somewhat problematic with P0137R1 is that before
it, you could reinterpret a `char` array as a POD object *without creating
it*; now, it's either 1) you cannot do that, because there was never any
object at that storage in the first place, or 2) you can do that, because
there *was* a char array that you've read data into, and you're just
reinterpreting that as a POD. Frankly I'm not sure what the correct
interpretation in this case is; could someone lend me their brain for a
second to clear this up?

I'd say you have the same problem that I "felt", it's just phrased
differently. There is something in the new language that makes you feel
this kind of uncertainty.

You say you can end up with a POD object without creating it. There is an
object, so it *was* created, but with a different nominal object type. But
the the nominal type is intrinsically significant only during
construction/initialisation/destruction, during the object's lifetime it is
the type of the expressions used to access it that is significant
(neglecting the polymorphic twist here). So even if you did not create a
POD object, there is an object that you can access as if it were POD. Which
is what your interpretation (2) says, I believe.

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/CAA7YVg1rxYH5XKVOmm-ZD8GNSJ-RUDzKHo_JRbSXTUnU5AO=
8cw%40mail.gmail.com.

--001a11403516ed8e44053b0f7908
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 S=
at, Aug 27, 2016 at 4:26 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><div><br></div><div>&gt; Now, the thing that <i>is </=
i>somewhat problematic with P0137R1 is that before it, you could reinterpre=
t a `char` array as a POD object <i>without creating it</i>; now, it&#39;s =
either 1) you cannot do that, because there was never any object at that st=
orage in the first place, or 2) you can do that, because there <i>was</i>=
=C2=A0a char array that you&#39;ve read data into, and you&#39;re just rein=
terpreting that as a POD. Frankly I&#39;m not sure what the correct interpr=
etation in this case is; could someone lend me their brain for a second to =
clear this up?</div><div><br></div><div>I&#39;d say you have the same probl=
em that I &quot;felt&quot;, it&#39;s just phrased differently. There is som=
ething in the new language that makes you feel this kind of uncertainty.</d=
iv><div><br></div><div>You say you can end up with a POD object without cre=
ating it. There is an object, so it <i>was</i>=C2=A0created, but with a dif=
ferent nominal object type. But the=C2=A0the nominal type is intrinsically =
significant only during construction/initialisation/destruction, during the=
 object&#39;s lifetime it is the type of the expressions used to access it =
that is significant (neglecting the polymorphic twist here). So even if you=
 did not create a POD object, there is an object that you can access as if =
it were POD. Which is what your interpretation (2) says, I believe.</div><d=
iv><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&quot; 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/CAA7YVg1rxYH5XKVOmm-ZD8GNSJ-RUDzKHo_J=
RbSXTUnU5AO8cw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1rxYH5XKVO=
mm-ZD8GNSJ-RUDzKHo_JRbSXTUnU5AO8cw%40mail.gmail.com</a>.<br />

--001a11403516ed8e44053b0f7908--

.

On 2016/08/18 17:58 +0900, D. B. wrote:
> Anyhow, TL;DR, the questions:
>
>   * Is this well-defined? Or am I relying on UB here?

I think you are relying on UB, unfortunately.

>   * Can this be made well-defined?
....
> So there might be some momentum already for specifically defining this.
> I hope so! (Otherwise I'll have to radically rethink my design, as this
> would be the only piece of formal UB in my current project)

FYI, there is CWG issue #1701.
"Array vs sequence in object representation"
http://wg21.cmeerw.net/cwg/issue1701

Probably, we need a formal proposal (which shows what should be portable
and why) to proceed the issue.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a78dfe39-5882-113f-a423-e57a54440da3%40f2.dion.ne.jp.

.

--e89a8fb1ea8a91f1a2053b1fa32e
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 28, 2016 at 11:34 AM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp>
wrote:

> >   * Can this be made well-defined?
> ...
> > So there might be some momentum already for specifically defining this.
> > I hope so! (Otherwise I'll have to radically rethink my design, as this
> > would be the only piece of formal UB in my current project)
>
> FYI, there is CWG issue #1701.
> "Array vs sequence in object representation"
> http://wg21.cmeerw.net/cwg/issue1701
>
>
Excellent, I hadn't found that - thank you. Here's an alternative link:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1701

This definitional distinction between *array* and *sequence* is the crux of
my question. To me, if the object representation is a *sequence* of *unsigned
char*, and an instance can be copied into and back from an *array* thereof
and retain its value - there absolutely must be the same count, layout, and
relative positioning of *unsigned char* within both the copied-to/-from
*array* and the object's own nebulous *sequence*... so why not just define
them as equivalent?

Calling the object representation an *array* of *unsigned char* would
define the pointer arithmetic I want - namely that given a trivially
copyable (or ideally standard-layout) object, we (and especially it) should
be able to reason about the byte offsets of arbitrary members wrt each
other or its base address - while (albeit I'm not an expert) seemingly not
breaking anything else.

In fact - only strengthening other cases that I can see. In point: Although
memcpy was not the motivating factor for me asking this, it is something I
quickly identified as being an issue, unless we hand-wave it away with
'well, the implementation can do whatever it wants'. That to me is not a
full answer, although it might serve as a superficial one.



> Probably, we need a formal proposal (which shows what should be portable
> and why) to proceed the issue.
>

Yeah. I might try to start writing one later... although I worry that more
experienced users would do a better job, so I kinda hope they can chime in.
:-)

There's also the issue of trying to get my motivating case down to a small
enough sample to (A) be useful and not just confusing, and (B) not
basically end up constituting the source of half of my current project!
What I have is a side-effect of larger architectural choices that I still
think are really clever, but which mean I'm working with objects *made of*
UCs, not *array of *UCs. Refactoring it around the latter just to satisfy
'UB by omission' in the former case is not something I want to do if I can
avoid it... when all the other parts of the Standard make it clear that any
supported CPU already has the machinery to do what I need - and, of course,
my current one happily does exactly what I expected, even at -O3.

So again, maybe other users are better equipped at present to show
convincing use-cases, at least until I can distill and generalise only the
pertinent aspects behind my question/preferred behaviour.

However, I would certainly want to contribute what I can, so I'll try to
get together a sufficiently small and useful looking sample.

--
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/CACGiwhG-Fz5HAaqt214sUQ0JFqn7GL-%3DXoN4o2KbFm8YFAqhNA%40mail.gmail.com.

--e89a8fb1ea8a91f1a2053b1fa32e
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 S=
un, Aug 28, 2016 at 11:34 AM, Kazutoshi Satoda <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:k_satoda@f2.dion.ne.jp" target=3D"_blank">k_satoda@f2.dion.ne.j=
p</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
&gt;=C2=A0 =C2=A0* Can this be made well-defined?<br>
....<br>
<span class=3D"">&gt; So there might be some momentum already for specifica=
lly defining this.<br>
&gt; I hope so! (Otherwise I&#39;ll have to radically rethink my design, as=
 this<br>
&gt; would be the only piece of formal UB in my current project)<br>
<br>
</span>FYI, there is CWG issue #1701.<br>
&quot;Array vs sequence in object representation&quot;<br>
<a href=3D"http://wg21.cmeerw.net/cwg/issue1701" rel=3D"noreferrer" target=
=3D"_blank">http://wg21.cmeerw.net/cwg/<wbr>issue1701</a><br>
<br></blockquote><div><br></div><div>Excellent, I hadn&#39;t found that - t=
hank you. Here&#39;s an alternative link: <a href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/cwg_active.html#1701">http://www.open-std.org/jtc1/sc=
22/wg21/docs/cwg_active.html#1701</a><br><br>This definitional distinction =
between <i>array</i> and <i>sequence</i> is the crux of my question. To me,=
 if the object representation is a <i>sequence</i> of <i>unsigned char</i>,=
 and an instance can be copied into and back from an <i>array</i> thereof a=
nd retain its value - there absolutely must be the same count, layout, and =
relative positioning of <i>unsigned char</i> within both the copied-to/-fro=
m <i>array</i> and the object&#39;s own nebulous <i>sequence</i>... so why =
not just define them as equivalent?<br><br>Calling the object representatio=
n an <i>array</i> of <i>unsigned char</i> would define the pointer arithmet=
ic I want - namely that given a trivially copyable (or ideally standard-lay=
out) object, we (and especially it) should be able to reason about the byte=
 offsets of arbitrary members wrt each other or its base address - while (a=
lbeit I&#39;m not an expert) seemingly not breaking anything else.<br><br><=
/div><div>In fact - only strengthening other cases that I can see. In point=
: Although memcpy was not the motivating factor for me asking this, it is s=
omething I quickly identified as being an issue, unless we hand-wave it awa=
y with &#39;well, the implementation can do whatever it wants&#39;. That to=
 me is not a full answer, although it might serve as a superficial one.<br>=
</div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
Probably, we need a formal proposal (which shows what should be portable<br=
>
and why) to proceed the issue.<br></blockquote><div><br></div><div>Yeah. I =
might try to start writing one later... although I worry that more experien=
ced users would do a better job, so I kinda hope they can chime in. :-)<br>=
<br>There&#39;s also the issue of trying to get my motivating case down to =
a small enough sample to (A) be useful and not just confusing, and (B) not =
basically end up constituting the source of half of my current project! Wha=
t I have is a side-effect of larger architectural choices that I still thin=
k are really clever, but which mean I&#39;m working with objects <i>made of=
</i> UCs, not <i>array of </i>UCs. Refactoring it around the latter just to=
 satisfy &#39;UB by omission&#39; in the former case is not something I wan=
t to do if I can avoid it... when all the other parts of the Standard make =
it clear that any supported CPU already has the machinery to do what I need=
 - and, of course, my current one happily does exactly what I expected, eve=
n at -O3.<br><br>So again, maybe other users are better equipped at present=
 to show convincing use-cases, at least until I can distill and generalise =
only the pertinent aspects behind my question/preferred behaviour.<br><br>H=
owever, I would certainly want to contribute what I can, so I&#39;ll try to=
 get together a sufficiently small and useful looking sample.<br><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&quot; 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/CACGiwhG-Fz5HAaqt214sUQ0JFqn7GL-%3DXo=
N4o2KbFm8YFAqhNA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG-Fz5HAa=
qt214sUQ0JFqn7GL-%3DXoN4o2KbFm8YFAqhNA%40mail.gmail.com</a>.<br />

--e89a8fb1ea8a91f1a2053b1fa32e--

.

--001a114e3072ed8e2d053b492dde
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 27, 2016 at 1:30 PM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:

> Let's wait from someone from CWG to confirm this. (I'm somewhat tempted t=
o
> CC Richard to this thread...).
>


Feel free! It sure would be great if he could swing by, as the Editor. So
if you happen to have his address handy... ;-)

I notice, for whatever little it might be worth, *cppreference *implies
pointer arithmetic into the object representation as if it is an array is
OK; in this example, they manually manipulate a byte that forms part
of the *object
*but not *value *representation, as a way to demonstrate the concept of the
latter. I have no idea whether this is kosher, though.
http://en.cppreference.com/w/cpp/language/object#Object_representation_and_=
value_representation
....but it does indicate, at least, that whoever wrote that *thinks* what I
originally thought, that treating the object representation "*sequence
*of *unsigned
char[sizeof(T)]*" as an *array* was OK.

The unclear relationship xor distinction between *sequence* and *array*
here is the fundamental question for the CWG, as it would answer my more
specific points by association. And as Kazutoshi Satoda mentioned, there's
already an issue in drafting...
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1701
....so maybe we can get somewhere with it.

I still can't tell whether P0137R1 really clarifies anything here... (i.e.
whether placement *new*ing into such an array, which would then have a
parallel lifetime, entitles me to do said arithmetic within the limitations
of the current vague sequence/array wording)

--=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/CACGiwhFBXO1%3D7_Na6bM1jseL6G99XKpnVS_YJMzhvdvFw=
yuW4g%40mail.gmail.com.

--001a114e3072ed8e2d053b492dde
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 S=
at, Aug 27, 2016 at 1:30 PM, Micha=C5=82 Dominiak <span dir=3D"ltr">&lt;<a =
href=3D"mailto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v style=3D"margin-left:40px"><span class=3D"gmail-">Let&#39;s wait from som=
eone from CWG to confirm this. (I&#39;m somewhat tempted to CC Richard to t=
his thread...).</span><br></div></blockquote><div><br><br></div><div>Feel f=
ree! It sure would be great if he could swing by, as the Editor. So if you =
happen to have his address handy... ;-)<br><br></div><div>I notice, for wha=
tever little it might be worth, <i>cppreference </i>implies pointer arithme=
tic into the object representation as if it is an array is OK; in this exam=
ple, they manually manipulate a byte that forms part of the <i>object </i>b=
ut not <i>value </i>representation, as a way to demonstrate the concept of =
the latter. I have no idea whether this is kosher, though.<br><a href=3D"ht=
tp://en.cppreference.com/w/cpp/language/object#Object_representation_and_va=
lue_representation">http://en.cppreference.com/w/cpp/language/object#Object=
_representation_and_value_representation</a><br></div><div>...but it does i=
ndicate, at least, that whoever wrote that <i>thinks</i> what I originally =
thought, that treating the object representation &quot;<b>sequence </b>of <=
i>unsigned char[sizeof(T)]</i>&quot; as an <b>array</b> was OK.<br><br></di=
v><div>The unclear relationship xor distinction between <i>sequence</i> and=
 <i>array</i> here is the fundamental question for the CWG, as it would ans=
wer my more specific points by association. And as <span class=3D"gmail-gD"=
 name=3D"Kazutoshi Satoda">Kazutoshi Satoda mentioned, there&#39;s already =
an issue in drafting...</span><br><a href=3D"http://www.open-std.org/jtc1/s=
c22/wg21/docs/cwg_active.html#1701">http://www.open-std.org/jtc1/sc22/wg21/=
docs/cwg_active.html#1701</a><br></div><div>...so maybe we can get somewher=
e with it.<br></div><div><br></div><div>I still can&#39;t tell whether P013=
7R1 really clarifies anything here... (i.e. whether placement <i>new</i>ing=
 into such an array, which would then have a parallel lifetime, entitles me=
 to do said arithmetic within the limitations of the current vague sequence=
/array wording)<br><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&quot; 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/CACGiwhFBXO1%3D7_Na6bM1jseL6G99XKpnVS=
_YJMzhvdvFwyuW4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFBXO1%3D=
7_Na6bM1jseL6G99XKpnVS_YJMzhvdvFwyuW4g%40mail.gmail.com</a>.<br />

--001a114e3072ed8e2d053b492dde--

.

On 2016/08/28 19:59 +0900, D. B. wrote:
> On Sun, Aug 28, 2016 at 11:34 AM, Kazutoshi Satoda <k_satoda@f2.dion.ne.jp> wrote:
....
>> FYI, there is CWG issue #1701.
>> "Array vs sequence in object representation"
>> http://wg21.cmeerw.net/cwg/issue1701
....
> This definitional distinction between *array* and *sequence* is the crux of
> my question. To me, if the object representation is a *sequence* of *unsigned
> char*, and an instance can be copied into and back from an *array* thereof
> and retain its value - there absolutely must be the same count, layout, and
> relative positioning of *unsigned char* within both the copied-to/-from
> *array* and the object's own nebulous *sequence*... so why not just define
> them as equivalent?

That will affect the validity of some currently possible optimizations.
(Though I don't know if this is the reason which CWG is worrying.)

Here is a small example.

  void f0(int* p);
  struct X {
    int a;
    int b;
  };
  int f1(void)
  {
    X x;
    x.a = 128;
    f0(&x.b);
    return x.a;
  }

If there is no valid way to obtain a pointer to x.a from &x.b, a
compiler can transform the last "return x.a" into "return 128" to
eliminate a load from memory.

But if the existence of x also implies the existence of an array object
of type unsigned char [sizeof(x)] at the address of x (and there are
intuitive pointer-interconvertible rules on the array elements), that
means f0() can do something like the following:

  void f0(int* p)
  {
    // I know p must point X::b here.
    X* px = (X*)((unsigned char*)p - offsetof(X, b));
    ++px->a;
  }

Then the above optimization will be no longer valid.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06576d10-caf3-0048-5c98-3f2481db02c4%40f2.dion.ne.jp.

.

--001a1146a0dcfccad8053b4ea64e
Content-Type: text/plain; charset=UTF-8

Well, yeah, but isn't that illegal because of aliasing though, rather than
pointer arithmetic specifically?

Anyway, the objects I work with contain only unsigned char and classes
wrapping the same, so there's not an aliasing issue there: the object
literally is just a bunch of unsigned char in a sequence, with no padding
or etc, but officially I'm not allowed to perform offset calculations
between different members as if they were an array.... rather than just a
"bunch". :/

--
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/CACGiwhEb6sacfKD8a%2BdmmVj%2BY24h4srdy4mMBDwySBD7yzoZzw%40mail.gmail.com.

--001a1146a0dcfccad8053b4ea64e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Well, yeah, but isn&#39;t that illegal because of ali=
asing though, rather than pointer arithmetic specifically?<br><br></div>Any=
way, the objects I work with contain only unsigned char and classes wrappin=
g the same, so there&#39;s not an aliasing issue there: the object literall=
y is just a bunch of unsigned char in a sequence, with no padding or etc, b=
ut officially I&#39;m not allowed to perform offset calculations between di=
fferent members as if they were an array.... rather than just a &quot;bunch=
&quot;. :/<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CACGiwhEb6sacfKD8a%2BdmmVj%2BY24h4srd=
y4mMBDwySBD7yzoZzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEb6sac=
fKD8a%2BdmmVj%2BY24h4srdy4mMBDwySBD7yzoZzw%40mail.gmail.com</a>.<br />

--001a1146a0dcfccad8053b4ea64e--

.

On 2016/08/31 4:04 +0900, D. B. wrote:
> Well, yeah, but isn't that illegal because of aliasing though, rather than
> pointer arithmetic specifically?

I don't see aliasing problem in f0(). Accessing px->a is to an object
of int, through lvalue of int. If I'm missing something, please explain
which access has the problem.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fd2c9a95-af83-1e21-f345-9084a650558f%40f2.dion.ne.jp.

.

--089e010d89ea836176053b4f938f
Content-Type: text/plain; charset=UTF-8

Maybe aliasing isn't the right word here, but I thought what your example
does to form the pointer is already UB or implementation-defined at best...
due to the cast from the weakest aligned char type to an object type that
might be misaligned, and the fact the compiler has no evidence of there
being a valid int at the adjusted position.

Whatever the many problems probably are, certainly it's horrid code and not
something I would ever write! ;-) To be clear, I don't want the 'object as
array of char' guarantee so that I can do offset acrobatics to other
types... not at all. I'm not trying to define that given int a, b, c; then
one should be able to say a[2] and get c.

All I want to do is calculate offsets between objects that are already
unsigned char, in contiguous *sequences*, but which formally I can't
because they weren't declared as an *array* of unsigned char.

--
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/CACGiwhHYYvXf0LtYa3Zm4aB69MUxQrNj%3D6yCz0rUKA5pUTSiwg%40mail.gmail.com.

--089e010d89ea836176053b4f938f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Maybe aliasing isn&#39;t the right word here, but I t=
hought what your example does to form the pointer is already UB or implemen=
tation-defined at best... due to the cast from the weakest aligned char typ=
e to an object type that might be misaligned, and the fact the compiler has=
 no evidence of there being a valid int at the adjusted position.<br><br></=
div>Whatever the many problems probably are, certainly it&#39;s horrid code=
 and not something I would ever write! ;-) To be clear, I don&#39;t want th=
e &#39;object as array of char&#39; guarantee so that I can do offset acrob=
atics to other types... not at all. I&#39;m not trying to define that given=
 int a, b, c; then one should be able to say a[2] and get c.<br><br>All I w=
ant to do is calculate offsets between objects that are already unsigned ch=
ar, in contiguous <i>sequences</i>, but which formally I can&#39;t because =
they weren&#39;t declared as an <i>array</i> of unsigned char.<br><br></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CACGiwhHYYvXf0LtYa3Zm4aB69MUxQrNj%3D6=
yCz0rUKA5pUTSiwg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHYYvXf0L=
tYa3Zm4aB69MUxQrNj%3D6yCz0rUKA5pUTSiwg%40mail.gmail.com</a>.<br />

--089e010d89ea836176053b4f938f--

.

On 2016/08/31 5:10 +0900, D. B. wrote:
> Maybe aliasing isn't the right word here, but I thought what your example
> does to form the pointer is already UB or implementation-defined at best...
> due to the cast from the weakest aligned char type to an object type that
> might be misaligned, and the fact the compiler has no evidence of there
> being a valid int at the adjusted position.

I don't see no alignment problem, provided that f0() is called with a
pointer argument which actually points a X::b, and that offsetof() does
the right job.

> All I want to do is calculate offsets between objects that are already
> unsigned char, in contiguous *sequences*, but which formally I can't
> because they weren't declared as an *array* of unsigned char.

Sorry but, I got lost. How do you have "sequences" (what?) which are
not declared as an array? Probably some example code (which includes
how the objects are created, and how offsets are calculated) will help.
Sorry if it is already shown.

--
k_satoda

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6c171183-aba9-0ac5-265d-af6e4108b4d9%40f2.dion.ne.jp.

.

--001a1149ba74a9d20b053b5bbd3e
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 30, 2016 at 9:10 PM, D. B. <db0451@gmail.com> wrote:

> Maybe aliasing isn't the right word here, but I thought what your example
> does to form the pointer is already UB or implementation-defined at best...
> due to the cast from the weakest aligned char type to an object type that
> might be misaligned, and the fact the compiler has no evidence of there
> being a valid int at the adjusted position.
>

But it might not be misaligned, and there might be a valid int at that
position, so (especially if the programmer uses std::launder) the compiler
has to assume that the access could be valid. This unfortunately is one of
those cases where the benefit of doubt falls on the side of the programmer.

Whatever the many problems probably are, certainly it's horrid code and not
> something I would ever write! ;-) To be clear, I don't want the 'object as
> array of char' guarantee so that I can do offset acrobatics to other
> types... not at all. I'm not trying to define that given int a, b, c; then
> one should be able to say a[2] and get c.
>

Of course what you want is perfectly legitimate! The problem is that
defining storage 'array of char' provides more than you need, and enough
for some other programmer to go off and do tricky things that break the
balancing act between programmer and implementor.

All I want to do is calculate offsets between objects that are already
> unsigned char, in contiguous *sequences*, but which formally I can't
> because they weren't declared as an *array* of unsigned char.
>

I think we agreed that you can; you just have to use linear scan or binary
search - it's only direct subtraction that is barred to you.

--
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/CAJnLdOZ6WaXn4M%3DVmz1ZB%2B7cnw95rzhNiX%2BCodHFHU-JVSoNWA%40mail.gmail.com.

--001a1149ba74a9d20b053b5bbd3e
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=
ue, Aug 30, 2016 at 9:10 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</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>Maybe aliasing isn&=
#39;t the right word here, but I thought what your example does to form the=
 pointer is already UB or implementation-defined at best... due to the cast=
 from the weakest aligned char type to an object type that might be misalig=
ned, and the fact the compiler has no evidence of there being a valid int a=
t the adjusted position.<br></div></div></blockquote><div><br></div><div>Bu=
t it might not be misaligned, and there might be a valid int at that positi=
on, so (especially if the programmer uses std::launder) the compiler has to=
 assume that the access could be valid. This unfortunately is one of those =
cases where the benefit of doubt falls on the side of the programmer.</div>=
<div><br></div><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></div>W=
hatever the many problems probably are, certainly it&#39;s horrid code and =
not something I would ever write! ;-) To be clear, I don&#39;t want the &#3=
9;object as array of char&#39; guarantee so that I can do offset acrobatics=
 to other types... not at all. I&#39;m not trying to define that given int =
a, b, c; then one should be able to say a[2] and get c.<br></div></blockquo=
te><div><br></div><div>Of course what you want is perfectly legitimate! The=
 problem is that defining storage &#39;array of char&#39; provides more tha=
n you need, and enough for some other programmer to go off and do tricky th=
ings that break the balancing act between programmer and implementor.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">All I want t=
o do is calculate offsets between objects that are already unsigned char, i=
n contiguous <i>sequences</i>, but which formally I can&#39;t because they =
weren&#39;t declared as an <i>array</i> of unsigned char.<br></div></blockq=
uote><div><br></div><div>I think we agreed that you can; you just have to u=
se linear scan or binary search - it&#39;s only direct subtraction that is =
barred to you.</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&quot; 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/CAJnLdOZ6WaXn4M%3DVmz1ZB%2B7cnw95rzhN=
iX%2BCodHFHU-JVSoNWA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZ6Wa=
Xn4M%3DVmz1ZB%2B7cnw95rzhNiX%2BCodHFHU-JVSoNWA%40mail.gmail.com</a>.<br />

--001a1149ba74a9d20b053b5bbd3e--

.

--001a114065c033f581053b5c1173
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 31, 2016 at 12:41 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> I think we agreed that you can; you just have to use linear scan or
binary search - it's only direct subtraction that is barred to you.

Does that means you now disagree with the analysis I presented earlier even
in the case of a strict C++14 conformance? Care to explain why?

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/CAA7YVg3b_7-4zUSnYzbnsQ1txhRZqVBnhAa3xBMWscsoCVgqGw%40mail.gmail.com.

--001a114065c033f581053b5c1173
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 12:41 PM, &#39;Edward Catmur&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<=
br><div><br></div><div>&gt; I think we agreed that you can; you just have t=
o use linear scan or binary search - it&#39;s only direct subtraction that =
is barred to you.</div><div><br></div><div>Does that means you now disagree=
 with the analysis I presented earlier even in the case of a strict C++14 c=
onformance? Care to explain why?</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&quot; 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/CAA7YVg3b_7-4zUSnYzbnsQ1txhRZqVBnhAa3=
xBMWscsoCVgqGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3b_7-4zUSn=
YzbnsQ1txhRZqVBnhAa3xBMWscsoCVgqGw%40mail.gmail.com</a>.<br />

--001a114065c033f581053b5c1173--

.

--94eb2c08a748143fe8053b5de8f1
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 31, 2016 at 12:04 PM, Viacheslav Usov <via.usov@gmail.com>
wrote:

> On Wed, Aug 31, 2016 at 12:41 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > I think we agreed that you can; you just have to use linear scan or
> binary search - it's only direct subtraction that is barred to you.
>
> Does that means you now disagree with the analysis I presented earlier
> even in the case of a strict C++14 conformance? Care to explain why?
>

Sorry, I can't find that analysis. At one point you wrote:

> What I think you can do is take the address of the complete object, cast
it to pointer to array of unsigned chars, get the address of the first
element of that array, then increment the resultant pointer until it
becomes equal to the address of the member of interest (that is cast to
pointer to unsigned char).

I agree with this analysis, except that I don't believe that you can "cast [the
address of the complete object] to pointer to array of unsigned chars"; I
believe that you can cast a pointer to the complete object (with type
pointer to the type of the complete object) to type pointer to unsigned
char and get a pointer (to the complete object) that can be used to
traverse the sequence of unsigned char that constitutes the object's
storage. This after all is what memcpy is required to do.

--
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/CAJnLdObL9uu3OPPGnwNHR3t2K%3DFNSQQzk_TpeOFjLb6gAQ5JLA%40mail.gmail.com.

--94eb2c08a748143fe8053b5de8f1
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 12:04 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">On Wed, Aug 31, 2016 at 12:41 PM, &#39;Edwar=
d Catmur&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt=
;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposal=
s@isocpp.org</a>&gt;</span> wrote:<br><div><br></div><div>&gt; I think we a=
greed that you can; you just have to use linear scan or binary search - it&=
#39;s only direct subtraction that is barred to you.</div><div><br></div><d=
iv>Does that means you now disagree with the analysis I presented earlier e=
ven in the case of a strict C++14 conformance? Care to explain why?=C2=A0</=
div></div></div></div></blockquote><div><br></div><div>Sorry, I can&#39;t f=
ind that analysis. At one point you wrote:</div><div><br></div><div>&gt;=C2=
=A0<span style=3D"font-size:12.8000001907349px">What I think you can do is =
take the address of the complete object, cast it to pointer to array of uns=
igned chars, get the address of the first element of that array, then incre=
ment the resultant pointer until it becomes equal to the address of the mem=
ber of interest (that is cast to pointer to unsigned char).</span></div><di=
v><span style=3D"font-size:12.8000001907349px"><br></span></div><div><span =
style=3D"font-size:12.8000001907349px">I agree with this analysis, except t=
hat I don&#39;t believe that you can &quot;</span><span style=3D"font-size:=
12.8000001907349px">cast [</span><span style=3D"font-size:12.8000001907349p=
x">the address of the complete object</span><span style=3D"font-size:12.800=
0001907349px">] to pointer to array of unsigned chars</span><span style=3D"=
font-size:12.8000001907349px">&quot;; I believe that you can cast a pointer=
 to the complete object (with type pointer to the type of the complete obje=
ct) to type pointer to unsigned char and get a pointer (to the complete obj=
ect) that can be used to traverse the sequence of unsigned char that consti=
tutes the object&#39;s storage. This after all is what memcpy is required t=
o do.</span></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&quot; 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/CAJnLdObL9uu3OPPGnwNHR3t2K%3DFNSQQzk_=
TpeOFjLb6gAQ5JLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObL9uu3OP=
PGnwNHR3t2K%3DFNSQQzk_TpeOFjLb6gAQ5JLA%40mail.gmail.com</a>.<br />

--94eb2c08a748143fe8053b5de8f1--

.

--001a1142500e522256053b5f6c7b
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 31, 2016 at 3:16 PM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Sorry, I can't find that analysis.

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/HaQO5Q_uiKg/
6pgDHdjXEAAJ

> I don't believe that you can "cast [the address of the complete object]
to pointer to array of unsigned chars"

Such a cast is essential to the analysis I referenced. Why do you not
believe it is possible?

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/CAA7YVg0JmPvsZ89R88TM%2BJpmVHT%3DMKsdbSdsOuY0L42-0mWExQ%40mail.gmail.com.

--001a1142500e522256053b5f6c7b
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 3:16 PM, &#39;Edward Catmur&#39; via ISO C++ Standard -=
 Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@iso=
cpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<b=
r><div><br></div><div>&gt; Sorry, I can&#39;t find that analysis.</div><div=
><br></div><div><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std=
-proposals/HaQO5Q_uiKg/6pgDHdjXEAAJ" target=3D"_blank">https://groups.googl=
e.com/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals/HaQO5Q_uiKg/<wbr>6pgDHdjXE=
AAJ</a><br></div><div><br></div><div>&gt;=C2=A0<span style=3D"font-size:12.=
8px">I don&#39;t believe that you can &quot;</span><span style=3D"font-size=
:12.8px">cast [</span><span style=3D"font-size:12.8px">the address of the c=
omplete object</span><span style=3D"font-size:12.8px">] to pointer to array=
 of unsigned chars</span><span style=3D"font-size:12.8px">&quot;</span></di=
v><div><span style=3D"font-size:12.8px"><br></span></div><div>Such a cast i=
s essential to the analysis I referenced. Why do you not believe it is poss=
ible?</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&quot; 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/CAA7YVg0JmPvsZ89R88TM%2BJpmVHT%3DMKsd=
bSdsOuY0L42-0mWExQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0JmPvs=
Z89R88TM%2BJpmVHT%3DMKsdbSdsOuY0L42-0mWExQ%40mail.gmail.com</a>.<br />

--001a1142500e522256053b5f6c7b--

.

--001a1149ba7498a3cb053b5fc030
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 31, 2016 at 4:05 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Wed, Aug 31, 2016 at 3:16 PM, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
> > Sorry, I can't find that analysis.
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/
> HaQO5Q_uiKg/6pgDHdjXEAAJ
>

Oh, sorry, I understand what you're saying now. You're saying that a
C++14-conformant implementation is obliged to regard the storage as
containing (as well as the object) an array of unsigned char completely
overlaying the object and its storage, and so pointer arithmetic is
legitimate?

> I don't believe that you can "cast [the address of the complete object]
> to pointer to array of unsigned chars"
>
> Such a cast is essential to the analysis I referenced. Why do you not
> believe it is possible?
>

I agree that if C++14 were to be implemented strictly in isolation such an
implementation would have to behave as you have described. However I also
believe that such is not intended, and that P0137R1 is clarifying (a defect
in) the wording.

--
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/CAJnLdObnd8LDFRKN77NJF63KPE2098KZ7-SCPFdaPM6eqD3JLg%40mail.gmail.com.

--001a1149ba7498a3cb053b5fc030
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 4:05 PM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</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">On Wed, Aug 31, 2016 at 3:16 P=
M, &#39;Edward Catmur&#39; via ISO C++ Standard - Future Proposals <span di=
r=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank"=
>std-proposals@isocpp.org</a>&gt;</span> wrote:<br><div><br></div><div>&gt;=
 Sorry, I can&#39;t find that analysis.</div><div><br></div><div><a href=3D=
"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/HaQO5Q_uiKg/6pg=
DHdjXEAAJ" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/=
msg/std-proposals/<wbr>HaQO5Q_uiKg/6pgDHdjXEAAJ</a></div></div></div></div>=
</blockquote><div><br></div><div>Oh, sorry, I understand what you&#39;re sa=
ying now. You&#39;re saying that a C++14-conformant implementation is oblig=
ed to regard the storage as containing (as well as the object) an array of =
unsigned char completely overlaying the object and its storage, and so poin=
ter arithmetic is legitimate?</div><div><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"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div></div><div>&gt;=C2=A0<span style=3D"font-size:12.8px">I don&#39;t be=
lieve that you can &quot;</span><span style=3D"font-size:12.8px">cast [</sp=
an><span style=3D"font-size:12.8px">the address of the complete object</spa=
n><span style=3D"font-size:12.8px">] to pointer to array of unsigned chars<=
/span><span style=3D"font-size:12.8px">&quot;</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div>Such a cast is essential to the=
 analysis I referenced. Why do you not believe it is possible?</div></div><=
/div></div></blockquote><div><br></div><div>I agree that if C++14 were to b=
e implemented strictly in isolation such an implementation would have to be=
have as you have described. However I also believe that such is not intende=
d, and that P0137R1 is clarifying (a defect in) the wording.</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&quot; 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/CAJnLdObnd8LDFRKN77NJF63KPE2098KZ7-SC=
PFdaPM6eqD3JLg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObnd8LDFRKN=
77NJF63KPE2098KZ7-SCPFdaPM6eqD3JLg%40mail.gmail.com</a>.<br />

--001a1149ba7498a3cb053b5fc030--

.

------=_Part_2344_55958992.1472664085788
Content-Type: multipart/alternative;
 boundary="----=_Part_2345_970807030.1472664085788"

------=_Part_2345_970807030.1472664085788
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.

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.

--
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/1897a39a-9c99-47c6-a486-10ee500e5add%40isocpp.org.

------=_Part_2345_970807030.1472664085788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">C++ allows accessing an object as a sequence of <span styl=
e=3D"font-family: courier new,monospace;">unsigned char</span>, but (appare=
ntly?) not an <b>array</b> of <span style=3D"font-family: courier new,monos=
pace;">unsigned char</span>. If that&#39;s true, then it follows that you c=
an&#39;t use pointer arithmetic on an <span style=3D"font-family: courier n=
ew,monospace;">unsigned char *</span> to obtain offsets into the object.<br=
><br>This can be worked around on platforms with flat memory models by emul=
ating pointer arithmetic yourself:<br>=C2=A0 1) <span style=3D"font-family:=
 courier new,monospace;">reinterpret_cast</span> the pointer to a large-eno=
ugh integral type<br>=C2=A0 2) offset the integer<br>=C2=A0 3) <span style=
=3D"font-family: courier new,monospace;">reinterpret_cast</span> back to <s=
pan style=3D"font-family: courier new,monospace;">unsigned char *</span><br=
><br>But this is awkward and implementation-dependent (the casts are implem=
entation-defined). It would be better to just straight up allow pointer ari=
thmetic on an <span style=3D"font-family: courier new,monospace;">unsigned =
char *</span> within the object representation of an object.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/1897a39a-9c99-47c6-a486-10ee500e5add%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1897a39a-9c99-47c6-a486-10ee500e5add=
%40isocpp.org</a>.<br />

------=_Part_2345_970807030.1472664085788--

------=_Part_2344_55958992.1472664085788--

.