------=_Part_5176_1718176612.1417457440604
Content-Type: multipart/alternative;
 boundary="----=_Part_5177_181716675.1417457440605"

------=_Part_5177_181716675.1417457440605
Content-Type: text/plain; charset=UTF-8

I think that if an empty class derives from exactly one class, or any
number of classes whose inheritance hierarchy is empty and exactly one
whose inheritance hierarchy is non-empty, then pointer arithmetic ought to
be legal on the derived class if used on an array of the non-empty base
class.  In practice, this is already true: sizeof(Derived) ==
sizeof(NonEmptyBase) in pretty much all implementations.  However, the
Standard considers this behavior undefined, even for standard-layout
structures.

For standard-layout structures, it's even more clear that this ought to
work.  Standard-layout is practically *defined* to ensure that the sizes
are the same, because it considers non-empty classes derived from empty
base classes and vice versa to be compatible with C.  Yet, pointer
arithmetic in this case is undefined.

I see several possible rulesets to my proposal, in increasing order of
liberalism:

Only allow on standard-layout structures:
1. All standard-layout classes whose inheritance hierarchy contains the
same non-empty base class are compatible in terms of pointer arithmetic.
2. Pointer arithmetic is compatible among empty classes that share a base
class in their hierarchy.  Why you'd have an array of empty classes is
beyond me, but I don't see a reason to prohibit pointer arithmetic.
3. Such arithmetic is only compatible if alignof(Derived) ==
alignof(NonEmptyBase).  I.e., explicitly aligning the derived class or
other empty base classes breaks it.
4. For all empty classes E and all classes C, alignof(E) <= alignof(C).
This probably ought to be in the Standard anyway.  Real implementations
often allow attaching alignment to types, even though alignas does not; on
such implementations, this can only be forced true for empty classes with
no alignment directive in the empty class hierarchy.
5. The usual rules about double-deriving from the same empty base class
causing non-emptiness apply.

Only allow without virtual functions:
1. A class with no data members of its own that immediately derives from
exactly one non-empty base class would be pointer-arithmetic-compatible
with that non-empty base class.
2. No class in the hierarchy is allowed to have virtual functions or
virtual inheritance, including the class in question, or #1 breaks.
3. #1 is only true if the alignment is the same, once again.

Only allow without virtual inheritance:
1. The same as immediately above, but allow virtual functions.
2a. The derived class must not have any virtual functions of its own.  Or
an alternative rule:
2b. All non-destructor virtual functions in the derived class must be
declared override.
3. (Note: This ruleset means that the information required for typeid and
dynamic_cast to work with the derived type must not increase the size.
I.e., this would have to be done in the space allocated for the non-empty
base class, such as its vtable.  In practice, all this is already true.)

Most permissive:
1. Like immediately above, except that virtual inheritance is permitted
within the non-empty base class.
2. Virtual inheritance at the current derivation would break it, however.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I think that if an empty class derives from exactly one cl=
ass, or any number of classes whose inheritance hierarchy is empty and exac=
tly one whose inheritance hierarchy is non-empty, then pointer arithmetic o=
ught to be legal on the derived class if used on an array of the non-empty =
base class.&nbsp; In practice, this is already true: <span style=3D"font-fa=
mily: courier new,monospace;">sizeof(Derived) =3D=3D sizeof(NonEmptyBase)</=
span> in pretty much all implementations.&nbsp; However, the Standard consi=
ders this behavior undefined, even for standard-layout structures.<br><br>F=
or standard-layout structures, it's even more clear that this ought to work=
..&nbsp; Standard-layout is practically *defined* to ensure that the sizes a=
re the same, because it considers non-empty classes derived from empty base=
 classes and vice versa to be compatible with C.&nbsp; Yet, pointer arithme=
tic in this case is undefined.<br><br>I see several possible rulesets to my=
 proposal, in increasing order of liberalism:<br><br>Only allow on standard=
-layout structures:<br>1. All standard-layout classes whose inheritance hie=
rarchy contains the same non-empty base class are compatible in terms of po=
inter arithmetic.<br>2. Pointer arithmetic is compatible among empty classe=
s that share a base class in their hierarchy.&nbsp; Why you'd have an array=
 of empty classes is beyond me, but I don't see a reason to prohibit pointe=
r arithmetic.<br>3. Such arithmetic is only compatible if <span style=3D"fo=
nt-family: courier new,monospace;">alignof(Derived) =3D=3D alignof(NonEmpty=
Base)</span>.&nbsp; I.e., explicitly aligning the derived class or other em=
pty base classes breaks it.<br>4. For all empty classes E and all classes C=
, <span style=3D"font-family: courier new,monospace;">alignof(E) &lt;=3D al=
ignof(C)</span>.&nbsp; This probably ought to be in the Standard anyway.&nb=
sp; Real implementations often allow attaching alignment to types, even tho=
ugh <span style=3D"font-family: courier new,monospace;">alignas</span> does=
 not; on such implementations, this can only be forced true for empty class=
es with no alignment directive in the empty class hierarchy.<br>5. The usua=
l rules about double-deriving from the same empty base class causing non-em=
ptiness apply.<br><br>Only allow without virtual functions:<br>1. A class w=
ith no data members of its own that immediately derives from exactly one no=
n-empty base class would be pointer-arithmetic-compatible with that non-emp=
ty base class.<br>2. No class in the hierarchy is allowed to have virtual f=
unctions or virtual inheritance, including the class in question, or #1 bre=
aks.<br>3. #1 is only true if the alignment is the same, once again.<br><br=
>Only allow without virtual inheritance:<br>1. The same as immediately abov=
e, but allow virtual functions.<br>2a. The derived class must not have any =
virtual functions of its own.&nbsp; Or an alternative rule:<br>2b. All non-=
destructor virtual functions in the derived class must be declared <span st=
yle=3D"font-family: courier new,monospace;">override</span>.<br>3. (Note: T=
his ruleset means that the information required for typeid and dynamic_cast=
 to work with the derived type must not increase the size.&nbsp; I.e., this=
 would have to be done in the space allocated for the non-empty base class,=
 such as its vtable.&nbsp; In practice, all this is already true.)<br><br>M=
ost permissive:<br>1. Like immediately above, except that virtual inheritan=
ce is permitted within the non-empty base class.<br>2. Virtual inheritance =
at the current derivation would break it, however.<br><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5177_181716675.1417457440605--
------=_Part_5176_1718176612.1417457440604--

.

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

I am not sure what problem you are trying to solve. I imagine (have not
checked the standard) that when dealing with two *standard-layout*,
*layout-compatible* types pointer arithmetic should be guaranteed to be
equivalent by the standard (is it really undefined behavior today? can you
point where this is stated?), but I am not sure that I would go further
than that. In particular considering that I don't see any motivating use
case for the feature...

   David
On Mon Dec 01 2014 at 1:10:41 PM Myriachan <myriachan@gmail.com> wrote:

> I think that if an empty class derives from exactly one class, or any
> number of classes whose inheritance hierarchy is empty and exactly one
> whose inheritance hierarchy is non-empty, then pointer arithmetic ought to
> be legal on the derived class if used on an array of the non-empty base
> class.  In practice, this is already true: sizeof(Derived) ==
> sizeof(NonEmptyBase) in pretty much all implementations.  However, the
> Standard considers this behavior undefined, even for standard-layout
> structures.
>
> For standard-layout structures, it's even more clear that this ought to
> work.  Standard-layout is practically *defined* to ensure that the sizes
> are the same, because it considers non-empty classes derived from empty
> base classes and vice versa to be compatible with C.  Yet, pointer
> arithmetic in this case is undefined.
>
> I see several possible rulesets to my proposal, in increasing order of
> liberalism:
>
> Only allow on standard-layout structures:
> 1. All standard-layout classes whose inheritance hierarchy contains the
> same non-empty base class are compatible in terms of pointer arithmetic.
> 2. Pointer arithmetic is compatible among empty classes that share a base
> class in their hierarchy.  Why you'd have an array of empty classes is
> beyond me, but I don't see a reason to prohibit pointer arithmetic.
> 3. Such arithmetic is only compatible if alignof(Derived) ==
> alignof(NonEmptyBase).  I.e., explicitly aligning the derived class or
> other empty base classes breaks it.
> 4. For all empty classes E and all classes C, alignof(E) <= alignof(C).
> This probably ought to be in the Standard anyway.  Real implementations
> often allow attaching alignment to types, even though alignas does not;
> on such implementations, this can only be forced true for empty classes
> with no alignment directive in the empty class hierarchy.
> 5. The usual rules about double-deriving from the same empty base class
> causing non-emptiness apply.
>
> Only allow without virtual functions:
> 1. A class with no data members of its own that immediately derives from
> exactly one non-empty base class would be pointer-arithmetic-compatible
> with that non-empty base class.
> 2. No class in the hierarchy is allowed to have virtual functions or
> virtual inheritance, including the class in question, or #1 breaks.
> 3. #1 is only true if the alignment is the same, once again.
>
> Only allow without virtual inheritance:
> 1. The same as immediately above, but allow virtual functions.
> 2a. The derived class must not have any virtual functions of its own.  Or
> an alternative rule:
> 2b. All non-destructor virtual functions in the derived class must be
> declared override.
> 3. (Note: This ruleset means that the information required for typeid and
> dynamic_cast to work with the derived type must not increase the size.
> I.e., this would have to be done in the space allocated for the non-empty
> base class, such as its vtable.  In practice, all this is already true.)
>
> Most permissive:
> 1. Like immediately above, except that virtual inheritance is permitted
> within the non-empty base class.
> 2. Virtual inheritance at the current derivation would break it, however.
>
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

I am not sure what problem you are trying to solve. I imagine (have not che=
cked the standard) that when dealing with two *standard-layout*, *layout-co=
mpatible* types pointer arithmetic should be guaranteed to be equivalent by=
 the standard (is it really undefined behavior today? can you point where t=
his is stated?), but I am not sure that I would go further than that. In pa=
rticular considering that I don&#39;t see any motivating use case for the f=
eature...<br><br>=C2=A0 =C2=A0David<br><div class=3D"gmail_quote">On Mon De=
c 01 2014 at 1:10:41 PM Myriachan &lt;<a href=3D"mailto:myriachan@gmail.com=
">myriachan@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">I think that if an empty class derives from exactly one class,=
 or any number of classes whose inheritance hierarchy is empty and exactly =
one whose inheritance hierarchy is non-empty, then pointer arithmetic ought=
 to be legal on the derived class if used on an array of the non-empty base=
 class.=C2=A0 In practice, this is already true: <span style=3D"font-family=
:courier new,monospace">sizeof(Derived) =3D=3D sizeof(NonEmptyBase)</span> =
in pretty much all implementations.=C2=A0 However, the Standard considers t=
his behavior undefined, even for standard-layout structures.<br><br>For sta=
ndard-layout structures, it&#39;s even more clear that this ought to work.=
=C2=A0 Standard-layout is practically *defined* to ensure that the sizes ar=
e the same, because it considers non-empty classes derived from empty base =
classes and vice versa to be compatible with C.=C2=A0 Yet, pointer arithmet=
ic in this case is undefined.<br><br>I see several possible rulesets to my =
proposal, in increasing order of liberalism:<br><br>Only allow on standard-=
layout structures:<br>1. All standard-layout classes whose inheritance hier=
archy contains the same non-empty base class are compatible in terms of poi=
nter arithmetic.<br>2. Pointer arithmetic is compatible among empty classes=
 that share a base class in their hierarchy.=C2=A0 Why you&#39;d have an ar=
ray of empty classes is beyond me, but I don&#39;t see a reason to prohibit=
 pointer arithmetic.<br>3. Such arithmetic is only compatible if <span styl=
e=3D"font-family:courier new,monospace">alignof(Derived) =3D=3D alignof(Non=
EmptyBase)</span>.=C2=A0 I.e., explicitly aligning the derived class or oth=
er empty base classes breaks it.<br>4. For all empty classes E and all clas=
ses C, <span style=3D"font-family:courier new,monospace">alignof(E) &lt;=3D=
 alignof(C)</span>.=C2=A0 This probably ought to be in the Standard anyway.=
=C2=A0 Real implementations often allow attaching alignment to types, even =
though <span style=3D"font-family:courier new,monospace">alignas</span> doe=
s not; on such implementations, this can only be forced true for empty clas=
ses with no alignment directive in the empty class hierarchy.<br>5. The usu=
al rules about double-deriving from the same empty base class causing non-e=
mptiness apply.<br><br>Only allow without virtual functions:<br>1. A class =
with no data members of its own that immediately derives from exactly one n=
on-empty base class would be pointer-arithmetic-compatible with that non-em=
pty base class.<br>2. No class in the hierarchy is allowed to have virtual =
functions or virtual inheritance, including the class in question, or #1 br=
eaks.<br>3. #1 is only true if the alignment is the same, once again.<br><b=
r>Only allow without virtual inheritance:<br>1. The same as immediately abo=
ve, but allow virtual functions.<br>2a. The derived class must not have any=
 virtual functions of its own.=C2=A0 Or an alternative rule:<br>2b. All non=
-destructor virtual functions in the derived class must be declared <span s=
tyle=3D"font-family:courier new,monospace">override</span>.<br>3. (Note: Th=
is ruleset means that the information required for typeid and dynamic_cast =
to work with the derived type must not increase the size.=C2=A0 I.e., this =
would have to be done in the space allocated for the non-empty base class, =
such as its vtable.=C2=A0 In practice, all this is already true.)<br><br>Mo=
st permissive:<br>1. Like immediately above, except that virtual inheritanc=
e is permitted within the non-empty base class.<br>2. Virtual inheritance a=
t the current derivation would break it, however.<br><br>Melissa<br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--90e6ba6e8f9a700c0505093d3588--

.

------=_Part_362_1771660442.1417680643453
Content-Type: multipart/alternative;
 boundary="----=_Part_363_1892844193.1417680643454"

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

On Tuesday, December 2, 2014 7:16:19 AM UTC-8, David Rodr=C3=ADguez Ibeas w=
rote:
>
> [...] I imagine (have not checked the standard) that when dealing with tw=
o=20
> *standard-layout*, *layout-compatible* types pointer arithmetic should be=
=20
> guaranteed to be equivalent by the standard (is it really undefined=20
> behavior today? [...]
>

It's undefined by 5.7/6 (recently amended by DR1865=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1865>):

> For addition or subtraction, if the expressions P or Q have type =E2=80=
=9Cpointer=20
> to cv T=E2=80=9D, where T and the array element type are not similar (4.4=
), the=20
> behavior is undefined. [Note: In particular, a pointer to a base class=20
> cannot be used for pointer arithmetic when the array contains objects of =
a=20
> derived class type. =E2=80=94end note]
>

In other words, the pointer's pointed-to type and the actual element type=
=20
must be exactly the same (ignoring top-level and nested cv qualifiers).

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Tuesday, December 2, 2014 7:16:19 AM UTC-8, David Rodr=
=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">[...] I=
 imagine (have not checked the standard) that when dealing with two *standa=
rd-layout*, *layout-compatible* types pointer arithmetic should be guarante=
ed to be equivalent by the standard (is it really undefined behavior today?=
 [...]<br></blockquote><div><br>It's undefined by 5.7/6 (recently amended b=
y <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1=
865">DR1865</a>):<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te">For addition or subtraction, if the expressions P or Q have type =E2=80=
=9Cpointer to cv T=E2=80=9D, where T and the array element type are not sim=
ilar (4.4), the behavior is undefined. [Note: In particular, a pointer to a=
 base class cannot be used for pointer arithmetic when the array contains o=
bjects of a derived class type. =E2=80=94end note]<span style=3D"color: rgb=
(153, 0, 255);"><br></span></blockquote><br>In other words, the pointer's p=
ointed-to type and the actual element type must be exactly the same (ignori=
ng top-level and nested cv qualifiers).<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_363_1892844193.1417680643454--
------=_Part_362_1771660442.1417680643453--

.

------=_Part_393_2063757417.1418082715584
Content-Type: multipart/alternative;
 boundary="----=_Part_394_1562524822.1418082715584"

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

On Thursday, December 4, 2014 12:10:43 AM UTC-8, Christopher wrote:
>
> On Tuesday, December 2, 2014 7:16:19 AM UTC-8, David Rodr=C3=ADguez Ibeas=
 wrote:
>>
>> [...] I imagine (have not checked the standard) that when dealing with=
=20
>> two *standard-layout*, *layout-compatible* types pointer arithmetic shou=
ld=20
>> be guaranteed to be equivalent by the standard (is it really undefined=
=20
>> behavior today? [...]
>>
>
> It's undefined by 5.7/6 (recently amended by DR1865=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1865>):
>
>> For addition or subtraction, if the expressions P or Q have type =E2=80=
=9Cpointer=20
>> to cv T=E2=80=9D, where T and the array element type are not similar (4.=
4), the=20
>> behavior is undefined. [Note: In particular, a pointer to a base class=
=20
>> cannot be used for pointer arithmetic when the array contains objects of=
 a=20
>> derived class type. =E2=80=94end note]
>>
>
> In other words, the pointer's pointed-to type and the actual element type=
=20
> must be exactly the same (ignoring top-level and nested cv qualifiers).
>

Yes, that is what I'm trying to solve--thanks for looking it up for me,=20
Christopher =3D^-^=3D  The current Standard considers even when the types a=
re=20
standard-layout and layout-compatible with one another.  Note that=20
"similar" in this context (from [conv.qual]) means specifically two pointer=
=20
types in which the only difference is the cv-qualifiers at each pointer=20
level.  I.e. "const char *volatile *" and "char *const *" are "similar".

As for "motivating use case", this is useful when you want to extend an=20
existing standard-layout class, especially a C class, with extra=20
functionality.

struct ipv6_address : public sockaddr_in6
{
    std::string to_string() const;
....
};

Melissa

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Thursday, December 4, 2014 12:10:43 AM UTC-8, Christoph=
er wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On T=
uesday, December 2, 2014 7:16:19 AM UTC-8, David Rodr=C3=ADguez Ibeas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">[...] I imagine (have not checked =
the standard) that when dealing with two *standard-layout*, *layout-compati=
ble* types pointer arithmetic should be guaranteed to be equivalent by the =
standard (is it really undefined behavior today? [...]<br></blockquote><div=
><br>It's undefined by 5.7/6 (recently amended by <a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1865" target=3D"_blank" onmo=
usedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open=
-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231865\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNHTtqBnfF_YtXYVo11g52uj7nm-1Q';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%231865\46sa\75D\46sntz\075=
1\46usg\75AFQjCNHTtqBnfF_YtXYVo11g52uj7nm-1Q';return true;">DR1865</a>):<br=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" class=3D"gmail_quote">For addition or subtract=
ion, if the expressions P or Q have type =E2=80=9Cpointer to cv T=E2=80=9D,=
 where T and the array element type are not similar (4.4), the behavior is =
undefined. [Note: In particular, a pointer to a base class cannot be used f=
or pointer arithmetic when the array contains objects of a derived class ty=
pe. =E2=80=94end note]<span style=3D"color:rgb(153,0,255)"><br></span></blo=
ckquote><br>In other words, the pointer's pointed-to type and the actual el=
ement type must be exactly the same (ignoring top-level and nested cv quali=
fiers).<br></div></div></blockquote><div><br>Yes, that is what I'm trying t=
o solve--thanks for looking it up for me, Christopher =3D^-^=3D&nbsp; The c=
urrent Standard considers even when the types are standard-layout and layou=
t-compatible with one another.&nbsp; Note that "similar" in this context (f=
rom [conv.qual]) means specifically two pointer types in which the only dif=
ference is the cv-qualifiers at each pointer level.&nbsp; I.e. "<span style=
=3D"font-family: courier new,monospace;">const char *volatile *</span>" and=
 "<span style=3D"font-family: courier new,monospace;">char *const *</span>"=
 are "similar".<br><br>As for "motivating use case", this is useful when yo=
u want to extend an existing standard-layout class, especially a C class, w=
ith extra functionality.<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> ipv6_address </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">public</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
ockaddr_in6<br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">s=
tring</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to_s=
tring</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></div></code></div><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_394_1562524822.1418082715584--
------=_Part_393_2063757417.1418082715584--

.