Topic: Syntax for Empty Base Optimization (second attempt)
Author: Avi Kivity <avi@cloudius-systems.com>
Date: Sun, 22 May 2016 07:49:54 -0700 (PDT)
Raw View
------=_Part_1152_34301872.1463928594466
Content-Type: multipart/alternative;
boundary="----=_Part_1153_1041829287.1463928594466"
------=_Part_1153_1041829287.1463928594466
Content-Type: text/plain; charset=UTF-8
Some time ago I proposed [1] new syntax for EBO. At that time the
discussion devolved into an argument about the attribute syntax. I'm
proposing it again, changing the syntax to avoid attributes.
Library writers often find themselves wrapping possibly-empty objects in
synthetic structs to take advantage of EBO:
template <typename T, typename Allocator>
class my_container {
struct alloc_n_size : Allocator {
size_t size;
// ctor etc.
} _M_alloc_n_size; // only occupies sizeof(size_t) if
is_empty<Allocator>.
...
};
Would it not be more comfortable to supply some syntax for this:
template <typename T, typename Allocator>
class my_container {
size_t _M_size;
std::allow_zero_size<Allocator> _M_allocator;
...
};
std::allow_zero_size<> is a library class template that uses compiler magic
to tell the compiler that it is acceptable that the address of _M_allocator
compare equal to that of some other object (that is, it need not insert
padding if sizeof(Allocator) == 0). It overrides operator.() and friends
so that _M_allocator can be used as if std::allow_zero_size<> was not
specified.
The new syntax allows library authors to provide optimized code, while
avoiding the need to write obfuscated code everywhere.
[1]
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-THIcBwAJ
--
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/ef7e4f73-207c-4964-8ba4-1c43869a7301%40isocpp.org.
------=_Part_1153_1041829287.1463928594466
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Some time ago I proposed [1] new syntax for EBO. At t=
hat time the discussion devolved into an argument about the attribute synta=
x. =C2=A0I'm proposing it again, changing the syntax to avoid attribute=
s.</div><div><br></div><div><br></div><div>Library writers often find thems=
elves wrapping possibly-empty objects in synthetic structs to take advantag=
e of EBO:</div><div><br></div><div>=C2=A0 template <typename T, typename=
Allocator></div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=
=A0 =C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //=
ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=A0 // only=
occupies sizeof(size_t) if is_empty<Allocator>.</div><div>=C2=A0 =C2=
=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>Would it not be=
more comfortable to supply some syntax for this:</div><div><br></div><div>=
=C2=A0 template <typename T, typename Allocator></div><div>=C2=A0 cla=
ss my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_size;</div><div>=
=C2=A0 =C2=A0 =C2=A0 std::allow_zero_size<Allocator> _M_allocator;</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><d=
iv>std::allow_zero_size<> is a library class template that uses compi=
ler magic to tell the compiler that it is acceptable that the address of _M=
_allocator compare equal to that of some other object (that is, it need not=
insert padding if sizeof(Allocator) =3D=3D 0). =C2=A0It overrides operator=
..() and friends so that _M_allocator can be used as if std::allow_zero_size=
<> was not specified.</div><div><br></div><div>The new syntax allows =
library authors to provide optimized code, while avoiding the need to write=
obfuscated code everywhere.</div><div><br></div><div>[1] https://groups.go=
ogle.com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-THIcBwAJ<br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ef7e4f73-207c-4964-8ba4-1c43869a7301%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef7e4f73-207c-4964-8ba4-1c43869a7301=
%40isocpp.org</a>.<br />
------=_Part_1153_1041829287.1463928594466--
------=_Part_1152_34301872.1463928594466--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 23 May 2016 17:09:32 -0700 (PDT)
Raw View
------=_Part_3426_2102240640.1464048572518
Content-Type: multipart/alternative;
boundary="----=_Part_3427_119488321.1464048572518"
------=_Part_3427_119488321.1464048572518
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:
>
> Some time ago I proposed [1] new syntax for EBO. At that time the=20
> discussion devolved into an argument about the attribute syntax. I'm=20
> proposing it again, changing the syntax to avoid attributes.
>
> Library writers often find themselves wrapping possibly-empty objects in=
=20
> synthetic structs to take advantage of EBO:
>
> template <typename T, typename Allocator>
> class my_container {
> struct alloc_n_size : Allocator {
> size_t size;
> // ctor etc.
> } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
> is_empty<Allocator>.
> ...
> };
>
> Would it not be more comfortable to supply some syntax for this:
>
> template <typename T, typename Allocator>
> class my_container {
> size_t _M_size;
> std::allow_zero_size<Allocator> _M_allocator;
> ...
> };
>
> std::allow_zero_size<> is a library class template that uses compiler=20
> magic to tell the compiler that it is acceptable that the address of=20
> _M_allocator compare equal to that of some other object (that is, it need=
=20
> not insert padding if sizeof(Allocator) =3D=3D 0). It overrides operator=
..()=20
> and friends so that _M_allocator can be used as if std::allow_zero_size<>=
=20
> was not specified.
>
I think that if it were possible to implement such a std::allow_zero_size<T=
>=20
today, everybody would be doing it (and that includes Boost).
The hard part isn't so much the semantics of the allow_zero_size class=20
template =E2=80=94 that sounds great to me =E2=80=94 but rather the problem=
is that *there=20
is no possible implementation of it* today.
It's kind of like saying "wouldn't it be a good idea if an object named=20
std::cout existed and we could just write std::cout << foo to print the=20
value of any type at all", in the days before operator overloading existed.=
=20
Those high-level semantics (arguably) sound great... but in order to=20
*implement* those semantics, we need someone to do the core-language work=
=20
of figuring out what it means to overload an operator, or in this case, to=
=20
have an object with the same address as a different object.
If I'm wrong and there *does* currently exist a (non-portable but) *working=
* proof-of-concept=20
implementation of foo::allow_zero_size<T>, then that's awesome and I want=
=20
to see it. And your proposal should include a link to it.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fb70edf7-1666-4668-8da7-069c02ee31ee%40isocpp.or=
g.
------=_Part_3427_119488321.1464048572518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Some=
time ago I proposed [1] new syntax for EBO. At that time the discussion de=
volved into an argument about the attribute syntax. =C2=A0I'm proposing=
it again, changing the syntax to avoid attributes.</div><div><br></div><di=
v>Library writers often find themselves wrapping possibly-empty objects in =
synthetic structs to take advantage of EBO:</div><div><br></div><div>=C2=A0=
template <typename T, typename Allocator></div><div>=C2=A0 class my_=
container {</div><div>=C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator =
{</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0=
} _M_alloc_n_size; =C2=A0 // only occupies sizeof(size_t) if is_empty<A=
llocator>.</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><=
div><br></div><div>Would it not be more comfortable to supply some syntax f=
or this:</div><div><br></div><div>=C2=A0 template <typename T, typename =
Allocator></div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0=
=C2=A0 size_t _M_size;</div><div>=C2=A0 =C2=A0 =C2=A0 std::allow_zero_size=
<<wbr>Allocator> _M_allocator;</div><div>=C2=A0 =C2=A0 =C2=A0 ...</di=
v><div>=C2=A0 };</div><div><br></div><div>std::allow_zero_size<> is a=
library class template that uses compiler magic to tell the compiler that =
it is acceptable that the address of _M_allocator compare equal to that of =
some other object (that is, it need not insert padding if sizeof(Allocator)=
=3D=3D 0). =C2=A0It overrides operator.() and friends so that _M_allocator=
can be used as if std::allow_zero_size<> was not specified.</div></d=
iv></blockquote><div><br></div><div>I think that if it were possible to imp=
lement such a <font face=3D"courier new, monospace">std::allow_zero_size<=
;T></font> today, everybody would be doing it (and that includes Boost).=
</div><div>The hard part isn't so much the semantics of the <font face=
=3D"courier new, monospace">allow_zero_size</font> class template =E2=80=94=
that sounds great to me =E2=80=94 but rather the problem is that <i>there =
is no possible implementation of it</i> today.</div><div><br></div><div>It&=
#39;s kind of like saying "wouldn't it be a good idea if an object=
named <font face=3D"courier new, monospace">std::cout</font> existed and w=
e could just write <font face=3D"courier new, monospace">std::cout <<=
foo</font> to print the value of any type at all", in the days before=
operator overloading existed. =C2=A0Those high-level semantics (arguably) =
sound great... but in order to <i>implement</i> those semantics, we need so=
meone to do the core-language work of figuring out what it means to overloa=
d an operator, or in this case, to have an object with the same address as =
a different object.</div><div><br></div><div>If I'm wrong and there <i>=
does</i> currently exist a (non-portable but) <i>working</i>=C2=A0proof-of-=
concept implementation of <font face=3D"courier new, monospace">foo::allow_=
zero_size<T></font>, then that's awesome and I want to see it. An=
d your proposal should include a link to it.</div><div><br></div><div>=E2=
=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb70edf7-1666-4668-8da7-069c02ee31ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fb70edf7-1666-4668-8da7-069c02ee31ee=
%40isocpp.org</a>.<br />
------=_Part_3427_119488321.1464048572518--
------=_Part_3426_2102240640.1464048572518--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 23 May 2016 20:17:56 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">From the original : "<span style=3D"line-height: initial;">std:=
:allow_zero_size<> is a library class template that uses compiler mag=
ic</span><span style=3D"font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; font-size: initial; text-align: initial; line-height: initial;">"</=
span></div><div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; font-size: initial; text=
-align: initial; line-height: initial;"><br></span></div><div style=3D"widt=
h: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif,=
sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color=
: rgb(255, 255, 255);"><span style=3D"font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; font-size: initial; text-align: initial; line-height:=
initial;">"Compiler magic" means there is no way for me or you to write it=
, but we could mandate that compilers recognize allow_zero_size<> and=
magically make it work. </span></div><div style=3D"width: 100%; font-=
size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; c=
olor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255=
, 255);"><span style=3D"font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; font-size: initial; text-align: initial; line-height: initial;"><br=
></span></div><div style=3D"width: 100%; font-size: initial; font-family: C=
alibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-=
align: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; font-size: initial; t=
ext-align: initial; line-height: initial;">Maybe</span></div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);"><span style=3D"font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; font-size: initial; text-align: initial; line-hei=
ght: initial;"><br></span></div><div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><s=
pan style=3D"font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; fon=
t-size: initial; text-align: initial; line-height: initial;">Allocator a[0]=
; </span></div><div style=3D"width: 100%; font-size: initial; font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125);=
text-align: initial; background-color: rgb(255, 255, 255);"><span style=3D=
"font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; font-size: init=
ial; text-align: initial; line-height: initial;"><br></span></div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"><span style=3D"font-family: Calibri, 'Slate=
Pro', sans-serif, sans-serif; font-size: initial; text-align: initial; lin=
e-height: initial;">Would be an acceptable language alternative. </spa=
n></div><div style=3D"width: 100%; font-size: initial; font-family: Calibri=
, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align:=
initial; background-color: rgb(255, 255, 255);"><span style=3D"font-size: =
initial; line-height: initial; text-align: initial;">Or</span></div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; line-h=
eight: initial; text-align: initial;"><br></span></div><div style=3D"width:=
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><span style=3D"font-size: initial; line-height: initia=
l; text-align: initial;">Allocator a =3D delete; //default? register? ...</=
span></div><div style=3D"width: 100%; font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; font-size: initial; text=
-align: initial; line-height: initial;"><br></span></div><div style=3D"widt=
h: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif,=
sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color=
: rgb(255, 255, 255);"><span style=3D"font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; font-size: initial; text-align: initial; line-height:=
initial;">Otherwise, you need a new keyword. </span></div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br></div> =
=
<div style=3D"width: 100%; font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);"><br style=3D"dis=
play:initial"></div> =
=
<div style=
=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);">Sent from my BlackBerry portable =
;Babbage Device</div> =
=
<table width=3D"100%"=
style=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colsp=
an=3D"2" style=3D"font-size: initial; text-align: initial; background-color=
: rgb(255, 255, 255);"> <div style=3D"border-styl=
e: solid none none; border-top-color: rgb(181, 196, 223); border-top-width:=
1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pr=
o'; font-size: 10pt;"> <div><b>From: </b>Arthur O'Dwyer</div><div><b>Sent:=
</b>Monday, May 23, 2016 8:09 PM</div><div><b>To: </b>ISO C++ Standard - F=
uture Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.org</div><d=
iv><b>Subject: </b>[std-proposals] Re: Syntax for Empty Base Optimization (=
second attempt)</div></div></td></tr></tbody></table><div style=3D"border-s=
tyle: solid none none; border-top-color: rgb(186, 188, 209); border-top-wid=
th: 1pt; font-size: initial; text-align: initial; background-color: rgb(255=
, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D=
"ltr">On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Some time ago I=
proposed [1] new syntax for EBO. At that time the discussion devolved into=
an argument about the attribute syntax. I'm proposing it again, chan=
ging the syntax to avoid attributes.</div><div><br></div><div>Library write=
rs often find themselves wrapping possibly-empty objects in synthetic struc=
ts to take advantage of EBO:</div><div><br></div><div> template <t=
ypename T, typename Allocator></div><div> class my_container {</di=
v><div> struct alloc_n_size : Allocator {</div><div>&nb=
sp; size_t size;</div><div> =
// ctor etc.</div><div> } _M_alloc_n_siz=
e; // only occupies sizeof(size_t) if is_empty<Allocator>.</di=
v><div> ...</div><div> };</div><div><br></div><di=
v>Would it not be more comfortable to supply some syntax for this:</div><di=
v><br></div><div> template <typename T, typename Allocator></di=
v><div> class my_container {</div><div> size_t _M=
_size;</div><div> std::allow_zero_size<<wbr>Allocato=
r> _M_allocator;</div><div> ...</div><div> };<=
/div><div><br></div><div>std::allow_zero_size<> is a library class te=
mplate that uses compiler magic to tell the compiler that it is acceptable =
that the address of _M_allocator compare equal to that of some other object=
(that is, it need not insert padding if sizeof(Allocator) =3D=3D 0).  =
;It overrides operator.() and friends so that _M_allocator can be used as i=
f std::allow_zero_size<> was not specified.</div></div></blockquote><=
div><br></div><div>I think that if it were possible to implement such a <fo=
nt face=3D"courier new, monospace">std::allow_zero_size<T></font> tod=
ay, everybody would be doing it (and that includes Boost).</div><div>The ha=
rd part isn't so much the semantics of the <font face=3D"courier new, monos=
pace">allow_zero_size</font> class template =E2=80=94 that sounds great to =
me =E2=80=94 but rather the problem is that <i>there is no possible impleme=
ntation of it</i> today.</div><div><br></div><div>It's kind of like saying =
"wouldn't it be a good idea if an object named <font face=3D"courier new, m=
onospace">std::cout</font> existed and we could just write <font face=3D"co=
urier new, monospace">std::cout << foo</font> to print the value of a=
ny type at all", in the days before operator overloading existed. Tho=
se high-level semantics (arguably) sound great... but in order to <i>implem=
ent</i> those semantics, we need someone to do the core-language work of fi=
guring out what it means to overload an operator, or in this case, to have =
an object with the same address as a different object.</div><div><br></div>=
<div>If I'm wrong and there <i>does</i> currently exist a (non-portable but=
) <i>working</i> proof-of-concept implementation of <font face=3D"cour=
ier new, monospace">foo::allow_zero_size<T></font>, then that's aweso=
me and I want to see it. And your proposal should include a link to it.</di=
v><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fb70edf7-1666-4668-8da7-069c02ee31ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/fb70edf7-1666-4668-8da7-069c02ee=
31ee%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160524001756.4890705.90511.11218%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160524001756.4890705.90511.11218%40gm=
ail.com</a>.<br />
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 23 May 2016 18:07:58 -0700
Raw View
--089e013d0dee48916805338c31e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Or a context-sensitive keyword like override. I don't fully understand the
constraints on them, but "Type var allow_empty;" could work. Dunno if we
want "allow_empty" or something more directly connected to the effect like
"allow_same_address".
On Mon, May 23, 2016 at 5:17 PM, Tony V E <tvaneerd@gmail.com> wrote:
> From the original : "std::allow_zero_size<> is a library class template
> that uses compiler magic"
>
> "Compiler magic" means there is no way for me or you to write it, but we
> could mandate that compilers recognize allow_zero_size<> and magically ma=
ke
> it work.
>
> Maybe
>
> Allocator a[0];
>
> Would be an acceptable language alternative.
> Or
>
> Allocator a =3D delete; //default? register? ...
>
> Otherwise, you need a new keyword.
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Arthur O'Dwyer
> *Sent: *Monday, May 23, 2016 8:09 PM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-proposals@isocpp.org
> *Subject: *[std-proposals] Re: Syntax for Empty Base Optimization (second
> attempt)
>
> On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:
>>
>> Some time ago I proposed [1] new syntax for EBO. At that time the
>> discussion devolved into an argument about the attribute syntax. I'm
>> proposing it again, changing the syntax to avoid attributes.
>>
>> Library writers often find themselves wrapping possibly-empty objects in
>> synthetic structs to take advantage of EBO:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> struct alloc_n_size : Allocator {
>> size_t size;
>> // ctor etc.
>> } _M_alloc_n_size; // only occupies sizeof(size_t) if
>> is_empty<Allocator>.
>> ...
>> };
>>
>> Would it not be more comfortable to supply some syntax for this:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> size_t _M_size;
>> std::allow_zero_size<Allocator> _M_allocator;
>> ...
>> };
>>
>> std::allow_zero_size<> is a library class template that uses compiler
>> magic to tell the compiler that it is acceptable that the address of
>> _M_allocator compare equal to that of some other object (that is, it nee=
d
>> not insert padding if sizeof(Allocator) =3D=3D 0). It overrides operato=
r.()
>> and friends so that _M_allocator can be used as if std::allow_zero_size<=
>
>> was not specified.
>>
>
> I think that if it were possible to implement such a
> std::allow_zero_size<T> today, everybody would be doing it (and that
> includes Boost).
> The hard part isn't so much the semantics of the allow_zero_size class
> template =E2=80=94 that sounds great to me =E2=80=94 but rather the probl=
em is that *there
> is no possible implementation of it* today.
>
> It's kind of like saying "wouldn't it be a good idea if an object named
> std::cout existed and we could just write std::cout << foo to print the
> value of any type at all", in the days before operator overloading
> existed. Those high-level semantics (arguably) sound great... but in ord=
er
> to *implement* those semantics, we need someone to do the core-language
> work of figuring out what it means to overload an operator, or in this
> case, to have an object with the same address as a different object.
>
> If I'm wrong and there *does* currently exist a (non-portable but)
> *working* proof-of-concept implementation of foo::allow_zero_size<T>,
> then that's awesome and I want to see it. And your proposal should includ=
e
> a link to it.
>
> =E2=80=93Arthur
>
> --
> 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/fb70edf7-166=
6-4668-8da7-069c02ee31ee%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fb70edf7-16=
66-4668-8da7-069c02ee31ee%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
> --
> 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/201605240017=
56.4890705.90511.11218%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160524001=
756.4890705.90511.11218%40gmail.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/CANh-dX%3D-%2BXEtD_oZ6y50iomgVp1szQyKQycnqHO9TZv=
5mvgCGA%40mail.gmail.com.
--089e013d0dee48916805338c31e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Or a context-sensitive keyword like override. I don't =
fully understand the constraints on them, but "Type var allow_empty;&q=
uot; could work. Dunno if we want "allow_empty" or something more=
directly connected to the effect like "allow_same_address".=C2=
=A0</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, =
May 23, 2016 at 5:17 PM, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"backgroun=
d-color:rgb(255,255,255);line-height:initial"> =
<div style=3D"widt=
h:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif=
,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(25=
5,255,255)">From the original : "<span style=3D"line-height:initial">s=
td::allow_zero_size<> is a library class template that uses compiler =
magic</span><span style=3D"font-family:Calibri,'Slate Pro',sans-ser=
if,sans-serif;font-size:initial;text-align:initial;line-height:initial">&qu=
ot;</span></div><div style=3D"width:100%;font-size:initial;font-family:Cali=
bri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-ali=
gn:initial;background-color:rgb(255,255,255)"><span style=3D"font-family:Ca=
libri,'Slate Pro',sans-serif,sans-serif;font-size:initial;text-alig=
n:initial;line-height:initial"><br></span></div><div style=3D"width:100%;fo=
nt-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-ser=
if;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255=
)"><span style=3D"font-family:Calibri,'Slate Pro',sans-serif,sans-s=
erif;font-size:initial;text-align:initial;line-height:initial">"Compil=
er magic" means there is no way for me or you to write it, but we coul=
d mandate that compilers recognize allow_zero_size<> and magically ma=
ke it work.=C2=A0</span></div><div style=3D"width:100%;font-size:initial;fo=
nt-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73=
,125);text-align:initial;background-color:rgb(255,255,255)"><span style=3D"=
font-family:Calibri,'Slate Pro',sans-serif,sans-serif;font-size:ini=
tial;text-align:initial;line-height:initial"><br></span></div><div style=3D=
"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)"><span style=3D"font-family:Calibri,'Slate Pro',san=
s-serif,sans-serif;font-size:initial;text-align:initial;line-height:initial=
">Maybe</span></div><div style=3D"width:100%;font-size:initial;font-family:=
Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text=
-align:initial;background-color:rgb(255,255,255)"><span style=3D"font-famil=
y:Calibri,'Slate Pro',sans-serif,sans-serif;font-size:initial;text-=
align:initial;line-height:initial"><br></span></div><div style=3D"width:100=
%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans=
-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255=
,255)"><span style=3D"font-family:Calibri,'Slate Pro',sans-serif,sa=
ns-serif;font-size:initial;text-align:initial;line-height:initial">Allocato=
r a[0];=C2=A0</span></div><div style=3D"width:100%;font-size:initial;font-f=
amily:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)"><span style=3D"font=
-family:Calibri,'Slate Pro',sans-serif,sans-serif;font-size:initial=
;text-align:initial;line-height:initial"><br></span></div><div style=3D"wid=
th:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-seri=
f,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(2=
55,255,255)"><span style=3D"font-family:Calibri,'Slate Pro',sans-se=
rif,sans-serif;font-size:initial;text-align:initial;line-height:initial">Wo=
uld be an acceptable language alternative.=C2=A0</span></div><div style=3D"=
width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-s=
erif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rg=
b(255,255,255)"><span style=3D"font-size:initial;line-height:initial;text-a=
lign:initial">Or</span></div><div style=3D"width:100%;font-size:initial;fon=
t-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,=
125);text-align:initial;background-color:rgb(255,255,255)"><span style=3D"f=
ont-size:initial;line-height:initial;text-align:initial"><br></span></div><=
div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pr=
o',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)"><span style=3D"font-size:initial;line-height:i=
nitial;text-align:initial">Allocator a =3D delete; //default? register? ...=
</span></div><div style=3D"width:100%;font-size:initial;font-family:Calibri=
,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:=
initial;background-color:rgb(255,255,255)"><span style=3D"font-family:Calib=
ri,'Slate Pro',sans-serif,sans-serif;font-size:initial;text-align:i=
nitial;line-height:initial"><br></span></div><div style=3D"width:100%;font-=
size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;=
color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">=
<span style=3D"font-family:Calibri,'Slate Pro',sans-serif,sans-seri=
f;font-size:initial;text-align:initial;line-height:initial">Otherwise, you =
need a new keyword. </span></div><div style=3D"width:100%;font-size:initial=
;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div> =
=
<div style=3D"width=
:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,=
sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255=
,255,255)"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size:initial;font-family:Calibri,'S=
late Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial=
;background-color:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=
=C2=A0portable=C2=A0Babbage=C2=A0Device</div> =
=
<t=
able width=3D"100%" style=3D"background-color:white;border-spacing:0px"> <t=
body><tr><td colspan=3D"2" style=3D"font-size:initial;text-align:initial;ba=
ckground-color:rgb(255,255,255)"> <div style=3D"b=
order-style:solid none none;border-top-color:rgb(181,196,223);border-top-wi=
dth:1pt;padding:3pt 0in 0in;font-family:Tahoma,'BB Alpha Sans','=
;Slate Pro';font-size:10pt"> <div><b>From: </b>Arthur O'Dwyer</div=
><div><b>Sent: </b>Monday, May 23, 2016 8:09 PM</div><div><b>To: </b>ISO C+=
+ Standard - Future Proposals</div><div><b>Reply To: </b><a href=3D"mailto:=
std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a></d=
iv><div><b>Subject: </b>[std-proposals] Re: Syntax for Empty Base Optimizat=
ion (second attempt)</div></div></td></tr></tbody></table><div><div class=
=3D"h5"><div style=3D"border-style:solid none none;border-top-color:rgb(186=
,188,209);border-top-width:1pt;font-size:initial;text-align:initial;backgro=
und-color:rgb(255,255,255)"></div><br><div><div dir=3D"ltr">On Sunday, May =
22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>Some time ago I proposed [1] new syntax f=
or EBO. At that time the discussion devolved into an argument about the att=
ribute syntax.=C2=A0 I'm proposing it again, changing the syntax to avo=
id attributes.</div><div><br></div><div>Library writers often find themselv=
es wrapping possibly-empty objects in synthetic structs to take advantage o=
f EBO:</div><div><br></div><div>=C2=A0 template <typename T, typename Al=
locator></div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =
=C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // cto=
r etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=A0 // only occ=
upies sizeof(size_t) if is_empty<Allocator>.</div><div>=C2=A0 =C2=A0 =
=C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>Would it not be mor=
e comfortable to supply some syntax for this:</div><div><br></div><div>=C2=
=A0 template <typename T, typename Allocator></div><div>=C2=A0 class =
my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_size;</div><div>=C2=
=A0 =C2=A0 =C2=A0 std::allow_zero_size<Allocator> _M_allocator;</div>=
<div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>=
std::allow_zero_size<> is a library class template that uses compiler=
magic to tell the compiler that it is acceptable that the address of _M_al=
locator compare equal to that of some other object (that is, it need not in=
sert padding if sizeof(Allocator) =3D=3D 0).=C2=A0 It overrides operator.()=
and friends so that _M_allocator can be used as if std::allow_zero_size<=
;> was not specified.</div></div></blockquote><div><br></div><div>I thin=
k that if it were possible to implement such a <font face=3D"courier new, m=
onospace">std::allow_zero_size<T></font> today, everybody would be do=
ing it (and that includes Boost).</div><div>The hard part isn't so much=
the semantics of the <font face=3D"courier new, monospace">allow_zero_size=
</font> class template =E2=80=94 that sounds great to me =E2=80=94 but rath=
er the problem is that <i>there is no possible implementation of it</i> tod=
ay.</div><div><br></div><div>It's kind of like saying "wouldn'=
t it be a good idea if an object named <font face=3D"courier new, monospace=
">std::cout</font> existed and we could just write <font face=3D"courier ne=
w, monospace">std::cout << foo</font> to print the value of any type =
at all", in the days before operator overloading existed.=C2=A0 Those =
high-level semantics (arguably) sound great... but in order to <i>implement=
</i> those semantics, we need someone to do the core-language work of figur=
ing out what it means to overload an operator, or in this case, to have an =
object with the same address as a different object.</div><div><br></div><di=
v>If I'm wrong and there <i>does</i> currently exist a (non-portable bu=
t) <i>working</i>=C2=A0proof-of-concept implementation of <font face=3D"cou=
rier new, monospace">foo::allow_zero_size<T></font>, then that's =
awesome and I want to see it. And your proposal should include a link to it=
..</div><div><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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/fb70edf7-1666-4668-8da7-069c02ee31ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fb70edf7-1666-=
4668-8da7-069c02ee31ee%40isocpp.org</a>.<br>
<br></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20160524001756.4890705.90511.11218%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160524001756.48=
90705.90511.11218%40gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D-%2BXEtD_oZ6y50iomgVp1szQyK=
QycnqHO9TZv5mvgCGA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3D-%2=
BXEtD_oZ6y50iomgVp1szQyKQycnqHO9TZv5mvgCGA%40mail.gmail.com</a>.<br />
--089e013d0dee48916805338c31e2--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 May 2016 10:40:44 -0700 (PDT)
Raw View
------=_Part_1591_1609830444.1464111644116
Content-Type: multipart/alternative;
boundary="----=_Part_1592_8443047.1464111644117"
------=_Part_1592_8443047.1464111644117
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, May 23, 2016 at 8:09:32 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:
>>
>> Some time ago I proposed [1] new syntax for EBO. At that time the=20
>> discussion devolved into an argument about the attribute syntax. I'm=20
>> proposing it again, changing the syntax to avoid attributes.
>>
>> Library writers often find themselves wrapping possibly-empty objects in=
=20
>> synthetic structs to take advantage of EBO:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> struct alloc_n_size : Allocator {
>> size_t size;
>> // ctor etc.
>> } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
>> is_empty<Allocator>.
>> ...
>> };
>>
>> Would it not be more comfortable to supply some syntax for this:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> size_t _M_size;
>> std::allow_zero_size<Allocator> _M_allocator;
>> ...
>> };
>>
>> std::allow_zero_size<> is a library class template that uses compiler=20
>> magic to tell the compiler that it is acceptable that the address of=20
>> _M_allocator compare equal to that of some other object (that is, it nee=
d=20
>> not insert padding if sizeof(Allocator) =3D=3D 0). It overrides operato=
r.()=20
>> and friends so that _M_allocator can be used as if std::allow_zero_size<=
>=20
>> was not specified.
>>
>
> I think that if it were possible to implement such a=20
> std::allow_zero_size<T> today, everybody would be doing it (and that=20
> includes Boost).
> The hard part isn't so much the semantics of the allow_zero_size class=20
> template =E2=80=94 that sounds great to me =E2=80=94 but rather the probl=
em is that *there=20
> is no possible implementation of it* today.
>
> It's kind of like saying "wouldn't it be a good idea if an object named=
=20
> std::cout existed and we could just write std::cout << foo to print the=
=20
> value of any type at all", in the days before operator overloading existe=
d.=20
> Those high-level semantics (arguably) sound great... but in order to=20
> *implement* those semantics, we need someone to do the core-language work=
=20
> of figuring out what it means to overload an operator, or in this case, t=
o=20
> have an object with the same address as a different object.
>
To be fair, we already have that. Standard layout types with empty base=20
classes *require* that the base class pointers point to the derived=20
classes. They enforce EBO.
It's simply a matter of expanding that to members. But doing so in a way=20
that doesn't break the layout of existing members.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ae183578-af1b-49af-9b30-5d2661a6a41a%40isocpp.or=
g.
------=_Part_1592_8443047.1464111644117
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, May 23, 2016 at 8:09:32 PM UTC-4, Arthu=
r O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Some time ago I p=
roposed [1] new syntax for EBO. At that time the discussion devolved into a=
n argument about the attribute syntax. =C2=A0I'm proposing it again, ch=
anging the syntax to avoid attributes.</div><div><br></div><div>Library wri=
ters often find themselves wrapping possibly-empty objects in synthetic str=
ucts to take advantage of EBO:</div><div><br></div><div>=C2=A0 template <=
;typename T, typename Allocator></div><div>=C2=A0 class my_container {</=
div><div>=C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_=
size; =C2=A0 // only occupies sizeof(size_t) if is_empty<Allocator>.<=
/div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div>=
<div>Would it not be more comfortable to supply some syntax for this:</div>=
<div><br></div><div>=C2=A0 template <typename T, typename Allocator><=
/div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t=
_M_size;</div><div>=C2=A0 =C2=A0 =C2=A0 std::allow_zero_size<<wbr>Alloc=
ator> _M_allocator;</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 =
};</div><div><br></div><div>std::allow_zero_size<> is a library class=
template that uses compiler magic to tell the compiler that it is acceptab=
le that the address of _M_allocator compare equal to that of some other obj=
ect (that is, it need not insert padding if sizeof(Allocator) =3D=3D 0). =
=C2=A0It overrides operator.() and friends so that _M_allocator can be used=
as if std::allow_zero_size<> was not specified.</div></div></blockqu=
ote><div><br></div><div>I think that if it were possible to implement such =
a <font face=3D"courier new, monospace">std::allow_zero_size<T></font=
> today, everybody would be doing it (and that includes Boost).</div><div>T=
he hard part isn't so much the semantics of the <font face=3D"courier n=
ew, monospace">allow_zero_size</font> class template =E2=80=94 that sounds =
great to me =E2=80=94 but rather the problem is that <i>there is no possibl=
e implementation of it</i> today.</div><div><br></div><div>It's kind of=
like saying "wouldn't it be a good idea if an object named <font =
face=3D"courier new, monospace">std::cout</font> existed and we could just =
write <font face=3D"courier new, monospace">std::cout << foo</font> t=
o print the value of any type at all", in the days before operator ove=
rloading existed. =C2=A0Those high-level semantics (arguably) sound great..=
.. but in order to <i>implement</i> those semantics, we need someone to do t=
he core-language work of figuring out what it means to overload an operator=
, or in this case, to have an object with the same address as a different o=
bject.</div></div></blockquote><div><br>To be fair, we already have that. S=
tandard layout types with empty base classes <i>require</i> that the base c=
lass pointers point to the derived classes. They enforce EBO.<br><br>It'=
;s simply a matter of expanding that to members. But doing so in a way that=
doesn't break the layout of existing members.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae183578-af1b-49af-9b30-5d2661a6a41a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae183578-af1b-49af-9b30-5d2661a6a41a=
%40isocpp.org</a>.<br />
------=_Part_1592_8443047.1464111644117--
------=_Part_1591_1609830444.1464111644116--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 May 2016 11:24:10 -0700 (PDT)
Raw View
------=_Part_459_628838486.1464114250822
Content-Type: multipart/alternative;
boundary="----=_Part_460_998952254.1464114250822"
------=_Part_460_998952254.1464114250822
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 24, 2016 at 1:40:44 PM UTC-4, Nicol Bolas wrote:
>
> On Monday, May 23, 2016 at 8:09:32 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:
>>>
>>> Some time ago I proposed [1] new syntax for EBO. At that time the=20
>>> discussion devolved into an argument about the attribute syntax. I'm=
=20
>>> proposing it again, changing the syntax to avoid attributes.
>>>
>>> Library writers often find themselves wrapping possibly-empty objects i=
n=20
>>> synthetic structs to take advantage of EBO:
>>>
>>> template <typename T, typename Allocator>
>>> class my_container {
>>> struct alloc_n_size : Allocator {
>>> size_t size;
>>> // ctor etc.
>>> } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
>>> is_empty<Allocator>.
>>> ...
>>> };
>>>
>>> Would it not be more comfortable to supply some syntax for this:
>>>
>>> template <typename T, typename Allocator>
>>> class my_container {
>>> size_t _M_size;
>>> std::allow_zero_size<Allocator> _M_allocator;
>>> ...
>>> };
>>>
>>> std::allow_zero_size<> is a library class template that uses compiler=
=20
>>> magic to tell the compiler that it is acceptable that the address of=20
>>> _M_allocator compare equal to that of some other object (that is, it ne=
ed=20
>>> not insert padding if sizeof(Allocator) =3D=3D 0). It overrides operat=
or.()=20
>>> and friends so that _M_allocator can be used as if std::allow_zero_size=
<>=20
>>> was not specified.
>>>
>>
>> I think that if it were possible to implement such a=20
>> std::allow_zero_size<T> today, everybody would be doing it (and that=20
>> includes Boost).
>> The hard part isn't so much the semantics of the allow_zero_size class=
=20
>> template =E2=80=94 that sounds great to me =E2=80=94 but rather the prob=
lem is that *there=20
>> is no possible implementation of it* today.
>>
>> It's kind of like saying "wouldn't it be a good idea if an object named=
=20
>> std::cout existed and we could just write std::cout << foo to print the=
=20
>> value of any type at all", in the days before operator overloading exist=
ed.=20
>> Those high-level semantics (arguably) sound great... but in order to=20
>> *implement* those semantics, we need someone to do the core-language=20
>> work of figuring out what it means to overload an operator, or in this=
=20
>> case, to have an object with the same address as a different object.
>>
>
> To be fair, we already have that. Standard layout types with empty base=
=20
> classes *require* that the base class pointers point to the derived=20
> classes. They enforce EBO.
>
> It's simply a matter of expanding that to members. But doing so in a way=
=20
> that doesn't break the layout of existing members.
>
To expand on this, I once wrote up a prospective proposa=20
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/stat=
eless$20inner/std-proposals/HjGujSdKXX0/27WIWTc_EwAJ>l=20
that included "stateless classes": empty types which would *always* not=20
take up space. That's slightly different compared to what the OP wants; he=
=20
wants a variable to possibly take up space or not, depending on whether the=
=20
type is empty. His happens at the cite of use; my happens at the cite of=20
declaration.
I think the OP's proposal could work with my `stateless` construct, with=20
two small changes to it. First, as I specified it, a `stateless` class=20
cannot have subobjects of non-stateless type. That could be expanded to=20
allow base-class subobjects of empty types. Since all stateless classes are=
=20
by definition standard layout, they are required to have EBO. So their=20
pointers would already be considered "related" to a pointer to a derived=20
class, and thus allowed to be equal.
The other change would be permitting the `stateless` specifier to take a=20
constant expression, like `noexcept`. If that expression evaluates to=20
`true`, then the type is stateless; if it evaluates to false, it is not.
That would allow you to implement the OP's idea as follows:
template<typename T>
stateless(is_empty_v<T>) struct allow_zero_size : public T
{
using T::T; //Forward constructors; inherit everything else.
};
If `T` is empty, then `allow_zero_size<T>` will be stateless.
I would say that a class which is marked as conditionally stateless should=
=20
have all of the limitations of stateless types as I outline them (not being=
=20
able to be aggregated into arrays).
I don't think there are any issues with implementing `stateless` types,=20
within the limitations as I outlined them in my proposal. The key issue I=
=20
sidestepped with my proposal was that `stateless` types are *not*=20
zero-sized. They simply do not affect the size or layout of the types they=
=20
are a subobject of.
The standardese issue is a bigger deal. Though `stateless` types not being=
=20
zero-sized probably sidesteps most of the big issues.
--=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/8ad44136-c933-405e-bb72-d97204bee863%40isocpp.or=
g.
------=_Part_460_998952254.1464114250822
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 24, 2016 at 1:40:44 PM UTC-4, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Mond=
ay, May 23, 2016 at 8:09:32 PM UTC-4, Arthur O'Dwyer 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 Sunday, May 22, 2016 at 7:4=
9:54 AM UTC-7, Avi Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>Some time ago I proposed [1] new syntax for EBO. At that=
time the discussion devolved into an argument about the attribute syntax. =
=C2=A0I'm proposing it again, changing the syntax to avoid attributes.<=
/div><div><br></div><div>Library writers often find themselves wrapping pos=
sibly-empty objects in synthetic structs to take advantage of EBO:</div><di=
v><br></div><div>=C2=A0 template <typename T, typename Allocator></di=
v><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 struct al=
loc_n_size : Allocator {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_=
t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ctor etc.</div><div=
>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=A0 // only occupies sizeof(siz=
e_t) if is_empty<Allocator>.</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div>=
<div>=C2=A0 };</div><div><br></div><div>Would it not be more comfortable to=
supply some syntax for this:</div><div><br></div><div>=C2=A0 template <=
typename T, typename Allocator></div><div>=C2=A0 class my_container {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_size;</div><div>=C2=A0 =C2=A0 =C2=A0=
std::allow_zero_size<<wbr>Allocator> _M_allocator;</div><div>=C2=A0 =
=C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>std::allow_z=
ero_size<> is a library class template that uses compiler magic to te=
ll the compiler that it is acceptable that the address of _M_allocator comp=
are equal to that of some other object (that is, it need not insert padding=
if sizeof(Allocator) =3D=3D 0). =C2=A0It overrides operator.() and friends=
so that _M_allocator can be used as if std::allow_zero_size<> was no=
t specified.</div></div></blockquote><div><br></div><div>I think that if it=
were possible to implement such a <font face=3D"courier new, monospace">st=
d::allow_zero_size<T></font> today, everybody would be doing it (and =
that includes Boost).</div><div>The hard part isn't so much the semanti=
cs of the <font face=3D"courier new, monospace">allow_zero_size</font> clas=
s template =E2=80=94 that sounds great to me =E2=80=94 but rather the probl=
em is that <i>there is no possible implementation of it</i> today.</div><di=
v><br></div><div>It's kind of like saying "wouldn't it be a go=
od idea if an object named <font face=3D"courier new, monospace">std::cout<=
/font> existed and we could just write <font face=3D"courier new, monospace=
">std::cout << foo</font> to print the value of any type at all"=
, in the days before operator overloading existed. =C2=A0Those high-level s=
emantics (arguably) sound great... but in order to <i>implement</i> those s=
emantics, we need someone to do the core-language work of figuring out what=
it means to overload an operator, or in this case, to have an object with =
the same address as a different object.</div></div></blockquote><div><br>To=
be fair, we already have that. Standard layout types with empty base class=
es <i>require</i> that the base class pointers point to the derived classes=
.. They enforce EBO.<br><br>It's simply a matter of expanding that to me=
mbers. But doing so in a way that doesn't break the layout of existing =
members.</div></div></blockquote><div><br>To expand on this, I <a href=3D"h=
ttps://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/statel=
ess$20inner/std-proposals/HjGujSdKXX0/27WIWTc_EwAJ">once wrote up a prospec=
tive proposa</a>l that included "stateless classes": empty types =
which would <i>always</i> not take up space. That's slightly different =
compared to what the OP wants; he wants a variable to possibly take up spac=
e or not, depending on whether the type is empty. His happens at the cite o=
f use; my happens at the cite of declaration.<br><br>I think the OP's p=
roposal could work with my `stateless` construct, with two small changes to=
it. First, as I specified it, a `stateless` class cannot have subobjects o=
f non-stateless type. That could be expanded to allow base-class subobjects=
of empty types. Since all stateless classes are by definition standard lay=
out, they are required to have EBO. So their pointers would already be cons=
idered "related" to a pointer to a derived class, and thus allowe=
d to be equal.<br><br>The other change would be permitting the `stateless` =
specifier to take a constant expression, like `noexcept`. If that expressio=
n evaluates to `true`, then the type is stateless; if it evaluates to false=
, it is not.<br><br>That would allow you to implement the OP's idea as =
follows:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>stateless</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">is_empty_v</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #6=
60;" 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">struct</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> allow_zero_size </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">public</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">//Forward constructors; inherit everything else.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></di=
v><br>If `T` is empty, then `allow_zero_size<T>` will be stateless.<b=
r><br>I would say that a class which is marked as conditionally stateless s=
hould have all of the limitations of stateless types as I outline them (not=
being able to be aggregated into arrays).<br><br>I don't think there a=
re any issues with implementing `stateless` types, within the limitations a=
s I outlined them in my proposal. The key issue I sidestepped with my propo=
sal was that `stateless` types are <i>not</i> zero-sized. They simply do no=
t affect the size or layout of the types they are a subobject of.<br><br>Th=
e standardese issue is a bigger deal. Though `stateless` types not being ze=
ro-sized probably sidesteps most of the big issues.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ad44136-c933-405e-bb72-d97204bee863%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ad44136-c933-405e-bb72-d97204bee863=
%40isocpp.org</a>.<br />
------=_Part_460_998952254.1464114250822--
------=_Part_459_628838486.1464114250822--
.
Author: Vinnie Falco <vinnie.falco@gmail.com>
Date: Wed, 25 May 2016 03:32:53 -0700 (PDT)
Raw View
------=_Part_1339_708973491.1464172373736
Content-Type: multipart/alternative;
boundary="----=_Part_1340_2117477073.1464172373736"
------=_Part_1340_2117477073.1464172373736
Content-Type: text/plain; charset=UTF-8
On Sunday, May 22, 2016 at 10:49:54 AM UTC-4, Avi Kivity wrote:
>
> std::allow_zero_size<> is a library class template that uses compiler
> magic to tell the compiler that it is acceptable that the address of
> _M_allocator compare equal to that of some other object (that is, it need
> not insert padding if sizeof(Allocator) == 0).
>
Here's a solution that works today, the syntax is based on
boost::base_from_member:
https://github.com/vinniefalco/Beast/blob/c0952e54db7bd519440dc0611db7347cb048296d/include/beast/core/detail/empty_base_optimization.hpp
--
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/c5930064-2f8f-4e5e-be56-b46b337f44b9%40isocpp.org.
------=_Part_1340_2117477073.1464172373736
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, May 22, 2016 at 10:49:54 AM UTC-4, Avi Kivity w=
rote:<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>std=
::allow_zero_size<> is a library class template that uses compiler ma=
gic to tell the compiler that it is acceptable that the address of _M_alloc=
ator compare equal to that of some other object (that is, it need not inser=
t padding if sizeof(Allocator) =3D=3D 0).</div></div></blockquote><div><br>=
Here's a solution that works today, the syntax is based on boost::base_=
from_member:<br>https://github.com/vinniefalco/Beast/blob/c0952e54db7bd5194=
40dc0611db7347cb048296d/include/beast/core/detail/empty_base_optimization.h=
pp<br>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c5930064-2f8f-4e5e-be56-b46b337f44b9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5930064-2f8f-4e5e-be56-b46b337f44b9=
%40isocpp.org</a>.<br />
------=_Part_1340_2117477073.1464172373736--
------=_Part_1339_708973491.1464172373736--
.
Author: Avi Kivity <avi@cloudius-systems.com>
Date: Thu, 26 May 2016 05:21:32 -0700 (PDT)
Raw View
------=_Part_221_1533054738.1464265292567
Content-Type: multipart/alternative;
boundary="----=_Part_222_69171682.1464265292568"
------=_Part_222_69171682.1464265292568
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 24, 2016 at 3:09:32 AM UTC+3, Arthur O'Dwyer wrote:
>
> On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:
>>
>> Some time ago I proposed [1] new syntax for EBO. At that time the=20
>> discussion devolved into an argument about the attribute syntax. I'm=20
>> proposing it again, changing the syntax to avoid attributes.
>>
>> Library writers often find themselves wrapping possibly-empty objects in=
=20
>> synthetic structs to take advantage of EBO:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> struct alloc_n_size : Allocator {
>> size_t size;
>> // ctor etc.
>> } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
>> is_empty<Allocator>.
>> ...
>> };
>>
>> Would it not be more comfortable to supply some syntax for this:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> size_t _M_size;
>> std::allow_zero_size<Allocator> _M_allocator;
>> ...
>> };
>>
>> std::allow_zero_size<> is a library class template that uses compiler=20
>> magic to tell the compiler that it is acceptable that the address of=20
>> _M_allocator compare equal to that of some other object (that is, it nee=
d=20
>> not insert padding if sizeof(Allocator) =3D=3D 0). It overrides operato=
r.()=20
>> and friends so that _M_allocator can be used as if std::allow_zero_size<=
>=20
>> was not specified.
>>
>
> I think that if it were possible to implement such a=20
> std::allow_zero_size<T> today, everybody would be doing it (and that=20
> includes Boost).
> The hard part isn't so much the semantics of the allow_zero_size class=20
> template =E2=80=94 that sounds great to me =E2=80=94 but rather the probl=
em is that *there=20
> is no possible implementation of it* today.
>
Of course the implementation relies on compiler magic. For example,=20
libstdc++ might define it as
template <typename T>
struct allow_zero_size {
T _M_elem [[gnu::allow_zero_size]];
...
};
relying on a new, compiler-specific attribute. Other parts of the standard=
=20
library do this; for example search for __has_trivial_copy in <type_traits>=
..
=20
>
> It's kind of like saying "wouldn't it be a good idea if an object named=
=20
> std::cout existed and we could just write std::cout << foo to print the=
=20
> value of any type at all", in the days before operator overloading existe=
d.=20
> Those high-level semantics (arguably) sound great... but in order to=20
> *implement* those semantics, we need someone to do the core-language work=
=20
> of figuring out what it means to overload an operator, or in this case, t=
o=20
> have an object with the same address as a different object.
>
> If I'm wrong and there *does* currently exist a (non-portable but)=20
> *working* proof-of-concept implementation of foo::allow_zero_size<T>,=20
> then that's awesome and I want to see it. And your proposal should includ=
e=20
> a link to it.
>
>
>
There isn't. The intent is to introduce functionality without changing the=
=20
syntax, by wrapping compiler-specific syntax in a library class.
--=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/83c4be9a-d7a8-48b7-868a-b033e0134370%40isocpp.or=
g.
------=_Part_222_69171682.1464265292568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, May 24, 2016 at 3:09:32 AM UTC+3, Arthur O=
'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Sunday, May 22, 2016 at 7:49:54 AM UTC-7, Avi Kivity wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Some time ago I propos=
ed [1] new syntax for EBO. At that time the discussion devolved into an arg=
ument about the attribute syntax. =C2=A0I'm proposing it again, changin=
g the syntax to avoid attributes.</div><div><br></div><div>Library writers =
often find themselves wrapping possibly-empty objects in synthetic structs =
to take advantage of EBO:</div><div><br></div><div>=C2=A0 template <type=
name T, typename Allocator></div><div>=C2=A0 class my_container {</div><=
div>=C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size=
; =C2=A0 // only occupies sizeof(size_t) if is_empty<Allocator>.</div=
><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div=
>Would it not be more comfortable to supply some syntax for this:</div><div=
><br></div><div>=C2=A0 template <typename T, typename Allocator></div=
><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_=
size;</div><div>=C2=A0 =C2=A0 =C2=A0 std::allow_zero_size<<wbr>Allocator=
> _M_allocator;</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</=
div><div><br></div><div>std::allow_zero_size<> is a library class tem=
plate that uses compiler magic to tell the compiler that it is acceptable t=
hat the address of _M_allocator compare equal to that of some other object =
(that is, it need not insert padding if sizeof(Allocator) =3D=3D 0). =C2=A0=
It overrides operator.() and friends so that _M_allocator can be used as if=
std::allow_zero_size<> was not specified.</div></div></blockquote><d=
iv><br></div><div>I think that if it were possible to implement such a <fon=
t face=3D"courier new, monospace">std::allow_zero_size<T></font> toda=
y, everybody would be doing it (and that includes Boost).</div><div>The har=
d part isn't so much the semantics of the <font face=3D"courier new, mo=
nospace">allow_zero_size</font> class template =E2=80=94 that sounds great =
to me =E2=80=94 but rather the problem is that <i>there is no possible impl=
ementation of it</i> today.</div></div></blockquote><div><br></div><div><br=
></div><div>Of course the implementation relies on compiler magic. =C2=A0Fo=
r example, libstdc++ might define it as</div><div><br></div><div>=C2=A0 tem=
plate <typename T></div><div>=C2=A0 struct allow_zero_size {</div><di=
v>=C2=A0 =C2=A0 T _M_elem [[gnu::allow_zero_size]];</div><div>=C2=A0 =C2=A0=
...</div><div>=C2=A0 };</div><div><br></div><div>relying on a new, compile=
r-specific attribute. =C2=A0Other parts of the standard library do this; fo=
r example search for __has_trivial_copy in <type_traits>.</div><div><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
dir=3D"ltr"><div><br></div><div>It's kind of like saying "wouldn&=
#39;t it be a good idea if an object named <font face=3D"courier new, monos=
pace">std::cout</font> existed and we could just write <font face=3D"courie=
r new, monospace">std::cout << foo</font> to print the value of any t=
ype at all", in the days before operator overloading existed. =C2=A0Th=
ose high-level semantics (arguably) sound great... but in order to <i>imple=
ment</i> those semantics, we need someone to do the core-language work of f=
iguring out what it means to overload an operator, or in this case, to have=
an object with the same address as a different object.</div><div><br></div=
><div>If I'm wrong and there <i>does</i> currently exist a (non-portabl=
e but) <i>working</i>=C2=A0proof-of-concept implementation of <font face=3D=
"courier new, monospace">foo::allow_zero_size<T></font>, then that=
9;s awesome and I want to see it. And your proposal should include a link t=
o it.</div><div><br></div><div><br></div></div></blockquote><div><br></div>=
<div><br></div><div>There isn't. =C2=A0The intent is to introduce funct=
ionality without changing the syntax, by wrapping compiler-specific syntax =
in a library class.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/83c4be9a-d7a8-48b7-868a-b033e0134370%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83c4be9a-d7a8-48b7-868a-b033e0134370=
%40isocpp.org</a>.<br />
------=_Part_222_69171682.1464265292568--
------=_Part_221_1533054738.1464265292567--
.
Author: Marc <marc.glisse@gmail.com>
Date: Sun, 5 Jun 2016 01:56:53 -0700 (PDT)
Raw View
------=_Part_701_485034287.1465117013434
Content-Type: multipart/alternative;
boundary="----=_Part_702_379684302.1465117013434"
------=_Part_702_379684302.1465117013434
Content-Type: text/plain; charset=UTF-8
On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:
>
> Some time ago I proposed [1] new syntax for EBO. At that time the
> discussion devolved into an argument about the attribute syntax. I'm
> proposing it again, changing the syntax to avoid attributes.
>
I believe that the best way of moving forward with this is to implement
your proposal (the attribute version) as an extension in gcc (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 ) or clang. That would
include: write and test a patch, submit the patch to gcc/clang's mailing
list, send a heads up to the cxx-abi-dev mailing list to give developers
for other compilers a chance to comment on your exact ABI choices, start
adding uses of this attribute in your code, boost, etc. And then you would
be able to come to the committee with a stronger position.
--
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/a37ace27-20f1-40b8-bc07-1ffe26ab6e55%40isocpp.org.
------=_Part_702_379684302.1465117013434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Some=
time ago I proposed [1] new syntax for EBO. At that time the discussion de=
volved into an argument about the attribute syntax. =C2=A0I'm proposing=
it again, changing the syntax to avoid attributes.</div></div></blockquote=
><div><br>I believe that the best way of moving forward with this is to imp=
lement your proposal (the attribute version) as an extension in gcc ( https=
://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63579 ) or clang. That would incl=
ude: write and test a patch, submit the patch to gcc/clang's mailing li=
st, send a heads up to the cxx-abi-dev mailing list to give developers for =
other compilers a chance to comment on your exact ABI choices, start adding=
uses of this attribute in your code, boost, etc. And then you would be abl=
e to come to the committee with a stronger position.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a37ace27-20f1-40b8-bc07-1ffe26ab6e55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a37ace27-20f1-40b8-bc07-1ffe26ab6e55=
%40isocpp.org</a>.<br />
------=_Part_702_379684302.1465117013434--
------=_Part_701_485034287.1465117013434--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 09:13:09 -0700 (PDT)
Raw View
------=_Part_1890_482083079.1465575189344
Content-Type: multipart/alternative;
boundary="----=_Part_1891_170259669.1465575189344"
------=_Part_1891_170259669.1465575189344
Content-Type: text/plain; charset=UTF-8
Note that EBO is actively dangerous. If you inherit from a class that
defines a virtual member function that matches the signature of one of your
own methods, then you end up overriding it for your EBO'd type.
On Sunday, May 22, 2016 at 5:49:54 PM UTC+3, Avi Kivity wrote:
>
> Some time ago I proposed [1] new syntax for EBO. At that time the
> discussion devolved into an argument about the attribute syntax. I'm
> proposing it again, changing the syntax to avoid attributes.
>
>
> Library writers often find themselves wrapping possibly-empty objects in
> synthetic structs to take advantage of EBO:
>
> template <typename T, typename Allocator>
> class my_container {
> struct alloc_n_size : Allocator {
> size_t size;
> // ctor etc.
> } _M_alloc_n_size; // only occupies sizeof(size_t) if
> is_empty<Allocator>.
> ...
> };
>
> Would it not be more comfortable to supply some syntax for this:
>
> template <typename T, typename Allocator>
> class my_container {
> size_t _M_size;
> std::allow_zero_size<Allocator> _M_allocator;
> ...
> };
>
> std::allow_zero_size<> is a library class template that uses compiler
> magic to tell the compiler that it is acceptable that the address of
> _M_allocator compare equal to that of some other object (that is, it need
> not insert padding if sizeof(Allocator) == 0). It overrides operator.()
> and friends so that _M_allocator can be used as if std::allow_zero_size<>
> was not specified.
>
> The new syntax allows library authors to provide optimized code, while
> avoiding the need to write obfuscated code everywhere.
>
> [1]
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-THIcBwAJ
>
--
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/25078c44-ba07-437b-b6cb-f3234e2b66bc%40isocpp.org.
------=_Part_1891_170259669.1465575189344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that EBO is actively dangerous. =C2=A0If you inherit =
from a class that defines a virtual member function that matches the signat=
ure of one of your own methods, then you end up overriding it for your EBO&=
#39;d type.<div><br></div><div><br><br>On Sunday, May 22, 2016 at 5:49:54 P=
M UTC+3, Avi Kivity 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>Some time ago I proposed [1] new syntax for EBO. At that =
time the discussion devolved into an argument about the attribute syntax. =
=C2=A0I'm proposing it again, changing the syntax to avoid attributes.<=
/div><div><br></div><div><br></div><div>Library writers often find themselv=
es wrapping possibly-empty objects in synthetic structs to take advantage o=
f EBO:</div><div><br></div><div>=C2=A0 template <typename T, typename Al=
locator></div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =
=C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // cto=
r etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=A0 // only occ=
upies sizeof(size_t) if is_empty<Allocator>.</div><div>=C2=A0 =C2=A0 =
=C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>Would it not be mor=
e comfortable to supply some syntax for this:</div><div><br></div><div>=C2=
=A0 template <typename T, typename Allocator></div><div>=C2=A0 class =
my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_size;</div><div>=C2=
=A0 =C2=A0 =C2=A0 std::allow_zero_size<<wbr>Allocator> _M_allocator;<=
/div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div>=
<div>std::allow_zero_size<> is a library class template that uses com=
piler magic to tell the compiler that it is acceptable that the address of =
_M_allocator compare equal to that of some other object (that is, it need n=
ot insert padding if sizeof(Allocator) =3D=3D 0). =C2=A0It overrides operat=
or.() and friends so that _M_allocator can be used as if std::allow_zero_si=
ze<> was not specified.</div><div><br></div><div>The new syntax allow=
s library authors to provide optimized code, while avoiding the need to wri=
te obfuscated code everywhere.</div><div><br></div><div>[1] <a href=3D"http=
s://groups.google.com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-THIc=
BwAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'ht=
tps://groups.google.com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-TH=
IcBwAJ';return true;" onclick=3D"this.href=3D'https://groups.google=
..com/a/isocpp.org/d/msg/std-proposals/J4dMn1YaEhk/X_I-THIcBwAJ';return =
true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals=
/J4dMn1YaEhk/X_I-<wbr>THIcBwAJ</a><br></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/25078c44-ba07-437b-b6cb-f3234e2b66bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25078c44-ba07-437b-b6cb-f3234e2b66bc=
%40isocpp.org</a>.<br />
------=_Part_1891_170259669.1465575189344--
------=_Part_1890_482083079.1465575189344--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 09:16:23 -0700 (PDT)
Raw View
------=_Part_2203_55154307.1465575383159
Content-Type: multipart/alternative;
boundary="----=_Part_2204_1328329537.1465575383160"
------=_Part_2204_1328329537.1465575383160
Content-Type: text/plain; charset=UTF-8
On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:
>
> On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:
>>
>> Some time ago I proposed [1] new syntax for EBO. At that time the
>> discussion devolved into an argument about the attribute syntax. I'm
>> proposing it again, changing the syntax to avoid attributes.
>>
>
> I believe that the best way of moving forward with this is to implement
> your proposal (the attribute version) as an extension in gcc (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 ) or clang. That would
> include: write and test a patch, submit the patch to gcc/clang's mailing
> list, send a heads up to the cxx-abi-dev mailing list to give developers
> for other compilers a chance to comment on your exact ABI choices, start
> adding uses of this attribute in your code, boost, etc. And then you would
> be able to come to the committee with a stronger position.
>
That is a very expensive way of moving forward. It requires me to learn
the details of gcc/clang (both large projects with a high barrier to entry).
I understand it for a complex proposal where there is a lot of effort
needed anyway, but for small/trivial proposals like mine it's a good way to
kill the proposal in its infancy.
--
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/fed3692c-cd52-44ca-9dda-56f2edcb431e%40isocpp.org.
------=_Part_2204_1328329537.1465575383160
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc=
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 Sun=
day, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Some time ago I proposed [1] n=
ew syntax for EBO. At that time the discussion devolved into an argument ab=
out the attribute syntax. =C2=A0I'm proposing it again, changing the sy=
ntax to avoid attributes.</div></div></blockquote><div><br>I believe that t=
he best way of moving forward with this is to implement your proposal (the =
attribute version) as an extension in gcc ( <a href=3D"https://gcc.gnu.org/=
bugzilla/show_bug.cgi?id=3D63579" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc=
..gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63579\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCcc6kSoOZg';return true;" onclick=3D"thi=
s.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fb=
ugzilla%2Fshow_bug.cgi%3Fid%3D63579\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NFV2vVCeERF0jdNdw7OCcc6kSoOZg';return true;">https://gcc.gnu.org/bugzil=
la/<wbr>show_bug.cgi?id=3D63579</a> ) or clang. That would include: write a=
nd test a patch, submit the patch to gcc/clang's mailing list, send a h=
eads up to the cxx-abi-dev mailing list to give developers for other compil=
ers a chance to comment on your exact ABI choices, start adding uses of thi=
s attribute in your code, boost, etc. And then you would be able to come to=
the committee with a stronger position.<br></div></div></blockquote><div><=
br></div><div>That is a very expensive way of moving forward. =C2=A0It requ=
ires me to learn the details of gcc/clang (both large projects with a high =
barrier to entry).</div><div><br></div><div>I understand it for a complex p=
roposal where there is a lot of effort needed anyway, but for small/trivial=
proposals like mine it's a good way to kill the proposal in its infanc=
y.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fed3692c-cd52-44ca-9dda-56f2edcb431e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fed3692c-cd52-44ca-9dda-56f2edcb431e=
%40isocpp.org</a>.<br />
------=_Part_2204_1328329537.1465575383160--
------=_Part_2203_55154307.1465575383159--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 10:02:25 -0700 (PDT)
Raw View
------=_Part_3010_927263724.1465578145560
Content-Type: multipart/alternative;
boundary="----=_Part_3011_819951998.1465578145566"
------=_Part_3011_819951998.1465578145566
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 12:16:23 PM UTC-4, Avi Kivity wrote:
>
> On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:
>>
>> On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:
>>>
>>> Some time ago I proposed [1] new syntax for EBO. At that time the
>>> discussion devolved into an argument about the attribute syntax. I'm
>>> proposing it again, changing the syntax to avoid attributes.
>>>
>>
>> I believe that the best way of moving forward with this is to implement
>> your proposal (the attribute version) as an extension in gcc (
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 ) or clang. That
>> would include: write and test a patch, submit the patch to gcc/clang's
>> mailing list, send a heads up to the cxx-abi-dev mailing list to give
>> developers for other compilers a chance to comment on your exact ABI
>> choices, start adding uses of this attribute in your code, boost, etc. And
>> then you would be able to come to the committee with a stronger position.
>>
>
> That is a very expensive way of moving forward. It requires me to learn
> the details of gcc/clang (both large projects with a high barrier to entry).
>
> I understand it for a complex proposal where there is a lot of effort
> needed anyway, but for small/trivial proposals like mine it's a good way to
> kill the proposal in its infancy.
>
Your proposal is most assuredly *not* trivial.
Your proposal requires changing how the compiler lays out a class; you
declare an NSDM, but it somehow takes up no room. Your proposal requires
that the address of an object (the empty NSDM) need not be distinct from
other unrelated objects. And so forth.
I know it sounds rather burdensome to have to go through so much effort
just to get something standardized. But despite how simple the idea *sounds*,
you are still talking about a rather significant change to some very
low-level parts of the system.
Empty base optimization is something that is much easier to do
mechanically, because the conversion from derived class pointer to base
class pointer is designed to not require the pointer value to change.
On Friday, June 10, 2016 at 12:13:09 PM UTC-4, Avi Kivity wrote:
>
> Note that EBO is actively dangerous. If you inherit from a class that
> defines a virtual member function that matches the signature of one of your
> own methods, then you end up overriding it for your EBO'd type.
>
An issue that could easily be fixed by adding one of two features:
1: The ability to declare a function which will *not* override from a base
class virtual. That is, an explicit `nonvirtual`.
void funcname() nonvirtual;
2: The ability to declare that when inheriting from a class, you want to
override nothing from that class. I would call this "final inheritance";
neither you nor your child classes can override virtual members of the
specified base class.
class foo : public final bar {...};
Both of these would be a *lot* easier to implement than stateless members.
--
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/1ddfd38d-e6ad-4977-86a9-e052f71c51f2%40isocpp.org.
------=_Part_3011_819951998.1465578145566
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 12:16:23 PM UTC-4, Avi Kivity =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sund=
ay, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">On Sunday, May 22, 2016 at 4:49:54 PM UTC+2=
, Avi Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>Some time ago I proposed [1] new syntax for EBO. At that time the dis=
cussion devolved into an argument about the attribute syntax. =C2=A0I'm=
proposing it again, changing the syntax to avoid attributes.</div></div></=
blockquote><div><br>I believe that the best way of moving forward with this=
is to implement your proposal (the attribute version) as an extension in g=
cc ( <a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63579" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3F=
id%3D63579\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCcc6kS=
oOZg';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63579\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCcc6kSoOZg';re=
turn true;">https://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi?id=3D63579</a> )=
or clang. That would include: write and test a patch, submit the patch to =
gcc/clang's mailing list, send a heads up to the cxx-abi-dev mailing li=
st to give developers for other compilers a chance to comment on your exact=
ABI choices, start adding uses of this attribute in your code, boost, etc.=
And then you would be able to come to the committee with a stronger positi=
on.<br></div></div></blockquote><div><br></div><div>That is a very expensiv=
e way of moving forward. =C2=A0It requires me to learn the details of gcc/c=
lang (both large projects with a high barrier to entry).</div><div><br></di=
v><div>I understand it for a complex proposal where there is a lot of effor=
t needed anyway, but for small/trivial proposals like mine it's a good =
way to kill the proposal in its infancy.=C2=A0</div></div></blockquote><div=
><br>Your proposal is most assuredly <i>not</i> trivial.<br><br>Your propos=
al requires changing how the compiler lays out a class; you declare an NSDM=
, but it somehow takes up no room. Your proposal requires that the address =
of an object (the empty NSDM) need not be distinct from other unrelated obj=
ects. And so forth.<br><br>I know it sounds rather burdensome to have to go=
through so much effort just to get something standardized. But despite how=
simple the idea <i>sounds</i>, you are still talking about a rather signif=
icant change to some very low-level parts of the system.<br><br>Empty base =
optimization is something that is much easier to do mechanically, because t=
he conversion from derived class pointer to base class pointer is designed =
to not require the pointer value to change.<br><br>On Friday, June 10, 2016=
at 12:13:09 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">Note
that EBO is actively dangerous. =C2=A0If you inherit from a class that=20
defines a virtual member function that matches the signature of one of=20
your own methods, then you end up overriding it for your EBO'd type.</d=
iv></blockquote><br>An issue that could easily be fixed by adding one of tw=
o features:<br><br>1: The ability to declare a function which will *not* ov=
erride from a base class virtual. That is, an explicit `nonvirtual`.<br><br=
><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> funcname</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> nonvirtual</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code></di=
v><br>2: The ability to declare that when inheriting from a class, you want=
to override nothing from that class. I would call this "final inherit=
ance"; neither you nor your child classes can override virtual members=
of the specified base class.<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> foo </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">pub=
lic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">final</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> bar </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{...};</span></div></code>=
</div><br>Both of these would be a *lot* easier to implement than stateless=
members.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1ddfd38d-e6ad-4977-86a9-e052f71c51f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ddfd38d-e6ad-4977-86a9-e052f71c51f2=
%40isocpp.org</a>.<br />
------=_Part_3011_819951998.1465578145566--
------=_Part_3010_927263724.1465578145560--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 10 Jun 2016 10:30:13 -0700
Raw View
On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
> Note that EBO is actively dangerous. If you inherit from a class that
> defines a virtual member function that matches the signature of one of your
> own methods, then you end up overriding it for your EBO'd type.
A class with virtuals is not empty.
--
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/2189852.XU9jXIe9bq%40tjmaciei-mobl1.
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 11:11:00 -0700 (PDT)
Raw View
------=_Part_456_861094893.1465582260870
Content-Type: multipart/alternative;
boundary="----=_Part_457_374822953.1465582260870"
------=_Part_457_374822953.1465582260870
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 8:02:25 PM UTC+3, Nicol Bolas wrote:
>
> On Friday, June 10, 2016 at 12:16:23 PM UTC-4, Avi Kivity wrote:
>>
>> On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:
>>>
>>> On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:
>>>>
>>>> Some time ago I proposed [1] new syntax for EBO. At that time the
>>>> discussion devolved into an argument about the attribute syntax. I'm
>>>> proposing it again, changing the syntax to avoid attributes.
>>>>
>>>
>>> I believe that the best way of moving forward with this is to implement
>>> your proposal (the attribute version) as an extension in gcc (
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 ) or clang. That
>>> would include: write and test a patch, submit the patch to gcc/clang's
>>> mailing list, send a heads up to the cxx-abi-dev mailing list to give
>>> developers for other compilers a chance to comment on your exact ABI
>>> choices, start adding uses of this attribute in your code, boost, etc. And
>>> then you would be able to come to the committee with a stronger position.
>>>
>>
>> That is a very expensive way of moving forward. It requires me to learn
>> the details of gcc/clang (both large projects with a high barrier to entry).
>>
>> I understand it for a complex proposal where there is a lot of effort
>> needed anyway, but for small/trivial proposals like mine it's a good way to
>> kill the proposal in its infancy.
>>
>
> Your proposal is most assuredly *not* trivial.
>
> Your proposal requires changing how the compiler lays out a class; you
> declare an NSDM, but it somehow takes up no room.
>
C compilers (including gcc and clang) manage to do it just fine.
> Your proposal requires that the address of an object (the empty NSDM) need
> not be distinct from other unrelated objects.
>
Something that C compilers seem to be able to live with.
> And so forth.
>
Is there anything else?
>
> I know it sounds rather burdensome to have to go through so much effort
> just to get something standardized. But despite how simple the idea
> *sounds*, you are still talking about a rather significant change to some
> very low-level parts of the system.
>
I must disagree. Both the C compiler prior art, and the compilers laying
out base classes with zero size (base classes are no more than data members
at these low levels) support me. Any non-simplicity would be in possible
conflicts with aliasing rules, but since both gcc and clang support empty
data members (in C), implementing the front-end syntax for that would be no
help in figuring those out.
>
> Empty base optimization is something that is much easier to do
> mechanically, because the conversion from derived class pointer to base
> class pointer is designed to not require the pointer value to change.
>
>
It is not easy to do mechanically, esp. for a template class. What if the
class is final? What if the class is not an aggregate, but a primitive
type? What if the class starts making member functions of the inheriting
class virtual?
> On Friday, June 10, 2016 at 12:13:09 PM UTC-4, Avi Kivity wrote:
>>
>> Note that EBO is actively dangerous. If you inherit from a class that
>> defines a virtual member function that matches the signature of one of your
>> own methods, then you end up overriding it for your EBO'd type.
>>
>
> An issue that could easily be fixed by adding one of two features:
>
> 1: The ability to declare a function which will *not* override from a base
> class virtual. That is, an explicit `nonvirtual`.
>
> void funcname() nonvirtual;
>
> 2: The ability to declare that when inheriting from a class, you want to
> override nothing from that class. I would call this "final inheritance";
> neither you nor your child classes can override virtual members of the
> specified base class.
>
> class foo : public final bar {...};
>
> Both of these would be a *lot* easier to implement than stateless members.
>
--
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/aa9299bc-9c33-4d4f-b0c7-48c280249c35%40isocpp.org.
------=_Part_457_374822953.1465582260870
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 10, 2016 at 8:02:25 PM UTC+3, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Friday, June 10, 2016 at 12:16:23 PM UTC-4, Avi Kivity wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, June 5, 2016 at 1=
1:56:53 AM UTC+3, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:<b=
lockquote 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>Some time ago I=
proposed [1] new syntax for EBO. At that time the discussion devolved into=
an argument about the attribute syntax. =C2=A0I'm proposing it again, =
changing the syntax to avoid attributes.</div></div></blockquote><div><br>I=
believe that the best way of moving forward with this is to implement your=
proposal (the attribute version) as an extension in gcc ( <a href=3D"https=
://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63579" rel=3D"nofollow" target=3D=
"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63579\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCcc6kSoOZg';return true;"=
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2F=
gcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D63579\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCcc6kSoOZg';return true;">https://gcc=
..gnu.org/bugzilla/<wbr>show_bug.cgi?id=3D63579</a> ) or clang. That would i=
nclude: write and test a patch, submit the patch to gcc/clang's mailing=
list, send a heads up to the cxx-abi-dev mailing list to give developers f=
or other compilers a chance to comment on your exact ABI choices, start add=
ing uses of this attribute in your code, boost, etc. And then you would be =
able to come to the committee with a stronger position.<br></div></div></bl=
ockquote><div><br></div><div>That is a very expensive way of moving forward=
.. =C2=A0It requires me to learn the details of gcc/clang (both large projec=
ts with a high barrier to entry).</div><div><br></div><div>I understand it =
for a complex proposal where there is a lot of effort needed anyway, but fo=
r small/trivial proposals like mine it's a good way to kill the proposa=
l in its infancy.=C2=A0</div></div></blockquote><div><br>Your proposal is m=
ost assuredly <i>not</i> trivial.<br><br>Your proposal requires changing ho=
w the compiler lays out a class; you declare an NSDM, but it somehow takes =
up no room.</div></div></blockquote><div><br></div><div><br></div><div>C co=
mpilers (including gcc and clang) manage to do it just fine.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
> Your proposal requires that the address of an object (the empty NSDM) nee=
d not be distinct from other unrelated objects.</div></div></blockquote><di=
v><br></div><div>Something that C compilers seem to be able to live with.</=
div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div> And so forth.<br></div></div></blockquote><div=
><br></div><div>Is there anything else?</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>I know it sounds =
rather burdensome to have to go through so much effort just to get somethin=
g standardized. But despite how simple the idea <i>sounds</i>, you are stil=
l talking about a rather significant change to some very low-level parts of=
the system.<br></div></div></blockquote><div><br></div><div>I must disagre=
e. =C2=A0Both the C compiler prior art, and the compilers laying out base c=
lasses with zero size (base classes are no more than data members at these =
low levels) support me. =C2=A0Any non-simplicity would be in possible confl=
icts with aliasing rules, but since both gcc and clang support empty data m=
embers (in C), implementing the front-end syntax for that would be no help =
in figuring those out.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><br>Empty base optimization is somethi=
ng that is much easier to do mechanically, because the conversion from deri=
ved class pointer to base class pointer is designed to not require the poin=
ter value to change.<br><br></div></div></blockquote><div><br></div><div>It=
is not easy to do mechanically, esp. for a template class. =C2=A0What if t=
he class is final? =C2=A0What if the class is not an aggregate, but a primi=
tive type? =C2=A0What if the class starts making member functions of the in=
heriting class virtual?</div><div><br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>On Friday, June 10, 20=
16 at 12:13:09 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Note
that EBO is actively dangerous. =C2=A0If you inherit from a class that=20
defines a virtual member function that matches the signature of one of=20
your own methods, then you end up overriding it for your EBO'd type.</d=
iv></blockquote><br>An issue that could easily be fixed by adding one of tw=
o features:<br><br>1: The ability to declare a function which will *not* ov=
erride from a base class virtual. That is, an explicit `nonvirtual`.<br><br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><s=
pan style=3D"color:#008">void</span><span style=3D"color:#000"> funcname</s=
pan><span style=3D"color:#660">()</span><span style=3D"color:#000"> nonvirt=
ual</span><span style=3D"color:#660">;</span></div></code></div><br>2: The =
ability to declare that when inheriting from a class, you want to override =
nothing from that class. I would call this "final inheritance"; n=
either you nor your child classes can override virtual members of the speci=
fied base class.<br><br><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:br=
eak-word"><code><div><span style=3D"color:#008">class</span><span style=3D"=
color:#000"> foo </span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">public</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">final</span><span style=3D"co=
lor:#000"> bar </span><span style=3D"color:#660">{...};</span></div></code>=
</div><br>Both of these would be a *lot* easier to implement than stateless=
members.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/aa9299bc-9c33-4d4f-b0c7-48c280249c35%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa9299bc-9c33-4d4f-b0c7-48c280249c35=
%40isocpp.org</a>.<br />
------=_Part_457_374822953.1465582260870--
------=_Part_456_861094893.1465582260870--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 11:13:41 -0700 (PDT)
Raw View
------=_Part_705_492085766.1465582421297
Content-Type: multipart/alternative;
boundary="----=_Part_706_545533931.1465582421297"
------=_Part_706_545533931.1465582421297
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>
> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
> > Note that EBO is actively dangerous. If you inherit from a class that
> > defines a virtual member function that matches the signature of one of
> your
> > own methods, then you end up overriding it for your EBO'd type.
>
> A class with virtuals is not empty.
>
You don't know that beforehand.
template <class PossiblyEmptyComparator>
struct my_container;
Should my_container inherit from PossiblyEmptyComparator, or should it
contain it as a data member?
What if PossiblyEmptyComparator is a function pointer type?
>
> --
> 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/7dd2d457-f49b-4794-ba5c-ab29c16c4d65%40isocpp.org.
------=_Part_706_545533931.1465582421297
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thia=
go Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-fei=
ra, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
<br>> Note that EBO is actively dangerous. =C2=A0If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div><div><br></div><div>You don't know that=
beforehand.</div><div><br></div><div>template <class PossiblyEmptyCompa=
rator></div><div>struct my_container;</div><div><br></div><div>Should my=
_container inherit from PossiblyEmptyComparator, or should it contain it as=
a data member?</div><div><br></div><div>What if PossiblyEmptyComparator is=
a function pointer type?</div><div><br></div><div><br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7dd2d457-f49b-4794-ba5c-ab29c16c4d65%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7dd2d457-f49b-4794-ba5c-ab29c16c4d65=
%40isocpp.org</a>.<br />
------=_Part_706_545533931.1465582421297--
------=_Part_705_492085766.1465582421297--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 11:17:38 -0700 (PDT)
Raw View
------=_Part_470_681447503.1465582658372
Content-Type: multipart/alternative;
boundary="----=_Part_471_1704198743.1465582658372"
------=_Part_471_1704198743.1465582658372
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 8:02:25 PM UTC+3, Nicol Bolas wrote:
>
>
> An issue that could easily be fixed by adding one of two features:
>
> 1: The ability to declare a function which will *not* override from a base
> class virtual. That is, an explicit `nonvirtual`.
>
> void funcname() nonvirtual;
>
>
So, my container type, and all derived classes, must declare all their
methods virtual? That's no solution.
> 2: The ability to declare that when inheriting from a class, you want to
> override nothing from that class. I would call this "final inheritance";
> neither you nor your child classes can override virtual members of the
> specified base class.
>
> class foo : public final bar {...};
>
>
Then my
template <class Bar>
struct foo : public final Bar { ... };
would break every time I add some virtual method to Bar that happens to
conflict with it (or any of the derived classes).
> Both of these would be a *lot* easier to implement than stateless members.
>
Actually, they are far harder to implement. Zero-sized members are already
supported by (at least most) compilers, all that is missing is syntax to
use the capability.
--
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/3c600f16-6b70-4ca9-8152-88dbc1a2bd47%40isocpp.org.
------=_Part_471_1704198743.1465582658372
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 10, 2016 at 8:02:25 PM UTC+3, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br>An issue that could easily be fixed by adding one of two features=
:<br><br>1: The ability to declare a function which will *not* override fro=
m a base class virtual. That is, an explicit `nonvirtual`.<br><br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> funcname</span><span=
style=3D"color:#660">()</span><span style=3D"color:#000"> nonvirtual</span=
><span style=3D"color:#660">;</span></div></code></div><br></div></div></bl=
ockquote><div><br></div><div>So, my container type, and all derived classes=
, must declare all their methods virtual? =C2=A0That's no solution.</di=
v><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>2: The ability to declare that when inheriting =
from a class, you want to override nothing from that class. I would call th=
is "final inheritance"; neither you nor your child classes can ov=
erride virtual members of the specified base class.<br><br><div style=3D"ba=
ckground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:=
solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"colo=
r:#008">class</span><span style=3D"color:#000"> foo </span><span style=3D"c=
olor:#660">:</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">public</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">final</span><span style=3D"color:#000"> bar </span><span style=3D"col=
or:#660">{...};</span></div></code></div><br></div></div></blockquote><div>=
<br></div><div>Then my</div><div><br></div><div>=C2=A0 template <class B=
ar></div><div>=C2=A0 struct foo : public final Bar { ... };</div><div><b=
r></div><div>would break every time I add some virtual method to Bar that h=
appens to conflict with it (or any of the derived classes).</div><div><br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Both of these would be a *lot* easier to implement than state=
less members.<br></div></div></blockquote><div><br></div><div>Actually, the=
y are far harder to implement. =C2=A0Zero-sized members are already support=
ed by (at least most) compilers, all that is missing is syntax to use the c=
apability.</div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c600f16-6b70-4ca9-8152-88dbc1a2bd47%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c600f16-6b70-4ca9-8152-88dbc1a2bd47=
%40isocpp.org</a>.<br />
------=_Part_471_1704198743.1465582658372--
------=_Part_470_681447503.1465582658372--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 10 Jun 2016 21:22:17 +0300
Raw View
On 10 June 2016 at 20:02, Nicol Bolas <jmckesson@gmail.com> wrote:
> 2: The ability to declare that when inheriting from a class, you want to
> override nothing from that class. I would call this "final inheritance";
> neither you nor your child classes can override virtual members of the
> specified base class.
>
> class foo : public final bar {...};
I have considered proposing and implementing something like that. I spelled it
class foo final_overrider : public bar {...};
because that allows designating a class that doesn't inherit from any
other class as a final overrider.
Sure, it's different in the sense that foo can be derived from but
none of the virtual functions
in it or its bases can be overridden in such derived classes. The base
controls the ability to override,
not the derived class, like in your idea. I'm not saying either is
necessarily better, I'm just reporting
that such ideas have been considered.
--
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/CAFk2RUb_VHrjG4gHpAu8QPKXMvZaZMO7TwGFdOqR1YGD0RJXWA%40mail.gmail.com.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 10 Jun 2016 12:07:17 -0700
Raw View
--94eb2c059d50558c490534f13f26
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <avi@scylladb.com> wrote:
> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>>
>> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
>> > Note that EBO is actively dangerous. If you inherit from a class that
>> > defines a virtual member function that matches the signature of one of
>> your
>> > own methods, then you end up overriding it for your EBO'd type.
>>
>> A class with virtuals is not empty.
>>
>
> You don't know that beforehand.
>
> template <class PossiblyEmptyComparator>
> struct my_container;
>
> Should my_container inherit from PossiblyEmptyComparator, or should it
> contain it as a data member?
>
> What if PossiblyEmptyComparator is a function pointer type?
>
Now you're no longer talking about EBO, though. You're talking about NEBP:
the Non-Empty Base Pessimization. *Obviously* you should never name
*anything* as a base class of yours if you don't know what's in it. Library
implementors don't do that; why should you?
Instead, you'd do something roughly like
template<class PossiblyEmptyComparator, class Enable=3Dvoid>
struct ComparatorPlusInt {
PossiblyEmptyComparator c;
int i;
PossiblyEmptyComparator& get_comparator() { return c; }
int& get_int() { return i; }
};
template<class EmptyComparator>
struct ComparatorPlusInt<EmptyComparator,
enable_if_t<is_empty_v<EmptyComparator>>> : EmptyComparator {
int i;
EmptyComparator& get_comparator() { return *(EmptyComparator*)(this); }
int& get_int() { return i; }
};
and then make a member of type ComparatorPlusInt<MyComparator>, which does
the right thing either way. Your class doesn't need to trust the
MyComparator class, because it's only ever inherited-from when it *is*
empty (and even then, it's not inherited by *your* class but by the
ComparatorPlusInt class).
Which I guess raises the question of whether std::pair<EmptyComparator,
int> and/or std::pair<int, EmptyComparator> should be allowed and/or
required to DTRT in this case. I don't actually know what the current
wording is, and suspect that it might have the goal of allowing
std::pair<X,Y> to be layout-equivalent to a POD struct whenever possible
(which conflicts with the goal of making it as small as possible).
I'm pretty sure you (Avi) know all this already, so I'm kind of confused
how we got onto the topic of "what if my empty base class has virtual
members", "what if my empty base class isn't a class at all", etc. If you
want better support for EBO, how about designing an EBO-friendly
std::pair/std::tuple (which might already be done, for all I know); or else
doing the heavy lifting of figuring out what it would mean for two
non-zero-size objects to share a memory address; or else doing the heavy
lifting of figuring out what it would mean for an object to have zero size.
Re your comments elsethread: C doesn't have a lot of these "heavy lifting"
problems because it *does* allow zero-sized objects and it *doesn't* have a
very strong type system the way C++ does. C++'s heavy lifting isn't in the
machine-level implementation details; there you're right that the compilers
can just "do what C does." The heavy lifting is in the C++-specific stuff:
the *high-level semantics*, the *language*. That's the hard part.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0KdC%3D%2BE%3D06_kbChDftPwtxB2V2t5ZgL7HPP7=
xQLLL0UCg%40mail.gmail.com.
--94eb2c059d50558c490534f13f26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <span dir=3D"=
ltr"><<a href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylladb=
..com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Friday, June=
10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:<blockquote class=3D"g=
mail_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">On se=
xta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
<br>> Note that EBO is actively dangerous.=C2=A0 If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div></span><div>You don't know that beforeh=
and.</div><div><br></div><div>template <class PossiblyEmptyComparator>=
;</div><div>struct my_container;</div><div><br></div><div>Should my_contain=
er inherit from PossiblyEmptyComparator, or should it contain it as a data =
member?</div><div><br></div><div>What if PossiblyEmptyComparator is a funct=
ion pointer type?</div></div></blockquote><div><br></div><div>Now you'r=
e no longer talking about EBO, though. You're talking about NEBP: the N=
on-Empty Base Pessimization. <i>Obviously</i> you should never name=C2=A0<i=
>anything</i> as a base class of yours if you don't know what's in =
it. Library implementors don't do that; why should you?</div><div><br><=
/div><div>Instead, you'd do something roughly like</div><div><br></div>=
<div>template<class PossiblyEmptyComparator, class Enable=3Dvoid></di=
v><div>struct ComparatorPlusInt {</div><div>=C2=A0 =C2=A0 PossiblyEmptyComp=
arator c;</div><div>=C2=A0 =C2=A0 int i;</div><div>=C2=A0 =C2=A0 PossiblyEm=
ptyComparator& get_comparator() { return c; }</div><div>=C2=A0 =C2=A0 i=
nt& get_int() { return i; }</div><div>};</div><div><br></div><div><div>=
template<class EmptyComparator></div><div>struct ComparatorPlusInt<=
;EmptyComparator, enable_if_t<is_empty_v<EmptyComparator>>> =
: EmptyComparator {</div><div>=C2=A0 =C2=A0 int i;<br></div><div>=C2=A0 =C2=
=A0 EmptyComparator& get_comparator() { return *(EmptyComparator*)(this=
); }</div><div>=C2=A0 =C2=A0 int& get_int() { return i; }</div><div>};<=
/div></div><div><br></div><div>and then make a member of type ComparatorPlu=
sInt<MyComparator>, which does the right thing either way. Your class=
doesn't need to trust the MyComparator class, because it's only ev=
er inherited-from when it <i>is</i> empty (and even then, it's not inhe=
rited by <i>your</i> class but by the ComparatorPlusInt class).</div><div><=
br></div><div>Which I guess raises the question of whether std::pair<Emp=
tyComparator, int> and/or std::pair<int, EmptyComparator> should b=
e allowed and/or required to DTRT in this case. I don't actually know w=
hat the current wording is, and suspect that it might have the goal of allo=
wing std::pair<X,Y> to be layout-equivalent to a POD struct whenever =
possible (which conflicts with the goal of making it as small as possible).=
</div><div><br></div><div>I'm pretty sure you (Avi) know all this alrea=
dy, so I'm kind of confused how we got onto the topic of "what if =
my empty base class has virtual members", "what if my empty base =
class isn't a class at all", etc.=C2=A0 If you want better support=
for EBO, how about designing an EBO-friendly std::pair/std::tuple (which m=
ight already be done, for all I know); or else doing the heavy lifting of f=
iguring out what it would mean for two non-zero-size objects to share a mem=
ory address; or else doing the heavy lifting of figuring out what it would =
mean for an object to have zero size.</div><div><br></div><div>Re your comm=
ents elsethread: C doesn't have a lot of these "heavy lifting"=
; problems because it <i>does</i> allow zero-sized objects and it <i>doesn&=
#39;t</i> have a very strong type system the way C++ does. C++'s heavy =
lifting isn't in the machine-level implementation details; there you=
9;re right that the compilers can just "do what C does." =C2=A0Th=
e heavy lifting is in the C++-specific stuff: the <i>high-level semantics</=
i>, the <i>language</i>. That's the hard part.</div><div><br></div><div=
>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KdC%3D%2BE%3D06_kbChDftPwtxB2V=
2t5ZgL7HPP7xQLLL0UCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KdC%=
3D%2BE%3D06_kbChDftPwtxB2V2t5ZgL7HPP7xQLLL0UCg%40mail.gmail.com</a>.<br />
--94eb2c059d50558c490534f13f26--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 22:21:24 +0300
Raw View
--001a11442644fc1a2a0534f17286
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com=
>
wrote:
> On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <avi@scylladb.com> wrote:
>
>> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>>>
>>> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
>>> > Note that EBO is actively dangerous. If you inherit from a class tha=
t
>>> > defines a virtual member function that matches the signature of one o=
f
>>> your
>>> > own methods, then you end up overriding it for your EBO'd type.
>>>
>>> A class with virtuals is not empty.
>>>
>>
>> You don't know that beforehand.
>>
>> template <class PossiblyEmptyComparator>
>> struct my_container;
>>
>> Should my_container inherit from PossiblyEmptyComparator, or should it
>> contain it as a data member?
>>
>> What if PossiblyEmptyComparator is a function pointer type?
>>
>
> Now you're no longer talking about EBO, though. You're talking about NEBP=
:
> the Non-Empty Base Pessimization. *Obviously* you should never name
> *anything* as a base class of yours if you don't know what's in it.
> Library implementors don't do that; why should you?
>
They do it all the time, with exactly the example I gave. A colleague hit
it recently with boost's binomial heap.
Are you suggesting you should never inherit from a template parameter?
Because then template classes can choose from:
1. Inheriting from the base class and hitting weird problems
2. Using complex enable_if style solutions
3. Eliding the optimization altogether.
This could be so easily solved with
4. Adding [[allow_empty_size]] attribute to the data member.
But I guess we must preserve C++'s reputation for making things hard on its
users.
>
> Instead, you'd do something roughly like
>
> template<class PossiblyEmptyComparator, class Enable=3Dvoid>
> struct ComparatorPlusInt {
> PossiblyEmptyComparator c;
> int i;
> PossiblyEmptyComparator& get_comparator() { return c; }
> int& get_int() { return i; }
> };
>
> template<class EmptyComparator>
> struct ComparatorPlusInt<EmptyComparator,
> enable_if_t<is_empty_v<EmptyComparator>>> : EmptyComparator {
> int i;
> EmptyComparator& get_comparator() { return *(EmptyComparator*)(this);=
}
> int& get_int() { return i; }
> };
>
> and then make a member of type ComparatorPlusInt<MyComparator>, which doe=
s
> the right thing either way. Your class doesn't need to trust the
> MyComparator class, because it's only ever inherited-from when it *is*
> empty (and even then, it's not inherited by *your* class but by the
> ComparatorPlusInt class).
>
>
I'm not saying it can't be done. I'm saying that a 15-line solution which
must be repeated every time it is used is a horrible solution.
> Which I guess raises the question of whether std::pair<EmptyComparator,
> int> and/or std::pair<int, EmptyComparator> should be allowed and/or
> required to DTRT in this case. I don't actually know what the current
> wording is, and suspect that it might have the goal of allowing
> std::pair<X,Y> to be layout-equivalent to a POD struct whenever possible
> (which conflicts with the goal of making it as small as possible).
>
> I'm pretty sure you (Avi) know all this already, so I'm kind of confused
> how we got onto the topic of "what if my empty base class has virtual
> members", "what if my empty base class isn't a class at all",
>
As I already explained, at the point where I (or any library writer) want
to apply EBO, it is not known whether the base class is empty or not. As
I'm sure you also know already.
> etc. If you want better support for EBO, how about designing an
> EBO-friendly std::pair/std::tuple (which might already be done, for all I
> know); or else doing the heavy lifting of figuring out what it would mean
> for two non-zero-size objects to share a memory address; or else doing th=
e
> heavy lifting of figuring out what it would mean for an object to have ze=
ro
> size.
>
Again I'm sure it can be done, but this obfuscates the code. I wanted the
data member not to take any space, not to pair it with another member.
I understand not wanting to add to the standard for every little code
cleanup, but EBO is very common, is required for an efficient
implementation of the standard itself, and would be a lot more common if it
were not so hard to implement.
>
> Re your comments elsethread: C doesn't have a lot of these "heavy lifting=
"
> problems because it *does* allow zero-sized objects and it *doesn't* have
> a very strong type system the way C++ does. C++'s heavy lifting isn't in
> the machine-level implementation details; there you're right that the
> compilers can just "do what C does." The heavy lifting is in the
> C++-specific stuff: the *high-level semantics*, the *language*. That's
> the hard part.
>
Then it's totally unreasonable for a compiler newbie like myself to try and
figure them out. But can you explain where in the high level semantics a
zero sized data member enters at all?
>
> =E2=80=93Arthur
>
> --
> 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/CADvuK0KdC%3=
D%2BE%3D06_kbChDftPwtxB2V2t5ZgL7HPP7xQLLL0UCg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KdC%=
3D%2BE%3D06_kbChDftPwtxB2V2t5ZgL7HPP7xQLLL0UCg%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/CAF950WKyRbv7ehCjxxsF6X0%3Dsfpzw0y05pubAbBWuJuBg=
C9sFw%40mail.gmail.com.
--001a11442644fc1a2a0534f17286
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <span dir=3D"ltr">=
<<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j=
..odwyer@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><span class=3D"">On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivi=
ty <span dir=3D"ltr"><<a href=3D"mailto:avi@scylladb.com" target=3D"_bla=
nk">avi@scylladb.com</a>></span> wrote:<br></span><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D""><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"><span>On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieir=
a wrote:<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">On sexta-feira, 10 de junho de 2016 09:13:09 PDT A=
vi Kivity wrote:
<br>> Note that EBO is actively dangerous.=C2=A0 If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div></span><div>You don't know that beforeh=
and.</div><div><br></div><div>template <class PossiblyEmptyComparator>=
;</div><div>struct my_container;</div><div><br></div><div>Should my_contain=
er inherit from PossiblyEmptyComparator, or should it contain it as a data =
member?</div><div><br></div><div>What if PossiblyEmptyComparator is a funct=
ion pointer type?</div></div></blockquote><div><br></div></span><div>Now yo=
u're no longer talking about EBO, though. You're talking about NEBP=
: the Non-Empty Base Pessimization. <i>Obviously</i> you should never name=
=C2=A0<i>anything</i> as a base class of yours if you don't know what&#=
39;s in it. Library implementors don't do that; why should you?</div></=
div></div></div></blockquote><div><br></div><div><br></div><div>They do it =
all the time, with exactly the example I gave.=C2=A0 A colleague hit it rec=
ently with boost's binomial heap.</div><div><br></div><div>Are you sugg=
esting you should never inherit from a template parameter?=C2=A0 Because th=
en template classes can choose from:</div><div><br></div><div>1. Inheriting=
from the base class and hitting weird problems</div><div>2. Using complex =
enable_if style solutions</div><div>3. Eliding the optimization altogether.=
</div><div><br></div><div>This could be so easily solved with=C2=A0</div><d=
iv><br></div><div>4. Adding [[allow_empty_size]] attribute to the data memb=
er.</div><div><br></div><div>But I guess we must preserve C++'s reputat=
ion for making things hard on its users.</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><br></div><div>Instead, you'd do something roughl=
y like</div><div><br></div><div>template<class PossiblyEmptyComparator, =
class Enable=3Dvoid></div><div>struct ComparatorPlusInt {</div><div>=C2=
=A0 =C2=A0 PossiblyEmptyComparator c;</div><div>=C2=A0 =C2=A0 int i;</div><=
div>=C2=A0 =C2=A0 PossiblyEmptyComparator& get_comparator() { return c;=
}</div><div>=C2=A0 =C2=A0 int& get_int() { return i; }</div><div>};</d=
iv><div><br></div><div><div>template<class EmptyComparator></div><div=
>struct ComparatorPlusInt<EmptyComparator, enable_if_t<is_empty_v<=
EmptyComparator>>> : EmptyComparator {</div><div>=C2=A0 =C2=A0 int=
i;<br></div><div>=C2=A0 =C2=A0 EmptyComparator& get_comparator() { ret=
urn *(EmptyComparator*)(this); }</div><div>=C2=A0 =C2=A0 int& get_int()=
{ return i; }</div><div>};</div></div><div><br></div><div>and then make a =
member of type ComparatorPlusInt<MyComparator>, which does the right =
thing either way. Your class doesn't need to trust the MyComparator cla=
ss, because it's only ever inherited-from when it <i>is</i> empty (and =
even then, it's not inherited by <i>your</i> class but by the Comparato=
rPlusInt class).</div><div><br></div></div></div></div></blockquote><div><b=
r></div><div>I'm not saying it can't be done.=C2=A0 I'm saying =
that a 15-line solution which must be repeated every time it is used is a h=
orrible solution.</div><div><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></div><div>Which I guess raises the question of whether std::pa=
ir<EmptyComparator, int> and/or std::pair<int, EmptyComparator>=
should be allowed and/or required to DTRT in this case. I don't actual=
ly know what the current wording is, and suspect that it might have the goa=
l of allowing std::pair<X,Y> to be layout-equivalent to a POD struct =
whenever possible (which conflicts with the goal of making it as small as p=
ossible).</div><div><br></div><div>I'm pretty sure you (Avi) know all t=
his already, so I'm kind of confused how we got onto the topic of "=
;what if my empty base class has virtual members", "what if my em=
pty base class isn't a class at all", </div></div></div></div></bl=
ockquote><div><br></div><div><br></div><div>As I already explained, at the =
point where I (or any library writer) want to apply EBO, it is not known wh=
ether the base class is empty or not.=C2=A0 As I'm sure you also know a=
lready.</div><div><br></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>etc.=C2=A0 If you want better support for EBO, how about designing an EBO=
-friendly std::pair/std::tuple (which might already be done, for all I know=
); or else doing the heavy lifting of figuring out what it would mean for t=
wo non-zero-size objects to share a memory address; or else doing the heavy=
lifting of figuring out what it would mean for an object to have zero size=
..</div></div></div></div></blockquote><div><br></div><div><br></div><div>Ag=
ain I'm sure it can be done, but this obfuscates the code.=C2=A0 I want=
ed the data member not to take any space, not to pair it with another membe=
r.</div><div><br></div><div>I understand not wanting to add to the standard=
for every little code cleanup, but EBO is very common, is required for an =
efficient implementation of the standard itself, and would be a lot more co=
mmon if it were not so hard to implement.</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><br></div><div>Re your comments elsethread: C doesn&#=
39;t have a lot of these "heavy lifting" problems because it <i>d=
oes</i> allow zero-sized objects and it <i>doesn't</i> have a very stro=
ng type system the way C++ does. C++'s heavy lifting isn't in the m=
achine-level implementation details; there you're right that the compil=
ers can just "do what C does." =C2=A0The heavy lifting is in the =
C++-specific stuff: the <i>high-level semantics</i>, the <i>language</i>. T=
hat's the hard part.</div></div></div></div></blockquote><div><br></div=
><div><br></div><div>Then it's totally unreasonable for a compiler newb=
ie like myself to try and figure them out.=C2=A0 But can you explain where =
in the high level semantics a zero sized data member enters at all? =C2=A0<=
/div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></=
div><div>=E2=80=93Arthur</div></div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KdC%3D%2BE%3D06_kbChDftPwtxB2V=
2t5ZgL7HPP7xQLLL0UCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CADvuK0KdC%3D%2BE%3D06_kbChDftPwtxB2V2t5ZgL7HPP7xQLLL0UCg%40mail=
..gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WKyRbv7ehCjxxsF6X0%3Dsfpzw0y05p=
ubAbBWuJuBgC9sFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WKyRbv7eh=
CjxxsF6X0%3Dsfpzw0y05pubAbBWuJuBgC9sFw%40mail.gmail.com</a>.<br />
--001a11442644fc1a2a0534f17286--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 12:25:20 -0700 (PDT)
Raw View
------=_Part_867_111484132.1465586720283
Content-Type: multipart/alternative;
boundary="----=_Part_868_1539327015.1465586720284"
------=_Part_868_1539327015.1465586720284
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, June 10, 2016 at 3:07:19 PM UTC-4, Arthur O'Dwyer wrote:
>
> Re your comments elsethread: C doesn't have a lot of these "heavy lifting=
"=20
> problems because it *does* allow zero-sized objects and it *doesn't* have=
=20
> a very strong type system the way C++ does. C++'s heavy lifting isn't in=
=20
> the machine-level implementation details; there you're right that the=20
> compilers can just "do what C does." The heavy lifting is in the=20
> C++-specific stuff: the *high-level semantics*, the *language*. That's=20
> the hard part.
>
> =E2=80=93Arthur
>
To be fair, the high level semantics are the *easy* part.
We know *exactly* what behavior we want from these things. All we really=20
want is for a type to be able to take up no space while it is an NSDM or=20
base class of another type. It can still have a non-zero `sizeof` (thus=20
permitting allocating them on the heap), so that's a can of worms we don't=
=20
need to open up. And the `this` pointer for member functions is irrelevant,=
=20
since because the class is stateless, it doesn't need to access any=20
non-stateless NSDMs.
The principle standardization problems that I can see for the concept are:
1: Aliasing. Pointers to such classes have to be able to alias with=20
unrelated types.
2: Layout. Stateless members should not disrupt the layout of the other=20
NSDMs within a type. This also affects ABIs, since NSDMs have always=20
disrupted C++ member layouts before. So the Itanium C++ ABI would need to=
=20
be changed... I guess?
3: The rule(s) on objects having to have a specific piece of storage.
4: Pointer addressing and arithmetic. If you increment a pointer to a=20
stateless NSDM, what do you get? Can you have NSDM arrays of stateless=20
members, and if so, do they take up space?
5: Trivial copyability. If the object takes up no space, yet has a non-zero=
=20
`sizeof()`, is the type trivially copyable? If a stateless pointer always=
=20
aliases with some other object's memory, wouldn't trivially copying it bash=
=20
that other object's memory? Or do we say that stateless types are not=20
trivially copyable, but having them as subobjects does not by itself make=
=20
their owning objects non-trivially copyable?
Note that #5 is something I just realized while composing this message; I=
=20
hadn't considered that issue before.
I don't consider these "high-level" problems. The high-level of the idea is=
=20
quite clear. But they are significant things that have to be ironed out.
--=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/7750e5bb-fc96-41bf-b0cc-1dc29447c89e%40isocpp.or=
g.
------=_Part_868_1539327015.1465586720284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 3:07:19 PM UTC-4, Arthur O'=
;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>Re your comments elsethread: C doesn&#=
39;t have a lot of these "heavy lifting" problems because it <i>d=
oes</i> allow zero-sized objects and it <i>doesn't</i> have a very stro=
ng type system the way C++ does. C++'s heavy lifting isn't in the m=
achine-level implementation details; there you're right that the compil=
ers can just "do what C does." =C2=A0The heavy lifting is in the =
C++-specific stuff: the <i>high-level semantics</i>, the <i>language</i>. T=
hat's the hard part.</div><div><br></div><div>=E2=80=93Arthur</div></di=
v></div></div></blockquote><div><br>To be fair, the high level semantics ar=
e the <i>easy</i> part.<br><br>We know <i>exactly</i> what behavior we want=
from these things. All we really want is for a type to be able to take up =
no space while it is an NSDM or base class of another type. It can still ha=
ve a non-zero `sizeof` (thus permitting allocating them on the heap), so th=
at's a can of worms we don't need to open up. And the `this` pointe=
r for member functions is irrelevant, since because the class is stateless,=
it doesn't need to access any non-stateless NSDMs.<br><br>The principl=
e standardization problems that I can see for the concept are:<br><br>1: Al=
iasing. Pointers to such classes have to be able to alias with unrelated ty=
pes.<br><br>2: Layout. Stateless members should not disrupt the layout of t=
he other NSDMs within a type. This also affects ABIs, since NSDMs have alwa=
ys disrupted C++ member layouts before. So the Itanium C++ ABI would need t=
o be changed... I guess?<br><br>3: The rule(s) on objects having to have a =
specific piece of storage.<br><br>4: Pointer addressing and arithmetic. If =
you increment a pointer to a stateless NSDM, what do you get? Can you have =
NSDM arrays of stateless members, and if so, do they take up space?<br><br>=
5: Trivial copyability. If the object takes up no space, yet has a non-zero=
`sizeof()`, is the type trivially copyable? If a stateless pointer always =
aliases with some other object's memory, wouldn't trivially copying=
it bash that other object's memory? Or do we say that stateless types =
are not trivially copyable, but having them as subobjects does not by itsel=
f make their owning objects non-trivially copyable?<br><br>Note that #5 is =
something I just realized while composing this message; I hadn't consid=
ered that issue before.<br><br>I don't consider these "high-level&=
quot; problems. The high-level of the idea is quite clear. But they are sig=
nificant things that have to be ironed out.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7750e5bb-fc96-41bf-b0cc-1dc29447c89e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7750e5bb-fc96-41bf-b0cc-1dc29447c89e=
%40isocpp.org</a>.<br />
------=_Part_868_1539327015.1465586720284--
------=_Part_867_111484132.1465586720283--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Fri, 10 Jun 2016 15:32:34 -0400
Raw View
--Apple-Mail=_D971A77D-0C45-4EF7-9CC9-44FA29538730
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
On Jun 10, 2016, at 3:07 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wro=
te:
>=20
> I'm pretty sure you (Avi) know all this already, so I'm kind of confused =
how we got onto the topic of "what if my empty base class has virtual membe=
rs", "what if my empty base class isn't a class at all", etc. If you want =
better support for EBO, how about designing an EBO-friendly std::pair/std::=
tuple (which might already be done, for all I know); or else doing the heav=
y lifting of figuring out what it would mean for two non-zero-size objects =
to share a memory address; or else doing the heavy lifting of figuring out =
what it would mean for an object to have zero size.
Can=E2=80=99t do it for pair because of the need to have the named data mem=
bers first and second. But for tuple=E2=80=A6
#include <iostream>
#include <tuple>
struct empty {};
int
main()
{
std::cout << sizeof(int) << '\n';
std::cout << sizeof(std::tuple<int, empty>) << '\n';
std::cout << sizeof(long long) << '\n';
std::cout << sizeof(std::tuple<long long, empty>) << '\n';
}
gcc and clang/libc++ output:
4
4
8
8
The optimization is allowed but not required for tuple.
Howard
--=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/E40B9393-C842-4343-9EFD-0DE5BEF4D773%40gmail.com=
..
--Apple-Mail=_D971A77D-0C45-4EF7-9CC9-44FA29538730
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXWxXSAAoJEGbcHCxKqhWCpC8P/0hD2N1CSeILYKUt6TXHiPFt
vyXGF9Sr3c/ZTo8dB4ZaepsCL8rPv+yU3bJXibr0I1lNmtWx+Kmmg7gqbZ66mcDZ
Siau0D8P9QADmZmhBbM6bcG4cS7+z+Bh2eDs1BrqGA/isPfLW3y+V1IraEJ+4nsP
BEgag8KjMToCvtBBMg8I5uGLs+4T6Y6gtkvdVsNSkoJUJAGYArkIVjpBsE89GOds
1VuD1xROg/Lp/GA8BGY3G51hmy5/cqqbY0tyOHEWbFEG1nr6lDZC4dw31Qn+O4eI
zA6y1TrL5kMOBP4YsFAdqR6JNb0nk38CifWTBOEb7VgcTSJmvBHrQAwnrh5eiegz
uTITWUoYDOk747CTIUy7EAfmWgg1RIOjfT9Q6CiE0X6BtQZ8OasomBFMjWp9U9zg
K/5qvj1p7VAzV10TfnHDZh9GnWuMSrJluPD+DI2A7CGUf2v6c8B3gyeRy1Ry422Y
4RzW2VbqBbKTZlu1RQutSot5oKrhRhRtIbkGOHwzmUQO0CMiPlIvqgV5nncydna0
iiZETzFXqiWmJ97+EewpbBSTFAL6mNLnIY44IgGXaktiPZblBl98WGYn9DjldusB
bOqyu99prKSBjWPxRV7Xwu/InAjyjnmsm1hnlSeNHBGDds+feCJqOctqEM2myz1u
Z2RjFeDmt38ZQuZcJK80
=DO5k
-----END PGP SIGNATURE-----
--Apple-Mail=_D971A77D-0C45-4EF7-9CC9-44FA29538730--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 12:38:05 -0700 (PDT)
Raw View
------=_Part_1228_1004282061.1465587485656
Content-Type: multipart/alternative;
boundary="----=_Part_1229_923025765.1465587485657"
------=_Part_1229_923025765.1465587485657
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:
>
> On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
>
>> On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <a...@scylladb.com
>> <javascript:>> wrote:
>>
>>> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>>>>
>>>> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
>>>> > Note that EBO is actively dangerous. If you inherit from a class
>>>> that
>>>> > defines a virtual member function that matches the signature of one
>>>> of your
>>>> > own methods, then you end up overriding it for your EBO'd type.
>>>>
>>>> A class with virtuals is not empty.
>>>>
>>>
>>> You don't know that beforehand.
>>>
>>> template <class PossiblyEmptyComparator>
>>> struct my_container;
>>>
>>> Should my_container inherit from PossiblyEmptyComparator, or should it
>>> contain it as a data member?
>>>
>>> What if PossiblyEmptyComparator is a function pointer type?
>>>
>>
>> Now you're no longer talking about EBO, though. You're talking about
>> NEBP: the Non-Empty Base Pessimization. *Obviously* you should never
>> name *anything* as a base class of yours if you don't know what's in it.
>> Library implementors don't do that; why should you?
>>
>
>
> They do it all the time, with exactly the example I gave. A colleague hit
> it recently with boost's binomial heap.
>
> Are you suggesting you should never inherit from a template parameter?
>
As he clearly said, you shouldn't inherit from something you don't know
what it is.
> Because then template classes can choose from:
>
> 1. Inheriting from the base class and hitting weird problems
> 2. Using complex enable_if style solutions
> 3. Eliding the optimization altogether.
>
> This could be so easily solved with
>
> 4. Adding [[allow_empty_size]] attribute to the data member.
>
Attributes *are never allowed* to change the behavior of a program. That's
the rule with them. Period.
> But I guess we must preserve C++'s reputation for making things hard on
> its users.
>
>
>> Re your comments elsethread: C doesn't have a lot of these "heavy
>> lifting" problems because it *does* allow zero-sized objects and it
>> *doesn't* have a very strong type system the way C++ does. C++'s heavy
>> lifting isn't in the machine-level implementation details; there you're
>> right that the compilers can just "do what C does." The heavy lifting is
>> in the C++-specific stuff: the *high-level semantics*, the *language*.
>> That's the hard part.
>>
>
> Then it's totally unreasonable for a compiler newbie like myself to try
> and figure them out. But can you explain where in the high level semantics
> a zero sized data member enters at all?
>
.... Everywhere? Is that a place?
C++ defines an object, first and foremost, as "a region of storage". The
entire C++ object model *relies* on that. A zero-sized object is anathema
to that definition. You would have to rewrite a lot of the standard before
you can permit zero-sized objects.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53222639-9274-4dbc-a4fc-e57e94d9704c%40isocpp.org.
------=_Part_1229_923025765.1465587485657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity w=
rote:<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><di=
v class=3D"gmail_quote">On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwye=
r <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"m39B8hnpAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&=
#39;;return true;">arthur....@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span>On Fri, Jun 10, 2016 at 11:13 A=
M, Avi Kivity <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"m39B8hnpAAAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">a...@scylladb.com</a>></span> wrote:<br><=
/span><div><div class=3D"gmail_quote"><span><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><span>On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kiv=
ity wrote:
<br>> Note that EBO is actively dangerous.=C2=A0 If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div></span><div>You don't know that beforeh=
and.</div><div><br></div><div>template <class PossiblyEmptyComparator>=
;</div><div>struct my_container;</div><div><br></div><div>Should my_contain=
er inherit from PossiblyEmptyComparator, or should it contain it as a data =
member?</div><div><br></div><div>What if PossiblyEmptyComparator is a funct=
ion pointer type?</div></div></blockquote><div><br></div></span><div>Now yo=
u're no longer talking about EBO, though. You're talking about NEBP=
: the Non-Empty Base Pessimization. <i>Obviously</i> you should never name=
=C2=A0<i>anything</i> as a base class of yours if you don't know what&#=
39;s in it. Library implementors don't do that; why should you?</div></=
div></div></div></blockquote><div><br></div><div><br></div><div>They do it =
all the time, with exactly the example I gave.=C2=A0 A colleague hit it rec=
ently with boost's binomial heap.</div><div><br></div><div>Are you sugg=
esting you should never inherit from a template parameter?</div></div></div=
></div></blockquote><div><br>As he clearly said, you shouldn't inherit =
from something you don't know what it is.<br>=C2=A0</div><blockquote cl=
ass=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_qu=
ote"><div>Because then template classes can choose from:</div><div><br></di=
v><div>1. Inheriting from the base class and hitting weird problems</div><d=
iv>2. Using complex enable_if style solutions</div><div>3. Eliding the opti=
mization altogether.</div><div><br></div><div>This could be so easily solve=
d with=C2=A0</div><div><br></div><div>4. Adding [[allow_empty_size]] attrib=
ute to the data member.</div></div></div></div></blockquote><div><br>Attrib=
utes <i>are never allowed</i> to change the behavior of a program. That'=
;s the rule with them. Period.<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div><div>But I guess we must preserv=
e C++'s reputation for making things hard on its users.<br>=C2=A0</div>=
</div></div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><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><div class=3D"gmail_quote"><div><br></div><div>=
Re your comments elsethread: C doesn't have a lot of these "heavy =
lifting" problems because it <i>does</i> allow zero-sized objects and =
it <i>doesn't</i> have a very strong type system the way C++ does. C++&=
#39;s heavy lifting isn't in the machine-level implementation details; =
there you're right that the compilers can just "do what C does.&qu=
ot; =C2=A0The heavy lifting is in the C++-specific stuff: the <i>high-level=
semantics</i>, the <i>language</i>. That's the hard part.</div></div><=
/div></div></blockquote><div><br></div><div></div><div>Then it's totall=
y unreasonable for a compiler newbie like myself to try and figure them out=
..=C2=A0 But can you explain where in the high level semantics a zero sized =
data member enters at all?<br></div></div></div></div></blockquote><div><br=
>... Everywhere? Is that a place?<br><br>C++ defines an object, first and f=
oremost, as "a region of storage". The entire C++ object model <i=
>relies</i> on that. A zero-sized object is anathema to that definition. Yo=
u would have to rewrite a lot of the standard before you can permit zero-si=
zed objects.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53222639-9274-4dbc-a4fc-e57e94d9704c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/53222639-9274-4dbc-a4fc-e57e94d9704c=
%40isocpp.org</a>.<br />
------=_Part_1229_923025765.1465587485657--
------=_Part_1228_1004282061.1465587485656--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 12:38:49 -0700 (PDT)
Raw View
------=_Part_2497_2108205970.1465587529708
Content-Type: multipart/alternative;
boundary="----=_Part_2498_1382696001.1465587529709"
------=_Part_2498_1382696001.1465587529709
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 2:11:01 PM UTC-4, Avi Kivity wrote:
>
> On Friday, June 10, 2016 at 8:02:25 PM UTC+3, Nicol Bolas wrote:
>>
>> On Friday, June 10, 2016 at 12:16:23 PM UTC-4, Avi Kivity wrote:
>>>
>>> On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:
>>>>
>>>> On Sunday, May 22, 2016 at 4:49:54 PM UTC+2, Avi Kivity wrote:
>>>>>
>>>>> Some time ago I proposed [1] new syntax for EBO. At that time the
>>>>> discussion devolved into an argument about the attribute syntax. I'm
>>>>> proposing it again, changing the syntax to avoid attributes.
>>>>>
>>>>
>>>> I believe that the best way of moving forward with this is to implement
>>>> your proposal (the attribute version) as an extension in gcc (
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579 ) or clang. That
>>>> would include: write and test a patch, submit the patch to gcc/clang's
>>>> mailing list, send a heads up to the cxx-abi-dev mailing list to give
>>>> developers for other compilers a chance to comment on your exact ABI
>>>> choices, start adding uses of this attribute in your code, boost, etc. And
>>>> then you would be able to come to the committee with a stronger position.
>>>>
>>>
>>> That is a very expensive way of moving forward. It requires me to learn
>>> the details of gcc/clang (both large projects with a high barrier to entry).
>>>
>>> I understand it for a complex proposal where there is a lot of effort
>>> needed anyway, but for small/trivial proposals like mine it's a good way to
>>> kill the proposal in its infancy.
>>>
>>
>> Your proposal is most assuredly *not* trivial.
>>
>> Your proposal requires changing how the compiler lays out a class; you
>> declare an NSDM, but it somehow takes up no room.
>>
>
> C compilers (including gcc and clang) manage to do it just fine.
>
As Arthur said, C allows zero-sized objects. There are a lot of rules in
C++ that get broken if you permit that. That's not an implementation
problem so much as a standardization problem.
And so forth.
>>
>
> Is there anything else?
>
How about the Itanium ABI
<https://mentorembedded.github.io/cxx-abi/abi.html>? I don't see the part
of that which permits empty NSDMs of a class to not take up space. It
permits EBO, but not stateless NSDMs.
Empty base optimization is something that is much easier to do
>> mechanically, because the conversion from derived class pointer to base
>> class pointer is designed to not require the pointer value to change.
>>
>
> It is not easy to do mechanically, esp. for a template class. What if the
> class is final? What if the class is not an aggregate, but a primitive
> type? What if the class starts making member functions of the inheriting
> class virtual?
>
It's easier to do mechanically from the perspective of the standard and
implementation. The layout of base classes relative to the derived class
and to one another is implementation defined. The standard has to permit
base class pointers to alias with derived class ones, so as to support
implementations where base class members come first. This is what makes EBO
possible.
That's what I meant by "mechanically". How you happen to use any available
EBO in your application is entirely up 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/0ca5ebce-fa8d-44c8-9fdf-377a9452bca1%40isocpp.org.
------=_Part_2498_1382696001.1465587529709
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 2:11:01 PM UTC-4, Avi Kivity w=
rote:<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">On Frida=
y, June 10, 2016 at 8:02:25 PM UTC+3, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Friday, June 10, 2016 at 12:16:2=
3 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Sunday, June 5, 2016 at 11:56:53 AM UTC+3, Marc wrote:<blockq=
uote 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 Sunday, May 22, 2016 a=
t 4:49:54 PM UTC+2, Avi Kivity wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Some time ago I proposed [1] new syntax for EBO. At=
that time the discussion devolved into an argument about the attribute syn=
tax. =C2=A0I'm proposing it again, changing the syntax to avoid attribu=
tes.</div></div></blockquote><div><br>I believe that the best way of moving=
forward with this is to implement your proposal (the attribute version) as=
an extension in gcc ( <a href=3D"https://gcc.gnu.org/bugzilla/show_bug.cgi=
?id=3D63579" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2=
Fshow_bug.cgi%3Fid%3D63579\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV2vVCeE=
RF0jdNdw7OCcc6kSoOZg';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cg=
i%3Fid%3D63579\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV2vVCeERF0jdNdw7OCc=
c6kSoOZg';return true;">https://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi?=
id=3D63579</a> ) or clang. That would include: write and test a patch, subm=
it the patch to gcc/clang's mailing list, send a heads up to the cxx-ab=
i-dev mailing list to give developers for other compilers a chance to comme=
nt on your exact ABI choices, start adding uses of this attribute in your c=
ode, boost, etc. And then you would be able to come to the committee with a=
stronger position.<br></div></div></blockquote><div><br></div><div>That is=
a very expensive way of moving forward. =C2=A0It requires me to learn the =
details of gcc/clang (both large projects with a high barrier to entry).</d=
iv><div><br></div><div>I understand it for a complex proposal where there i=
s a lot of effort needed anyway, but for small/trivial proposals like mine =
it's a good way to kill the proposal in its infancy.=C2=A0</div></div><=
/blockquote><div><br>Your proposal is most assuredly <i>not</i> trivial.<br=
><br>Your proposal requires changing how the compiler lays out a class; you=
declare an NSDM, but it somehow takes up no room.</div></div></blockquote>=
<div></div><div><br></div><div>C compilers (including gcc and clang) manage=
to do it just fine.</div></div></blockquote><div><br>As Arthur said, C all=
ows zero-sized objects. There are a lot of rules in C++ that get broken if =
you permit that. That's not an implementation problem so much as a stan=
dardization problem.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div> And so forth.<br></div></div></blockquote><div><br>=
</div><div>Is there anything else?</div></div></blockquote><div><br>How abo=
ut the <a href=3D"https://mentorembedded.github.io/cxx-abi/abi.html">Itaniu=
m ABI</a>? I don't see the part of that which permits empty NSDMs of a =
class to not take up space. It permits EBO, but not stateless NSDMs.<br><br=
></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"></blockquo=
te><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"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Empty base optimization=
is something that is much easier to do mechanically, because the conversio=
n from derived class pointer to base class pointer is designed to not requi=
re the pointer value to change.<br></div></div></blockquote><div><br></div>=
<div>It is not easy to do mechanically, esp. for a template class. =C2=A0Wh=
at if the class is final? =C2=A0What if the class is not an aggregate, but =
a primitive type? =C2=A0What if the class starts making member functions of=
the inheriting class virtual?</div></div></blockquote><div><br>It's ea=
sier to do mechanically from the perspective of the standard and implementa=
tion. The layout of base classes relative to the derived class and to one a=
nother is implementation defined. The standard has to permit base class poi=
nters to alias with derived class ones, so as to support implementations wh=
ere base class members come first. This is what makes EBO possible.<br><br>=
That's what I meant by "mechanically". How you happen to use =
any available EBO in your application is entirely up to you.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0ca5ebce-fa8d-44c8-9fdf-377a9452bca1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ca5ebce-fa8d-44c8-9fdf-377a9452bca1=
%40isocpp.org</a>.<br />
------=_Part_2498_1382696001.1465587529709--
------=_Part_2497_2108205970.1465587529708--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 22:47:41 +0300
Raw View
--001a113da350f74e760534f1d07c
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:
>>
>> On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur....@gmail.com>
>> wrote:
>>
>>> On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <a...@scylladb.com> wrote:
>>>
>>>> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>>>>>
>>>>> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
>>>>> > Note that EBO is actively dangerous. If you inherit from a class
>>>>> that
>>>>> > defines a virtual member function that matches the signature of one
>>>>> of your
>>>>> > own methods, then you end up overriding it for your EBO'd type.
>>>>>
>>>>> A class with virtuals is not empty.
>>>>>
>>>>
>>>> You don't know that beforehand.
>>>>
>>>> template <class PossiblyEmptyComparator>
>>>> struct my_container;
>>>>
>>>> Should my_container inherit from PossiblyEmptyComparator, or should it
>>>> contain it as a data member?
>>>>
>>>> What if PossiblyEmptyComparator is a function pointer type?
>>>>
>>>
>>> Now you're no longer talking about EBO, though. You're talking about
>>> NEBP: the Non-Empty Base Pessimization. *Obviously* you should never
>>> name *anything* as a base class of yours if you don't know what's in
>>> it. Library implementors don't do that; why should you?
>>>
>>
>>
>> They do it all the time, with exactly the example I gave. A colleague
>> hit it recently with boost's binomial heap.
>>
>> Are you suggesting you should never inherit from a template parameter?
>>
>
> As he clearly said, you shouldn't inherit from something you don't know
> what it is.
>
Well, then how can you apply EBO in a library? Say, std::unordered_set<Key,
Hash, ...>, where Hash may and often is empty.
>
>
>> Because then template classes can choose from:
>>
>> 1. Inheriting from the base class and hitting weird problems
>> 2. Using complex enable_if style solutions
>> 3. Eliding the optimization altogether.
>>
>> This could be so easily solved with
>>
>> 4. Adding [[allow_empty_size]] attribute to the data member.
>>
>
> Attributes *are never allowed* to change the behavior of a program.
> That's the rule with them. Period.
>
>
I'm fine with other syntax. But please, not 15-lines of enable_if.
> But I guess we must preserve C++'s reputation for making things hard on
>> its users.
>>
>>
>
>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>> lifting" problems because it *does* allow zero-sized objects and it
>>> *doesn't* have a very strong type system the way C++ does. C++'s heavy
>>> lifting isn't in the machine-level implementation details; there you're
>>> right that the compilers can just "do what C does." The heavy lifting is
>>> in the C++-specific stuff: the *high-level semantics*, the *language*.
>>> That's the hard part.
>>>
>>
>> Then it's totally unreasonable for a compiler newbie like myself to try
>> and figure them out. But can you explain where in the high level semantics
>> a zero sized data member enters at all?
>>
>
> ... Everywhere? Is that a place?
>
> C++ defines an object, first and foremost, as "a region of storage". The
> entire C++ object model *relies* on that. A zero-sized object is anathema
> to that definition.
>
Would not the zero-sized object occupy a zero-sized region of storage?
> You would have to rewrite a lot of the standard before you can permit
> zero-sized objects.
>
Could you give me an example?
> --
> 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/53222639-9274-4dbc-a4fc-e57e94d9704c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53222639-9274-4dbc-a4fc-e57e94d9704c%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/CAF950WLeaU51c%3DCq3H5j%3D7q-zOHZOxQNrHXAOY1VgnZtd4SbeQ%40mail.gmail.com.
--001a113da350f74e760534f1d07c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On =
Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">O=
n Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <span dir=3D"ltr"><<=
a rel=3D"nofollow">arthur....@gmail.com</a>></span> wrote:<span class=3D=
""><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"><span>On Fri, Jun 10=
, 2016 at 11:13 AM, Avi Kivity <span dir=3D"ltr"><<a rel=3D"nofollow">a.=
...@scylladb.com</a>></span> wrote:<br></span><div><div class=3D"gmail_qu=
ote"><span><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-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, June 10, 2016=
at 8:30:20 PM UTC+3, Thiago Macieira wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On sexta-feira=
, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
<br>> Note that EBO is actively dangerous.=C2=A0 If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div></span><div>You don't know that beforeh=
and.</div><div><br></div><div>template <class PossiblyEmptyComparator>=
;</div><div>struct my_container;</div><div><br></div><div>Should my_contain=
er inherit from PossiblyEmptyComparator, or should it contain it as a data =
member?</div><div><br></div><div>What if PossiblyEmptyComparator is a funct=
ion pointer type?</div></div></blockquote><div><br></div></span><div>Now yo=
u're no longer talking about EBO, though. You're talking about NEBP=
: the Non-Empty Base Pessimization. <i>Obviously</i> you should never name=
=C2=A0<i>anything</i> as a base class of yours if you don't know what&#=
39;s in it. Library implementors don't do that; why should you?</div></=
div></div></div></blockquote><div><br></div><div><br></div><div>They do it =
all the time, with exactly the example I gave.=C2=A0 A colleague hit it rec=
ently with boost's binomial heap.</div><div><br></div><div>Are you sugg=
esting you should never inherit from a template parameter?</div></span></di=
v></div></div></blockquote><div><br>As he clearly said, you shouldn't i=
nherit from something you don't know what it is.<br></div></div></block=
quote><div><br></div><div><br></div><div>Well, then how can you apply EBO i=
n a library? Say, std::unordered_set<Key, Hash, ...>, where Hash may =
and often is empty.</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"><d=
iv dir=3D"ltr"><div>=C2=A0</div><span class=3D""><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Because=
then template classes can choose from:</div><div><br></div><div>1. Inherit=
ing from the base class and hitting weird problems</div><div>2. Using compl=
ex enable_if style solutions</div><div>3. Eliding the optimization altogeth=
er.</div><div><br></div><div>This could be so easily solved with=C2=A0</div=
><div><br></div><div>4. Adding [[allow_empty_size]] attribute to the data m=
ember.</div></div></div></div></blockquote></span><div><br>Attributes <i>ar=
e never allowed</i> to change the behavior of a program. That's the rul=
e with them. Period.<br>=C2=A0</div></div></blockquote><div><br></div><div>=
I'm fine with other syntax.=C2=A0 But please, not 15-lines of enable_if=
..</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div><div>But I guess we must preserve C++'s reputation=
for making things hard on its users.<br>=C2=A0</div></div></div></div></bl=
ockquote></span><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"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><div><br></div><span class=3D""><div>Re =
your comments elsethread: C doesn't have a lot of these "heavy lif=
ting" problems because it <i>does</i> allow zero-sized objects and it =
<i>doesn't</i> have a very strong type system the way C++ does. C++'=
;s heavy lifting isn't in the machine-level implementation details; the=
re you're right that the compilers can just "do what C does."=
=C2=A0The heavy lifting is in the C++-specific stuff: the <i>high-level se=
mantics</i>, the <i>language</i>. That's the hard part.</div></span></d=
iv></div></div></blockquote><span class=3D""><div><br></div><div></div><div=
>Then it's totally unreasonable for a compiler newbie like myself to tr=
y and figure them out.=C2=A0 But can you explain where in the high level se=
mantics a zero sized data member enters at all?<br></div></span></div></div=
></div></blockquote><div><br>... Everywhere? Is that a place?<br><br>C++ de=
fines an object, first and foremost, as "a region of storage". Th=
e entire C++ object model <i>relies</i> on that. A zero-sized object is ana=
thema to that definition.</div></div></blockquote><div><br></div><div><br><=
/div><div>Would not the zero-sized object occupy a zero-sized region of sto=
rage?</div><div><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> You would have to rewrite a lot of the standard befor=
e you can permit zero-sized objects.<br></div></div></blockquote><div><br><=
/div><div><br></div><div>Could you give me an example?</div><div>=C2=A0</di=
v><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></div><span cl=
ass=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53222639-9274-4dbc-a4fc-e57e94d9704c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53222639-9274-=
4dbc-a4fc-e57e94d9704c%40isocpp.org</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WLeaU51c%3DCq3H5j%3D7q-zOHZOxQN=
rHXAOY1VgnZtd4SbeQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WLeaU51=
c%3DCq3H5j%3D7q-zOHZOxQNrHXAOY1VgnZtd4SbeQ%40mail.gmail.com</a>.<br />
--001a113da350f74e760534f1d07c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 10 Jun 2016 12:53:49 -0700
Raw View
On sexta-feira, 10 de junho de 2016 11:13:41 PDT Avi Kivity wrote:
> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
> > On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
> >
> > > Note that EBO is actively dangerous. If you inherit from a class that
> > > defines a virtual member function that matches the signature of one of
> >
> > your
> >
> > > own methods, then you end up overriding it for your EBO'd type.
> >
> > A class with virtuals is not empty.
>
> You don't know that beforehand.
Yes, you do, otherwise you're putting the cart ahead of the ox.
EBO is a solution for the problem of taking up space when you know the class
is empty. If you know it's not empty or you don't know, you don't derive from
that class.
--
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/2871170.DMf7rPM5rj%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 10 Jun 2016 12:56:21 -0700
Raw View
On sexta-feira, 10 de junho de 2016 12:25:20 PDT Nicol Bolas wrote:
> We know *exactly* what behavior we want from these things. All we really
> want is for a type to be able to take up no space while it is an NSDM or
> base class of another type. It can still have a non-zero `sizeof` (thus
> permitting allocating them on the heap), so that's a can of worms we don't
> need to open up. And the `this` pointer for member functions is irrelevant,
> since because the class is stateless, it doesn't need to access any
> non-stateless NSDMs.
The this pointer may be used for other things, like looking up information in
a global variable keyed to the address.
--
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/2395229.0cdAKMefiS%40tjmaciei-mobl1.
.
Author: Avi Kivity <avi@scylladb.com>
Date: Fri, 10 Jun 2016 23:11:21 +0300
Raw View
--001a114b2f6696c5f00534f2254c
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 10, 2016 at 10:53 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On sexta-feira, 10 de junho de 2016 11:13:41 PDT Avi Kivity wrote:
> > On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
> > > On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
> > >
> > > > Note that EBO is actively dangerous. If you inherit from a class
> that
> > > > defines a virtual member function that matches the signature of one
> of
> > >
> > > your
> > >
> > > > own methods, then you end up overriding it for your EBO'd type.
> > >
> > > A class with virtuals is not empty.
> >
> > You don't know that beforehand.
>
> Yes, you do, otherwise you're putting the cart ahead of the ox.
>
> EBO is a solution for the problem of taking up space when you know the
> class
> is empty. If you know it's not empty or you don't know, you don't derive
> from
> that class.
>
>
Then it's very difficult to use EBO. You have to provide two
specializations for the two cases, because in the general case, you know
very little about the parameter.
I'm trying to make EBO usable.
> --
> 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/2871170.DMf7rPM5rj%40tjmaciei-mobl1
> .
>
--
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/CAF950WLTN%3DjQeXKuoMvaPeKJtY81%2BPfzOmkBaW-dA%2BBxqOLjfA%40mail.gmail.com.
--001a114b2f6696c5f00534f2254c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jun 10, 2016 at 10:53 PM, Thiago Macieira <span dir=3D"ltr"><=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>On sexta-feira, 10 de junho de 2016 11:13:41 PDT Avi Kivity wrote:<br>
> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:<b=
r>
> > On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote=
:<br>
> ><br>
> > > Note that EBO is actively dangerous.=C2=A0 If you inherit fr=
om a class that<br>
> > > defines a virtual member function that matches the signature=
of one of<br>
> ><br>
> > your<br>
> ><br>
> > > own methods, then you end up overriding it for your EBO'=
d type.<br>
> ><br>
> > A class with virtuals is not empty.<br>
><br>
> You don't know that beforehand.<br>
<br>
</span>Yes, you do, otherwise you're putting the cart ahead of the ox.<=
br>
<br>
EBO is a solution for the problem of taking up space when you know the clas=
s<br>
is empty. If you know it's not empty or you don't know, you don'=
;t derive from<br>
that class.<br>
<span class=3D""><br></span></blockquote><div><br></div><div><br></div><div=
>Then it's very difficult to use EBO.=C2=A0 You have to provide two spe=
cializations for the two cases, because in the general case, you know very =
little about the parameter.</div><div><br></div><div>I'm trying to make=
EBO usable.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D"">
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/2871170.DMf7rPM5rj%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/2871170.DMf7rPM5rj%40tjmaciei-mobl1</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WLTN%3DjQeXKuoMvaPeKJtY81%2BPfz=
OmkBaW-dA%2BBxqOLjfA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WLTN%=
3DjQeXKuoMvaPeKJtY81%2BPfzOmkBaW-dA%2BBxqOLjfA%40mail.gmail.com</a>.<br />
--001a114b2f6696c5f00534f2254c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 14:56:05 -0700 (PDT)
Raw View
------=_Part_2420_1539352129.1465595765324
Content-Type: multipart/alternative;
boundary="----=_Part_2421_1763263871.1465595765325"
------=_Part_2421_1763263871.1465595765325
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>
> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>> lifting" problems because it *does* allow zero-sized objects and it
>>>> *doesn't* have a very strong type system the way C++ does. C++'s heavy
>>>> lifting isn't in the machine-level implementation details; there you're
>>>> right that the compilers can just "do what C does." The heavy lifting is
>>>> in the C++-specific stuff: the *high-level semantics*, the *language*.
>>>> That's the hard part.
>>>>
>>>
>>> Then it's totally unreasonable for a compiler newbie like myself to try
>>> and figure them out. But can you explain where in the high level semantics
>>> a zero sized data member enters at all?
>>>
>>
>> ... Everywhere? Is that a place?
>>
>> C++ defines an object, first and foremost, as "a region of storage". The
>> entire C++ object model *relies* on that. A zero-sized object is
>> anathema to that definition.
>>
>
>
> Would not the zero-sized object occupy a zero-sized region of storage?
>
And what exactly is "a zero-sized region of storage"? You cannot allocate
or deallocate *nothing*. Even `malloc` doesn't work reasonably with zero.
You may or may not get back a NULL pointer, but whatever you get back, you
aren't allowed to dereference it.
What does it mean to have the address of, or a reference to, nothing? What
does it mean to perform pointer arithmetic on a pointer to nothing? Can you
have an array of nothing?
You would have to rewrite a lot of the standard before you can permit
>> zero-sized objects.
>>
>
>
> Could you give me an example?
>
You're the one proposing it. You're the one claiming that it's easy. The
burden of proof here is on *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/f4f103ad-587a-4f87-b48d-31c08b533366%40isocpp.org.
------=_Part_2421_1763263871.1465595765325
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity w=
rote:<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><di=
v class=3D"gmail_quote">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"bo529IfqAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">jmck...@gmail.com</a>></span> wrote: <br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div><div></div></div></div></div></blockquote></sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><span><div>Re your comments elsethread: C =
doesn't have a lot of these "heavy lifting" problems because =
it <i>does</i> allow zero-sized objects and it <i>doesn't</i> have a ve=
ry strong type system the way C++ does. C++'s heavy lifting isn't i=
n the machine-level implementation details; there you're right that the=
compilers can just "do what C does." =C2=A0The heavy lifting is =
in the C++-specific stuff: the <i>high-level semantics</i>, the <i>language=
</i>. That's the hard part.</div></span></div></div></div></blockquote>=
<span><div><br></div><div></div><div>Then it's totally unreasonable for=
a compiler newbie like myself to try and figure them out.=C2=A0 But can yo=
u explain where in the high level semantics a zero sized data member enters=
at all?<br></div></span></div></div></div></blockquote><div><br>... Everyw=
here? Is that a place?<br><br>C++ defines an object, first and foremost, as=
"a region of storage". The entire C++ object model <i>relies</i>=
on that. A zero-sized object is anathema to that definition.</div></div></=
blockquote><div><br></div><div><br></div><div>Would not the zero-sized obje=
ct occupy a zero-sized region of storage?</div></div></div></div></blockquo=
te><div><br>And what exactly is "a zero-sized region of storage"?=
You cannot allocate or deallocate <i>nothing</i>. Even `malloc` doesn'=
t work reasonably with zero. You may or may not get back a NULL pointer, bu=
t whatever you get back, you aren't allowed to dereference it.<br><br>W=
hat does it mean to have the address of, or a reference to, nothing? What d=
oes it mean to perform pointer arithmetic on a pointer to nothing? Can you =
have an array of nothing?<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div> You would have to rewrite a=
lot of the standard before you can permit zero-sized objects.<br></div></d=
iv></blockquote><div><br></div><div><br></div><div>Could you give me an exa=
mple?</div></div></div></div></blockquote><div><br>You're the one propo=
sing it. You're the one claiming that it's easy. The burden of proo=
f here is on <i>you</i>.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4f103ad-587a-4f87-b48d-31c08b533366%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4f103ad-587a-4f87-b48d-31c08b533366=
%40isocpp.org</a>.<br />
------=_Part_2421_1763263871.1465595765325--
------=_Part_2420_1539352129.1465595765324--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Jun 2016 15:04:35 -0700 (PDT)
Raw View
------=_Part_2472_198872204.1465596275484
Content-Type: multipart/alternative;
boundary="----=_Part_2473_731085134.1465596275484"
------=_Part_2473_731085134.1465596275484
Content-Type: text/plain; charset=UTF-8
On Friday, June 10, 2016 at 4:11:42 PM UTC-4, Avi Kivity wrote:
>
> On Fri, Jun 10, 2016 at 10:53 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On sexta-feira, 10 de junho de 2016 11:13:41 PDT Avi Kivity wrote:
>> > On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>> > > On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
>> > >
>> > > > Note that EBO is actively dangerous. If you inherit from a class
>> that
>> > > > defines a virtual member function that matches the signature of one
>> of
>> > >
>> > > your
>> > >
>> > > > own methods, then you end up overriding it for your EBO'd type.
>> > >
>> > > A class with virtuals is not empty.
>> >
>> > You don't know that beforehand.
>>
>> Yes, you do, otherwise you're putting the cart ahead of the ox.
>>
>> EBO is a solution for the problem of taking up space when you know the
>> class
>> is empty. If you know it's not empty or you don't know, you don't derive
>> from
>
> that class.
>>
>
> Then it's very difficult to use EBO. You have to provide two
> specializations for the two cases, because in the general case, you know
> very little about the parameter.
>
> I'm trying to make EBO usable.
>
Please stop treating the Empty Base Optimization like its *sole purpose* is
to be used by some template type to store some other template type without
taking up space in the total aggregate object. That is certainly a viable
use for the EBO, but that's not the only reason why we have it.
The Empty Base Optimization is perfectly usable right now. It's just
cumbersome for your *specific* 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/76ba6609-8100-4ed6-9baf-2f9f4097314e%40isocpp.org.
------=_Part_2473_731085134.1465596275484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 10, 2016 at 4:11:42 PM UTC-4, Avi Kivity w=
rote:<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><di=
v class=3D"gmail_quote">On Fri, Jun 10, 2016 at 10:53 PM, Thiago Macieira <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"Cl1qfdLrAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;;return true;">thi...@macieira.org</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span>On sexta-feira, 10 de junho de 2016 11:13:41 PDT Avi=
Kivity wrote:<br>
> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:<b=
r>
> > On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote=
:<br>
> ><br>
> > > Note that EBO is actively dangerous.=C2=A0 If you inherit fr=
om a class that<br>
> > > defines a virtual member function that matches the signature=
of one of<br>
> ><br>
> > your<br>
> ><br>
> > > own methods, then you end up overriding it for your EBO'=
d type.<br>
> ><br>
> > A class with virtuals is not empty.<br>
><br>
> You don't know that beforehand.<br>
<br>
</span>Yes, you do, otherwise you're putting the cart ahead of the ox.<=
br>
<br>
EBO is a solution for the problem of taking up space when you know the clas=
s<br>
is empty. If you know it's not empty or you don't know, you don'=
;t derive from=C2=A0</blockquote></div></div></div></blockquote><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">that class.
<span><br></span></blockquote><div><br></div><div></div><div>Then it's =
very difficult to use EBO.=C2=A0 You have to provide two specializations fo=
r the two cases, because in the general case, you know very little about th=
e parameter.</div><div><br></div><div>I'm trying to make EBO usable.<br=
></div></div></div></div></blockquote><div><br>Please stop treating the Emp=
ty Base Optimization like its <i>sole purpose</i> is to be used by some tem=
plate type to store some other template type without taking up space in the=
total aggregate object. That is certainly a viable use for the EBO, but th=
at's not the only reason why we have it.<br><br>The Empty Base Optimiza=
tion is perfectly usable right now. It's just cumbersome for your <i>sp=
ecific</i> use case.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76ba6609-8100-4ed6-9baf-2f9f4097314e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76ba6609-8100-4ed6-9baf-2f9f4097314e=
%40isocpp.org</a>.<br />
------=_Part_2473_731085134.1465596275484--
------=_Part_2472_198872204.1465596275484--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 10 Jun 2016 16:14:39 -0700
Raw View
--001a1146cfa0ffd4d60534f4b3f0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2016 at 12:25 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 10, 2016 at 3:07:19 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> Re your comments elsethread: C doesn't have a lot of these "heavy
>> lifting" problems because it *does* allow zero-sized objects and it
>> *doesn't* have a very strong type system the way C++ does. C++'s heavy
>> lifting isn't in the machine-level implementation details; there you're
>> right that the compilers can just "do what C does." The heavy lifting i=
s
>> in the C++-specific stuff: the *high-level semantics*, the *language*.
>> That's the hard part.
>>
>
> To be fair, the high level semantics are the *easy* part.
>
> We know *exactly* what behavior we want from these things. [...]
>
Hi Nicol,
For the record, we're actually in violent agreement here. When I wrote
"high-level", I meant "high-level" as in "high-level language". I believe
everyone agrees 100% on what *machine code* we want generated for these
things; the heavy lifting is all on the philosophical, language-lawyery
side. "Dude, what does zero size even *mean*?", you know? So by
"low-level" I meant "machine code" and by "high-level" I meant "C++
standard".
Whereas by "high-level" you (seem to have) meant "abstract handwavey idea"
and by "low-level" you (seem to have) meant "nitty-gritty details of
standardese".
I think we're in complete agreement on where the problems are, even if
we've used exactly opposite adjectives to describe them. :)
I agree with all of your 5 specific points, especially the one about arrays
of zero-sized elements.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0J0dRupoepzXP7wC89KcH5DtWJ4eKPPgpqQet5yRQ5=
JwA%40mail.gmail.com.
--001a1146cfa0ffd4d60534f4b3f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jun 10, 2016 at 12:25 PM, Nicol Bolas <span dir=3D=
"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span clas=
s=3D"">On Friday, June 10, 2016 at 3:07:19 PM UTC-4, Arthur O'Dwyer wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><div>Re your comments elsethread: C doesn't have a lot of t=
hese "heavy lifting" problems because it <i>does</i> allow zero-s=
ized objects and it <i>doesn't</i> have a very strong type system the w=
ay C++ does. C++'s heavy lifting isn't in the machine-level impleme=
ntation details; there you're right that the compilers can just "d=
o what C does." =C2=A0The heavy lifting is in the C++-specific stuff: =
the <i>high-level semantics</i>, the <i>language</i>. That's the hard p=
art.</div></div></div></blockquote></span><div><br>To be fair, the high lev=
el semantics are the <i>easy</i> part.<br><br>We know <i>exactly</i> what b=
ehavior we want from these things. [...]</div></div></blockquote><div><br><=
/div><div>Hi Nicol,</div><div>For the record, we're actually in violent=
agreement here.=C2=A0 When I wrote "high-level", I meant "h=
igh-level" as in "high-level language".=C2=A0 I believe ever=
yone agrees 100% on what <i>machine code</i> we want generated for these th=
ings; the heavy lifting is all on the philosophical, language-lawyery side.=
"Dude, what does zero size even <i>mean</i>?", you know?=C2=A0 S=
o by "low-level" I meant "machine code" and by "hi=
gh-level" I meant "C++ standard".</div><div><br></div><div>W=
hereas by "high-level" you (seem to have) meant "abstract ha=
ndwavey idea" and by "low-level" you (seem to have) meant &q=
uot;nitty-gritty details of standardese".</div><div><br></div><div>I t=
hink we're in complete agreement on where the problems are, even if we&=
#39;ve used exactly opposite adjectives to describe them. :)</div><div><br>=
</div><div>I agree with all of your 5 specific points, especially the one a=
bout arrays of zero-sized elements.</div><div><br></div><div>=E2=80=93Arthu=
r</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0J0dRupoepzXP7wC89KcH5DtWJ4eKPP=
gpqQet5yRQ5JwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0J0dRupoepz=
XP7wC89KcH5DtWJ4eKPPgpqQet5yRQ5JwA%40mail.gmail.com</a>.<br />
--001a1146cfa0ffd4d60534f4b3f0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 10 Jun 2016 16:56:02 -0700
Raw View
On sexta-feira, 10 de junho de 2016 23:11:21 PDT Avi Kivity wrote:
> > Yes, you do, otherwise you're putting the cart ahead of the ox.
> >
> > EBO is a solution for the problem of taking up space when you know the
> > class
> > is empty. If you know it's not empty or you don't know, you don't derive
> > from
> > that class.
>
> Then it's very difficult to use EBO. You have to provide two
> specializations for the two cases, because in the general case, you know
> very little about the parameter.
>
> I'm trying to make EBO usable.
You're again putting the cart ahead of the oxen.
You don't use EBO. Compilers aren't required to have that optimisation.
It just happens that some do and therefore library writers have used that
optimisation to to save space. The objective is to save space, not to derive.
--
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/3430372.t4tFe8WtuC%40tjmaciei-mobl1.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 10 Jun 2016 17:16:27 -0700
Raw View
--001a113f495e055f0e0534f5917c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 10, 2016 at 12:47 PM, Avi Kivity <avi@scylladb.com> wrote:
> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>
>> On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:
>>>
>>> On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur....@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Now you're no longer talking about EBO, though. You're talking about
>>>> NEBP: the Non-Empty Base Pessimization. *Obviously* you should never
>>>> name *anything* as a base class of yours if you don't know what's in
>>>> it. Library implementors don't do that; why should you?
>>>>
>>>
>>> They do it all the time, with exactly the example I gave. A colleague
>>> hit it recently with boost's binomial heap.
>>>
>>
Huh. I checked with the Boost code
<http://www.boost.org/doc/libs/1_52_0/boost/heap/binomial_heap.hpp> and
then with Wandbox <http://melpon.org/wandbox/permlink/jrQkoIvhiEcirdHw> and
you're correct, boost::heap::binomial_heap is incorrectly implemented.
(It's also apparently been unmaintained for a while, as it produces a whole
spew of warnings when compiled with Clang.) binomial_heap exposes (makes
user-visible) private member functions such as allocate() and construct()
which aren't supposed to exist in its interface; basically Boost is
claiming that a heap is-an <https://en.wikipedia.org/wiki/Is-a> allocator,
which is nonsense as far as I'm concerned.
This may be defensible on the grounds of "everybody used to do it this
way," or it may be indefensible, I'm not old enough to judge. :) But I do
think that these days it's not the *right* way to do it.
>
>>> Are you suggesting you should never inherit from a template parameter?
>>>
>>
>> As he clearly said, you shouldn't inherit from something you don't know
>> what it is.
>>
>
> Well, then how can you apply EBO in a library? Say,
> std::unordered_set<Key, Hash, ...>, where Hash may and often is empty.
>
The way I said (and provided code for). You pick one of your members to
combine in a tuple with that possibly-empty member. Thanks to Howard
Hinnant's reply in this thread, I gather that on good implementations
(which I'm just going to blithely assume means "all popular
implementations" ;)) you can do it via
template<class Key, class Hash, class EqualityComparator>
class unordered_set {
using bucket =3D std::list<Key>;
std::tuple<Hash, EqualityComparator, std::vector<bucket>> m;
auto&& hash() { return std::get<0>(m); }
auto&& cmp() { return std::get<1>(m); }
auto&& buckets() { return std::get<2>(m); }
};
unordered_set *is-not-a* hash, and *is-not-a* comparator; but it does
*have-a* hash and *have-a* comparator. We write our code to express that
relationship, and then we get correct and efficient code basically for free=
..
To the extent that std::tuple doesn't give us efficient code (e.g. if it
orders the members wrong and thus wastes a lot of space on padding),
vendors can go fix *that*; that's easy. Or if users are demanding a way to
implement tuple-like types (not identical to std::tuple) without so much
metaprogramming, then that sounds like it might produce some kind of
change. But it sounds basically like you're asking for zero-sized objects
in C++ (which is unlikely to happen), and your particular use-case is
already solved by std::tuple (modulo possible Quality of Implementation
issues with some vendors), so there's not a lot of motivation to do
anything about it.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BhUnFaCsZva5pNRZFESfh44uTGu%3DPJ7xoikgp=
nRgNZwA%40mail.gmail.com.
--001a113f495e055f0e0534f5917c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jun 10, 2016 at 12:47 PM, Avi Kivity <span dir=3D"=
ltr"><<a href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylladb=
..com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr">On Fri, Jun 10, 2016 at 10:38 PM=
, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" =
target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote cl=
ass=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:1e=
x"><div dir=3D"ltr">On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivit=
y wrote:<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_quote">On Fri=
, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a rel=
=3D"nofollow">arthur....@gmail.com</a>></span> wrote:<span><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span><div><br></d=
iv></span><div>Now you're no longer talking about EBO, though. You'=
re talking about NEBP: the Non-Empty Base Pessimization. <i>Obviously</i> y=
ou should never name=C2=A0<i>anything</i> as a base class of yours if you d=
on't know what's in it. Library implementors don't do that; why=
should you?</div></div></div></div></blockquote><div><br></div><div>They d=
o it all the time, with exactly the example I gave.=C2=A0 A colleague hit i=
t recently with boost's binomial heap.</div></span></div></div></blockq=
uote></div></blockquote></span></div></div></div></blockquote><div><br></di=
v><div>Huh. I checked with <a href=3D"http://www.boost.org/doc/libs/1_52_0/=
boost/heap/binomial_heap.hpp">the Boost code</a> and then with <a href=3D"h=
ttp://melpon.org/wandbox/permlink/jrQkoIvhiEcirdHw">Wandbox</a> and you'=
;re correct, boost::heap::binomial_heap is incorrectly implemented. (It'=
;s also apparently been unmaintained for a while, as it produces a whole sp=
ew of warnings when compiled with Clang.) =C2=A0binomial_heap exposes (make=
s user-visible) private member functions such as allocate() and construct()=
which aren't supposed to exist in its interface; basically Boost is cl=
aiming that a heap <a href=3D"https://en.wikipedia.org/wiki/Is-a">is-an</a>=
allocator, which is nonsense as far as I'm concerned.</div><div><br></=
div><div>This may be defensible on the grounds of "everybody used to d=
o it this way," or it may be indefensible, I'm not old enough to j=
udge. :) =C2=A0But I do think that these days it's not the <i>right</i>=
way to do it.</div><div><br></div><div>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n class=3D""><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"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><span><div><br></div><div>Are you sug=
gesting you should never inherit from a template parameter?</div></span></d=
iv></div></div></blockquote><div><br>As he clearly said, you shouldn't =
inherit from something you don't know what it is.<br></div></div></bloc=
kquote><div><br></div></span><div>Well, then how can you apply EBO in a lib=
rary? Say, std::unordered_set<Key, Hash, ...>, where Hash may and oft=
en is empty.</div></div></div></div></blockquote><div><br></div><div>The wa=
y I said (and provided code for).=C2=A0 You pick one of your members to com=
bine in a tuple with that possibly-empty member. Thanks to Howard Hinnant&#=
39;s reply in this thread, I gather that on good implementations (which I&#=
39;m just going to blithely assume means "all popular implementations&=
quot; ;)) you can do it via</div><div><br></div><div><font face=3D"monospac=
e, monospace">=C2=A0 =C2=A0 template<class Key, class Hash, class Equali=
tyComparator></font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 class unordered_set {</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 using bucket =3D std::list<Key>=
;;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 std::tuple<Hash,=C2=A0EqualityComparator, std::vector<buck=
et>> m;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 auto&& hash() { return std::get<0>(m); }=
</font></div><div><div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 auto&& cmp() { return std::get<1>(m); }</fo=
nt></div></div></div><div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 auto&& buckets() { return std::get<2>(m)=
; }</font></div></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=
=A0 };</font></div><div><br></div><div>unordered_set <b>is-not-a</b> hash, =
and <b>is-not-a</b> comparator; but it does <b>have-a</b> hash and <b>have-=
a</b> comparator. We write our code to express that relationship, and then =
we get correct and efficient code basically for free.</div><div><br></div><=
div>To the extent that std::tuple doesn't give us efficient code (e.g. =
if it orders the members wrong and thus wastes a lot of space on padding), =
vendors can go fix <i>that</i>; that's easy. Or if users are demanding =
a way to implement tuple-like types (not identical to std::tuple) without s=
o much metaprogramming, then that sounds like it might produce some kind of=
change. But it sounds basically like you're asking for zero-sized obje=
cts in C++ (which is unlikely to happen), and your particular use-case is a=
lready solved by std::tuple (modulo possible Quality of Implementation issu=
es with some vendors), so there's not a lot of motivation to do anythin=
g about it.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BhUnFaCsZva5pNRZFESfh44uTGu%=
3DPJ7xoikgpnRgNZwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BhUn=
FaCsZva5pNRZFESfh44uTGu%3DPJ7xoikgpnRgNZwA%40mail.gmail.com</a>.<br />
--001a113f495e055f0e0534f5917c--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 11 Jun 2016 13:15:06 +0300
Raw View
--047d7b67092b2223680534fdef55
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>
>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>>> lifting" problems because it *does* allow zero-sized objects and it
>>>>> *doesn't* have a very strong type system the way C++ does. C++'s
>>>>> heavy lifting isn't in the machine-level implementation details; there
>>>>> you're right that the compilers can just "do what C does." The heavy
>>>>> lifting is in the C++-specific stuff: the *high-level semantics*, the
>>>>> *language*. That's the hard part.
>>>>>
>>>>
>>>> Then it's totally unreasonable for a compiler newbie like myself to try
>>>> and figure them out. But can you explain where in the high level semantics
>>>> a zero sized data member enters at all?
>>>>
>>>
>>> ... Everywhere? Is that a place?
>>>
>>> C++ defines an object, first and foremost, as "a region of storage". The
>>> entire C++ object model *relies* on that. A zero-sized object is
>>> anathema to that definition.
>>>
>>
>>
>> Would not the zero-sized object occupy a zero-sized region of storage?
>>
>
> And what exactly is "a zero-sized region of storage"? You cannot allocate
> or deallocate *nothing*. Even `malloc` doesn't work reasonably with zero.
> You may or may not get back a NULL pointer, but whatever you get back, you
> aren't allowed to dereference it.
>
>
That never comes into question. The zero-sized region is always part of a
larger non-zero-sized region.
Zero-sized regions seem to exist just fine in C++, when inheriting from an
empty base class, and in C, with empty struct members. Both C++ and C seem
to have solved this problem.
> What does it mean to have the address of, or a reference to, nothing?
>
The same thing as
struct B {};
struct D : B { int x; };
D d;
B* ptr_to_nothing = &d; // actually points at d.x
B& ref_to_nothing = d;
> What does it mean to perform pointer arithmetic on a pointer to nothing?
>
B* arithmetic = ptr_to_nothing + 1;
> Can you have an array of nothing?
>
No. The attribute or whatever syntax we choose applies to structs, not
arrays.
>
> You would have to rewrite a lot of the standard before you can permit
>>> zero-sized objects.
>>>
>>
>>
>> Could you give me an example?
>>
>
> You're the one proposing it. You're the one claiming that it's easy. The
> burden of proof here is on *you*.
>
I'm perfectly willing to shoulder the burden of proof, but since you
claimed the problem is Everywhere, I thought it would be trivial for me to
help me start out.
I am unable to even see the problem. Perhaps I'm not suited to the task,
or perhaps that's because the compiler writers have already figured it out
for base classes and C data members.
> --
> 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/f4f103ad-587a-4f87-b48d-31c08b533366%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4f103ad-587a-4f87-b48d-31c08b533366%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/CAF950W%2BqUxj4tu03qa9rVLUTFE8Hg6e%2BCAxxStHtS-90TjbCxQ%40mail.gmail.com.
--047d7b67092b2223680534fdef55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Friday, June 1=
0, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:<span class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jun 10, 2016 =
at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@=
gmail.com</a>></span> wrote: <br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div><div><div></div></div></div></div><=
/blockquote></span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div></div><span><div>Re your comments elsethread: C doesn't have a lo=
t of these "heavy lifting" problems because it <i>does</i> allow =
zero-sized objects and it <i>doesn't</i> have a very strong type system=
the way C++ does. C++'s heavy lifting isn't in the machine-level i=
mplementation details; there you're right that the compilers can just &=
quot;do what C does." =C2=A0The heavy lifting is in the C++-specific s=
tuff: the <i>high-level semantics</i>, the <i>language</i>. That's the =
hard part.</div></span></div></div></div></blockquote><span><div><br></div>=
<div></div><div>Then it's totally unreasonable for a compiler newbie li=
ke myself to try and figure them out.=C2=A0 But can you explain where in th=
e high level semantics a zero sized data member enters at all?<br></div></s=
pan></div></div></div></blockquote><div><br>... Everywhere? Is that a place=
?<br><br>C++ defines an object, first and foremost, as "a region of st=
orage". The entire C++ object model <i>relies</i> on that. A zero-size=
d object is anathema to that definition.</div></div></blockquote><div><br><=
/div><div><br></div><div>Would not the zero-sized object occupy a zero-size=
d region of storage?</div></div></div></div></blockquote></span><div><br>An=
d what exactly is "a zero-sized region of storage"? You cannot al=
locate or deallocate <i>nothing</i>. Even `malloc` doesn't work reasona=
bly with zero. You may or may not get back a NULL pointer, but whatever you=
get back, you aren't allowed to dereference it.<br><br></div></div></b=
lockquote><div><br></div><div><br></div><div>That never comes into question=
..=C2=A0 The zero-sized region is always part of a larger non-zero-sized reg=
ion.</div><div><br></div><div>Zero-sized regions seem to exist just fine in=
C++, when inheriting from an empty base class, and in C, with empty struct=
members.=C2=A0 Both C++ and C seem to have solved this problem.</div><div>=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-le=
ft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>What does=
it mean to have the address of, or a reference to, nothing?</div></div></b=
lockquote><div><br></div><div><br></div><div>The same thing as</div><div><b=
r></div><div>=C2=A0 struct B {};</div><div>=C2=A0 struct D : B { int x; };<=
/div><div>=C2=A0 D d;</div><div>=C2=A0 B* ptr_to_nothing =3D &d; =C2=A0=
// actually points at d.x</div><div>=C2=A0 B& ref_to_nothing =3D d;</di=
v><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
What does it mean to perform pointer arithmetic on a pointer to nothing?</=
div></div></blockquote><div><br></div><div><br></div><div>=C2=A0B* arithmet=
ic =3D ptr_to_nothing + 1;</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div> Can you have an array of nothing?<br></div></div></blockquot=
e><div><br></div><div>No.=C2=A0 The attribute or whatever syntax we choose =
applies to structs, not arrays.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><br></div><span class=3D""><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div> You would have to rewrite a lot of the standard =
before you can permit zero-sized objects.<br></div></div></blockquote><div>=
<br></div><div><br></div><div>Could you give me an example?</div></div></di=
v></div></blockquote></span><div><br>You're the one proposing it. You&#=
39;re the one claiming that it's easy. The burden of proof here is on <=
i>you</i>.<br></div></div></blockquote><div><br></div><div><br></div><div>I=
'm perfectly willing to shoulder the burden of proof, but since you cla=
imed the problem is Everywhere, I thought it would be trivial for me to hel=
p me start out.</div><div><br></div><div>I am unable to even see the proble=
m.=C2=A0 Perhaps I'm not suited to the task, or perhaps that's beca=
use the compiler writers have already figured it out for base classes and C=
data members.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4f103ad-587a-4f87-b48d-31c08b533366%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f4f103ad-587a-=
4f87-b48d-31c08b533366%40isocpp.org</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BqUxj4tu03qa9rVLUTFE8Hg6e%2B=
CAxxStHtS-90TjbCxQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BqUx=
j4tu03qa9rVLUTFE8Hg6e%2BCAxxStHtS-90TjbCxQ%40mail.gmail.com</a>.<br />
--047d7b67092b2223680534fdef55--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 11 Jun 2016 13:16:08 +0300
Raw View
--001a114b2f66d360250534fdf27b
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 11, 2016 at 2:56 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On sexta-feira, 10 de junho de 2016 23:11:21 PDT Avi Kivity wrote:
> > > Yes, you do, otherwise you're putting the cart ahead of the ox.
> > >
> > > EBO is a solution for the problem of taking up space when you know the
> > > class
> > > is empty. If you know it's not empty or you don't know, you don't
> derive
> > > from
> > > that class.
> >
> > Then it's very difficult to use EBO. You have to provide two
> > specializations for the two cases, because in the general case, you know
> > very little about the parameter.
> >
> > I'm trying to make EBO usable.
>
> You're again putting the cart ahead of the oxen.
>
> You don't use EBO. Compilers aren't required to have that optimisation.
>
> It just happens that some do and therefore library writers have used that
> optimisation to to save space. The objective is to save space, not to
> derive.
>
>
You are right, I worded it poorly. My proposal is an alternative to EBO
that makes EBO unnecessary.
> --
> 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/3430372.t4tFe8WtuC%40tjmaciei-mobl1
> .
>
--
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/CAF950WKGrRqn9wxwesWCRfRLzff_sC0iDQgB3nMNct%3DfEpBR4g%40mail.gmail.com.
--001a114b2f66d360250534fdf27b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 11, 2016 at 2:56 AM, Thiago Macieira <span dir=3D"ltr"><=
<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On sexta-feira, 10 de junho de 2016 23:11:21 PDT Avi Kivity wrote:<br>
> > Yes, you do, otherwise you're putting the cart ahead of the o=
x.<br>
> ><br>
> > EBO is a solution for the problem of taking up space when you kno=
w the<br>
> > class<br>
> > is empty. If you know it's not empty or you don't know, y=
ou don't derive<br>
> > from<br>
> > that class.<br>
><br>
> Then it's very difficult to use EBO.=C2=A0 You have to provide two=
<br>
> specializations for the two cases, because in the general case, you kn=
ow<br>
> very little about the parameter.<br>
><br>
> I'm trying to make EBO usable.<br>
<br>
</span>You're again putting the cart ahead of the oxen.<br>
<br>
You don't use EBO. Compilers aren't required to have that optimisat=
ion.<br>
<br>
It just happens that some do and therefore library writers have used that<b=
r>
optimisation to to save space. The objective is to save space, not to deriv=
e.<br>
<span class=3D""><br></span></blockquote><div><br></div><div><br></div><div=
>You are right, I worded it poorly.=C2=A0 My proposal is an alternative to =
EBO that makes EBO unnecessary.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><span class=3D"">
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/3430372.t4tFe8WtuC%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/3430372.t4tFe8WtuC%40tjmaciei-mobl1</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WKGrRqn9wxwesWCRfRLzff_sC0iDQgB=
3nMNct%3DfEpBR4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WKGrRqn9w=
xwesWCRfRLzff_sC0iDQgB3nMNct%3DfEpBR4g%40mail.gmail.com</a>.<br />
--001a114b2f66d360250534fdf27b--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 11 Jun 2016 13:24:08 +0300
Raw View
--001a1144422c66df940534fe0f1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 11, 2016 at 3:16 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> On Fri, Jun 10, 2016 at 12:47 PM, Avi Kivity <avi@scylladb.com> wrote:
>
>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmckesson@gmail.com>
>> wrote:
>>
>>> On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:
>>>>
>>>> On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur....@gmail.com=
>
>>>> wrote:
>>>>
>>>>>
>>>>> Now you're no longer talking about EBO, though. You're talking about
>>>>> NEBP: the Non-Empty Base Pessimization. *Obviously* you should never
>>>>> name *anything* as a base class of yours if you don't know what's in
>>>>> it. Library implementors don't do that; why should you?
>>>>>
>>>>
>>>> They do it all the time, with exactly the example I gave. A colleague
>>>> hit it recently with boost's binomial heap.
>>>>
>>>
> Huh. I checked with the Boost code
> <http://www.boost.org/doc/libs/1_52_0/boost/heap/binomial_heap.hpp> and
> then with Wandbox <http://melpon.org/wandbox/permlink/jrQkoIvhiEcirdHw>
> and you're correct, boost::heap::binomial_heap is incorrectly implemented=
..
> (It's also apparently been unmaintained for a while, as it produces a who=
le
> spew of warnings when compiled with Clang.) binomial_heap exposes (makes
> user-visible) private member functions such as allocate() and construct()
> which aren't supposed to exist in its interface; basically Boost is
> claiming that a heap is-an <https://en.wikipedia.org/wiki/Is-a>
> allocator, which is nonsense as far as I'm concerned.
>
> This may be defensible on the grounds of "everybody used to do it this
> way," or it may be indefensible, I'm not old enough to judge. :) But I d=
o
> think that these days it's not the *right* way to do it.
>
>
Of course it has a bug. My point is that save that extra word of memory is
hard and error prone. Should the language force you to decide between
verbose and error prone code, or efficient code?
>
>
>>
>>>> Are you suggesting you should never inherit from a template parameter?
>>>>
>>>
>>> As he clearly said, you shouldn't inherit from something you don't know
>>> what it is.
>>>
>>
>> Well, then how can you apply EBO in a library? Say,
>> std::unordered_set<Key, Hash, ...>, where Hash may and often is empty.
>>
>
> The way I said (and provided code for). You pick one of your members to
> combine in a tuple with that possibly-empty member. Thanks to Howard
> Hinnant's reply in this thread, I gather that on good implementations
> (which I'm just going to blithely assume means "all popular
> implementations" ;)) you can do it via
>
> template<class Key, class Hash, class EqualityComparator>
> class unordered_set {
> using bucket =3D std::list<Key>;
> std::tuple<Hash, EqualityComparator, std::vector<bucket>> m;
> auto&& hash() { return std::get<0>(m); }
> auto&& cmp() { return std::get<1>(m); }
> auto&& buckets() { return std::get<2>(m); }
> };
>
> unordered_set *is-not-a* hash, and *is-not-a* comparator; but it does
> *have-a* hash and *have-a* comparator. We write our code to express that
> relationship, and then we get correct and efficient code basically for fr=
ee.
>
>
I agree this is much better than most EBO uses I've seen. But (a)
non-EBOing std::tuple implementations exist, and are in widespread use. (b)
you're still writing boilerplate (and you omitted const accessors) (c) this
only works if you know for sure there's one member which is non-empty (d)
it forces an initialization order on your members.
> To the extent that std::tuple doesn't give us efficient code (e.g. if it
> orders the members wrong and thus wastes a lot of space on padding),
> vendors can go fix *that*; that's easy.
>
Not if they want to maintain ABI compatibility, which they do.
> Or if users are demanding a way to implement tuple-like types (not
> identical to std::tuple) without so much metaprogramming, then that sound=
s
> like it might produce some kind of change. But it sounds basically like
> you're asking for zero-sized objects in C++ (which is unlikely to happen)=
,
> and your particular use-case is already solved by std::tuple (modulo
> possible Quality of Implementation issues with some vendors), so there's
> not a lot of motivation to do anything about it.
>
>
You mean, if it can be theoretically made to work, but is completely
impractical, we can consider the problem solved?
> =E2=80=93Arthur
>
> --
> 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/CADvuK0%2BhU=
nFaCsZva5pNRZFESfh44uTGu%3DPJ7xoikgpnRgNZwA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2Bh=
UnFaCsZva5pNRZFESfh44uTGu%3DPJ7xoikgpnRgNZwA%40mail.gmail.com?utm_medium=3D=
email&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/CAF950W%2BKJEHkG0x-Z3R22bDMLSx%2BL9mn8x4ZrJj9_j5=
Zrx7Yug%40mail.gmail.com.
--001a1144422c66df940534fe0f1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 11, 2016 at 3:16 AM, Arthur O'Dwyer <span dir=3D"ltr">&=
lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.=
odwyer@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span class=3D"">On Fri, Jun 10, 2016 at 12:47 PM, Avi Kivit=
y <span dir=3D"ltr"><<a href=3D"mailto:avi@scylladb.com" target=3D"_blan=
k">avi@scylladb.com</a>></span> wrote:<br></span><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin: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"><span clas=
s=3D"">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><=
<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.co=
m</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 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"><span class=3D"">On Fr=
iday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:</span><blockquot=
e 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-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><span class=3D"">On Fri,=
Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <span dir=3D"ltr"><<a rel=
=3D"nofollow">arthur....@gmail.com</a>></span> wrote:</span><span class=
=3D""><span><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><span><div><br></div></span><div>Now you're no longer talking ab=
out EBO, though. You're talking about NEBP: the Non-Empty Base Pessimiz=
ation. <i>Obviously</i> you should never name=C2=A0<i>anything</i> as a bas=
e class of yours if you don't know what's in it. Library implemento=
rs don't do that; why should you?</div></div></div></div></blockquote><=
div><br></div><div>They do it all the time, with exactly the example I gave=
..=C2=A0 A colleague hit it recently with boost's binomial heap.</div></=
span></span></div></div></blockquote></div></blockquote></span></div></div>=
</div></blockquote><div><br></div><div>Huh. I checked with <a href=3D"http:=
//www.boost.org/doc/libs/1_52_0/boost/heap/binomial_heap.hpp" target=3D"_bl=
ank">the Boost code</a> and then with <a href=3D"http://melpon.org/wandbox/=
permlink/jrQkoIvhiEcirdHw" target=3D"_blank">Wandbox</a> and you're cor=
rect, boost::heap::binomial_heap is incorrectly implemented. (It's also=
apparently been unmaintained for a while, as it produces a whole spew of w=
arnings when compiled with Clang.) =C2=A0binomial_heap exposes (makes user-=
visible) private member functions such as allocate() and construct() which =
aren't supposed to exist in its interface; basically Boost is claiming =
that a heap <a href=3D"https://en.wikipedia.org/wiki/Is-a" target=3D"_blank=
">is-an</a> allocator, which is nonsense as far as I'm concerned.</div>=
<div><br></div><div>This may be defensible on the grounds of "everybod=
y used to do it this way," or it may be indefensible, I'm not old =
enough to judge. :) =C2=A0But I do think that these days it's not the <=
i>right</i> way to do it.</div><span class=3D""><div><br></div></span></div=
></div></div></blockquote><div><br></div><div><br></div><div>Of course it h=
as a bug.=C2=A0 My point is that save that extra word of memory is hard and=
error prone.=C2=A0 Should the language force you to decide between verbose=
and error prone code, or efficient code?</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><div></div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><span><div><br></div><div>Are you sugges=
ting you should never inherit from a template parameter?</div></span></div>=
</div></div></blockquote><div><br>As he clearly said, you shouldn't inh=
erit from something you don't know what it is.<br></div></div></blockqu=
ote><div><br></div></span><div>Well, then how can you apply EBO in a librar=
y? Say, std::unordered_set<Key, Hash, ...>, where Hash may and often =
is empty.</div></div></div></div></blockquote><div><br></div></span><div>Th=
e way I said (and provided code for).=C2=A0 You pick one of your members to=
combine in a tuple with that possibly-empty member. Thanks to Howard Hinna=
nt's reply in this thread, I gather that on good implementations (which=
I'm just going to blithely assume means "all popular implementati=
ons" ;)) you can do it via</div><div><br></div><div><font face=3D"mono=
space, monospace">=C2=A0 =C2=A0 template<class Key, class Hash, class Eq=
ualityComparator></font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 class unordered_set {</font></div><div><font face=3D"monospac=
e, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 using bucket =3D std::list<Key=
>;</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 std::tuple<Hash,=C2=A0EqualityComparator, std::vector<b=
ucket>> m;</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 auto&& hash() { return std::get<0>(m=
); }</font></div><div><div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 auto&& cmp() { return std::get<1>(m); }<=
/font></div></div></div><div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 auto&& buckets() { return std::get<2>=
;(m); }</font></div></div><div><font face=3D"monospace, monospace">=C2=A0 =
=C2=A0 };</font></div><div><br></div><div>unordered_set <b>is-not-a</b> has=
h, and <b>is-not-a</b> comparator; but it does <b>have-a</b> hash and <b>ha=
ve-a</b> comparator. We write our code to express that relationship, and th=
en we get correct and efficient code basically for free.</div><div><br></di=
v></div></div></div></blockquote><div><br></div><div><br></div><div>I agree=
this is much better than most EBO uses I've seen.=C2=A0 But (a) non-EB=
Oing std::tuple implementations exist, and are in widespread use. (b) you&#=
39;re still writing boilerplate (and you omitted const accessors) (c) this =
only works if you know for sure there's one member which is non-empty (=
d) it forces an initialization order on your members.</div><div><br></div><=
div>=C2=A0</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>To the extent t=
hat std::tuple doesn't give us efficient code (e.g. if it orders the me=
mbers wrong and thus wastes a lot of space on padding), vendors can go fix =
<i>that</i>; that's easy. </div></div></div></div></blockquote><div><br=
></div><div>Not if they want to maintain ABI compatibility, which they do.<=
/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>Or if users are deman=
ding a way to implement tuple-like types (not identical to std::tuple) with=
out so much metaprogramming, then that sounds like it might produce some ki=
nd of change. But it sounds basically like you're asking for zero-sized=
objects in C++ (which is unlikely to happen), and your particular use-case=
is already solved by std::tuple (modulo possible Quality of Implementation=
issues with some vendors), so there's not a lot of motivation to do an=
ything about it.</div><div><br></div></div></div></div></blockquote><div><b=
r></div><div>You mean, if it can be theoretically made to work, but is comp=
letely impractical, we can consider the problem solved?</div><div><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 clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div>=E2=80=93Arthu=
r</div></div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BhUnFaCsZva5pNRZFESfh44uTGu%=
3DPJ7xoikgpnRgNZwA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CADvuK0%2BhUnFaCsZva5pNRZFESfh44uTGu%3DPJ7xoikgpnRgNZwA%40mail.gma=
il.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BKJEHkG0x-Z3R22bDMLSx%2BL9mn=
8x4ZrJj9_j5Zrx7Yug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BKJE=
HkG0x-Z3R22bDMLSx%2BL9mn8x4ZrJj9_j5Zrx7Yug%40mail.gmail.com</a>.<br />
--001a1144422c66df940534fe0f1f--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 11 Jun 2016 08:38:47 -0700
Raw View
On s=C3=A1bado, 11 de junho de 2016 13:15:06 PDT Avi Kivity wrote:
> The same thing as
>=20
> struct B {};
> struct D : B { int x; };
> D d;
> B* ptr_to_nothing =3D &d; // actually points at d.x
> B& ref_to_nothing =3D d;
>=20
> > What does it mean to perform pointer arithmetic on a pointer to nothing=
?
>=20
> B* arithmetic =3D ptr_to_nothing + 1;
And where does this point to?
Also, what's "one past the last element" for zero-sized elements? The same=
=20
pointer, or different?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/5862018.UHHoMLfmqT%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 11 Jun 2016 08:51:14 -0700 (PDT)
Raw View
------=_Part_126_977507222.1465660275095
Content-Type: multipart/alternative;
boundary="----=_Part_127_1510433425.1465660275096"
------=_Part_127_1510433425.1465660275096
Content-Type: text/plain; charset=UTF-8
On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>
> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>>
>>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com>
>>> wrote:
>>>
>>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>>>> lifting" problems because it *does* allow zero-sized objects and it
>>>>>> *doesn't* have a very strong type system the way C++ does. C++'s
>>>>>> heavy lifting isn't in the machine-level implementation details; there
>>>>>> you're right that the compilers can just "do what C does." The heavy
>>>>>> lifting is in the C++-specific stuff: the *high-level semantics*,
>>>>>> the *language*. That's the hard part.
>>>>>>
>>>>>
>>>>> Then it's totally unreasonable for a compiler newbie like myself to
>>>>> try and figure them out. But can you explain where in the high level
>>>>> semantics a zero sized data member enters at all?
>>>>>
>>>>
>>>> ... Everywhere? Is that a place?
>>>>
>>>> C++ defines an object, first and foremost, as "a region of storage".
>>>> The entire C++ object model *relies* on that. A zero-sized object is
>>>> anathema to that definition.
>>>>
>>>
>>>
>>> Would not the zero-sized object occupy a zero-sized region of storage?
>>>
>>
>> And what exactly is "a zero-sized region of storage"? You cannot allocate
>> or deallocate *nothing*. Even `malloc` doesn't work reasonably with
>> zero. You may or may not get back a NULL pointer, but whatever you get
>> back, you aren't allowed to dereference it.
>>
>>
>
> That never comes into question. The zero-sized region is always part of a
> larger non-zero-sized region.
>
> Zero-sized regions seem to exist just fine in C++, when inheriting from an
> empty base class,
>
But they're not zero-sized regions of memory. sizeof for the empty object
will return non-zero.
> and in C, with empty struct members. Both C++ and C seem to have solved
> this problem.
>
C++ only "solved that problem" by making specific exceptions to certain
operations when dealing with base class subobjects. Do you know where you
would have to make similar exceptions for member subobjects? Do you know if
you can just piggy back off of that language, or would you have to scour
the spec for locations where a member subobject that doesn't take up space
would be problematic?
What does it mean to have the address of, or a reference to, nothing?
>>
>
> The same thing as
>
> struct B {};
> struct D : B { int x; };
> D d;
> B* ptr_to_nothing = &d; // actually points at d.x
> B& ref_to_nothing = d;
>
But `B` is not zero-sized. Nor is `D::B` zero sized.
The use of `B` as a base class simply does not take up room in the layout
of `D`. That's a far cry from saying that `B` is zero-sized.
The other thing you're not getting is this.
This is perfectly legal:
B q;
B r;
memcpy(&q, &r, sizeof(B));
Because `B` is non-zero sized, that makes sense. `B` is trivially copyable,
so you can copy it via memcpy.
This too is legal.
struct D { B b; };
D q;
D r;
memcpy(&q.b, r.b, sizeof(B));
This however, is *not legal*:
struct D : B {...};
D q;
D r;
memcpy((B*)&q, (B*)&r, sizeof(B));
While both B and D are trivially copyable, you are not allowed to trivially
copy into a base-class subobject of another object. The standard
*explicitly* forbids this in [basic.types]/2. Why?
Because it would break empty base optimization (among other things).
By standard layout rules, the presence of `B` as a base class of `D` does
not distrub `D`'s layout. Therefore, a pointer to the `B` subobject must
point to some storage within `D`. And that storage is probably taken up by
one of the members of `D`. And since `B` is not zero-sized, copying
anything into a base-class subobject can cause problems.
> What does it mean to perform pointer arithmetic on a pointer to nothing?
>>
>
> B* arithmetic = ptr_to_nothing + 1;
>
That's not an answer. What's the relationship between these two pointers?
Are they pointing to the same 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/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d%40isocpp.org.
------=_Part_127_1510433425.1465660275096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity=
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 Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <sp=
an dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"z8Lh190ZAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'j=
avascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity w=
rote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><<a re=
l=3D"nofollow">jmck...@gmail.com</a>></span> wrote: <br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div></=
div></div></div></div></blockquote></span><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bor=
der-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div></div><span><div>Re your comments elsethread: =
C doesn't have a lot of these "heavy lifting" problems becaus=
e it <i>does</i> allow zero-sized objects and it <i>doesn't</i> have a =
very strong type system the way C++ does. C++'s heavy lifting isn't=
in the machine-level implementation details; there you're right that t=
he compilers can just "do what C does." =C2=A0The heavy lifting i=
s in the C++-specific stuff: the <i>high-level semantics</i>, the <i>langua=
ge</i>. That's the hard part.</div></span></div></div></div></blockquot=
e><span><div><br></div><div></div><div>Then it's totally unreasonable f=
or a compiler newbie like myself to try and figure them out.=C2=A0 But can =
you explain where in the high level semantics a zero sized data member ente=
rs at all?<br></div></span></div></div></div></blockquote><div><br>... Ever=
ywhere? Is that a place?<br><br>C++ defines an object, first and foremost, =
as "a region of storage". The entire C++ object model <i>relies</=
i> on that. A zero-sized object is anathema to that definition.</div></div>=
</blockquote><div><br></div><div><br></div><div>Would not the zero-sized ob=
ject occupy a zero-sized region of storage?</div></div></div></div></blockq=
uote></span><div><br>And what exactly is "a zero-sized region of stora=
ge"? You cannot allocate or deallocate <i>nothing</i>. Even `malloc` d=
oesn't work reasonably with zero. You may or may not get back a NULL po=
inter, but whatever you get back, you aren't allowed to dereference it.=
<br><br></div></div></blockquote><div><br></div><div><br></div><div>That ne=
ver comes into question.=C2=A0 The zero-sized region is always part of a la=
rger non-zero-sized region.</div><div><br></div><div>Zero-sized regions see=
m to exist just fine in C++, when inheriting from an empty base class,</div=
></div></div></div></blockquote><div><br>But they're not zero-sized reg=
ions of memory. sizeof for the empty object will return non-zero.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div>and in C, with empty struct members.=C2=A0 Bo=
th C++ and C seem to have solved this problem.</div></div></div></div></blo=
ckquote><div><br>C++ only "solved that problem" by making specifi=
c exceptions to certain operations when dealing with base class subobjects.=
Do you know where you would have to make similar exceptions for member sub=
objects? Do you know if you can just piggy back off of that language, or wo=
uld you have to scour the spec for locations where a member subobject that =
doesn't take up space would be problematic?<br><br></div><blockquote cl=
ass=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_qu=
ote"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>What does it mean to=
have the address of, or a reference to, nothing?</div></div></blockquote><=
div></div><div><br></div><div>The same thing as</div><div><br></div><div>=
=C2=A0 struct B {};</div><div>=C2=A0 struct D : B { int x; };</div><div>=C2=
=A0 D d;</div><div>=C2=A0 B* ptr_to_nothing =3D &d; =C2=A0// actually p=
oints at d.x</div><div>=C2=A0 B& ref_to_nothing =3D d;</div></div></div=
></div></blockquote><div><br>But `B` is not zero-sized. Nor is `D::B` zero =
sized.<br><br>The use of `B` as a base class simply does not take up room i=
n the layout of `D`. That's a far cry from saying that `B` is zero-size=
d.<br><br>The other thing you're not getting is this.<br><br>This is pe=
rfectly legal:<br><br><div class=3D"prettyprint" style=3D"background-color:=
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-=
prettify">B q</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>B =
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>memcpy</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(&</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">q</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: #660;" cla=
ss=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">r</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">B</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span></div></code></div=
><br>Because `B` is non-zero sized, that makes sense. `B` is trivially copy=
able, so you can copy it via memcpy.<br><br>This too is legal.<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> D </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> B b</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: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br>D q</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>D r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>memcpy</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(&</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">q</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">b</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">B</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">));</span></div></code></div><br>This howe=
ver, is <i>not legal</i>:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> D </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> B </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{...};=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>D =
q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>D r</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>memcpy</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">B</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">*)&</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">q</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">B</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">*)&</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">r</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">B</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">));</span></div></code></div><br>While both B and D are trivially co=
pyable, you are not allowed to trivially copy into a base-class subobject o=
f another object. The standard <i>explicitly</i> forbids this in [basic.typ=
es]/2. Why?<br><br>Because it would break empty base optimization (among ot=
her things).<br><br>By standard layout rules, the presence of `B` as a base=
class of `D` does not distrub `D`'s layout. Therefore, a pointer to th=
e `B` subobject must point to some storage within `D`. And that storage is =
probably taken up by one of the members of `D`. And since `B` is not zero-s=
ized, copying anything into a base-class subobject can cause problems.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div> What does it mean to perform pointer arithmetic on a pointer to noth=
ing?</div></div></blockquote><div><br></div><div></div><div>=C2=A0B* arithm=
etic =3D ptr_to_nothing + 1;</div></div></div></div></blockquote><div><br>T=
hat's not an answer. What's the relationship between these two poin=
ters? Are they pointing to the same object?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d=
%40isocpp.org</a>.<br />
------=_Part_127_1510433425.1465660275096--
------=_Part_126_977507222.1465660275095--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Sat, 11 Jun 2016 08:53:11 -0700 (PDT)
Raw View
------=_Part_10_407657653.1465660391206
Content-Type: multipart/alternative;
boundary="----=_Part_11_855205378.1465660391206"
------=_Part_11_855205378.1465660391206
Content-Type: text/plain; charset=UTF-8
On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>
> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> What does it mean to have the address of, or a reference to, nothing?
>>
>
> The same thing as
>
> struct B {};
> struct D : B { int x; };
> D d;
> B* ptr_to_nothing = &d; // actually points at d.x
> B& ref_to_nothing = d;
>
This isn't a pointer to nothing.
In general, B * is a pointer to an object of type B, which has a non-zero
size,
or an object of a type derived from B, which has a non-zero size.
>
>
>> What does it mean to perform pointer arithmetic on a pointer to nothing?
>>
>
> B* arithmetic = ptr_to_nothing + 1;
>
You can't do this, because ptr_to_nothing doesn't point to an object or
array
of type B or a type derived from B with no NSDMs.
--
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/6c0cd63b-085e-4ca2-af17-d1c0a9f1d129%40isocpp.org.
------=_Part_11_855205378.1465660391206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity=
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 c=
lass=3D"gmail_quote">On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"z8Lh190ZAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">What does it mean to have the address of, or a reference to, not=
hing?<br></div></blockquote><div><br></div><div>The same thing as</div><div=
><br></div><div>=C2=A0 struct B {};</div><div>=C2=A0 struct D : B { int x; =
};</div><div>=C2=A0 D d;</div><div>=C2=A0 B* ptr_to_nothing =3D &d; =C2=
=A0// actually points at d.x</div><div>=C2=A0 B& ref_to_nothing =3D d;<=
/div></div></div></blockquote><div><br></div><div>This isn't a pointer =
to nothing.</div><div>In general, B * is a pointer to an object of type B, =
which has a non-zero size,</div><div>or an object of a type derived from B,=
which has a non-zero size.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_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>=C2=A0=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div> What does it mean to perf=
orm pointer arithmetic on a pointer to nothing?</div></div></blockquote><di=
v><br></div><div>=C2=A0B* arithmetic =3D ptr_to_nothing + 1;</div></div></d=
iv></blockquote><div><br></div><div>You can't do this, because ptr_to_n=
othing doesn't point to an object or array</div><div>of type B or a typ=
e derived from B with no NSDMs.</div><div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6c0cd63b-085e-4ca2-af17-d1c0a9f1d129%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6c0cd63b-085e-4ca2-af17-d1c0a9f1d129=
%40isocpp.org</a>.<br />
------=_Part_11_855205378.1465660391206--
------=_Part_10_407657653.1465660391206--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 11 Jun 2016 20:26:17 +0300
Raw View
--001a1144422c1db931053503f59f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 11, 2016 at 6:38 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On s=C3=A1bado, 11 de junho de 2016 13:15:06 PDT Avi Kivity wrote:
> > The same thing as
> >
> > struct B {};
> > struct D : B { int x; };
> > D d;
> > B* ptr_to_nothing =3D &d; // actually points at d.x
> > B& ref_to_nothing =3D d;
> >
> > > What does it mean to perform pointer arithmetic on a pointer to
> nothing?
> >
> > B* arithmetic =3D ptr_to_nothing + 1;
>
> And where does this point to?
>
I'm guessing it adds sizeof(B) to the representation of ptr_to_nothing,
which is usually 1 for zero-sized classes.
Note that this is nothing new; you can do this with C++14 (and indeed
C++98). If you wish, you can check with your favorite compiler.
>
> Also, what's "one past the last element" for zero-sized elements? The sam=
e
> pointer, or different?
>
I did not say I propose this for arrays. For arrays, the behavior can
remain unchanged.
>
>
> --
> 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/5862018.UHHo=
MLfmqT%40tjmaciei-mobl1
> .
>
--=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/CAF950WJ5_KKALszLPxWaodR6yqVnK9E5SSRnTztZZf-OQ4O=
-Bw%40mail.gmail.com.
--001a1144422c1db931053503f59f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 11, 2016 at 6:38 PM, Thiago Macieira <span dir=3D"ltr"><=
<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On s=C3=A1bado, 11 de junho de 2016 13:15:06 PDT Avi Kivity wrote:<br>
> The same thing as<br>
><br>
>=C2=A0 =C2=A0struct B {};<br>
>=C2=A0 =C2=A0struct D : B { int x; };<br>
>=C2=A0 =C2=A0D d;<br>
>=C2=A0 =C2=A0B* ptr_to_nothing =3D &d;=C2=A0 // actually points at =
d.x<br>
>=C2=A0 =C2=A0B& ref_to_nothing =3D d;<br>
><br>
> > What does it mean to perform pointer arithmetic on a pointer to n=
othing?<br>
><br>
>=C2=A0 B* arithmetic =3D ptr_to_nothing + 1;<br>
<br>
</span>And where does this point to?<br></blockquote><div><br></div><div><b=
r></div><div>I'm guessing it adds sizeof(B) to the representation of pt=
r_to_nothing, which is usually 1 for zero-sized classes.</div><div><br></di=
v><div>Note that this is nothing new; you can do this with C++14 (and indee=
d C++98).=C2=A0 If you wish, you can check with your favorite compiler.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, what's "one past the last element" for zero-sized eleme=
nts? The same<br>
pointer, or different?<br></blockquote><div><br></div><div>I did not say I =
propose this for arrays.=C2=A0 For arrays, the behavior can remain unchange=
d.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
</span><span class=3D"">--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/5862018.UHHoMLfmqT%40tjmaciei-=
mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/5862018.UHHoMLfmqT%40tjmaciei-mobl1</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WJ5_KKALszLPxWaodR6yqVnK9E5SSRn=
TztZZf-OQ4O-Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WJ5_KKALszL=
PxWaodR6yqVnK9E5SSRnTztZZf-OQ4O-Bw%40mail.gmail.com</a>.<br />
--001a1144422c1db931053503f59f--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 11 Jun 2016 20:44:58 +0300
Raw View
--001a1144422cf14dfd053504373e
Content-Type: text/plain; charset=UTF-8
On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>>
>> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>>>
>>>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com>
>>>> wrote:
>>>>
>>>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>>>>> lifting" problems because it *does* allow zero-sized objects and it
>>>>>>> *doesn't* have a very strong type system the way C++ does. C++'s
>>>>>>> heavy lifting isn't in the machine-level implementation details; there
>>>>>>> you're right that the compilers can just "do what C does." The heavy
>>>>>>> lifting is in the C++-specific stuff: the *high-level semantics*,
>>>>>>> the *language*. That's the hard part.
>>>>>>>
>>>>>>
>>>>>> Then it's totally unreasonable for a compiler newbie like myself to
>>>>>> try and figure them out. But can you explain where in the high level
>>>>>> semantics a zero sized data member enters at all?
>>>>>>
>>>>>
>>>>> ... Everywhere? Is that a place?
>>>>>
>>>>> C++ defines an object, first and foremost, as "a region of storage".
>>>>> The entire C++ object model *relies* on that. A zero-sized object is
>>>>> anathema to that definition.
>>>>>
>>>>
>>>>
>>>> Would not the zero-sized object occupy a zero-sized region of storage?
>>>>
>>>
>>> And what exactly is "a zero-sized region of storage"? You cannot
>>> allocate or deallocate *nothing*. Even `malloc` doesn't work reasonably
>>> with zero. You may or may not get back a NULL pointer, but whatever you get
>>> back, you aren't allowed to dereference it.
>>>
>>>
>>
>> That never comes into question. The zero-sized region is always part of
>> a larger non-zero-sized region.
>>
>> Zero-sized regions seem to exist just fine in C++, when inheriting from
>> an empty base class,
>>
>
> But they're not zero-sized regions of memory. sizeof for the empty object
> will return non-zero.
>
Let me go back and explain what I want in detail so there are no
misunderstandings.
If I have
struct A {};
struct B : A {
int x;
};
then A takes up no space in B, and will have the same address as a pointer
to B or a pointer to B::x, in most implementations.
What I want is
struct A {};
struct C {
A a /* + some new syntax */;
int x;
};
with the same characteristics: a pointer to C::a can have the same address
as a pointer to C, and a pointer to C::x.
The motivation for this is to avoid the need for library writers to jump
through hoops with error-prone EBO optimizations, or to attempt to use
std::tuple<> which is verbose, and won't work in many of today's major
implementations, which cannot be changed due to ABI reasons.
Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1,
despite both objects taking up no space in either B or C. So the region of
memory occupied by them is zero, despite their sizeof being non-zero. This
is existing practice and is not introduced by my proposal.
>
>> and in C, with empty struct members. Both C++ and C seem to have solved
>> this problem.
>>
>
> C++ only "solved that problem" by making specific exceptions to certain
> operations when dealing with base class subobjects. Do you know where you
> would have to make similar exceptions for member subobjects? Do you know if
> you can just piggy back off of that language, or would you have to scour
> the spec for locations where a member subobject that doesn't take up space
> would be problematic?
>
I did not exhaustively read the standard looking for those places. But
given that:
1. the problem was solved for base classes
2. the problem was solved, in C, for member objects
3. the problem was solved, in at list gcc, for member objects, by declaring
them as arrays of zero size.
it seems to be reasonable that there are no insurmountable difficulties.
There's simply too much prior art to assume it is impossible or even
difficult.
>
> What does it mean to have the address of, or a reference to, nothing?
>>>
>>
>> The same thing as
>>
>> struct B {};
>> struct D : B { int x; };
>> D d;
>> B* ptr_to_nothing = &d; // actually points at d.x
>> B& ref_to_nothing = d;
>>
>
> But `B` is not zero-sized. Nor is `D::B` zero sized.
>
> The use of `B` as a base class simply does not take up room in the layout
> of `D`. That's a far cry from saying that `B` is zero-sized.
>
>
All right. I am not asking for C::a or A to be zero sized. I am asking
them not to take up room in C, with the same rules applying to base classes
(including, perhaps, that if C::a is not the last member in C, then it does
take up room in C).
> The other thing you're not getting is this.
>
> This is perfectly legal:
>
> B q;
> B r;
> memcpy(&q, &r, sizeof(B));
>
> Because `B` is non-zero sized, that makes sense. `B` is trivially
> copyable, so you can copy it via memcpy.
>
> This too is legal.
>
> struct D { B b; };
>
> D q;
> D r;
> memcpy(&q.b, r.b, sizeof(B));
>
> This however, is *not legal*:
> c
> struct D : B {...};
>
> D q;
> D r;
> memcpy((B*)&q, (B*)&r, sizeof(B));
>
> While both B and D are trivially copyable, you are not allowed to
> trivially copy into a base-class subobject of another object. The standard
> *explicitly* forbids this in [basic.types]/2. Why?
>
> Because it would break empty base optimization (among other things).
>
> By standard layout rules, the presence of `B` as a base class of `D` does
> not distrub `D`'s layout. Therefore, a pointer to the `B` subobject must
> point to some storage within `D`. And that storage is probably taken up by
> one of the members of `D`. And since `B` is not zero-sized, copying
> anything into a base-class subobject can cause problems.
>
>
Good. We can apply the same restriction to members annotated to take up no
room in their struct's layout.
> What does it mean to perform pointer arithmetic on a pointer to nothing?
>>>
>>
>> B* arithmetic = ptr_to_nothing + 1;
>>
>
> That's not an answer. What's the relationship between these two pointers?
> Are they pointing to the same object?
>
This code is not using my proposal, so whatever the answers are, the
standard already provides them (it might invoke undefined behavior for all
I know).
My point is, these pointers and references to nothing already exist; they
just exist in a hard-to-use way.
> --
> 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/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d%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/CAF950WKcNMr26%3DH_sv8BvZFWRZhUd0kBG3P79Tkf45nJJxDtvg%40mail.gmail.com.
--001a1144422cf14dfd053504373e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On S=
aturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:<span class=3D=
""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <span dir=3D=
"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">On Friday, June 10, 2016 at 3:48:02 PM UTC-=
4, Avi Kivity wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span dir=3D=
"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span> wrote: <br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><div><div></div></div></div></div></blockquote></span><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div></div><span><div>Re your comm=
ents elsethread: C doesn't have a lot of these "heavy lifting"=
; problems because it <i>does</i> allow zero-sized objects and it <i>doesn&=
#39;t</i> have a very strong type system the way C++ does. C++'s heavy =
lifting isn't in the machine-level implementation details; there you=
9;re right that the compilers can just "do what C does." =C2=A0Th=
e heavy lifting is in the C++-specific stuff: the <i>high-level semantics</=
i>, the <i>language</i>. That's the hard part.</div></span></div></div>=
</div></blockquote><span><div><br></div><div></div><div>Then it's total=
ly unreasonable for a compiler newbie like myself to try and figure them ou=
t.=C2=A0 But can you explain where in the high level semantics a zero sized=
data member enters at all?<br></div></span></div></div></div></blockquote>=
<div><br>... Everywhere? Is that a place?<br><br>C++ defines an object, fir=
st and foremost, as "a region of storage". The entire C++ object =
model <i>relies</i> on that. A zero-sized object is anathema to that defini=
tion.</div></div></blockquote><div><br></div><div><br></div><div>Would not =
the zero-sized object occupy a zero-sized region of storage?</div></div></d=
iv></div></blockquote></span><div><br>And what exactly is "a zero-size=
d region of storage"? You cannot allocate or deallocate <i>nothing</i>=
.. Even `malloc` doesn't work reasonably with zero. You may or may not g=
et back a NULL pointer, but whatever you get back, you aren't allowed t=
o dereference it.<br><br></div></div></blockquote><div><br></div><div><br><=
/div><div>That never comes into question.=C2=A0 The zero-sized region is al=
ways part of a larger non-zero-sized region.</div><div><br></div><div>Zero-=
sized regions seem to exist just fine in C++, when inheriting from an empty=
base class,</div></div></div></div></blockquote></span><div><br>But they&#=
39;re not zero-sized regions of memory. sizeof for the empty object will re=
turn non-zero.<br></div></div></blockquote><div><br></div><div>Let me go ba=
ck and explain what I want in detail so there are no misunderstandings.</di=
v><div><br></div><div>If I have</div><div><br></div><div>=C2=A0 =C2=A0struc=
t A {};</div><div>=C2=A0 =C2=A0struct B : A {</div><div>=C2=A0 =C2=A0 =C2=
=A0 int x;</div><div>=C2=A0 =C2=A0};</div><div><br></div><div>then A takes =
up no space in B, and will have the same address as a pointer to B or a poi=
nter to B::x, in most implementations.</div><div><br></div><div>What I want=
is</div><div><br></div><div>=C2=A0 struct A {};</div><div>=C2=A0 struct C =
{</div><div>=C2=A0 =C2=A0 =C2=A0 A a /* + some new syntax */; =C2=A0=C2=A0<=
/div><div>=C2=A0 =C2=A0 =C2=A0 int x;</div><div>=C2=A0 };</div><div><br></d=
iv><div>with the same characteristics: a pointer to C::a can have the same =
address as a pointer to C, and a pointer to C::x.</div><div><br></div><div>=
The motivation for this is to avoid the need for library writers to jump th=
rough hoops with error-prone EBO optimizations, or to attempt to use std::t=
uple<> which is verbose, and won't work in many of today's ma=
jor implementations, which cannot be changed due to ABI reasons.</div><div>=
=C2=A0</div><div>Now to answer your question, both sizeof(A) and sizeof(c.a=
) will be 1, despite both objects taking up no space in either B or C.=C2=
=A0 So the region of memory occupied by them is zero, despite their sizeof =
being non-zero. This is existing practice and is not introduced by my propo=
sal.</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"><d=
iv>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div>and in C, with empty str=
uct members.=C2=A0 Both C++ and C seem to have solved this problem.</div></=
div></div></div></blockquote></span><div><br>C++ only "solved that pro=
blem" by making specific exceptions to certain operations when dealing=
with base class subobjects. Do you know where you would have to make simil=
ar exceptions for member subobjects? Do you know if you can just piggy back=
off of that language, or would you have to scour the spec for locations wh=
ere a member subobject that doesn't take up space would be problematic?=
<br></div></div></blockquote><div><br></div><div>I did not exhaustively rea=
d the standard looking for those places.=C2=A0 But given that:</div><div><b=
r></div><div>1. the problem was solved for base classes</div><div>2. the pr=
oblem was solved, in C, for member objects</div><div>3. the problem was sol=
ved, in at list gcc, for member objects, by declaring them as arrays of zer=
o size.</div><div><br></div><div>it seems to be reasonable that there are n=
o insurmountable difficulties.=C2=A0 There's simply too much prior art =
to assume it is impossible or even difficult.</div><div><br></div><div>=C2=
=A0</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><br></div><sp=
an class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>What does it mean to have the address of, or a reference to, nothing?</d=
iv></div></blockquote><div></div><div><br></div><div>The same thing as</div=
><div><br></div><div>=C2=A0 struct B {};</div><div>=C2=A0 struct D : B { in=
t x; };</div><div>=C2=A0 D d;</div><div>=C2=A0 B* ptr_to_nothing =3D &d=
; =C2=A0// actually points at d.x</div><div>=C2=A0 B& ref_to_nothing =
=3D d;</div></div></div></div></blockquote></span><div><br>But `B` is not z=
ero-sized. Nor is `D::B` zero sized.<br><br>The use of `B` as a base class =
simply does not take up room in the layout of `D`. That's a far cry fro=
m saying that `B` is zero-sized.<br><br></div></div></blockquote><div><br><=
/div><div>All right.=C2=A0 I am not asking for C::a or A to be zero sized.=
=C2=A0 I am asking them not to take up room in C, with the same rules apply=
ing to base classes (including, perhaps, that if C::a is not the last membe=
r in C, then it does take up room in C).</div><div><br></div><div>=C2=A0</d=
iv><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>The other thing you=
're not getting is this.<br><br>This is perfectly legal:<br><br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px;word-wrap:break-word"><code><div><span styl=
e=3D"color:#000">B q</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br>B r</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">(&</span><=
span style=3D"color:#000">q</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">&</span><span s=
tyle=3D"color:#000">r</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">B</span><span style=3D"c=
olor:#660">));</span></div></code></div><br>Because `B` is non-zero sized, =
that makes sense. `B` is trivially copyable, so you can copy it via memcpy.=
<br><br>This too is legal.<br><br><div style=3D"background-color:rgb(250,25=
0,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wo=
rd-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><spa=
n style=3D"color:#000"> D </span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"> B b</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br><br>D q</span><span style=3D"color:#660">;</span><span =
style=3D"color:#000"><br>D r</span><span style=3D"color:#660">;</span><span=
style=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">(&</s=
pan><span style=3D"color:#000">q</span><span style=3D"color:#660">.</span><=
span style=3D"color:#000">b</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> r</span><span style=3D"color:#660">.</span><span styl=
e=3D"color:#000">b</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">sizeof</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">B</span><span style=3D"color=
:#660">));</span></div></code></div><br>This however, is <i>not legal</i>:<=
br>c<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(18=
7,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>=
<div><span style=3D"color:#008">struct</span><span style=3D"color:#000"> D =
</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> B </s=
pan><span style=3D"color:#660">{...};</span><span style=3D"color:#000"><br>=
<br>D q</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br>D r</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"><br>memcpy</span><span style=3D"color:#660">((</span><span style=3D"color=
:#000">B</span><span style=3D"color:#660">*)&</span><span style=3D"colo=
r:#000">q</span><span style=3D"color:#660">,</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">(</span><span style=3D"color:#000">B<=
/span><span style=3D"color:#660">*)&</span><span style=3D"color:#000">r=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">sizeof</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000">B</span><span style=3D"color:#660">));</span><=
/div></code></div><br>While both B and D are trivially copyable, you are no=
t allowed to trivially copy into a base-class subobject of another object. =
The standard <i>explicitly</i> forbids this in [basic.types]/2. Why?<br><br=
>Because it would break empty base optimization (among other things).<br><b=
r>By standard layout rules, the presence of `B` as a base class of `D` does=
not distrub `D`'s layout. Therefore, a pointer to the `B` subobject mu=
st point to some storage within `D`. And that storage is probably taken up =
by one of the members of `D`. And since `B` is not zero-sized, copying anyt=
hing into a base-class subobject can cause problems.<br>=C2=A0</div></div><=
/blockquote><div><br></div><div>Good.=C2=A0 We can apply the same restricti=
on to members annotated to take up no room in their struct's layout.</d=
iv><div><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"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div> What does it mean to perform pointer arithmetic on a point=
er to nothing?</div></div></blockquote><div><br></div><div></div><div>=C2=
=A0B* arithmetic =3D ptr_to_nothing + 1;</div></div></div></div></blockquot=
e></span><div><br>That's not an answer. What's the relationship bet=
ween these two pointers? Are they pointing to the same object?<br></div></d=
iv></blockquote><div><br></div><div><br></div><div>This code is not using m=
y proposal, so whatever the answers are, the standard already provides them=
(it might invoke undefined behavior for all I know).</div><div><br></div><=
div>My point is, these pointers and references to nothing already exist; th=
ey just exist in a hard-to-use way.=C2=A0</div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/838a4d44-20c8-4a6c-a276-76a5c8cb0f8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/838a4d44-20c8-=
4a6c-a276-76a5c8cb0f8d%40isocpp.org</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WKcNMr26%3DH_sv8BvZFWRZhUd0kBG3=
P79Tkf45nJJxDtvg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WKcNMr26%=
3DH_sv8BvZFWRZhUd0kBG3P79Tkf45nJJxDtvg%40mail.gmail.com</a>.<br />
--001a1144422cf14dfd053504373e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 11 Jun 2016 15:53:41 -0700
Raw View
On s=C3=A1bado, 11 de junho de 2016 20:44:58 PDT Avi Kivity wrote:
> Let me go back and explain what I want in detail so there are no
> misunderstandings.
We understand what you want. But you fail to understand how difficult it is=
to=20
get what you want in the standard.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/3670091.0KBWDU7pV0%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 11 Jun 2016 16:51:41 -0700 (PDT)
Raw View
------=_Part_1817_1766172971.1465689101137
Content-Type: multipart/alternative;
boundary="----=_Part_1818_1119883472.1465689101138"
------=_Part_1818_1119883472.1465689101138
Content-Type: text/plain; charset=UTF-8
On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Avi Kivity wrote:
>
>
>
> On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>>>
>>> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>>>>
>>>>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>>>>>> lifting" problems because it *does* allow zero-sized objects and
>>>>>>>> it *doesn't* have a very strong type system the way C++ does.
>>>>>>>> C++'s heavy lifting isn't in the machine-level implementation details;
>>>>>>>> there you're right that the compilers can just "do what C does." The heavy
>>>>>>>> lifting is in the C++-specific stuff: the *high-level semantics*,
>>>>>>>> the *language*. That's the hard part.
>>>>>>>>
>>>>>>>
>>>>>>> Then it's totally unreasonable for a compiler newbie like myself to
>>>>>>> try and figure them out. But can you explain where in the high level
>>>>>>> semantics a zero sized data member enters at all?
>>>>>>>
>>>>>>
>>>>>> ... Everywhere? Is that a place?
>>>>>>
>>>>>> C++ defines an object, first and foremost, as "a region of storage".
>>>>>> The entire C++ object model *relies* on that. A zero-sized object is
>>>>>> anathema to that definition.
>>>>>>
>>>>>
>>>>>
>>>>> Would not the zero-sized object occupy a zero-sized region of storage?
>>>>>
>>>>
>>>> And what exactly is "a zero-sized region of storage"? You cannot
>>>> allocate or deallocate *nothing*. Even `malloc` doesn't work
>>>> reasonably with zero. You may or may not get back a NULL pointer, but
>>>> whatever you get back, you aren't allowed to dereference it.
>>>>
>>>>
>>>
>>> That never comes into question. The zero-sized region is always part of
>>> a larger non-zero-sized region.
>>>
>>> Zero-sized regions seem to exist just fine in C++, when inheriting from
>>> an empty base class,
>>>
>>
>> But they're not zero-sized regions of memory. sizeof for the empty object
>> will return non-zero.
>>
>
> Let me go back and explain what I want in detail so there are no
> misunderstandings.
>
> ...
>
> Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1,
> despite both objects taking up no space in either B or C. So the region of
> memory occupied by them is zero, despite their sizeof being non-zero. This
> is existing practice and is not introduced by my proposal.
>
If that's your idea, then why do you keep bringing up zero-sized arrays and
zero-sized types? That is, you keep saying that C allows for empty members,
but it does so with a *completely different mechanism*: by allowing types
to have zero size.
So don't bring up empty types in C unless that's actually what you want.
and in C, with empty struct members. Both C++ and C seem to have solved
>>> this problem.
>>>
>>
>> C++ only "solved that problem" by making specific exceptions to certain
>> operations when dealing with base class subobjects. Do you know where you
>> would have to make similar exceptions for member subobjects? Do you know if
>> you can just piggy back off of that language, or would you have to scour
>> the spec for locations where a member subobject that doesn't take up space
>> would be problematic?
>>
>
> I did not exhaustively read the standard looking for those places. But
> given that:
>
> 1. the problem was solved for base classes
> 2. the problem was solved, in C, for member objects
> 3. the problem was solved, in at list gcc, for member objects, by
> declaring them as arrays of zero size.
>
> it seems to be reasonable that there are no insurmountable difficulties.
> There's simply too much prior art to assume it is impossible or even
> difficult.
>
As previously stated, #2 and #3 are non-sequiturs for this conversation.
That only leaves #1. And you also clearly state that you haven't looked for
such places. And therefore, you don't know if the solutions for base
classes will work for members. You also don't know if you would need to
make other adjustments that the base class solution didn't need.
So the basis for your claim is flimsy.
> The other thing you're not getting is this.
>>
>> This is perfectly legal:
>>
>> B q;
>> B r;
>> memcpy(&q, &r, sizeof(B));
>>
>> Because `B` is non-zero sized, that makes sense. `B` is trivially
>> copyable, so you can copy it via memcpy.
>>
>> This too is legal.
>>
>> struct D { B b; };
>>
>> D q;
>> D r;
>> memcpy(&q.b, r.b, sizeof(B));
>>
>> This however, is *not legal*:
>> c
>> struct D : B {...};
>>
>> D q;
>> D r;
>> memcpy((B*)&q, (B*)&r, sizeof(B));
>>
>> While both B and D are trivially copyable, you are not allowed to
>> trivially copy into a base-class subobject of another object. The standard
>> *explicitly* forbids this in [basic.types]/2. Why?
>>
>> Because it would break empty base optimization (among other things).
>>
>> By standard layout rules, the presence of `B` as a base class of `D` does
>> not distrub `D`'s layout. Therefore, a pointer to the `B` subobject must
>> point to some storage within `D`. And that storage is probably taken up by
>> one of the members of `D`. And since `B` is not zero-sized, copying
>> anything into a base-class subobject can cause problems.
>>
>
> Good. We can apply the same restriction to members annotated to take up
> no room in their struct's layout.
>
OK, the point of my spiel here was to explain to you just how little you
understand the *ramifications* of what you ask. Until I brought that up,
you had no idea that this copying thing was even an issue with your idea.
Which proves that you simply do not know much about the standardization
issues of permitting empty members.
And that's just *one thing*. How many others are there? You certainly don't
know.
Yet you continue to claim that it will not be difficult. Why should we
believe you about how difficult this is, when you have repeatedly displayed
your ignorance on the complexities of such a feature?
Not to mention, when asked to demonstrate how "not difficult" it would be
by actually implementing it, you balked and claimed that this request was
somehow unfair.
Anyone can say "go do this; it should be easy." It's far easier to do that
than to actually implement it or learn about the particulars of the spec so
that you can get the feature's wording right.
--
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/b8497d6d-d424-4615-bee2-d9d2be5fd485%40isocpp.org.
------=_Part_1818_1119883472.1465689101138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Av=
i Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><br><div><br><div class=3D"gmail_quote">On Sat, Jun 11, 2016 at 6:51 PM, =
Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"HvhoQWoyAQAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">jmck...@gmail.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, June 11, 2016 at =
6:15:28 AM UTC-4, Avi Kivity wrote:<span><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 Sat, Jun 11, 2016=
at 12:56 AM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Fr=
iday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:<span><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jun 10, 2016=
at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...=
@gmail.com</a>></span> wrote: <br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div><div><div></div></div></div></div>=
</blockquote></span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div></div><span><div>Re your comments elsethread: C doesn't have a l=
ot of these "heavy lifting" problems because it <i>does</i> allow=
zero-sized objects and it <i>doesn't</i> have a very strong type syste=
m the way C++ does. C++'s heavy lifting isn't in the machine-level =
implementation details; there you're right that the compilers can just =
"do what C does." =C2=A0The heavy lifting is in the C++-specific =
stuff: the <i>high-level semantics</i>, the <i>language</i>. That's the=
hard part.</div></span></div></div></div></blockquote><span><div><br></div=
><div></div><div>Then it's totally unreasonable for a compiler newbie l=
ike myself to try and figure them out.=C2=A0 But can you explain where in t=
he high level semantics a zero sized data member enters at all?<br></div></=
span></div></div></div></blockquote><div><br>... Everywhere? Is that a plac=
e?<br><br>C++ defines an object, first and foremost, as "a region of s=
torage". The entire C++ object model <i>relies</i> on that. A zero-siz=
ed object is anathema to that definition.</div></div></blockquote><div><br>=
</div><div><br></div><div>Would not the zero-sized object occupy a zero-siz=
ed region of storage?</div></div></div></div></blockquote></span><div><br>A=
nd what exactly is "a zero-sized region of storage"? You cannot a=
llocate or deallocate <i>nothing</i>. Even `malloc` doesn't work reason=
ably with zero. You may or may not get back a NULL pointer, but whatever yo=
u get back, you aren't allowed to dereference it.<br><br></div></div></=
blockquote><div><br></div><div><br></div><div>That never comes into questio=
n.=C2=A0 The zero-sized region is always part of a larger non-zero-sized re=
gion.</div><div><br></div><div>Zero-sized regions seem to exist just fine i=
n C++, when inheriting from an empty base class,</div></div></div></div></b=
lockquote></span><div><br>But they're not zero-sized regions of memory.=
sizeof for the empty object will return non-zero.<br></div></div></blockqu=
ote><div><br></div><div>Let me go back and explain what I want in detail so=
there are no misunderstandings.</div><div><br></div>...<br><div>=C2=A0</di=
v><div>Now to answer your question, both sizeof(A) and sizeof(c.a) will be =
1, despite both objects taking up no space in either B or C.=C2=A0 So the r=
egion of memory occupied by them is zero, despite their sizeof being non-ze=
ro. This is existing practice and is not introduced by my proposal.</div></=
div></div></div></blockquote><div><br>If that's your idea, then why do =
you keep bringing up zero-sized arrays and zero-sized types? That is, you k=
eep saying that C allows for empty members, but it does so with a <i>comple=
tely different mechanism</i>: by allowing types to have zero size.<br><br>S=
o don't bring up empty types in C unless that's actually what you w=
ant.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div></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"><span><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>and in C, with empty struct m=
embers.=C2=A0 Both C++ and C seem to have solved this problem.</div></div><=
/div></div></blockquote></span><div><br>C++ only "solved that problem&=
quot; by making specific exceptions to certain operations when dealing with=
base class subobjects. Do you know where you would have to make similar ex=
ceptions for member subobjects? Do you know if you can just piggy back off =
of that language, or would you have to scour the spec for locations where a=
member subobject that doesn't take up space would be problematic?<br><=
/div></div></blockquote><div><br></div><div>I did not exhaustively read the=
standard looking for those places.=C2=A0 But given that:</div><div><br></d=
iv><div>1. the problem was solved for base classes</div><div>2. the problem=
was solved, in C, for member objects</div><div>3. the problem was solved, =
in at list gcc, for member objects, by declaring them as arrays of zero siz=
e.=C2=A0</div></div></div></div></blockquote><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></=
div><div>it seems to be reasonable that there are no insurmountable difficu=
lties.=C2=A0 There's simply too much prior art to assume it is impossib=
le or even difficult.</div></div></div></div></blockquote><div><br>As previ=
ously stated, #2 and #3 are non-sequiturs for this conversation. That only =
leaves #1. And you also clearly state that you haven't looked for such =
places. And therefore, you don't know if the solutions for base classes=
will work for members. You also don't know if you would need to make o=
ther adjustments that the base class solution didn't need.<br><br>So th=
e basis for your claim is flimsy.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><span></span=
></div></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>The other thing you're not getting is this.<br><br>This is per=
fectly legal:<br><br><div style=3D"background-color:rgb(250,250,250);border=
-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break=
-word"><code><div><span style=3D"color:#000">B q</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"><br>B r</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>memcpy</span><span style=3D"=
color:#660">(&</span><span style=3D"color:#000">q</span><span style=3D"=
color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">&</span><span style=3D"color:#000">r</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>sizeof</span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
>B</span><span style=3D"color:#660">));</span></div></code></div><br>Becaus=
e `B` is non-zero sized, that makes sense. `B` is trivially copyable, so yo=
u can copy it via memcpy.<br><br>This too is legal.<br><br><div style=3D"ba=
ckground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:=
solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"colo=
r:#008">struct</span><span style=3D"color:#000"> D </span><span style=3D"co=
lor:#660">{</span><span style=3D"color:#000"> B b</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">};</span><span style=3D"color:#000"><br><br>D q</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"><br>D r</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"><br>memcpy</span><span style=
=3D"color:#660">(&</span><span style=3D"color:#000">q</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">b</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"> r</span><span style=3D"color=
:#660">.</span><span style=3D"color:#000">b</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style=3D"color:#000">B</=
span><span style=3D"color:#660">));</span></div></code></div><br>This howev=
er, is <i>not legal</i>:<br>c<br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><span=
style=3D"color:#000"> D </span><span style=3D"color:#660">:</span><span st=
yle=3D"color:#000"> B </span><span style=3D"color:#660">{...};</span><span =
style=3D"color:#000"><br><br>D q</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>D r</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">((</=
span><span style=3D"color:#000">B</span><span style=3D"color:#660">*)&<=
/span><span style=3D"color:#000">q</span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">B</span><span style=3D"color:#660">*)&</span><sp=
an style=3D"color:#000">r</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">B</span><span style=
=3D"color:#660">));</span></div></code></div><br>While both B and D are tri=
vially copyable, you are not allowed to trivially copy into a base-class su=
bobject of another object. The standard <i>explicitly</i> forbids this in [=
basic.types]/2. Why?<br><br>Because it would break empty base optimization =
(among other things).<br><br>By standard layout rules, the presence of `B` =
as a base class of `D` does not distrub `D`'s layout. Therefore, a poin=
ter to the `B` subobject must point to some storage within `D`. And that st=
orage is probably taken up by one of the members of `D`. And since `B` is n=
ot zero-sized, copying anything into a base-class subobject can cause probl=
ems.<br></div></div></blockquote><div><br></div><div>Good.=C2=A0 We can app=
ly the same restriction to members annotated to take up no room in their st=
ruct's layout.</div></div></div></div></blockquote><div><br>OK, the poi=
nt of my spiel here was to explain to you just how little you understand th=
e <i>ramifications</i> of what you ask. Until I brought that up, you had no=
idea that this copying thing was even an issue with your idea. Which prove=
s that you simply do not know much about the standardization issues of perm=
itting empty members.<br><br>And that's just <i>one thing</i>. How many=
others are there? You certainly don't know.<br><br>Yet you continue to=
claim that it will not be difficult. Why should we believe you about how d=
ifficult this is, when you have repeatedly displayed your ignorance on the =
complexities of such a feature?<br><br>Not to mention, when asked to demons=
trate how "not difficult" it would be by actually implementing it=
, you balked and claimed that this request was somehow unfair.<br><br>Anyon=
e can say "go do this; it should be easy." It's far easier to=
do that than to actually implement it or learn about the particulars of th=
e spec so that you can get the feature's wording right.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b8497d6d-d424-4615-bee2-d9d2be5fd485%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8497d6d-d424-4615-bee2-d9d2be5fd485=
%40isocpp.org</a>.<br />
------=_Part_1818_1119883472.1465689101138--
------=_Part_1817_1766172971.1465689101137--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 12 Jun 2016 10:20:35 +0300
Raw View
--94eb2c0d47d4d7275205350f9c11
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jun 12, 2016 at 1:53 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On s=C3=A1bado, 11 de junho de 2016 20:44:58 PDT Avi Kivity wrote:
> > Let me go back and explain what I want in detail so there are no
> > misunderstandings.
>
> We understand what you want. But you fail to understand how difficult it
> is to
> get what you want in the standard.
>
>
You are bring up objections, and I am explaining why those objections are
incorrect, but I don't see any response to that.
--=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/CAF950W%2BY75OyMQCVyoy_9WgmqWSX_buu0zogiO4996EKS=
Y8mfg%40mail.gmail.com.
--94eb2c0d47d4d7275205350f9c11
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jun 12, 2016 at 1:53 AM, Thiago Macieira <span dir=3D"ltr"><=
<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.or=
g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
On s=C3=A1bado, 11 de junho de 2016 20:44:58 PDT Avi Kivity wrote:<br>
> Let me go back and explain what I want in detail so there are no<br>
> misunderstandings.<br>
<br>
</span>We understand what you want. But you fail to understand how difficul=
t it is to<br>
get what you want in the standard.<br><span class=3D""><br></span></blockqu=
ote><div><br></div><div><br></div><div>You are bring up objections, and I a=
m explaining why those objections are incorrect, but I don't see any re=
sponse to that.=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" 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/CAF950W%2BY75OyMQCVyoy_9WgmqWSX_buu0z=
ogiO4996EKSY8mfg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BY75Oy=
MQCVyoy_9WgmqWSX_buu0zogiO4996EKSY8mfg%40mail.gmail.com</a>.<br />
--94eb2c0d47d4d7275205350f9c11--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 12 Jun 2016 10:36:45 +0300
Raw View
--047d7b5d4fc2a6198905350fd683
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 12, 2016 at 2:51 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Avi Kivity wrote:
>>
>>
>>
>> On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>>>>
>>>> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>>>>>
>>>>>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Re your comments elsethread: C doesn't have a lot of these "heavy
>>>>>>>>> lifting" problems because it *does* allow zero-sized objects and
>>>>>>>>> it *doesn't* have a very strong type system the way C++ does.
>>>>>>>>> C++'s heavy lifting isn't in the machine-level implementation details;
>>>>>>>>> there you're right that the compilers can just "do what C does." The heavy
>>>>>>>>> lifting is in the C++-specific stuff: the *high-level semantics*,
>>>>>>>>> the *language*. That's the hard part.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then it's totally unreasonable for a compiler newbie like myself to
>>>>>>>> try and figure them out. But can you explain where in the high level
>>>>>>>> semantics a zero sized data member enters at all?
>>>>>>>>
>>>>>>>
>>>>>>> ... Everywhere? Is that a place?
>>>>>>>
>>>>>>> C++ defines an object, first and foremost, as "a region of storage".
>>>>>>> The entire C++ object model *relies* on that. A zero-sized object
>>>>>>> is anathema to that definition.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Would not the zero-sized object occupy a zero-sized region of storage?
>>>>>>
>>>>>
>>>>> And what exactly is "a zero-sized region of storage"? You cannot
>>>>> allocate or deallocate *nothing*. Even `malloc` doesn't work
>>>>> reasonably with zero. You may or may not get back a NULL pointer, but
>>>>> whatever you get back, you aren't allowed to dereference it.
>>>>>
>>>>>
>>>>
>>>> That never comes into question. The zero-sized region is always part
>>>> of a larger non-zero-sized region.
>>>>
>>>> Zero-sized regions seem to exist just fine in C++, when inheriting from
>>>> an empty base class,
>>>>
>>>
>>> But they're not zero-sized regions of memory. sizeof for the empty
>>> object will return non-zero.
>>>
>>
>> Let me go back and explain what I want in detail so there are no
>> misunderstandings.
>>
>> ...
>>
>> Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1,
>> despite both objects taking up no space in either B or C. So the region of
>> memory occupied by them is zero, despite their sizeof being non-zero. This
>> is existing practice and is not introduced by my proposal.
>>
>
> If that's your idea, then why do you keep bringing up zero-sized arrays
> and zero-sized types? That is, you keep saying that C allows for empty
> members, but it does so with a *completely different mechanism*: by
> allowing types to have zero size.
>
No. I am proposing to use the same mechanism that C++ uses for empty bases
(which are not zero sized), and that C uses for empty members (which in C
also happen to be zero sized), and that gcc uses for array members of size
zero (which are zero sized).
>
> So don't bring up empty types in C unless that's actually what you want.
>
I do want empty types, but they are not zero sized.
struct A {};
sizeof(A) == 1.
>
> and in C, with empty struct members. Both C++ and C seem to have solved
>>>> this problem.
>>>>
>>>
>>> C++ only "solved that problem" by making specific exceptions to certain
>>> operations when dealing with base class subobjects. Do you know where you
>>> would have to make similar exceptions for member subobjects? Do you know if
>>> you can just piggy back off of that language, or would you have to scour
>>> the spec for locations where a member subobject that doesn't take up space
>>> would be problematic?
>>>
>>
>> I did not exhaustively read the standard looking for those places. But
>> given that:
>>
>> 1. the problem was solved for base classes
>> 2. the problem was solved, in C, for member objects
>> 3. the problem was solved, in at list gcc, for member objects, by
>> declaring them as arrays of zero size.
>>
>
>> it seems to be reasonable that there are no insurmountable difficulties.
>> There's simply too much prior art to assume it is impossible or even
>> difficult.
>>
>
> As previously stated, #2 and #3 are non-sequiturs for this conversation.
>
They are not non sequiturs. They are similar to my case but not exact. If
only things that were in the standard were allowed to be standardized, we'd
never get anywhere.
> That only leaves #1. And you also clearly state that you haven't looked
> for such places. And therefore, you don't know if the solutions for base
> classes will work for members. You also don't know if you would need to
> make other adjustments that the base class solution didn't need.
>
I don't know, that is why I am asking the collective wisdom of this list.
And the answers I'm getting are "it's everywhere" and "go look yourself"
which are just symptoms of automatic rejection, not of anyone knowing any
actual objection.
>
> So the basis for your claim is flimsy.
>
We have seen one issue with memcpy() of empty base classes explicitly
disallowed. It could be extended to empty members that take up no space
(since they are distinguished by some syntax or other). Are there any
other issues, or are we left with a vague everywhere?
>
>
>> The other thing you're not getting is this.
>>>
>>> This is perfectly legal:
>>>
>>> B q;
>>> B r;
>>> memcpy(&q, &r, sizeof(B));
>>>
>>> Because `B` is non-zero sized, that makes sense. `B` is trivially
>>> copyable, so you can copy it via memcpy.
>>>
>>> This too is legal.
>>>
>>> struct D { B b; };
>>>
>>> D q;
>>> D r;
>>> memcpy(&q.b, r.b, sizeof(B));
>>>
>>> This however, is *not legal*:
>>> c
>>> struct D : B {...};
>>>
>>> D q;
>>> D r;
>>> memcpy((B*)&q, (B*)&r, sizeof(B));
>>>
>>> While both B and D are trivially copyable, you are not allowed to
>>> trivially copy into a base-class subobject of another object. The standard
>>> *explicitly* forbids this in [basic.types]/2. Why?
>>>
>>> Because it would break empty base optimization (among other things).
>>>
>>> By standard layout rules, the presence of `B` as a base class of `D`
>>> does not distrub `D`'s layout. Therefore, a pointer to the `B` subobject
>>> must point to some storage within `D`. And that storage is probably taken
>>> up by one of the members of `D`. And since `B` is not zero-sized, copying
>>> anything into a base-class subobject can cause problems.
>>>
>>
>> Good. We can apply the same restriction to members annotated to take up
>> no room in their struct's layout.
>>
>
> OK, the point of my spiel here was to explain to you just how little you
> understand the *ramifications* of what you ask. Until I brought that up,
> you had no idea that this copying thing was even an issue with your idea.
> Which proves that you simply do not know much about the standardization
> issues of permitting empty members.
>
>
I'm not pretending to be an expert on standardization. I do happen to be an
expert C++ programmer and I know the feature will be very useful to library
writers.
> And that's just *one thing*. How many others are there? You certainly
> don't know.
>
> Yet you continue to claim that it will not be difficult. Why should we
> believe you about how difficult this is, when you have repeatedly displayed
> your ignorance on the complexities of such a feature?
>
>
Looks like we're an infinite loop. Yes, getting the language-lawyering
will require an expert in the standard (which I'm not). No, you can't
convince me this is difficult to implement, since the implementation
already exists (with some variations), or that it would be difficult for an
expert to word (since new syntax is introduced, we can remove any
guarantees that are given without the syntax).
> Not to mention, when asked to demonstrate how "not difficult" it would be
> by actually implementing it, you balked and claimed that this request was
> somehow unfair.
>
> Anyone can say "go do this; it should be easy." It's far easier to do that
> than to actually implement it or learn about the particulars of the spec so
> that you can get the feature's wording right.
>
What I am actually saying is that it would be easier for an expert in the
standard to word it than for me, and easier for an expert in the compiler
to implement it than to me. I'm not going to invest a week of me time to
prove this feature; I want it, but not that much. I thought that with the
focus on C++ being made easier to learn that this simplification would be
welcome. As it is now, reading a standard library implementation is very
difficult. My proposal won't make it easy, but it will make it less
difficult.
--
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/CAF950WLg7xjAV%2BN5%3DUddZfbjuQH8rkRo4RVXs_D4r-dBgRP0Ww%40mail.gmail.com.
--047d7b5d4fc2a6198905350fd683
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jun 12, 2016 at 2:51 AM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Avi Kivity wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br><div class=
=3D"gmail_quote"><span class=3D"">On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bo=
las <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></sp=
an> 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">On Saturday, =
June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:<span><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On =
Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"=
nofollow">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:=
<span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On =
Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"=
nofollow">jmck...@gmail.com</a>></span> wrote: <br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div=
dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div></div><=
/div></div></div></blockquote></span><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div></div><span><div>Re your comments elsethread: C doe=
sn't have a lot of these "heavy lifting" problems because it =
<i>does</i> allow zero-sized objects and it <i>doesn't</i> have a very =
strong type system the way C++ does. C++'s heavy lifting isn't in t=
he machine-level implementation details; there you're right that the co=
mpilers can just "do what C does." =C2=A0The heavy lifting is in =
the C++-specific stuff: the <i>high-level semantics</i>, the <i>language</i=
>. That's the hard part.</div></span></div></div></div></blockquote><sp=
an><div><br></div><div></div><div>Then it's totally unreasonable for a =
compiler newbie like myself to try and figure them out.=C2=A0 But can you e=
xplain where in the high level semantics a zero sized data member enters at=
all?<br></div></span></div></div></div></blockquote><div><br>... Everywher=
e? Is that a place?<br><br>C++ defines an object, first and foremost, as &q=
uot;a region of storage". The entire C++ object model <i>relies</i> on=
that. A zero-sized object is anathema to that definition.</div></div></blo=
ckquote><div><br></div><div><br></div><div>Would not the zero-sized object =
occupy a zero-sized region of storage?</div></div></div></div></blockquote>=
</span><div><br>And what exactly is "a zero-sized region of storage&qu=
ot;? You cannot allocate or deallocate <i>nothing</i>. Even `malloc` doesn&=
#39;t work reasonably with zero. You may or may not get back a NULL pointer=
, but whatever you get back, you aren't allowed to dereference it.<br><=
br></div></div></blockquote><div><br></div><div><br></div><div>That never c=
omes into question.=C2=A0 The zero-sized region is always part of a larger =
non-zero-sized region.</div><div><br></div><div>Zero-sized regions seem to =
exist just fine in C++, when inheriting from an empty base class,</div></di=
v></div></div></blockquote></span><div><br>But they're not zero-sized r=
egions of memory. sizeof for the empty object will return non-zero.<br></di=
v></div></blockquote><div><br></div><div>Let me go back and explain what I =
want in detail so there are no misunderstandings.</div><div><br></div></spa=
n>...<span class=3D""><br><div>=C2=A0</div><div>Now to answer your question=
, both sizeof(A) and sizeof(c.a) will be 1, despite both objects taking up =
no space in either B or C.=C2=A0 So the region of memory occupied by them i=
s zero, despite their sizeof being non-zero. This is existing practice and =
is not introduced by my proposal.</div></span></div></div></div></blockquot=
e><div><br>If that's your idea, then why do you keep bringing up zero-s=
ized arrays and zero-sized types? That is, you keep saying that C allows fo=
r empty members, but it does so with a <i>completely different mechanism</i=
>: by allowing types to have zero size.<br></div></div></blockquote><div><b=
r></div><div><br></div><div>No.=C2=A0 I am proposing to use the same mechan=
ism that C++ uses for empty bases (which are not zero sized), and that C us=
es for empty members (which in C also happen to be zero sized), and that gc=
c uses for array members of size zero (which are zero sized).</div><div>=C2=
=A0</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><br>So don=
9;t bring up empty types in C unless that's actually what you want.<br>=
</div></div></blockquote><div><br></div><div>I do want empty types, but the=
y are not zero sized.</div><div><br></div><div>struct A {};</div><div>sizeo=
f(A) =3D=3D 1.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><br></div><span class=3D""><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v></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"><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"=
><div>and in C, with empty struct members.=C2=A0 Both C++ and C seem to hav=
e solved this problem.</div></div></div></div></blockquote></span><div><br>=
C++ only "solved that problem" by making specific exceptions to c=
ertain operations when dealing with base class subobjects. Do you know wher=
e you would have to make similar exceptions for member subobjects? Do you k=
now if you can just piggy back off of that language, or would you have to s=
cour the spec for locations where a member subobject that doesn't take =
up space would be problematic?<br></div></div></blockquote><div><br></div><=
div>I did not exhaustively read the standard looking for those places.=C2=
=A0 But given that:</div><div><br></div><div>1. the problem was solved for =
base classes</div><div>2. the problem was solved, in C, for member objects<=
/div><div>3. the problem was solved, in at list gcc, for member objects, by=
declaring them as arrays of zero size.=C2=A0</div></div></div></div></bloc=
kquote><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"><div><br></div><div>it seems to be reasonable that the=
re are no insurmountable difficulties.=C2=A0 There's simply too much pr=
ior art to assume it is impossible or even difficult.</div></div></div></di=
v></blockquote></span><div><br>As previously stated, #2 and #3 are non-sequ=
iturs for this conversation. </div></div></blockquote><div><br></div><div>T=
hey are not non sequiturs.=C2=A0 They are similar to my case but not exact.=
=C2=A0 If only things that were in the standard were allowed to be standard=
ized, we'd never get anywhere.</div><div><br></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That only leaves #1. And =
you also clearly state that you haven't looked for such places. And the=
refore, you don't know if the solutions for base classes will work for =
members. You also don't know if you would need to make other adjustment=
s that the base class solution didn't need.<br></div></div></blockquote=
><div><br></div><div>I don't know, that is why I am asking the collecti=
ve wisdom of this list.=C2=A0 And the answers I'm getting are "it&=
#39;s everywhere" and "go look yourself" which are just symp=
toms of automatic rejection, not of anyone knowing any actual objection.</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><b=
r>So the basis for your claim is flimsy.<br></div></div></blockquote><div><=
br></div><div>We have seen one issue with memcpy() of empty base classes ex=
plicitly disallowed.=C2=A0 It could be extended to empty members that take =
up no space (since they are distinguished by some syntax or other).=C2=A0 A=
re there any other issues, or are we left with a vague everywhere?</div><di=
v><br></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>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><span></span></div></blockquot=
e><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The other=
thing you're not getting is this.<br><br>This is perfectly legal:<br><=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>=
<span style=3D"color:#000">B q</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br>B r</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">(&=
</span><span style=3D"color:#000">q</span><span style=3D"color:#660">,</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#660">&</span=
><span style=3D"color:#000">r</span><span style=3D"color:#660">,</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><spa=
n style=3D"color:#660">(</span><span style=3D"color:#000">B</span><span sty=
le=3D"color:#660">));</span></div></code></div><br>Because `B` is non-zero =
sized, that makes sense. `B` is trivially copyable, so you can copy it via =
memcpy.<br><br>This too is legal.<br><br><div style=3D"background-color:rgb=
(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width=
:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">struct</sp=
an><span style=3D"color:#000"> D </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"> B b</span><span style=3D"color:#660">;</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">};</span><span =
style=3D"color:#000"><br><br>D q</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>D r</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">(&am=
p;</span><span style=3D"color:#000">q</span><span style=3D"color:#660">.</s=
pan><span style=3D"color:#000">b</span><span style=3D"color:#660">,</span><=
span style=3D"color:#000"> r</span><span style=3D"color:#660">.</span><span=
style=3D"color:#000">b</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">B</span><span style=3D"=
color:#660">));</span></div></code></div><br>This however, is <i>not legal<=
/i>:<br>c<br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span style=3D"color:#008">struct</span><span style=3D"color:#000=
"> D </span><span style=3D"color:#660">:</span><span style=3D"color:#000"> =
B </span><span style=3D"color:#660">{...};</span><span style=3D"color:#000"=
><br><br>D q</span><span style=3D"color:#660">;</span><span style=3D"color:=
#000"><br>D r</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br>memcpy</span><span style=3D"color:#660">((</span><span style=3D"=
color:#000">B</span><span style=3D"color:#660">*)&</span><span style=3D=
"color:#000">q</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#00=
0">B</span><span style=3D"color:#660">*)&</span><span style=3D"color:#0=
00">r</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">sizeof</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">B</span><span style=3D"color:#660">));</s=
pan></div></code></div><br>While both B and D are trivially copyable, you a=
re not allowed to trivially copy into a base-class subobject of another obj=
ect. The standard <i>explicitly</i> forbids this in [basic.types]/2. Why?<b=
r><br>Because it would break empty base optimization (among other things).<=
br><br>By standard layout rules, the presence of `B` as a base class of `D`=
does not distrub `D`'s layout. Therefore, a pointer to the `B` subobje=
ct must point to some storage within `D`. And that storage is probably take=
n up by one of the members of `D`. And since `B` is not zero-sized, copying=
anything into a base-class subobject can cause problems.<br></div></div></=
blockquote><div><br></div><div>Good.=C2=A0 We can apply the same restrictio=
n to members annotated to take up no room in their struct's layout.</di=
v></div></div></div></blockquote></span><div><br>OK, the point of my spiel =
here was to explain to you just how little you understand the <i>ramificati=
ons</i> of what you ask. Until I brought that up, you had no idea that this=
copying thing was even an issue with your idea. Which proves that you simp=
ly do not know much about the standardization issues of permitting empty me=
mbers.<br><br></div></div></blockquote><div><br></div><div><br></div><div>I=
'm not pretending to be an expert on standardization. I do happen to be=
an expert C++ programmer and I know the feature will be very useful to lib=
rary writers.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>And that's just <i>one thing</i>. How many=
others are there? You certainly don't know.<br><br>Yet you continue to=
claim that it will not be difficult. Why should we believe you about how d=
ifficult this is, when you have repeatedly displayed your ignorance on the =
complexities of such a feature?<br><br></div></div></blockquote><div><br></=
div><div>Looks like we're an infinite loop.=C2=A0 Yes, getting the lang=
uage-lawyering will require an expert in the standard (which I'm not). =
No, you can't convince me this is difficult to implement, since the imp=
lementation already exists (with some variations), or that it would be diff=
icult for an expert to word (since new syntax is introduced, we can remove =
any guarantees that are given without the syntax).</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Not to mention, when ask=
ed to demonstrate how "not difficult" it would be by actually imp=
lementing it, you balked and claimed that this request was somehow unfair.<=
br><br>Anyone can say "go do this; it should be easy." It's f=
ar easier to do that than to actually implement it or learn about the parti=
culars of the spec so that you can get the feature's wording right.</di=
v></div></blockquote><div><br></div><div>What I am actually saying is that =
it would be easier for an expert in the standard to word it than for me, an=
d easier for an expert in the compiler to implement it than to me. I'm =
not going to invest a week of me time to prove this feature; I want it, but=
not that much. I thought that with the focus on C++ being made easier to l=
earn that this simplification would be welcome.=C2=A0 As it is now, reading=
a standard library implementation is very difficult.=C2=A0 My proposal won=
't make it easy, but it will make it less difficult.</div><div>=C2=A0</=
div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WLg7xjAV%2BN5%3DUddZfbjuQH8rkRo=
4RVXs_D4r-dBgRP0Ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WLg7xjA=
V%2BN5%3DUddZfbjuQH8rkRo4RVXs_D4r-dBgRP0Ww%40mail.gmail.com</a>.<br />
--047d7b5d4fc2a6198905350fd683--
.
Author: Jonathan <jonathanbcoe@gmail.com>
Date: Sun, 12 Jun 2016 10:37:25 +0100
Raw View
--Apple-Mail-772FDAC0-54B7-4B9B-A4A7-D5EFBCE7AED6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This seems like an interesting idea to me.=20
Is anyone who could implement this interested enough to have a go?
I'm afraid I'm personally in the 'interested but unable' category.
At a guess, an implementation (or firm conclusion that implementation is im=
possible) might make some of the required wording changes more straightforw=
ard to understand.
Regards,
Jon
> On 12 Jun 2016, at 08:36, Avi Kivity <avi@scylladb.com> wrote:
>=20
>=20
>=20
>> On Sun, Jun 12, 2016 at 2:51 AM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>>=20
>>=20
>>> On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Avi Kivity wrote:
>>>=20
>>>=20
>>>> On Sat, Jun 11, 2016 at 6:51 PM, Nicol Bolas <jmck...@gmail.com> wrote=
:
>>>>> On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Kivity wrote:
>>>>>> On Sat, Jun 11, 2016 at 12:56 AM, Nicol Bolas <jmck...@gmail.com> wr=
ote:
>>>>>>> On Friday, June 10, 2016 at 3:48:02 PM UTC-4, Avi Kivity wrote:
>>>>>>>> On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bolas <jmck...@gmail.com> =
wrote:=20
>>>>>>>>>> Re your comments elsethread: C doesn't have a lot of these "heav=
y lifting" problems because it does allow zero-sized objects and it doesn't=
have a very strong type system the way C++ does. C++'s heavy lifting isn't=
in the machine-level implementation details; there you're right that the c=
ompilers can just "do what C does." The heavy lifting is in the C++-specif=
ic stuff: the high-level semantics, the language. That's the hard part.
>>>>>>>>>=20
>>>>>>>>> Then it's totally unreasonable for a compiler newbie like myself =
to try and figure them out. But can you explain where in the high level se=
mantics a zero sized data member enters at all?
>>>>>>>>=20
>>>>>>>> ... Everywhere? Is that a place?
>>>>>>>>=20
>>>>>>>> C++ defines an object, first and foremost, as "a region of storage=
". The entire C++ object model relies on that. A zero-sized object is anath=
ema to that definition.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Would not the zero-sized object occupy a zero-sized region of stora=
ge?
>>>>>>=20
>>>>>>=20
>>>>>> And what exactly is "a zero-sized region of storage"? You cannot all=
ocate or deallocate nothing. Even `malloc` doesn't work reasonably with zer=
o. You may or may not get back a NULL pointer, but whatever you get back, y=
ou aren't allowed to dereference it.
>>>>>=20
>>>>>=20
>>>>> That never comes into question. The zero-sized region is always part=
of a larger non-zero-sized region.
>>>>>=20
>>>>> Zero-sized regions seem to exist just fine in C++, when inheriting fr=
om an empty base class,
>>>>=20
>>>>=20
>>>> But they're not zero-sized regions of memory. sizeof for the empty obj=
ect will return non-zero.
>>>=20
>>> Let me go back and explain what I want in detail so there are no misund=
erstandings.
>>>=20
>>> ...
>>> =20
>>> Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1, =
despite both objects taking up no space in either B or C. So the region of=
memory occupied by them is zero, despite their sizeof being non-zero. This=
is existing practice and is not introduced by my proposal.
>>=20
>> If that's your idea, then why do you keep bringing up zero-sized arrays =
and zero-sized types? That is, you keep saying that C allows for empty memb=
ers, but it does so with a completely different mechanism: by allowing type=
s to have zero size.
>=20
>=20
> No. I am proposing to use the same mechanism that C++ uses for empty bas=
es (which are not zero sized), and that C uses for empty members (which in =
C also happen to be zero sized), and that gcc uses for array members of siz=
e zero (which are zero sized).
> =20
>>=20
>> So don't bring up empty types in C unless that's actually what you want.
>=20
> I do want empty types, but they are not zero sized.
>=20
> struct A {};
> sizeof(A) =3D=3D 1.
>=20
> =20
>>=20
>>>>> and in C, with empty struct members. Both C++ and C seem to have sol=
ved this problem.
>>>>=20
>>>>=20
>>>> C++ only "solved that problem" by making specific exceptions to certai=
n operations when dealing with base class subobjects. Do you know where you=
would have to make similar exceptions for member subobjects? Do you know i=
f you can just piggy back off of that language, or would you have to scour =
the spec for locations where a member subobject that doesn't take up space =
would be problematic?
>>>=20
>>> I did not exhaustively read the standard looking for those places. But=
given that:
>>>=20
>>> 1. the problem was solved for base classes
>>> 2. the problem was solved, in C, for member objects
>>> 3. the problem was solved, in at list gcc, for member objects, by decla=
ring them as arrays of zero size.=20
>>>=20
>>> it seems to be reasonable that there are no insurmountable difficulties=
.. There's simply too much prior art to assume it is impossible or even dif=
ficult.
>>=20
>>=20
>> As previously stated, #2 and #3 are non-sequiturs for this conversation.
>=20
> They are not non sequiturs. They are similar to my case but not exact. =
If only things that were in the standard were allowed to be standardized, w=
e'd never get anywhere.
>=20
> =20
>> That only leaves #1. And you also clearly state that you haven't looked =
for such places. And therefore, you don't know if the solutions for base cl=
asses will work for members. You also don't know if you would need to make =
other adjustments that the base class solution didn't need.
>=20
> I don't know, that is why I am asking the collective wisdom of this list.=
And the answers I'm getting are "it's everywhere" and "go look yourself" =
which are just symptoms of automatic rejection, not of anyone knowing any a=
ctual objection.
> =20
>>=20
>> So the basis for your claim is flimsy.
>=20
> We have seen one issue with memcpy() of empty base classes explicitly dis=
allowed. It could be extended to empty members that take up no space (sinc=
e they are distinguished by some syntax or other). Are there any other iss=
ues, or are we left with a vague everywhere?
>=20
> =20
>> =20
>>>> The other thing you're not getting is this.
>>>>=20
>>>> This is perfectly legal:
>>>>=20
>>>> B q;
>>>> B r;
>>>> memcpy(&q, &r, sizeof(B));
>>>>=20
>>>> Because `B` is non-zero sized, that makes sense. `B` is trivially copy=
able, so you can copy it via memcpy.
>>>>=20
>>>> This too is legal.
>>>>=20
>>>> struct D { B b; };
>>>>=20
>>>> D q;
>>>> D r;
>>>> memcpy(&q.b, r.b, sizeof(B));
>>>>=20
>>>> This however, is not legal:
>>>> c
>>>> struct D : B {...};
>>>>=20
>>>> D q;
>>>> D r;
>>>> memcpy((B*)&q, (B*)&r, sizeof(B));
>>>>=20
>>>> While both B and D are trivially copyable, you are not allowed to triv=
ially copy into a base-class subobject of another object. The standard expl=
icitly forbids this in [basic.types]/2. Why?
>>>>=20
>>>> Because it would break empty base optimization (among other things).
>>>>=20
>>>> By standard layout rules, the presence of `B` as a base class of `D` d=
oes not distrub `D`'s layout. Therefore, a pointer to the `B` subobject mus=
t point to some storage within `D`. And that storage is probably taken up b=
y one of the members of `D`. And since `B` is not zero-sized, copying anyth=
ing into a base-class subobject can cause problems.
>>>=20
>>> Good. We can apply the same restriction to members annotated to take u=
p no room in their struct's layout.
>>=20
>>=20
>> OK, the point of my spiel here was to explain to you just how little you=
understand the ramifications of what you ask. Until I brought that up, you=
had no idea that this copying thing was even an issue with your idea. Whic=
h proves that you simply do not know much about the standardization issues =
of permitting empty members.
>=20
>=20
> I'm not pretending to be an expert on standardization. I do happen to be =
an expert C++ programmer and I know the feature will be very useful to libr=
ary writers.
>=20
> =20
>> And that's just one thing. How many others are there? You certainly don'=
t know.
>>=20
>> Yet you continue to claim that it will not be difficult. Why should we b=
elieve you about how difficult this is, when you have repeatedly displayed =
your ignorance on the complexities of such a feature?
>=20
> Looks like we're an infinite loop. Yes, getting the language-lawyering w=
ill require an expert in the standard (which I'm not). No, you can't convin=
ce me this is difficult to implement, since the implementation already exis=
ts (with some variations), or that it would be difficult for an expert to w=
ord (since new syntax is introduced, we can remove any guarantees that are =
given without the syntax).
> =20
>> Not to mention, when asked to demonstrate how "not difficult" it would b=
e by actually implementing it, you balked and claimed that this request was=
somehow unfair.
>>=20
>> Anyone can say "go do this; it should be easy." It's far easier to do th=
at than to actually implement it or learn about the particulars of the spec=
so that you can get the feature's wording right.
>=20
> What I am actually saying is that it would be easier for an expert in the=
standard to word it than for me, and easier for an expert in the compiler =
to implement it than to me. I'm not going to invest a week of me time to pr=
ove this feature; I want it, but not that much. I thought that with the foc=
us on C++ being made easier to learn that this simplification would be welc=
ome. As it is now, reading a standard library implementation is very diffi=
cult. My proposal won't make it easy, but it will make it less difficult.
> =20
>=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=
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/isoc=
pp.org/d/msgid/std-proposals/CAF950WLg7xjAV%2BN5%3DUddZfbjuQH8rkRo4RVXs_D4r=
-dBgRP0Ww%40mail.gmail.com.
--=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/FCAD1871-11D3-45F0-97F5-3601EA6EA618%40gmail.com=
..
--Apple-Mail-772FDAC0-54B7-4B9B-A4A7-D5EFBCE7AED6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div>This seems like an inte=
resting idea to me. </div><div><br></div><div>Is anyone who could impl=
ement this interested enough to have a go?</div><div>I'm afraid I'm persona=
lly in the 'interested but unable' category.</div><div><br></div><div><br><=
/div><div>At a guess, an implementation (or firm conclusion that implementa=
tion is impossible) might make some of the required wording changes more st=
raightforward to understand.</div><div><br></div><div>Regards,</div><div><b=
r></div><div>Jon</div><div><br>On 12 Jun 2016, at 08:36, Avi Kivity <<a =
href=3D"mailto:avi@scylladb.com">avi@scylladb.com</a>> wrote:<br><br></d=
iv><blockquote type=3D"cite"><div><div dir=3D"ltr"><br><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Sun, Jun 12, 2016 at 2:51 AM, Nico=
l Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>On Saturday, June 11, 2016 at 1:45:2=
0 PM UTC-4, Avi Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><br><div><br><div class=3D"gmail_quote"><span class=3D"">On Sat,=
Jun 11, 2016 at 6:51 PM, Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofol=
low">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Saturday, June 11, 2016 at 6:15:28 AM UTC-4, Avi Ki=
vity wrote:<span><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 Sat, Jun 11, 2016 at 12:56 AM, Nicol Bola=
s <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr">On Friday, June 10, 2016 at 3=
:48:02 PM UTC-4, Avi Kivity wrote:<span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On Fri, Jun 10, 2016 at 10:38 PM, Nicol Bola=
s <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span=
> wrote: <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><div><div></div></div></div></div></blockquote></span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><span><div>=
Re your comments elsethread: C doesn't have a lot of these "heavy lifting" =
problems because it <i>does</i> allow zero-sized objects and it <i>doesn't<=
/i> have a very strong type system the way C++ does. C++'s heavy lifting is=
n't in the machine-level implementation details; there you're right that th=
e compilers can just "do what C does." The heavy lifting is in the C+=
+-specific stuff: the <i>high-level semantics</i>, the <i>language</i>. Tha=
t's the hard part.</div></span></div></div></div></blockquote><span><div><b=
r></div><div></div><div>Then it's totally unreasonable for a compiler newbi=
e like myself to try and figure them out. But can you explain where i=
n the high level semantics a zero sized data member enters at all?<br></div=
></span></div></div></div></blockquote><div><br>... Everywhere? Is that a p=
lace?<br><br>C++ defines an object, first and foremost, as "a region of sto=
rage". The entire C++ object model <i>relies</i> on that. A zero-sized obje=
ct is anathema to that definition.</div></div></blockquote><div><br></div><=
div><br></div><div>Would not the zero-sized object occupy a zero-sized regi=
on of storage?</div></div></div></div></blockquote></span><div><br>And what=
exactly is "a zero-sized region of storage"? You cannot allocate or deallo=
cate <i>nothing</i>. Even `malloc` doesn't work reasonably with zero. You m=
ay or may not get back a NULL pointer, but whatever you get back, you aren'=
t allowed to dereference it.<br><br></div></div></blockquote><div><br></div=
><div><br></div><div>That never comes into question. The zero-sized r=
egion is always part of a larger non-zero-sized region.</div><div><br></div=
><div>Zero-sized regions seem to exist just fine in C++, when inheriting fr=
om an empty base class,</div></div></div></div></blockquote></span><div><br=
>But they're not zero-sized regions of memory. sizeof for the empty object =
will return non-zero.<br></div></div></blockquote><div><br></div><div>Let m=
e go back and explain what I want in detail so there are no misunderstandin=
gs.</div><div><br></div></span>...<span class=3D""><br><div> </div><di=
v>Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1, de=
spite both objects taking up no space in either B or C. So the region=
of memory occupied by them is zero, despite their sizeof being non-zero. T=
his is existing practice and is not introduced by my proposal.</div></span>=
</div></div></div></blockquote><div><br>If that's your idea, then why do yo=
u keep bringing up zero-sized arrays and zero-sized types? That is, you kee=
p saying that C allows for empty members, but it does so with a <i>complete=
ly different mechanism</i>: by allowing types to have zero size.<br></div><=
/div></blockquote><div><br></div><div><br></div><div>No. I am proposi=
ng to use the same mechanism that C++ uses for empty bases (which are not z=
ero sized), and that C uses for empty members (which in C also happen to be=
zero sized), and that gcc uses for array members of size zero (which are z=
ero sized).</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><br>So don't bring up empty types in C unless that's actually=
what you want.<br></div></div></blockquote><div><br></div><div>I do want e=
mpty types, but they are not zero sized.</div><div><br></div><div>struct A =
{};</div><div>sizeof(A) =3D=3D 1.</div><div><br></div><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><span class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><span><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"><div>and in C, with empty struct members. Both C=
++ and C seem to have solved this problem.</div></div></div></div></blockqu=
ote></span><div><br>C++ only "solved that problem" by making specific excep=
tions to certain operations when dealing with base class subobjects. Do you=
know where you would have to make similar exceptions for member subobjects=
? Do you know if you can just piggy back off of that language, or would you=
have to scour the spec for locations where a member subobject that doesn't=
take up space would be problematic?<br></div></div></blockquote><div><br><=
/div><div>I did not exhaustively read the standard looking for those places=
.. But given that:</div><div><br></div><div>1. the problem was solved =
for base classes</div><div>2. the problem was solved, in C, for member obje=
cts</div><div>3. the problem was solved, in at list gcc, for member objects=
, by declaring them as arrays of zero size. </div></div></div></div></=
blockquote><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><d=
iv class=3D"gmail_quote"><div><br></div><div>it seems to be reasonable that=
there are no insurmountable difficulties. There's simply too much pr=
ior art to assume it is impossible or even difficult.</div></div></div></di=
v></blockquote></span><div><br>As previously stated, #2 and #3 are non-sequ=
iturs for this conversation. </div></div></blockquote><div><br></div><div>T=
hey are not non sequiturs. They are similar to my case but not exact.=
If only things that were in the standard were allowed to be standard=
ized, we'd never get anywhere.</div><div><br></div><div> </div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>That only leaves #1. And you =
also clearly state that you haven't looked for such places. And therefore, =
you don't know if the solutions for base classes will work for members. You=
also don't know if you would need to make other adjustments that the base =
class solution didn't need.<br></div></div></blockquote><div><br></div><div=
>I don't know, that is why I am asking the collective wisdom of this list.&=
nbsp; And the answers I'm getting are "it's everywhere" and "go look yourse=
lf" which are just symptoms of automatic rejection, not of anyone knowing a=
ny actual objection.</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><br>So the basis for your claim is flimsy.<br></div></=
div></blockquote><div><br></div><div>We have seen one issue with memcpy() o=
f empty base classes explicitly disallowed. It could be extended to e=
mpty members that take up no space (since they are distinguished by some sy=
ntax or other). Are there any other issues, or are we left with a vag=
ue everywhere?</div><div><br></div><div> </div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div> </div><span class=3D""><blockquote clas=
s=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"><d=
iv></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><span><=
/span></div></blockquote><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>The other thing you're not getting is this.<br><br>This is pe=
rfectly legal:<br><br><div style=3D"background-color:rgb(250,250,250);borde=
r-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:brea=
k-word"><code><div><span style=3D"color:#000">B q</span><span style=3D"colo=
r:#660">;</span><span style=3D"color:#000"><br>B r</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"><br>memcpy</span><span style=3D=
"color:#660">(&</span><span style=3D"color:#000">q</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">&</span><span style=3D"color:#000">r</span><span style=3D"color=
:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">sizeof</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">B</span><span style=3D"color:#660">));</span></div></code></div><br>Becau=
se `B` is non-zero sized, that makes sense. `B` is trivially copyable, so y=
ou can copy it via memcpy.<br><br>This too is legal.<br><br><div style=3D"b=
ackground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style=
:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"col=
or:#008">struct</span><span style=3D"color:#000"> D </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"> B b</span><span style=3D"col=
or:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">};</span><span style=3D"color:#000"><br><br>D q</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"><br>D r</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br>memcpy</span><span style=
=3D"color:#660">(&</span><span style=3D"color:#000">q</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">b</span><span style=3D"c=
olor:#660">,</span><span style=3D"color:#000"> r</span><span style=3D"color=
:#660">.</span><span style=3D"color:#000">b</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style=3D"color:#000">B</=
span><span style=3D"color:#660">));</span></div></code></div><br>This howev=
er, is <i>not legal</i>:<br>c<br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><span=
style=3D"color:#000"> D </span><span style=3D"color:#660">:</span><span st=
yle=3D"color:#000"> B </span><span style=3D"color:#660">{...};</span><span =
style=3D"color:#000"><br><br>D q</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>D r</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br>memcpy</span><span style=3D"color:#660">((</=
span><span style=3D"color:#000">B</span><span style=3D"color:#660">*)&<=
/span><span style=3D"color:#000">q</span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">B</span><span style=3D"color:#660">*)&</span><sp=
an style=3D"color:#000">r</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">sizeof</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">B</span><span style=
=3D"color:#660">));</span></div></code></div><br>While both B and D are tri=
vially copyable, you are not allowed to trivially copy into a base-class su=
bobject of another object. The standard <i>explicitly</i> forbids this in [=
basic.types]/2. Why?<br><br>Because it would break empty base optimization =
(among other things).<br><br>By standard layout rules, the presence of `B` =
as a base class of `D` does not distrub `D`'s layout. Therefore, a pointer =
to the `B` subobject must point to some storage within `D`. And that storag=
e is probably taken up by one of the members of `D`. And since `B` is not z=
ero-sized, copying anything into a base-class subobject can cause problems.=
<br></div></div></blockquote><div><br></div><div>Good. We can apply t=
he same restriction to members annotated to take up no room in their struct=
's layout.</div></div></div></div></blockquote></span><div><br>OK, the poin=
t of my spiel here was to explain to you just how little you understand the=
<i>ramifications</i> of what you ask. Until I brought that up, you had no =
idea that this copying thing was even an issue with your idea. Which proves=
that you simply do not know much about the standardization issues of permi=
tting empty members.<br><br></div></div></blockquote><div><br></div><div><b=
r></div><div>I'm not pretending to be an expert on standardization. I do ha=
ppen to be an expert C++ programmer and I know the feature will be very use=
ful to library writers.</div><div><br></div><div> </div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>And that's just <i>one thing</i>. Ho=
w many others are there? You certainly don't know.<br><br>Yet you continue =
to claim that it will not be difficult. Why should we believe you about how=
difficult this is, when you have repeatedly displayed your ignorance on th=
e complexities of such a feature?<br><br></div></div></blockquote><div><br>=
</div><div>Looks like we're an infinite loop. Yes, getting the langua=
ge-lawyering will require an expert in the standard (which I'm not). No, yo=
u can't convince me this is difficult to implement, since the implementatio=
n already exists (with some variations), or that it would be difficult for =
an expert to word (since new syntax is introduced, we can remove any guaran=
tees that are given without the syntax).</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>Not to mention, when asked to demo=
nstrate how "not difficult" it would be by actually implementing it, you ba=
lked and claimed that this request was somehow unfair.<br><br>Anyone can sa=
y "go do this; it should be easy." It's far easier to do that than to actua=
lly implement it or learn about the particulars of the spec so that you can=
get the feature's wording right.</div></div></blockquote><div><br></div><d=
iv>What I am actually saying is that it would be easier for an expert in th=
e standard to word it than for me, and easier for an expert in the compiler=
to implement it than to me. I'm not going to invest a week of me time to p=
rove this feature; I want it, but not that much. I thought that with the fo=
cus on C++ being made easier to learn that this simplification would be wel=
come. As it is now, reading a standard library implementation is very=
difficult. My proposal won't make it easy, but it will make it less =
difficult.</div><div> </div></div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950WLg7xjAV%2BN5%3DUddZfbjuQH8rkRo=
4RVXs_D4r-dBgRP0Ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950WLg=
7xjAV%2BN5%3DUddZfbjuQH8rkRo4RVXs_D4r-dBgRP0Ww%40mail.gmail.com</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/FCAD1871-11D3-45F0-97F5-3601EA6EA618%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/FCAD1871-11D3-45F0-97F5-3601EA6EA618%=
40gmail.com</a>.<br />
--Apple-Mail-772FDAC0-54B7-4B9B-A4A7-D5EFBCE7AED6--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 12 Jun 2016 15:24:43 -0700
Raw View
On domingo, 12 de junho de 2016 10:20:35 PDT Avi Kivity wrote:
> On Sun, Jun 12, 2016 at 1:53 AM, Thiago Macieira <thiago@macieira.org>
>=20
> wrote:
> > On s=C3=A1bado, 11 de junho de 2016 20:44:58 PDT Avi Kivity wrote:
> > > Let me go back and explain what I want in detail so there are no
> > > misunderstandings.
> >=20
> > We understand what you want. But you fail to understand how difficult i=
t
> > is to
> > get what you want in the standard.
>=20
> You are bring up objections, and I am explaining why those objections are
> incorrect, but I don't see any response to that.
I'm not bringing up objections. I'm giving advice: what you want is actuall=
y=20
more difficult to explain than what you expect.
Just try and write the necessary parts of the standard and/or modify the=20
compilers to do what you're asking. Especially a compiler that doesn't=20
implement C99.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/4356238.0VNpuyXvmI%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 12 Jun 2016 20:29:48 -0700 (PDT)
Raw View
------=_Part_3618_838547301.1465788588785
Content-Type: multipart/alternative;
boundary="----=_Part_3619_192570935.1465788588785"
------=_Part_3619_192570935.1465788588785
Content-Type: text/plain; charset=UTF-8
On Sunday, June 12, 2016 at 3:37:07 AM UTC-4, Avi Kivity wrote:
>
> On Sun, Jun 12, 2016 at 2:51 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, Avi Kivity wrote:
>>>
>>> Now to answer your question, both sizeof(A) and sizeof(c.a) will be 1,
>>> despite both objects taking up no space in either B or C. So the region of
>>> memory occupied by them is zero, despite their sizeof being non-zero. This
>>> is existing practice and is not introduced by my proposal.
>>>
>>
>> If that's your idea, then why do you keep bringing up zero-sized arrays
>> and zero-sized types? That is, you keep saying that C allows for empty
>> members, but it does so with a *completely different mechanism*: by
>> allowing types to have zero size.
>>
>
> No. I am proposing to use the same mechanism that C++ uses for empty
> bases (which are not zero sized), and that C uses for empty members (which
> in C also happen to be zero sized), and that gcc uses for array members of
> size zero (which are zero sized).
>
Do you not understand the fact that those are *3 different mechanisms?*
Just because they have the same result does not mean that they achieve that
result in the same way.
Mechanisms are about "how" something gets done, not "what" is being done.
and in C, with empty struct members. Both C++ and C seem to have solved
>>>>> this problem.
>>>>>
>>>>
>>>> C++ only "solved that problem" by making specific exceptions to certain
>>>> operations when dealing with base class subobjects. Do you know where you
>>>> would have to make similar exceptions for member subobjects? Do you know if
>>>> you can just piggy back off of that language, or would you have to scour
>>>> the spec for locations where a member subobject that doesn't take up space
>>>> would be problematic?
>>>>
>>>
>>> I did not exhaustively read the standard looking for those places. But
>>> given that:
>>>
>>> 1. the problem was solved for base classes
>>> 2. the problem was solved, in C, for member objects
>>> 3. the problem was solved, in at list gcc, for member objects, by
>>> declaring them as arrays of zero size.
>>>
>>
>>> it seems to be reasonable that there are no insurmountable
>>> difficulties. There's simply too much prior art to assume it is impossible
>>> or even difficult.
>>>
>>
>> As previously stated, #2 and #3 are non-sequiturs for this conversation.
>>
>
> They are not non sequiturs. They are similar to my case but not exact.
> If only things that were in the standard were allowed to be standardized,
> we'd never get anywhere.
>
They're non-sequiturs because you clearly said, "I do want empty types, but
they are not zero sized." If you don't want zero-sized types, then bringing
up a feature involving zero-sized types is irrelevant since that is
explicitly not what you're asking for.
It's like saying that rockets can carry people into space because you've
seen airplanes fly. Even if your conclusion is right, your *reasoning* is
flawed. Airplanes and rockets use very different mechanisms to achieve
flight. Just as zero-sized types and base classes are very different
mechanisms for achieving things.
> That only leaves #1. And you also clearly state that you haven't looked
>> for such places. And therefore, you don't know if the solutions for base
>> classes will work for members. You also don't know if you would need to
>> make other adjustments that the base class solution didn't need.
>>
>
> I don't know, that is why I am asking the collective wisdom of this list.
> And the answers I'm getting are "it's everywhere" and "go look yourself"
> which are just symptoms of automatic rejection, not of anyone knowing any
> actual objection.
>
It's very important to understand how getting features standardized works.
You seem to be under the impression that there are legions of spec editors
just sitting around idle, champing at the bit to implement the next good
idea someone posts on a forum. And so if you post a really good idea, one
of them will do all the hard work for you.
That's not how it works. Pretty much *nothing* has ever been added to C++
just by doing that.
The way to get something standardized is by actually doing at least some of
the work. For a feature like this, one for which careful wording will have
to be crafted, you have to actually be able to demonstrate some knowledge
of what the corner cases are. If there is some reasonable doubt about it
being able to be implemented, you have to be able to show that it is
implementable (and no, bringing up irrelevant other cases is not good
enough). And so forth.
Ideas are worth *nothing*; it's *effort* that gets things done. That's not
"automatic rejection"; that's *reality*.
--
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/01e3e54c-0b77-4d84-9b08-dcb09bbf9eb6%40isocpp.org.
------=_Part_3619_192570935.1465788588785
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, June 12, 2016 at 3:37:07 AM UTC-4, Avi Kivity w=
rote:<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><di=
v class=3D"gmail_quote">On Sun, Jun 12, 2016 at 2:51 AM, Nicol Bolas <span =
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"vFk1Ns5fAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">On Saturday, June 11, 2016 at 1:45:20 PM UTC-4, =
Avi Kivity 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"><span></span><span><div>Now to answer your q=
uestion, both sizeof(A) and sizeof(c.a) will be 1, despite both objects tak=
ing up no space in either B or C.=C2=A0 So the region of memory occupied by=
them is zero, despite their sizeof being non-zero. This is existing practi=
ce and is not introduced by my proposal.</div></span></div></div></div></bl=
ockquote><div><br>If that's your idea, then why do you keep bringing up=
zero-sized arrays and zero-sized types? That is, you keep saying that C al=
lows for empty members, but it does so with a <i>completely different mecha=
nism</i>: by allowing types to have zero size.<br></div></div></blockquote>=
<div></div><div><br></div><div>No.=C2=A0 I am proposing to use the same mec=
hanism that C++ uses for empty bases (which are not zero sized), and that C=
uses for empty members (which in C also happen to be zero sized), and that=
gcc uses for array members of size zero (which are zero sized).</div></div=
></div></div></blockquote><div><br>Do you not understand the fact that thos=
e are <i><b>3 different mechanisms?</b></i> Just because they have the same=
result does not mean that they achieve that result in the same way.<br><br=
>Mechanisms are about "how" something gets done, not "what&q=
uot; is being done.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></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></div><span><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_quot=
e"><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"><span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div>and in C, with empty struct members.=C2=A0 Both C++ and C seem =
to have solved this problem.</div></div></div></div></blockquote></span><di=
v><br>C++ only "solved that problem" by making specific exception=
s to certain operations when dealing with base class subobjects. Do you kno=
w where you would have to make similar exceptions for member subobjects? Do=
you know if you can just piggy back off of that language, or would you hav=
e to scour the spec for locations where a member subobject that doesn't=
take up space would be problematic?<br></div></div></blockquote><div><br><=
/div><div>I did not exhaustively read the standard looking for those places=
..=C2=A0 But given that:</div><div><br></div><div>1. the problem was solved =
for base classes</div><div>2. the problem was solved, in C, for member obje=
cts</div><div>3. the problem was solved, in at list gcc, for member objects=
, by declaring them as arrays of zero size.=C2=A0</div></div></div></div></=
blockquote><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><d=
iv class=3D"gmail_quote"><div><br></div><div>it seems to be reasonable that=
there are no insurmountable difficulties.=C2=A0 There's simply too muc=
h prior art to assume it is impossible or even difficult.</div></div></div>=
</div></blockquote></span><div><br>As previously stated, #2 and #3 are non-=
sequiturs for this conversation. </div></div></blockquote><div><br></div><d=
iv>They are not non sequiturs.=C2=A0 They are similar to my case but not ex=
act.=C2=A0 If only things that were in the standard were allowed to be stan=
dardized, we'd never get anywhere.</div></div></div></div></blockquote>=
<div><br>They're non-sequiturs because you clearly said, "I do wan=
t empty types, but they are not zero sized." If you don't want zer=
o-sized types, then bringing up a feature involving zero-sized types is irr=
elevant since that is explicitly not what you're asking for.<br><br>It&=
#39;s like saying that rockets can carry people into space because you'=
ve seen airplanes fly. Even if your conclusion is right, your <i>reasoning<=
/i> is flawed. Airplanes and rockets use very different mechanisms to achie=
ve flight. Just as zero-sized types and base classes are very different mec=
hanisms for achieving things.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That only leaves #1. A=
nd you also clearly state that you haven't looked for such places. And =
therefore, you don't know if the solutions for base classes will work f=
or members. You also don't know if you would need to make other adjustm=
ents that the base class solution didn't need.<br></div></div></blockqu=
ote><div><br></div><div>I don't know, that is why I am asking the colle=
ctive wisdom of this list.=C2=A0 And the answers I'm getting are "=
it's everywhere" and "go look yourself" which are just s=
ymptoms of automatic rejection, not of anyone knowing any actual objection.=
</div></div></div></div></blockquote><div><br>It's very important to un=
derstand how getting features standardized works. You seem to be under the =
impression that there are legions of spec editors just sitting around idle,=
champing at the bit to implement the next good idea someone posts on a for=
um. And so if you post a really good idea, one of them will do all the hard=
work for you.<br><br>That's not how it works. Pretty much <i>nothing</=
i> has ever been added to C++ just by doing that.<br><br>The way to get som=
ething standardized is by actually doing at least some of the work. For a f=
eature like this, one for which careful wording will have to be crafted, yo=
u have to actually be able to demonstrate some knowledge of what the corner=
cases are. If there is some reasonable doubt about it being able to be imp=
lemented, you have to be able to show that it is implementable (and no, bri=
nging up irrelevant other cases is not good enough). And so forth.<br><br>I=
deas are worth <i>nothing</i>; it's <i>effort</i> that gets things done=
.. That's not "automatic rejection"; that's <i>reality</i>=
..<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/01e3e54c-0b77-4d84-9b08-dcb09bbf9eb6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/01e3e54c-0b77-4d84-9b08-dcb09bbf9eb6=
%40isocpp.org</a>.<br />
------=_Part_3619_192570935.1465788588785--
------=_Part_3618_838547301.1465788588785--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 14 Jun 2016 00:32:55 -0700 (PDT)
Raw View
------=_Part_1841_1422867605.1465889575681
Content-Type: multipart/alternative;
boundary="----=_Part_1842_1907624316.1465889575681"
------=_Part_1842_1907624316.1465889575681
Content-Type: text/plain; charset=UTF-8
What you need actually is not EBO. You need a new kind of empty base which
is not an object type. Such a type can with zero size, as a reference whose
size is explicitly unspecified. Then there is no problem about memory
layout, ABI compatibility, pointer arithmetic, etc. (However it can be more
problematic for standardization.)
--
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/c490c50c-15a5-48d6-ac81-c9d06f11b335%40isocpp.org.
------=_Part_1842_1907624316.1465889575681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What you need actually is not EBO. You need a new kind of =
empty base which is not an=20
object type. Such a type can with zero size, as a reference whose size=20
is explicitly unspecified. Then there is no problem about memory layout,
ABI compatibility, pointer arithmetic, etc. (However it can be more=20
problematic for standardization.)<br><br><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c490c50c-15a5-48d6-ac81-c9d06f11b335%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c490c50c-15a5-48d6-ac81-c9d06f11b335=
%40isocpp.org</a>.<br />
------=_Part_1842_1907624316.1465889575681--
------=_Part_1841_1422867605.1465889575681--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 14 Jun 2016 00:41:27 -0700 (PDT)
Raw View
------=_Part_6605_360048416.1465890087281
Content-Type: multipart/alternative;
boundary="----=_Part_6606_2098130927.1465890087282"
------=_Part_6606_2098130927.1465890087282
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=883:38:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity wrote:
>>
>> On Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <arthur....@gmail.com>=
=20
>> wrote:
>>
>>> On Fri, Jun 10, 2016 at 11:13 AM, Avi Kivity <a...@scylladb.com> wrote:
>>>
>>>> On Friday, June 10, 2016 at 8:30:20 PM UTC+3, Thiago Macieira wrote:
>>>>>
>>>>> On sexta-feira, 10 de junho de 2016 09:13:09 PDT Avi Kivity wrote:=20
>>>>> > Note that EBO is actively dangerous. If you inherit from a class=
=20
>>>>> that=20
>>>>> > defines a virtual member function that matches the signature of one=
=20
>>>>> of your=20
>>>>> > own methods, then you end up overriding it for your EBO'd type.=20
>>>>>
>>>>> A class with virtuals is not empty.=20
>>>>>
>>>>
>>>> You don't know that beforehand.
>>>>
>>>> template <class PossiblyEmptyComparator>
>>>> struct my_container;
>>>>
>>>> Should my_container inherit from PossiblyEmptyComparator, or should it=
=20
>>>> contain it as a data member?
>>>>
>>>> What if PossiblyEmptyComparator is a function pointer type?
>>>>
>>>
>>> Now you're no longer talking about EBO, though. You're talking about=20
>>> NEBP: the Non-Empty Base Pessimization. *Obviously* you should never=20
>>> name *anything* as a base class of yours if you don't know what's in=20
>>> it. Library implementors don't do that; why should you?
>>>
>>
>>
>> They do it all the time, with exactly the example I gave. A colleague=
=20
>> hit it recently with boost's binomial heap.
>>
>> Are you suggesting you should never inherit from a template parameter?
>>
>
> As he clearly said, you shouldn't inherit from something you don't know=
=20
> what it is.
> =20
>
>> Because then template classes can choose from:
>>
>> 1. Inheriting from the base class and hitting weird problems
>> 2. Using complex enable_if style solutions
>> 3. Eliding the optimization altogether.
>>
>> This could be so easily solved with=20
>>
>> 4. Adding [[allow_empty_size]] attribute to the data member.
>>
>
> Attributes *are never allowed* to change the behavior of a program.=20
> That's the rule with them. Period.
>
Citation needed. I only remember Herb Sutter claims that attributes should=
=20
never allowed to change the *semantics*.
Both of them are doubtful in the aspect of effect, since they are not=20
requirements in the normative standard text. Even the published standards=
=20
violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think it=
=20
is a defect?
=20
>
>> But I guess we must preserve C++'s reputation for making things hard on=
=20
>> its users.
>> =20
>>
>
>>> Re your comments elsethread: C doesn't have a lot of these "heavy=20
>>> lifting" problems because it *does* allow zero-sized objects and it=20
>>> *doesn't* have a very strong type system the way C++ does. C++'s heavy=
=20
>>> lifting isn't in the machine-level implementation details; there you're=
=20
>>> right that the compilers can just "do what C does." The heavy lifting =
is=20
>>> in the C++-specific stuff: the *high-level semantics*, the *language*.=
=20
>>> That's the hard part.
>>>
>>
>> Then it's totally unreasonable for a compiler newbie like myself to try=
=20
>> and figure them out. But can you explain where in the high level semant=
ics=20
>> a zero sized data member enters at all?
>>
>
> ... Everywhere? Is that a place?
>
> C++ defines an object, first and foremost, as "a region of storage". The=
=20
> entire C++ object model *relies* on that. A zero-sized object is anathema=
=20
> to that definition. You would have to rewrite a lot of the standard befor=
e=20
> you can permit zero-sized objects.
>
--=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/4c147bfa-32e7-458d-94b3-0aeeed0a405e%40isocpp.or=
g.
------=_Part_6606_2098130927.1465890087282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=883:38:05=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Friday, June 10, 2016 at 3:21:50 PM UTC-4, Avi Kivity 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 Fri, Jun 10, 2016 at 10:07 PM, Arthur O'Dwyer <span dir=
=3D"ltr"><<a rel=3D"nofollow">arthur....@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Fri, Jun 10, 2=
016 at 11:13 AM, Avi Kivity <span dir=3D"ltr"><<a rel=3D"nofollow">a...@=
scylladb.com</a>></span> wrote:<br></span><div><div class=3D"gmail_quote=
"><span><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"><span>On Friday, June 10, 2016 at=
8:30:20 PM UTC+3, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex">On sexta-feira, 1=
0 de junho de 2016 09:13:09 PDT Avi Kivity wrote:
<br>> Note that EBO is actively dangerous.=C2=A0 If you inherit from a c=
lass that=20
<br>> defines a virtual member function that matches the signature of on=
e of your=20
<br>> own methods, then you end up overriding it for your EBO'd type=
..
<br>
<br>A class with virtuals is not empty.
<br></blockquote><div><br></div></span><div>You don't know that beforeh=
and.</div><div><br></div><div>template <class PossiblyEmptyComparator>=
;</div><div>struct my_container;</div><div><br></div><div>Should my_contain=
er inherit from PossiblyEmptyComparator, or should it contain it as a data =
member?</div><div><br></div><div>What if PossiblyEmptyComparator is a funct=
ion pointer type?</div></div></blockquote><div><br></div></span><div>Now yo=
u're no longer talking about EBO, though. You're talking about NEBP=
: the Non-Empty Base Pessimization. <i>Obviously</i> you should never name=
=C2=A0<i>anything</i> as a base class of yours if you don't know what&#=
39;s in it. Library implementors don't do that; why should you?</div></=
div></div></div></blockquote><div><br></div><div><br></div><div>They do it =
all the time, with exactly the example I gave.=C2=A0 A colleague hit it rec=
ently with boost's binomial heap.</div><div><br></div><div>Are you sugg=
esting you should never inherit from a template parameter?</div></div></div=
></div></blockquote><div><br>As he clearly said, you shouldn't inherit =
from something you don't know what it is.<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<div>Because then template classes can choose from:</div><div><br></div><di=
v>1. Inheriting from the base class and hitting weird problems</div><div>2.=
Using complex enable_if style solutions</div><div>3. Eliding the optimizat=
ion altogether.</div><div><br></div><div>This could be so easily solved wit=
h=C2=A0</div><div><br></div><div>4. Adding [[allow_empty_size]] attribute t=
o the data member.</div></div></div></div></blockquote><div><br>Attributes =
<i>are never allowed</i> to change the behavior of a program. That's th=
e rule with them. Period.<br></div></div></blockquote><div>Citation needed.=
I only remember Herb Sutter claims that attributes should never allowed to=
change the <i>semantics</i>.<br>Both of them are doubtful in the aspect of=
effect, since they are not requirements in the normative standard text. Ev=
en the published standards violate these rules. Also note [dcl.align] is [d=
cl.attr]. Do you think it is a defect?<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>But I guess we must =
preserve C++'s reputation for making things hard on its users.<br>=C2=
=A0</div></div></div></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=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"><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 class=3D"gmail_quote"><div><br></div><=
div>Re your comments elsethread: C doesn't have a lot of these "he=
avy lifting" problems because it <i>does</i> allow zero-sized objects =
and it <i>doesn't</i> have a very strong type system the way C++ does. =
C++'s heavy lifting isn't in the machine-level implementation detai=
ls; there you're right that the compilers can just "do what C does=
.." =C2=A0The heavy lifting is in the C++-specific stuff: the <i>high-l=
evel semantics</i>, the <i>language</i>. That's the hard part.</div></d=
iv></div></div></blockquote><div><br></div><div></div><div>Then it's to=
tally unreasonable for a compiler newbie like myself to try and figure them=
out.=C2=A0 But can you explain where in the high level semantics a zero si=
zed data member enters at all?<br></div></div></div></div></blockquote><div=
><br>... Everywhere? Is that a place?<br><br>C++ defines an object, first a=
nd foremost, as "a region of storage". The entire C++ object mode=
l <i>relies</i> on that. A zero-sized object is anathema to that definition=
.. You would have to rewrite a lot of the standard before you can permit zer=
o-sized objects.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4c147bfa-32e7-458d-94b3-0aeeed0a405e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c147bfa-32e7-458d-94b3-0aeeed0a405e=
%40isocpp.org</a>.<br />
------=_Part_6606_2098130927.1465890087282--
------=_Part_6605_360048416.1465890087281--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 14 Jun 2016 10:19:56 -0700 (PDT)
Raw View
------=_Part_3864_831103977.1465924796309
Content-Type: multipart/alternative;
boundary="----=_Part_3865_1689962051.1465924796310"
------=_Part_3865_1689962051.1465924796310
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=883:38:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> Attributes *are never allowed* to change the behavior of a program.=20
>> That's the rule with them. Period.
>>
> Citation needed. I only remember Herb Sutter claims that attributes shoul=
d=20
> never allowed to change the *semantics*.
>
Semantics, behavior; it's effectively the same thing: could you tell the=20
difference in the program if the attribute weren't present?
If the answer is yes, then it can't be an attribute. And since=20
attributes-as-behavior/semantics is clearly on Herb Sutter's "over my dead=
=20
body" list, using attributes to change the program's visible behavior is a=
=20
non-starter.
Both of them are doubtful in the aspect of effect, since they are not=20
> requirements in the normative standard text. Even the published standards=
=20
> violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think it=
=20
> is a defect?
>
While `alignas` is grammatically an `attribute-specifier`, it is=20
grammatically *not* an `attribute`. It isn't in an `attribute-list`, so it=
=20
doesn't go within a [[]] pair. So it doesn't count.
--=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/d6375a69-a68b-45a8-8fee-c59cb98b4b2d%40isocpp.or=
g.
------=_Part_3865_1689962051.1465924796310
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989=
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">=E5=9C=
=A8 2016=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=
=B8=8A=E5=8D=883:38:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<block=
quote 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>Attributes <i>are n=
ever allowed</i> to change the behavior of a program. That's the rule w=
ith them. Period.<br></div></div></blockquote><div>Citation needed. I only =
remember Herb Sutter claims that attributes should never allowed to change =
the <i>semantics</i>.<br></div></div></blockquote><div><br>Semantics, behav=
ior; it's effectively the same thing: could you tell the difference in =
the program if the attribute weren't present?<br><br>If the answer is y=
es, then it can't be an attribute. And since attributes-as-behavior/sem=
antics is clearly on Herb Sutter's "over my dead body" list, =
using attributes to change the program's visible behavior is a non-star=
ter.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>Both of them are doubtful in the aspect of effect, since they are=
not requirements in the normative standard text. Even the published standa=
rds violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think =
it is a defect?<br></div></div></blockquote><div><br>While `alignas` is gra=
mmatically an `attribute-specifier`, it is grammatically <i>not</i> an `att=
ribute`. It isn't in an `attribute-list`, so it doesn't go within a=
[[]] pair. So it doesn't count.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d6375a69-a68b-45a8-8fee-c59cb98b4b2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6375a69-a68b-45a8-8fee-c59cb98b4b2d=
%40isocpp.org</a>.<br />
------=_Part_3865_1689962051.1465924796310--
------=_Part_3864_831103977.1465924796309--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Wed, 15 Jun 2016 20:47:28 -0700 (PDT)
Raw View
------=_Part_285_1445584322.1466048848510
Content-Type: multipart/alternative;
boundary="----=_Part_286_971543939.1466048848511"
------=_Part_286_971543939.1466048848511
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD =
UTC+8=E4=B8=8A=E5=8D=883:38:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> Attributes *are never allowed* to change the behavior of a program.=20
>>> That's the rule with them. Period.
>>>
>> Citation needed. I only remember Herb Sutter claims that attributes=20
>> should never allowed to change the *semantics*.
>>
>
> Semantics, behavior; it's effectively the same thing: could you tell the=
=20
> difference in the program if the attribute weren't present?
>
> If the answer is yes, then it can't be an attribute. And since=20
> attributes-as-behavior/semantics is clearly on Herb Sutter's "over my dea=
d=20
> body" list, using attributes to change the program's visible behavior is =
a=20
> non-starter.
>
> For example, in a program with [[noreturn]] used correctly, its existence=
=20
should not change the behavior, but it alters the semantics.
I remember Herb did not like this. Perhaps he should use "behavior" instead=
..
=20
> Both of them are doubtful in the aspect of effect, since they are not=20
>> requirements in the normative standard text. Even the published standard=
s=20
>> violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think i=
t=20
>> is a defect?
>>
>
> While `alignas` is grammatically an `attribute-specifier`, it is=20
> grammatically *not* an `attribute`. It isn't in an `attribute-list`, so=
=20
> it doesn't go within a [[]] pair. So it doesn't count.
>
While I agree with you on the point of grammar, the term "attribute" seems=
=20
to be not only used as a syntactic category.
N4594
7.6 Attributes [dcl.attr]
7.6.1 Attribute syntax and semantics [dcl.attr.grammar]
1 Attributes specify additional information for various source constructs=
=20
such as types, variables, names, blocks, or translation units.
attribute-specifier-seq:
attribute-specifier-seqopt attribute-specifier
attribute-specifier:
[ [ attribute-list ] ]
alignment-specifier
alignment-specifier:
alignas ( type-id ...opt )
alignas ( constant-expression ...opt )
attribute-list:
attributeopt
attribute-list , attributeopt
attribute ...
attribute-list , attribute ...
attribute:
attribute-token attribute-argument-clauseopt
attribute-token:
identifier
attribute-scoped-token
attribute-scoped-token:
attribute-namespace :: identifier
attribute-namespace:
identifier
attribute-argument-clause:
( balanced-token-seqopt )
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seqopt )
[ balanced-token-seqopt ]
{ balanced-token-seqopt }
any token other than a parenthesis, a bracket, or a brace
Perhaps `attribute-list` is more precise to the intention.
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/28393405-f69a-4cd4-8afb-901b2250c1db%40isocpp.or=
g.
------=_Part_286_971543939.1466048848511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 2016=E5=
=B9=B46=E6=9C=8811=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=
=883:38:05=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Attributes <i>are never allowe=
d</i> to change the behavior of a program. That's the rule with them. P=
eriod.<br></div></div></blockquote><div>Citation needed. I only remember He=
rb Sutter claims that attributes should never allowed to change the <i>sema=
ntics</i>.<br></div></div></blockquote><div><br>Semantics, behavior; it'=
;s effectively the same thing: could you tell the difference in the program=
if the attribute weren't present?<br></div></div></blockquote><blockqu=
ote 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><br>If the answe=
r is yes, then it can't be an attribute. And since attributes-as-behavi=
or/<wbr>semantics is clearly on Herb Sutter's "over my dead body&q=
uot; list, using attributes to change the program's visible behavior is=
a non-starter.<br><br></div></div></blockquote><div>For example, in a prog=
ram with [[noreturn]] used correctly, its=20
existence should not change the behavior, but it alters the semantics.<br><=
br>I remember Herb did not like this. Perhaps he should use "behavior&=
quot; instead.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div></div><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>Both of them are doubtful in the aspect of effect, s=
ince they are not requirements in the normative standard text. Even the pub=
lished standards violate these rules. Also note [dcl.align] is [dcl.attr]. =
Do you think it is a defect?<br></div></div></blockquote><div><br>While `al=
ignas` is grammatically an `attribute-specifier`, it is grammatically <i>no=
t</i> an `attribute`. It isn't in an `attribute-list`, so it doesn'=
t go within a [[]] pair. So it doesn't count.</div></div></blockquote><=
div><br>While I agree with you on the point of grammar, the term "attr=
ibute" seems to be not only used as a syntactic category.<br><br>N4594=
<br>7.6 Attributes [dcl.attr]<br>7.6.1 Attribute syntax and semantics [dcl.=
attr.grammar]<br>1 Attributes specify additional information for various so=
urce constructs such as types, variables, names, blocks, or translation uni=
ts.<br><br>attribute-specifier-seq:<br>attribute-specifier-seqopt attribute=
-specifier<br>attribute-specifier:<br>[ [ attribute-list ] ]<br>alignment-s=
pecifier<br>alignment-specifier:<br>alignas ( type-id ...opt )<br>alignas (=
constant-expression ...opt )<br>attribute-list:<br>attributeopt<br>attribu=
te-list , attributeopt<br>attribute ...<br>attribute-list , attribute ...<b=
r>attribute:<br>attribute-token attribute-argument-clauseopt<br>attribute-t=
oken:<br>identifier<br>attribute-scoped-token<br>attribute-scoped-token:<br=
>attribute-namespace :: identifier<br>attribute-namespace:<br>identifier<br=
>attribute-argument-clause:<br>( balanced-token-seqopt )<br>balanced-token-=
seq:<br>balanced-token<br>balanced-token-seq balanced-token<br>balanced-tok=
en:<br>( balanced-token-seqopt )<br>[ balanced-token-seqopt ]<br>{ balanced=
-token-seqopt }<br>any token other than a parenthesis, a bracket, or a brac=
e<br><br>Perhaps `attribute-list` is more precise to the intention.<br>=C2=
=A0<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/28393405-f69a-4cd4-8afb-901b2250c1db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28393405-f69a-4cd4-8afb-901b2250c1db=
%40isocpp.org</a>.<br />
------=_Part_286_971543939.1466048848511--
------=_Part_285_1445584322.1466048848510--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 16 Jun 2016 07:23:29 -0700 (PDT)
Raw View
------=_Part_907_1536332794.1466087009480
Content-Type: multipart/alternative;
boundary="----=_Part_908_1065832577.1466087009480"
------=_Part_908_1065832577.1466087009480
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, June 15, 2016 at 11:47:28 PM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote:
>>
> Both of them are doubtful in the aspect of effect, since they are not=20
>>> requirements in the normative standard text. Even the published standar=
ds=20
>>> violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think =
it=20
>>> is a defect?
>>>
>>
>> While `alignas` is grammatically an `attribute-specifier`, it is=20
>> grammatically *not* an `attribute`. It isn't in an `attribute-list`, so=
=20
>> it doesn't go within a [[]] pair. So it doesn't count.
>>
>
> While I agree with you on the point of grammar, the term "attribute" seem=
s=20
> to be not only used as a syntactic category.
>
If you look at this particular thread of conversation, it is abundantly=20
clear *exactly* what I was referring to when I said "attribute".
Please stop being pointlessly pedantic and derailing the conversation into=
=20
irrelevant issues.
--=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/42db7465-b516-4fae-94e8-1c25d634dbbf%40isocpp.or=
g.
------=_Part_908_1065832577.1466087009480
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, June 15, 2016 at 11:47:28 PM UTC-4, FrankHB1=
989 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">=E5=
=9C=A8 2016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=
=E4=B8=8A=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 14, =
2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote:</div></blockquote></div></bloc=
kquote><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"><block=
quote 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><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>Both of them are doubtful =
in the aspect of effect, since they are not requirements in the normative s=
tandard text. Even the published standards violate these rules. Also note [=
dcl.align] is [dcl.attr]. Do you think it is a defect?<br></div></div></blo=
ckquote><div><br>While `alignas` is grammatically an `attribute-specifier`,=
it is grammatically <i>not</i> an `attribute`. It isn't in an `attribu=
te-list`, so it doesn't go within a [[]] pair. So it doesn't count.=
</div></div></blockquote><div><br>While I agree with you on the point of gr=
ammar, the term "attribute" seems to be not only used as a syntac=
tic category.<br></div></div></blockquote><div><br>If you look at this part=
icular thread of conversation, it is abundantly clear <i>exactly</i> what I=
was referring to when I said "attribute".<br><br>Please stop bei=
ng pointlessly pedantic and derailing the conversation into irrelevant issu=
es.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42db7465-b516-4fae-94e8-1c25d634dbbf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42db7465-b516-4fae-94e8-1c25d634dbbf=
%40isocpp.org</a>.<br />
------=_Part_908_1065832577.1466087009480--
------=_Part_907_1536332794.1466087009480--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 16 Jun 2016 18:31:11 -0700 (PDT)
Raw View
------=_Part_112_910892498.1466127071479
Content-Type: multipart/alternative;
boundary="----=_Part_113_983023074.1466127071480"
------=_Part_113_983023074.1466127071480
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B46=E6=9C=8816=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC=
+8=E4=B8=8B=E5=8D=8810:23:29=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wednesday, June 15, 2016 at 11:47:28 PM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 =
UTC+8=E4=B8=8A=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Tuesday, June 14, 2016 at 3:41:27 AM UTC-4, FrankHB1989 wrote:
>>>
>> Both of them are doubtful in the aspect of effect, since they are not=20
>>>> requirements in the normative standard text. Even the published standa=
rds=20
>>>> violate these rules. Also note [dcl.align] is [dcl.attr]. Do you think=
it=20
>>>> is a defect?
>>>>
>>>
>>> While `alignas` is grammatically an `attribute-specifier`, it is=20
>>> grammatically *not* an `attribute`. It isn't in an `attribute-list`, so=
=20
>>> it doesn't go within a [[]] pair. So it doesn't count.
>>>
>>
>> While I agree with you on the point of grammar, the term "attribute"=20
>> seems to be not only used as a syntactic category.
>>
>
> If you look at this particular thread of conversation, it is abundantly=
=20
> clear *exactly* what I was referring to when I said "attribute".
>
> Please stop being pointlessly pedantic and derailing the conversation int=
o=20
> irrelevant issues.
>
=20
The derailing started from your point: "That's the rule with them. Period."
If you still believe it is valid, go for a new thread in std-discussion.=20
Period.
--=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/5efdd275-abad-416b-9407-1d91907fcdd2%40isocpp.or=
g.
------=_Part_113_983023074.1466127071480
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B46=E6=9C=8816=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=8810:23:29=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Wednesday, June 15, 2016 at 11:47:28 PM UTC-4, FrankHB1989=
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">=E5=9C=A8 2=
016=E5=B9=B46=E6=9C=8815=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=
=E5=8D=881:19:56=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<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 Tuesday, June 14, 2016 at 3=
:41:27 AM UTC-4, FrankHB1989 wrote:</div></blockquote></div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><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><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Both of them are doubtful in the aspect =
of effect, since they are not requirements in the normative standard text. =
Even the published standards violate these rules. Also note [dcl.align] is =
[dcl.attr]. Do you think it is a defect?<br></div></div></blockquote><div><=
br>While `alignas` is grammatically an `attribute-specifier`, it is grammat=
ically <i>not</i> an `attribute`. It isn't in an `attribute-list`, so i=
t doesn't go within a [[]] pair. So it doesn't count.</div></div></=
blockquote><div><br>While I agree with you on the point of grammar, the ter=
m "attribute" seems to be not only used as a syntactic category.<=
br></div></div></blockquote><div><br>If you look at this particular thread =
of conversation, it is abundantly clear <i>exactly</i> what I was referring=
to when I said "attribute".<br><br>Please stop being pointlessly=
pedantic and derailing the conversation into irrelevant issues.<br></div><=
/div></blockquote><div>=C2=A0</div><div>The derailing started from your poi=
nt: "That's the rule with them. Period."<br><br>If you still =
believe it is valid, go for a new thread in std-discussion. Period.<br><br>=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5efdd275-abad-416b-9407-1d91907fcdd2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5efdd275-abad-416b-9407-1d91907fcdd2=
%40isocpp.org</a>.<br />
------=_Part_113_983023074.1466127071480--
------=_Part_112_910892498.1466127071479--
.