Topic: [[empty]] attribute
Author: Alex B <devalexb@gmail.com>
Date: Mon, 25 Nov 2013 12:47:50 -0800 (PST)
Raw View
------=_Part_1654_10459907.1385412470085
Content-Type: text/plain; charset=ISO-8859-1
As we know, the size of an empty class/struct cannot be zero. But there is
the empty base class optimization (EBCO) from which we can benefit when the
type is empty.
There are two problems with it:
- Taking advantage of the EBCO can require quite a lot of changes to the
code. For example, if you have a member variable of an empty type, to be
optimal, you need to derive from it, or put it in a tuple/compressed_pair
along with another variable. This is annoying.
- We cannot benefit from EBCO if the class is final (since we cannot
derrive from a final class).
So why not adding an [[empty]] attribute that could be specified on
variables that could be empty.
template <class T>
struct A
{
T t;
static_assert(!is_empty<A>::value, "");
};
template <class T>
struct B
{
[[empty]] T t;
static_assert(is_empty<B>::value == is_empty<T>::value, "");
};
Typically, member variables for allocators could be declared with this
attribute in container classes:
template <class T, class Alloc>
class vector
{
T *_beg, *_end, *_end_cap;
[[empty]] Alloc _alloc;
/*....*/
And in many other use cases as well (std::tuple for 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1654_10459907.1385412470085
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>As we know, the size of an empty class/struct cannot =
be zero. But there is the empty base class optimization (EBCO) from which w=
e can benefit when the type is empty.</div><div> </div><div>There are =
two problems with it:</div><div>- Taking advantage of the EBCO can require =
quite a lot of changes to the code. For example, if you have a member varia=
ble of an empty type, to be optimal, you need to derive from it, or pu=
t it in a tuple/compressed_pair along with another variable. This is annoyi=
ng.</div><div>- We cannot benefit from EBCO if the class is final (since we=
cannot derrive from a final class).</div><div> </div><div>So why not =
adding an [[empty]] attribute that could be specified on variables that cou=
ld be empty.</div><div> </div><div style=3D"border: 1px solid rgb(187,=
187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);" c=
lass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pret=
tify"><</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-=
prettify">class</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-=
by-prettify"> T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"sty=
led-by-prettify">></span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: rgb(0, 0, 136);" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: rgb(0, 0, 0);" c=
lass=3D"styled-by-prettify"> A<br></span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0,=
0);" class=3D"styled-by-prettify"><br> T t</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify"=
>static_assert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">(!</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styl=
ed-by-prettify">is_empty</span><span style=3D"color: rgb(102, 102, 0);" cla=
ss=3D"styled-by-prettify"><</span><span style=3D"color: rgb(0, 0, 0);" c=
lass=3D"styled-by-prettify">A</span><span style=3D"color: rgb(102, 102, 0);=
" class=3D"styled-by-prettify">>::</span><span style=3D"color: rgb(0, 0,=
0);" class=3D"styled-by-prettify">value</span><span style=3D"color: rgb(10=
2, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(=
0, 136, 0);" class=3D"styled-by-prettify">""</span><span style=3D"color: rg=
b(102, 102, 0);" class=3D"styled-by-prettify">);</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span style=3D"col=
or: rgb(102, 102, 0);" class=3D"styled-by-prettify">};</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">template</span>=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"><</=
span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
> T</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">></span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify"> B<br></span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">[[</span><span style=3D"color: =
rgb(0, 0, 0);" class=3D"styled-by-prettify">empty</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">]]</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T t</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify"=
>static_assert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify">is_empty</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: rgb(0, 0, 0);" cl=
ass=3D"styled-by-prettify">B</span><span style=3D"color: rgb(102, 102, 0);"=
class=3D"styled-by-prettify">>::</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify">value </span><span style=3D"color: rgb(10=
2, 102, 0);" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> is_empty</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"><</span><span=
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">T</span><span =
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">>::</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">value</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> =
</span><span style=3D"color: rgb(0, 136, 0);" class=3D"styled-by-prettify">=
""</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-=
prettify">};</span></div></code></div><div><div> </div><div> </di=
v><div>Typically, member variables for allocators could be declared with th=
is attribute in container classes:</div><div> </div><div> </div><=
/div><div style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord; background-color: rgb(250, 250, 250);" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(=
0, 0, 136);" class=3D"styled-by-prettify">template</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify"><</span><span style=
=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">class</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T</span><span =
style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">class</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: rgb(102, 0, 102);" class=3D"styled-by-prettify">Alloc=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">></span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-pr=
ettify">class</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify"> vector<br></span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br> T </span><span style=3D"color: rg=
b(102, 102, 0);" class=3D"styled-by-prettify">*</span><span style=3D"color:=
rgb(0, 0, 0);" class=3D"styled-by-prettify">_beg</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: rgb(102, 102, 0);" class=3D"styled-by-prettify">*</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">_end</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">_end_cap</span>=
<span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled=
-by-prettify">[[</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify">empty</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"styled-by-prettify">]]</span><span style=3D"color: rgb(0, 0, 0);" class=3D=
"styled-by-prettify"> </span><span style=3D"color: rgb(102, 0, 102);" class=
=3D"styled-by-prettify">Alloc</span><span style=3D"color: rgb(0, 0, 0);" cl=
ass=3D"styled-by-prettify"> _alloc</span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"styled-by-prettify">;</span><span style=3D"color: rgb(0, 0,=
0);" class=3D"styled-by-prettify"><br><br> </span><span style=
=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettify">/*....*/</span></d=
iv></code></div><div> </div><div> </div><div>And in many other us=
e cases as well (std::tuple for example).</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1654_10459907.1385412470085--
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Mon, 25 Nov 2013 21:50:53 +0100
Raw View
2013/11/25 Alex B <devalexb@gmail.com>:
> As we know, the size of an empty class/struct cannot be zero. But there is
> the empty base class optimization (EBCO) from which we can benefit when the
> type is empty.
>
> There are two problems with it:
> - Taking advantage of the EBCO can require quite a lot of changes to the
> code. For example, if you have a member variable of an empty type, to be
> optimal, you need to derive from it, or put it in a tuple/compressed_pair
> along with another variable. This is annoying.
> - We cannot benefit from EBCO if the class is final (since we cannot derrive
> from a final class).
>
> So why not adding an [[empty]] attribute that could be specified on
> variables that could be empty.
>
> template <class T>
> struct A
> {
> T t;
> static_assert(!is_empty<A>::value, "");
> };
>
> template <class T>
> struct B
> {
> [[empty]] T t;
> static_assert(is_empty<B>::value == is_empty<T>::value, "");
> };
>
Is there any other reason for requiring "[[empty]]" instead of just
doing this per default other than ABI compatibility concerns? Is the
latter worth it?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 25 Nov 2013 12:58:41 -0800
Raw View
--001a11332252f8f71104ec06a0ec
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Nov 25, 2013 at 12:50 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
> 2013/11/25 Alex B <devalexb@gmail.com>:
> > As we know, the size of an empty class/struct cannot be zero. But there
> is
> > the empty base class optimization (EBCO) from which we can benefit when
> the
> > type is empty.
> >
> > There are two problems with it:
> > - Taking advantage of the EBCO can require quite a lot of changes to the
> > code. For example, if you have a member variable of an empty type, to be
> > optimal, you need to derive from it, or put it in a tuple/compressed_pair
> > along with another variable. This is annoying.
> > - We cannot benefit from EBCO if the class is final (since we cannot
> derrive
> > from a final class).
> >
> > So why not adding an [[empty]] attribute that could be specified on
> > variables that could be empty.
> >
> > template <class T>
> > struct A
> > {
> > T t;
> > static_assert(!is_empty<A>::value, "");
> > };
> >
> > template <class T>
> > struct B
> > {
> > [[empty]] T t;
> > static_assert(is_empty<B>::value == is_empty<T>::value, "");
> > };
> >
>
> Is there any other reason for requiring "[[empty]]" instead of just
> doing this per default other than ABI compatibility concerns? Is the
> latter worth it?
"[class.mem]p13: Nonstatic data members of a (non-union) class with the
same access control (Clause 11) are allocated so that later members have
higher addresses within a class object."
There exists code that relies on this property. Random example:
typedef std::set<void*> visited;
void visit(visited &v, std::pair<A, B> &x) {
if (visited.insert(&x.first).second)
visit(v, x.first);
if (visited.insert(&x.second).second)
visit(v, x.second);
}
This breaks if x.first and x.second can have the same address.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11332252f8f71104ec06a0ec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Nov 25, 2013 at 12:50 PM, Johannes Schaub <span di=
r=3D"ltr"><<a href=3D"mailto:schaub.johannes@googlemail.com" target=3D"_=
blank">schaub.johannes@googlemail.com</a>></span> wrote:<br><div class=
=3D"gmail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">2013/11/25 Alex B <<a href=
=3D"mailto:devalexb@gmail.com">devalexb@gmail.com</a>>:<br>
<div class=3D"im">> As we know, the size of an empty class/struct cannot=
be zero. But there is<br>
> the empty base class optimization (EBCO) from which we can benefit whe=
n the<br>
> type is empty.<br>
><br>
> There are two problems with it:<br>
> - Taking advantage of the EBCO can require quite a lot of changes to t=
he<br>
> code. For example, if you have a member variable of an empty type, to =
be<br>
> optimal, you need to derive from it, or put it in a tuple/compressed_p=
air<br>
> along with another variable. This is annoying.<br>
> - We cannot benefit from EBCO if the class is final (since we cannot d=
errive<br>
> from a final class).<br>
><br>
> So why not adding an [[empty]] attribute that could be specified on<br=
>
> variables that could be empty.<br>
><br>
> template <class T><br>
> struct A<br>
> {<br>
> =A0 =A0 T t;<br>
> =A0 =A0 static_assert(!is_empty<A>::value, "");<br>
> };<br>
><br>
> template <class T><br>
> struct B<br>
> {<br>
> =A0 =A0 [[empty]] T t;<br>
> =A0 =A0 static_assert(is_empty<B>::value =3D=3D is_empty<T>=
;::value, "");<br>
> };<br>
><br>
<br>
</div>Is there any other reason for requiring "[[empty]]" instead=
of just<br>
doing this per default other than ABI compatibility concerns? Is the<br>
latter worth it?</blockquote><div><br></div><div>"[class.mem]p13: Nons=
tatic data members of a (non-union) class with the same access control (Cla=
use 11) are allocated so that later members have higher addresses within a =
class object."</div>
<div><br></div><div>There exists code that relies on this property. Random =
example:</div><div><br></div><div>typedef std::set<void*> visited;</d=
iv><div>void visit(visited &v, std::pair<A, B> &x) {<br></div=
>
<div>=A0 if (visited.insert(&x.first).second)</div><div>=A0 =A0 visit(v=
, x.first);</div><div>=A0 if (visited.insert(&x.second).second)</div><d=
iv>=A0 =A0 visit(v, x.second);</div><div>}</div><div><br></div><div>This br=
eaks if x.first and x.second can have the same address.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11332252f8f71104ec06a0ec--
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Mon, 25 Nov 2013 19:00:34 -0200
Raw View
Hello,
On Mon, Nov 25, 2013 at 6:50 PM, Johannes Schaub
<schaub.johannes@googlemail.com> wrote:
> 2013/11/25 Alex B <devalexb@gmail.com>:
[snip]
> Is there any other reason for requiring "[[empty]]" instead of just
> doing this per default other than ABI compatibility concerns? Is the
> latter worth it?
The use of [[empty]] would create a class layout that could be
not conformant because I think.
struct B
{
[[empty]] T t;
int x;
};
B b;
assert(&b.t != &b.x);
But I don't think that attributes should be used to allow non-conformant
behavior, right? Maybe a keyword could be used that could make this
rule less strict for certain members.
> ---
Regards,
--
Felipe Magno de Almeida
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 25 Nov 2013 16:34:01 -0500
Raw View
On Mon, Nov 25, 2013 at 3:47 PM, Alex B <devalexb@gmail.com> wrote:
> optimal, you need to derive from it, or put it in a tuple/compressed_pair
> along with another variable. This is annoying.
As a almost unrelated comment: Can we have a std traits like
`is_final`?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alex B <devalexb@gmail.com>
Date: Mon, 25 Nov 2013 17:30:38 -0500
Raw View
--001a1133b05ecdfcb304ec07e918
Content-Type: text/plain; charset=ISO-8859-1
>
> As a almost unrelated comment: Can we have a std traits like
> `is_final`?
>
That would make much sense since most (if not all) C++11 standard library
implementations use such a keyword internally.
In fact, since C++11 there is actually no standard-safe way to benefit form
EBCO without relying to std::tuple (assuming std::tuple is implemented
using with EBCO).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1133b05ecdfcb304ec07e918
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34=
,34)">As a almost unrelated comment: Can we have a std traits like</span><b=
r>
</div>
`is_final`?<br></blockquote><div><br></div><div>That would make much sense =
since most (if not all) C++11 standard library implementations use such a k=
eyword internally.</div><div><br></div><div>In fact, since C++11 there is a=
ctually no standard-safe way to benefit form EBCO without relying to std::t=
uple (assuming std::tuple is implemented using with EBCO).</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133b05ecdfcb304ec07e918--
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 26 Nov 2013 12:30:19 -0500
Raw View
--001a11c353e6abc8e904ec17d53e
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Nov 25, 2013 at 4:00 PM, Felipe Magno de Almeida <
felipe.m.almeida@gmail.com> wrote:
> But I don't think that attributes should be used to allow non-conformant
> behavior, right? Maybe a keyword could be used that could make this
> rule less strict for certain members.
>
If it is true that attributes cannot be made to break the rules, other
options are available. Something like alignas(0) or alignas(void) or
alignas().
But is it true that attributes can't change the behavior? For example,
consider a function which returns. It can have a different (undefined)
behavior if you add the [[noreturn]] attribute to it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c353e6abc8e904ec17d53e
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 25, 2013 at 4:00 PM, Felipe Magno de Almeida <span dir="ltr"><<a href="mailto:felipe.m.almeida@gmail.com" target="_blank">felipe.m.almeida@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But I don't think that attributes should be used to allow non-conformant<br>
behavior, right? Maybe a keyword could be used that could make this<br>
rule less strict for certain members.<br></blockquote><div><br></div><div>If it is true that attributes cannot be made to break the rules, other options are available. Something like alignas(0) or alignas(void) or alignas().</div>
<div><br></div><div>But is it true that attributes can't change the behavior? For example, consider a function which returns. It can have a different (undefined) behavior if you add the [[noreturn]] attribute to it.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--001a11c353e6abc8e904ec17d53e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 26 Nov 2013 10:34:45 -0800
Raw View
--nextPart2521762.lPqptFFm00
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
On ter=E7a-feira, 26 de novembro de 2013 12:30:19, Alex B wrote:
> If it is true that attributes cannot be made to break the rules, othe=
r
> options are available. Something like alignas(0) or alignas(void) or
> alignas().
Maybe we should try to start with the problem you're trying to solve. T=
he OP=20
started with a proposal for a change, and discussed how one can today=20=
accomplish empty members, but you didn't explain why empty members are =
useful.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart2521762.lPqptFFm00
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSlOnLM/XwBW70U1gRAnLzAJ9SNUa9Fu8uwbT39Zn4XeUDvVYi6wCeNlGa
Uv/gwuIyzu4QQ8BSWWDVDwY=
=6lvD
-----END PGP SIGNATURE-----
--nextPart2521762.lPqptFFm00--
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 26 Nov 2013 13:49:04 -0500
Raw View
--047d7b3a84444d428e04ec18ef58
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
It is to optimize usage of empty types. It is a very common need in generic
code. This is what the EBCO optimization already does but complicates the
code quite a bit and unfortunately cannot always be applied since C++11
(since final classes are part of the standard).
The standard library use the EBCO technique in many places. See an
implementation of std::tuple of any of the main implementations. All the
standard containers are also optimized for empty allocators (the default
allocator is empty by the way). There are also empty functors in
associative containers.
On Tue, Nov 26, 2013 at 1:34 PM, Thiago Macieira <thiago@macieira.org>wrote=
:
> On ter=E7a-feira, 26 de novembro de 2013 12:30:19, Alex B wrote:
> > If it is true that attributes cannot be made to break the rules, other
> > options are available. Something like alignas(0) or alignas(void) or
> > alignas().
>
> Maybe we should try to start with the problem you're trying to solve. The
> OP
> started with a proposal for a change, and discussed how one can today
> accomplish empty members, but you didn't explain why empty members are
> useful.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b3a84444d428e04ec18ef58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It is to optimize usage of empty types. It is a very commo=
n need in generic code. This is what the EBCO optimization already does but=
complicates the code quite a bit and unfortunately cannot always be applie=
d since C++11 (since final classes are part of the standard).<div>
<br></div><div>The standard library use the EBCO technique in many places. =
See an implementation of std::tuple of any of the main implementations. All=
the standard containers are also optimized for empty allocators (the defau=
lt allocator is empty by the way). There are also empty functors in associa=
tive containers.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Nov 2=
6, 2013 at 1:34 PM, Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto=
:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On ter=E7a-feira, 26 de no=
vembro de 2013 12:30:19, Alex B wrote:<br>
> If it is true that attributes cannot be made to break the rules, other=
<br>
> options are available. Something like alignas(0) or alignas(void) or<b=
r>
> alignas().<br>
<br>
</div>Maybe we should try to start with the problem you're trying to so=
lve. The OP<br>
started with a proposal for a change, and discussed how one can today<br>
accomplish empty members, but you didn't explain why empty members are =
useful.<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b3a84444d428e04ec18ef58--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 26 Nov 2013 13:05:48 -0600
Raw View
--047d7beb9b5c8b668f04ec192da3
Content-Type: text/plain; charset=ISO-8859-1
On 26 November 2013 12:49, Alex B <devalexb@gmail.com> wrote:
> It is to optimize usage of empty types. It is a very common need in
> generic code. This is what the EBCO optimization already does but
> complicates the code quite a bit and unfortunately cannot always be applied
> since C++11 (since final classes are part of the standard).
>
While the standard allows users to define their classes as final, I do not
know of any final classes in the standard. What standard library classes
are you thinking of?
What is the use case for an empty class marked final? It doesn't seem
common enough to warrant a language feature.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7beb9b5c8b668f04ec192da3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 26 November 2013 12:49, Alex B <span dir=3D"ltr"><<a=
href=3D"mailto:devalexb@gmail.com" target=3D"_blank">devalexb@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 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It is to optimize usage of empty types. It is a very commo=
n need in generic code. This is what the EBCO optimization already does but=
complicates the code quite a bit and unfortunately cannot always be applie=
d since C++11 (since final classes are part of the standard).</div>
</blockquote><div><br></div><div>While the standard allows users to define =
their classes as final, I do not know of any final classes in the standard.=
=A0 What standard library classes are you thinking of?<br><br></div><div>
What is the use case for an empty class marked final?=A0 It doesn't see=
m common enough to warrant a language feature.<br></div></div>-- <br>=A0Nev=
in ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord=
..com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7beb9b5c8b668f04ec192da3--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 26 Nov 2013 21:15:23 +0200
Raw View
On 26 November 2013 21:05, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 26 November 2013 12:49, Alex B <devalexb@gmail.com> wrote:
>>
>> It is to optimize usage of empty types. It is a very common need in
>> generic code. This is what the EBCO optimization already does but
>> complicates the code quite a bit and unfortunately cannot always be applied
>> since C++11 (since final classes are part of the standard).
>
>
> While the standard allows users to define their classes as final, I do not
> know of any final classes in the standard. What standard library classes
> are you thinking of?
>
> What is the use case for an empty class marked final? It doesn't seem
> common enough to warrant a language feature.
We have had non-standard classes that can't be derived from long before
final was introduced.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Tue, 26 Nov 2013 17:28:21 -0200
Raw View
On Tue, Nov 26, 2013 at 4:34 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On ter=E7a-feira, 26 de novembro de 2013 12:30:19, Alex B wrote:
>> If it is true that attributes cannot be made to break the rules, other
>> options are available. Something like alignas(0) or alignas(void) or
>> alignas().
>
> Maybe we should try to start with the problem you're trying to solve. The=
OP
> started with a proposal for a change, and discussed how one can today
> accomplish empty members, but you didn't explain why empty members are us=
eful.
Empty members are very common with generic libraries, the STL included. It =
is
very common for allocators to be empty classes and if any container that us=
es
a allocator must, currently, use EBCO to optimize the container's size for =
when
allocators are empty. It would be really useful to be able to optimize any =
empty
members, somehow. Also, EBCO is very limited because you can't optimize
two empty members on the same compressed_pair.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
Felipe Magno de Almeida
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 26 Nov 2013 14:41:24 -0500
Raw View
--047d7b2e431c775c7204ec19aa2d
Content-Type: text/plain; charset=ISO-8859-1
class MyAlloc final
{
/*...*/
}; // MyAlloc is empty
Here, sizeof(std::vector<int, MyAlloc>) is bigger than
sizeof(std::vector<int>).
The EBCO cannot be used on the allocator because it is final.
But that is not my point; I admit that this is a pretty rare corner case
that might not be worth optimizing (why would someone make a final
allocator?). My first point is that the EBCO cannot be safely used *at all* in
user-defined generic code (unless using a tuple). If I define my own
container class, I don't even have a standard way to tell if a type T is
final or not, hence I cannot safely derive from the type and benefit from
the EBCO.
Second point (most important) is that it would be so much simpler than
current EBCO techniques...
Let's say I write a container class:
template <class T, class Alloc = std::allocator<T>>
class MyContainer
{
using BaseNode = /*...*/;
BaseNode* _base;
Alloc _alloc;
};
Now someone else look at the class and say hey, let's optimize the size of
the class since Alloc will most of the time be empty.
template <class T, class Alloc = std::allocator<T>>
class MyContainer
{
using BaseNode = /*...*/;
std::tuple<BaseNode*, Alloc> _base_and_alloc;
};
That will work but it will be a pain to change because all accesses to
_base and _alloc need to be modified for std::get<0>(_base_and_alloc) and
std::get<1>(_base_and_alloc).
Really, an attribute would be so much simpler...
On Tue, Nov 26, 2013 at 2:05 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 26 November 2013 12:49, Alex B <devalexb@gmail.com> wrote:
>
>> It is to optimize usage of empty types. It is a very common need in
>> generic code. This is what the EBCO optimization already does but
>> complicates the code quite a bit and unfortunately cannot always be applied
>> since C++11 (since final classes are part of the standard).
>>
>
> While the standard allows users to define their classes as final, I do not
> know of any final classes in the standard. What standard library classes
> are you thinking of?
>
> What is the use case for an empty class marked final? It doesn't seem
> common enough to warrant a language feature.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NEVhwtZuI1g/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b2e431c775c7204ec19aa2d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font face=3D"courier new, monospace">class MyAlloc final<=
/font><div><font face=3D"courier new, monospace">{</font></div><div><font f=
ace=3D"courier new, monospace">=A0 =A0/*...*/</font></div><div><font face=
=3D"courier new, monospace">}; // MyAlloc is empty</font></div>
<div><br></div><div>Here, sizeof(std::vector<int, MyAlloc>) is bigger=
than sizeof(std::vector<int>).</div><div>The EBCO cannot be used on =
the allocator because it is final.</div><div><br></div><div>But that is not=
my point; I admit that this is a pretty rare corner case that might not be=
worth optimizing (why would someone make a final allocator?). My first poi=
nt is that the EBCO cannot be safely used=A0<i>at all</i>=A0in user-defined=
generic code (unless using a tuple). If I define my own container class, I=
don't even have a standard way to tell if a type T is final or not, he=
nce I cannot safely derive from the type and benefit from the EBCO.</div>
<div><br></div><div>Second point (most important) is that it would be so mu=
ch simpler than current EBCO techniques...</div><div><br></div><div>Let'=
;s say I write a container class:</div><div><br></div><blockquote style=3D"=
margin:0 0 0 40px;border:none;padding:0px">
<div><font face=3D"courier new, monospace">template <class T, class Allo=
c =3D std::allocator<T>></font></div><div><font face=3D"courier ne=
w, monospace">class MyContainer</font></div><div><font face=3D"courier new,=
monospace">{</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 using BaseNode =3D /*...=
*/;</font></div><div><font face=3D"courier new, monospace">=A0 =A0 BaseNode=
* _base;</font></div><div><font face=3D"courier new, monospace">=A0 =A0 All=
oc _alloc;</font></div>
<div><font face=3D"courier new, monospace">};</font></div></blockquote><div=
><br></div><div>Now someone else look at the class and say hey, let's o=
ptimize the size of the class since Alloc will most of the time be empty.</=
div>
<div><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0=
px"><div><div><font face=3D"courier new, monospace">template <class T, c=
lass Alloc =3D std::allocator<T>></font></div></div><div><div><fon=
t face=3D"courier new, monospace">class MyContainer</font></div>
</div><div><div><font face=3D"courier new, monospace">{</font></div></div><=
div><div><font face=3D"courier new, monospace">=A0 =A0 using BaseNode =3D /=
*...*/;</font></div></div><div><div><font face=3D"courier new, monospace">=
=A0 =A0 std::tuple<BaseNode*, Alloc> _base_and_alloc;</font></div>
</div><div><div><font face=3D"courier new, monospace">};</font></div></div>=
</blockquote><div><br></div><div>That will work but it will be a pain to ch=
ange because all accesses to _base and _alloc need to be modified for std::=
get<0>(_base_and_alloc) and std::get<1>(_base_and_alloc).</div>
<div><br></div><div>Really, an attribute would be so much simpler...</div><=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, =
Nov 26, 2013 at 2:05 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"mailt=
o:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>><=
/span> wrote:<br>
<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 class=3D"im">On 26 Nov=
ember 2013 12:49, Alex B <span dir=3D"ltr"><<a href=3D"mailto:devalexb@g=
mail.com" target=3D"_blank">devalexb@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"i=
m"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It is to optimize usage of empty types. It is a very commo=
n need in generic code. This is what the EBCO optimization already does but=
complicates the code quite a bit and unfortunately cannot always be applie=
d since C++11 (since final classes are part of the standard).</div>
</blockquote><div><br></div></div><div>While the standard allows users to d=
efine their classes as final, I do not know of any final classes in the sta=
ndard.=A0 What standard library classes are you thinking of?<br><br></div>
<div>
What is the use case for an empty class marked final?=A0 It doesn't see=
m common enough to warrant a language feature.<span class=3D"HOEnZb"><font =
color=3D"#888888"><br></font></span></div></div><span class=3D"HOEnZb"><fon=
t color=3D"#888888">-- <br>
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a href=3D"=
tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 69=
1-1404</a>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/NEVhwtZuI1g/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/NEVhwtZuI1g=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b2e431c775c7204ec19aa2d--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 26 Nov 2013 13:54:00 -0600
Raw View
--f46d04389569f170a804ec19d9a2
Content-Type: text/plain; charset=ISO-8859-1
On 26 November 2013 13:41, Alex B <devalexb@gmail.com> wrote:
> class MyAlloc final
> {
> /*...*/
> }; // MyAlloc is empty
>
I understand that people *can* write final empty allocators, but I don't
understand *why* they would do so (other than "because it is possible").
>
> If I define my own container class, I don't even have a standard way to
> tell if a type T is final or not, hence I cannot safely derive from the
> type and benefit from the EBCO.
>
Oh, I'd like a trait to know whether or not one can derive from a type or
not.
>
> Second point (most important) is that it would be so much simpler than
> current EBCO techniques...
>
Agreed, as long as it doesn't run afowl of the increasing address rule that
Richard Smith pointed out.
> Really, an attribute would be so much simpler...
>
Why would I even want an attribute? In all but the rarest of circumstances
(again, those reliant on increasing addresses) I would want the unneeded
space optimized away.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d04389569f170a804ec19d9a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 26 November 2013 13:41, Alex B <span dir=3D"ltr"><<a=
href=3D"mailto:devalexb@gmail.com" target=3D"_blank">devalexb@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 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><font face=3D"courier new, monospace">class MyAlloc final<=
/font><div><font face=3D"courier new, monospace">{</font></div><div><font f=
ace=3D"courier new, monospace">=A0 =A0/*...*/</font></div><div><font face=
=3D"courier new, monospace">}; // MyAlloc is empty</font></div>
</div></blockquote><div><br></div><div>I understand that people <i>can</i> =
write final empty allocators, but I don't understand <i>why</i> they wo=
uld do so (other than "because it is possible"). <br></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><br></div>If I define my own container class, I don't even have a =
standard way to tell if a type T is final or not, hence I cannot safely der=
ive from the type and benefit from the EBCO.
</div></blockquote><div><br></div><div>Oh, I'd like a trait to know whe=
ther or not one can derive from a type or not. <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div><br></div><div>Second point (most important) is that =
it would be so much simpler than current EBCO techniques...</div></div></bl=
ockquote><div class=3D"gmail_quote"><br>Agreed, as long as it doesn't r=
un afowl of the increasing address rule that Richard Smith pointed out.<div=
>
=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>Really, an at=
tribute would be so much simpler...</div></div></blockquote><div><br></div>=
<div>
Why would I even want an attribute?=A0 In all but the rarest of circumstanc=
es (again, those reliant on increasing addresses) I would want the unneeded=
space optimized away.<br></div></div></div>-- <br>=A0Nevin ":-)"=
Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_b=
lank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d04389569f170a804ec19d9a2--
.
Author: Alex B <devalexb@gmail.com>
Date: Tue, 26 Nov 2013 15:02:13 -0500
Raw View
--047d7b10d06be86db604ec19f422
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> Why would I even want an attribute? In all but the rarest of
> circumstances (again, those reliant on increasing addresses) I would want
> the unneeded space optimized away.
>
>
I agree with you, and this goes in line with what Johannes posted as well.
But as Richard pointed out, we cannot change the default to allow this
optimization without any side-effect.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b10d06be86db604ec19f422
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 26, 2013 at 2:54 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br>
<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 class=3D"im"><br></div=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"gmail_=
quote"><div>
Why would I even want an attribute?=A0 In all but the rarest of circumstanc=
es (again, those reliant on increasing addresses) I would want the unneeded=
space optimized away.<br></div></div></div><div class=3D"im"><br></div></d=
iv>
</div></blockquote><div><br></div><div>I agree with you, and this goes in l=
ine with what Johannes posted as well.</div><div>But as Richard pointed out=
, we cannot change the default to allow this optimization without any side-=
effect.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b10d06be86db604ec19f422--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 26 Nov 2013 15:49:40 -0500
Raw View
On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> I understand that people can write final empty allocators, but I don't
> understand why they would do so (other than "because it is possible").
I don' understand either. AFAIK `final` only helps polymorphic
class (if not, we may want to add `final` everywhere in STL), and
a polymorphic class can not be empty :(
> Oh, I'd like a trait to know whether or not one can derive from a type or
> not.
Ditto. Different from is_final, this will include non-class types.
But looks more useful.
>> Really, an attribute would be so much simpler...
>
> Why would I even want an attribute? In all but the rarest of circumstances
> (again, those reliant on increasing addresses) I would want the unneeded
> space optimized away.
We just can't make such an attribute; attribute can not
change a program's observable behavior.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 26 Nov 2013 13:11:05 -0800
Raw View
--089e01294cf22bfea104ec1aeb1b
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <zy@miator.net> wrote:
> On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > I understand that people can write final empty allocators, but I don't
> > understand why they would do so (other than "because it is possible").
>
> I don' understand either. AFAIK `final` only helps polymorphic
> class (if not, we may want to add `final` everywhere in STL), and
> a polymorphic class can not be empty :(
>
> > Oh, I'd like a trait to know whether or not one can derive from a type or
> > not.
>
> Ditto. Different from is_final, this will include non-class types.
> But looks more useful.
>
> >> Really, an attribute would be so much simpler...
> >
> > Why would I even want an attribute? In all but the rarest of
> circumstances
> > (again, those reliant on increasing addresses) I would want the unneeded
> > space optimized away.
>
> We just can't make such an attribute; attribute can not
> change a program's observable behavior.
An attribute could change a program's observable behavior, and many of the
vendor-specific C++11 attributes do. The question is whether the committee
would allow an attribute that changes the program's observable behavior to
be standardized. Some committee members have been opposed to this before,
but to my knowledge the committee has not agreed that no standard attribute
will ever change a program's behavior.
If we want a rule, I think it should be that an attribute may only
*generalize* a program's observable behavior. More precisely:
Suppose the set of possible behaviors of the program using an attribute
is X.
If all instances of an attribute are ignored, the set of possible
behaviors of the program must be a subset of X.
In particular: an attribute can introduce undefined behavior (as
[[noreturn]] does), and an attribute can change the ABI (as
[[carries_dependency]] would on some platforms), but attributes are always
backwards-compatible with implementations that didn't support them, so long
as you recompile the entire program. [[empty]] would satisfy this criterion
(as would all three current standard attributes).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e01294cf22bfea104ec1aeb1b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <span dir=3D=
"ltr"><<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net<=
/a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber <<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:<br=
>
> I understand that people can write final empty allocators, but I don&#=
39;t<br>
> understand why they would do so (other than "because it is possib=
le").<br>
<br>
</div>I don' understand either. =A0AFAIK `final` only helps polymorphic=
<br>
class (if not, we may want to add `final` everywhere in STL), and<br>
a polymorphic class can not be empty :(<br>
<div class=3D"im"><br>
> Oh, I'd like a trait to know whether or not one can derive from a =
type or<br>
> not.<br>
<br>
</div>Ditto. =A0Different from is_final, this will include non-class types.=
<br>
But looks more useful.<br>
<div class=3D"im"><br>
>> Really, an attribute would be so much simpler...<br>
><br>
> Why would I even want an attribute? =A0In all but the rarest of circum=
stances<br>
> (again, those reliant on increasing addresses) I would want the unneed=
ed<br>
> space optimized away.<br>
<br>
</div>We just can't make such an attribute; attribute can not<br>
change a program's observable behavior.</blockquote><div><br></div><div=
>An attribute could change a program's observable behavior, and many of=
the vendor-specific C++11 attributes do. The question is whether the commi=
ttee would allow an attribute that changes the program's observable beh=
avior to be standardized. Some committee members have been opposed to this =
before, but to my knowledge the committee has not agreed that no standard a=
ttribute will ever change a program's behavior.</div>
<div><br></div><div>If we want a rule, I think it should be that an attribu=
te may only *generalize* a program's observable behavior. More precisel=
y:</div><div>=A0 Suppose the set of possible behaviors of the program using=
an attribute is X.=A0</div>
<div>=A0 If all instances of an attribute are ignored, the set of possible =
behaviors of the program must be a subset of X.</div><div><br></div><div>In=
particular: an attribute can introduce undefined behavior (as [[noreturn]]=
does), and an attribute can change the ABI (as [[carries_dependency]] woul=
d on some platforms), but attributes are always backwards-compatible with i=
mplementations that didn't support them, so long as you recompile the e=
ntire program. [[empty]] would satisfy this criterion (as would all three c=
urrent standard attributes).</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01294cf22bfea104ec1aeb1b--
.
Author: Marc <marc.glisse@gmail.com>
Date: Tue, 26 Nov 2013 13:17:20 -0800 (PST)
Raw View
------=_Part_35_18050119.1385500641117
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le lundi 25 novembre 2013 21:58:41 UTC+1, Richard Smith a =E9crit :
> > So why not adding an [[empty]] attribute that could be specified on
>> > variables that could be empty.
>>
>
An interesting way of working around the paragraph quoted below, though I=
=20
think I would like to also have the possibility of specifying the attribute=
=20
on the class (meaning on all members).
Is there any other reason for requiring "[[empty]]" instead of just
>> doing this per default other than ABI compatibility concerns? Is the
>> latter worth it?
>
>
> "[class.mem]p13: Nonstatic data members of a (non-union) class with the=
=20
> same access control (Clause 11) are allocated so that later members have=
=20
> higher addresses within a class object."
>
> There exists code that relies on this property. Random example:
>
> typedef std::set<void*> visited;
> void visit(visited &v, std::pair<A, B> &x) {
> if (visited.insert(&x.first).second)
> visit(v, x.first);
> if (visited.insert(&x.second).second)
> visit(v, x.second);
> }
>
> This breaks if x.first and x.second can have the same address.
>
The same technique fails to work with a std::tuple. Did you really see such=
=20
code in the wild? Sadly, it doesn't seem easy to warn about uses that could=
=20
break without a lot of false positives.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_35_18050119.1385500641117
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le lundi 25 novembre 2013 21:58:41 UTC+1, Richard Smith a =
=E9crit :<br><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"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div>
> So why not adding an [[empty]] attribute that could be specified on<br=
>
> variables that could be empty.<br></div></blockquote></div></div></div=
></blockquote><div><br>An interesting way of working around the paragraph q=
uoted below, though I think I would like to also have the possibility of sp=
ecifying the attribute on the class (meaning on all members).<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><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">Is there any other reason for requiring=
"[[empty]]" instead of just<br>
doing this per default other than ABI compatibility concerns? Is the<br>
latter worth it?</blockquote><div><br></div><div>"[class.mem]p13: Nonstatic=
data members of a (non-union) class with the same access control (Clause 1=
1) are allocated so that later members have higher addresses within a class=
object."</div>
<div><br></div><div>There exists code that relies on this property. Random =
example:</div><div><br></div><div>typedef std::set<void*> visited;</d=
iv><div>void visit(visited &v, std::pair<A, B> &x) {<br></div=
>
<div> if (visited.insert(&x.first).<wbr>second)</div><div> =
visit(v, x.first);</div><div> if (visited.insert(&x.second=
).<wbr>second)</div><div> visit(v, x.second);</div><div>}</div=
><div><br></div><div>This breaks if x.first and x.second can have the same =
address.</div></div></div></div></blockquote><div><br>The same technique fa=
ils to work with a std::tuple. Did you really see such code in the wild? Sa=
dly, it doesn't seem easy to warn about uses that could break without a lot=
of false positives.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_35_18050119.1385500641117--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 26 Nov 2013 16:14:57 -0800
Raw View
--nextPart3062202.8GRkkCvBTT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
On ter=E7a-feira, 26 de novembro de 2013 13:11:05, Richard Smith wrote:=
> In particular: an attribute can introduce undefined behavior (as
> [[noreturn]] does), and an attribute can change the ABI (as
> [[carries_dependency]] would on some platforms), but attributes are a=
lways
> backwards-compatible with implementations that didn't support them, s=
o long
> as you recompile the entire program. [[empty]] would satisfy this cri=
terion
> (as would all three current standard attributes).
[[noreturn]] does not change the behaviour. It's a hint to the compiler=
,=20
letting it know that this function does *not* return anyway so it may o=
ptimise=20
the code after it away.
The change in behaviour is if you make a noreturn function actually ret=
urn.=20
It's not the fault of the compiler if you lied.
The same applies to [[gnu::const]] and [[gnu::pure]]: it's a hint to th=
e=20
compiler about what the function already does. Lying to the compiler is=
always=20
a bad idea.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart3062202.8GRkkCvBTT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSlTmCM/XwBW70U1gRAhAJAJ0f2zC8NavwhCoNwRZyxyn8PaZ09wCfW4uJ
7rW/Ld2a2XwzAttyV0ag43c=
=JyI5
-----END PGP SIGNATURE-----
--nextPart3062202.8GRkkCvBTT--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 26 Nov 2013 16:26:48 -0800
Raw View
--001a11c2ae7620ddad04ec1da711
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 26, 2013 at 4:14 PM, Thiago Macieira <thiago@macieira.org>wrote=
:
> On ter=E7a-feira, 26 de novembro de 2013 13:11:05, Richard Smith wrote:
> > In particular: an attribute can introduce undefined behavior (as
> > [[noreturn]] does), and an attribute can change the ABI (as
> > [[carries_dependency]] would on some platforms), but attributes are
> always
> > backwards-compatible with implementations that didn't support them, so
> long
> > as you recompile the entire program. [[empty]] would satisfy this
> criterion
> > (as would all three current standard attributes).
>
> [[noreturn]] does not change the behaviour. It's a hint to the compiler,
> letting it know that this function does *not* return anyway so it may
> optimise
> the code after it away.
>
> The change in behaviour is if you make a noreturn function actually retur=
n.
> It's not the fault of the compiler if you lied.
>
Why should it matter how we can apportion blame? This is still a change in
behavior caused by adding the attribute.
This program has defined behavior and prints "hello world":
#include <stdio.h>
void f() {}
int main() {
f();
puts("hello world");
}
void g() {
puts("nasal demons");
}
On my implementation, if I mark 'f' as [[noreturn]], it instead prints
"nasal demons". The attribute has *changed* the set of meanings of the
program from {print "hello world"} to the set of all possible meanings (aka
"undefined behavior"). That's a pretty huge change in behavior.
The same applies to [[gnu::const]] and [[gnu::pure]]: it's a hint to the
> compiler about what the function already does. Lying to the compiler is
> always
> a bad idea.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2ae7620ddad04ec1da711
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Nov 26, 2013 at 4:14 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On ter=E7a-feira, 26 de no=
vembro de 2013 13:11:05, Richard Smith wrote:<br>
> In particular: an attribute can introduce undefined behavior (as<br>
> [[noreturn]] does), and an attribute can change the ABI (as<br>
> [[carries_dependency]] would on some platforms), but attributes are al=
ways<br>
> backwards-compatible with implementations that didn't support them=
, so long<br>
> as you recompile the entire program. [[empty]] would satisfy this crit=
erion<br>
> (as would all three current standard attributes).<br>
<br>
</div>[[noreturn]] does not change the behaviour. It's a hint to the co=
mpiler,<br>
letting it know that this function does *not* return anyway so it may optim=
ise<br>
the code after it away.<br>
<br>
The change in behaviour is if you make a noreturn function actually return.=
<br>
It's not the fault of the compiler if you lied.<br></blockquote><div><b=
r></div><div>Why should it matter how we can apportion blame? This is still=
a change in behavior caused by adding the attribute.</div><div><br></div>
<div>This program has defined behavior and prints "hello world":<=
/div><div><br></div><div>#include <stdio.h></div><div>void f() {}</di=
v><div>int main() {</div><div>=A0 f();</div><div>=A0 puts("hello world=
");</div>
<div>}</div><div>void g() {</div><div>=A0 puts("nasal demons");</=
div><div>}</div><div><br></div><div>On my implementation, if I mark 'f&=
#39; as [[noreturn]], it instead prints "nasal demons". The attri=
bute has *changed* the set of meanings of the program from {print "hel=
lo world"} to the set of all possible meanings (aka "undefined be=
havior"). That's a pretty huge change in behavior.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
The same applies to [[gnu::const]] and [[gnu::pure]]: it's a hint to th=
e<br>
compiler about what the function already does. Lying to the compiler is alw=
ays<br>
a bad idea.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2ae7620ddad04ec1da711--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Tue, 26 Nov 2013 18:57:38 -0600
Raw View
Richard Smith <richard@metafoo.co.uk> writes:
| On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <zy@miator.net> wrote:
|=20
| On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber
| <nevin@eviloverlord.com> wrote:
| > I understand that people can write final empty allocators, but I
| don't
| > understand why they would do so (other than "because it is
| possible").
| =20
| =20
| I don' understand either. =A0AFAIK `final` only helps polymorphic
| class (if not, we may want to add `final` everywhere in STL), and
| a polymorphic class can not be empty :(
| =20
| =20
| > Oh, I'd like a trait to know whether or not one can derive from
| a type or
| > not.
| =20
| =20
| Ditto. =A0Different from is_final, this will include non-class
| types.
| But looks more useful.
| =20
| =20
| >> Really, an attribute would be so much simpler...
| >
| > Why would I even want an attribute? =A0In all but the rarest of
| circumstances
| > (again, those reliant on increasing addresses) I would want the
| unneeded
| > space optimized away.
| =20
| =20
| We just can't make such an attribute; attribute can not
| change a program's observable behavior.
|=20
|=20
| An attribute could change a program's observable behavior, and many of
| the vendor-specific C++11 attributes do. The question is whether the
| committee would allow an attribute that changes the program's
| observable behavior to be standardized. Some committee members have
| been opposed to this before, but to my knowledge the committee has not
| agreed that no standard attribute will ever change a program's
| behavior.
In reality, the actual position was/is far more nuanced than that.
The gentlement agreement, and the general understanding, for voting
attributes into C++11 was that if a program P with attribute A is
well-formed and has a defined meaning, then the P' obtained from
P ignoring attribute A should be well-formed with equivalent meaning.
-- Gaby
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 26 Nov 2013 17:15:00 -0800
Raw View
--047d7bd6b4b27f785e04ec1e533b
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 26, 2013 at 4:57 PM, Gabriel Dos Reis <gdr@axiomatics.org>wrote:
> Richard Smith <richard@metafoo.co.uk> writes:
>
> | On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <zy@miator.net> wrote:
> |
> | On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber
> | <nevin@eviloverlord.com> wrote:
> | > I understand that people can write final empty allocators, but I
> | don't
> | > understand why they would do so (other than "because it is
> | possible").
> |
> |
> | I don' understand either. AFAIK `final` only helps polymorphic
> | class (if not, we may want to add `final` everywhere in STL), and
> | a polymorphic class can not be empty :(
> |
> |
> | > Oh, I'd like a trait to know whether or not one can derive from
> | a type or
> | > not.
> |
> |
> | Ditto. Different from is_final, this will include non-class
> | types.
> | But looks more useful.
> |
> |
> | >> Really, an attribute would be so much simpler...
> | >
> | > Why would I even want an attribute? In all but the rarest of
> | circumstances
> | > (again, those reliant on increasing addresses) I would want the
> | unneeded
> | > space optimized away.
> |
> |
> | We just can't make such an attribute; attribute can not
> | change a program's observable behavior.
> |
> |
> | An attribute could change a program's observable behavior, and many of
> | the vendor-specific C++11 attributes do. The question is whether the
> | committee would allow an attribute that changes the program's
> | observable behavior to be standardized. Some committee members have
> | been opposed to this before, but to my knowledge the committee has not
> | agreed that no standard attribute will ever change a program's
> | behavior.
>
> In reality, the actual position was/is far more nuanced than that.
>
> The gentlement agreement, and the general understanding, for voting
> attributes into C++11 was that if a program P with attribute A is
> well-formed and has a defined meaning, then the P' obtained from
> P ignoring attribute A should be well-formed with equivalent meaning.
>
Thanks.
I think this rule is too strict -- "equivalent meaning" is sufficient, but
not necessary. In general, we have a set of denotations for P, and all that
seems necessary is that the denotations for P' are a subset of those for P,
not that they are the same (this also removes the need for a "defined
meaning" clause).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd6b4b27f785e04ec1e533b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Nov 26, 2013 at 4:57 PM, Gabriel Dos Reis <span di=
r=3D"ltr"><<a href=3D"mailto:gdr@axiomatics.org" target=3D"_blank">gdr@a=
xiomatics.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">Rich=
ard Smith <<a href=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.u=
k</a>> writes:<br>
<br>
| On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <<a href=3D"mailto:zy@mi=
ator.net">zy@miator.net</a>> wrote:<br>
|<br>
| =A0 =A0 On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber<br>
| =A0 =A0 <<a href=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.=
com</a>> wrote:<br>
| =A0 =A0 > I understand that people can write final empty allocators, b=
ut I<br>
| =A0 =A0 don't<br>
| =A0 =A0 > understand why they would do so (other than "because it=
is<br>
| =A0 =A0 possible").<br>
|<br>
|<br>
| =A0 =A0 I don' understand either. =A0AFAIK `final` only helps polymor=
phic<br>
| =A0 =A0 class (if not, we may want to add `final` everywhere in STL), and=
<br>
| =A0 =A0 a polymorphic class can not be empty :(<br>
|<br>
|<br>
| =A0 =A0 > Oh, I'd like a trait to know whether or not one can deri=
ve from<br>
| =A0 =A0 a type or<br>
| =A0 =A0 > not.<br>
|<br>
|<br>
| =A0 =A0 Ditto. =A0Different from is_final, this will include non-class<br=
>
| =A0 =A0 types.<br>
| =A0 =A0 But looks more useful.<br>
|<br>
|<br>
| =A0 =A0 >> Really, an attribute would be so much simpler...<br>
| =A0 =A0 ><br>
| =A0 =A0 > Why would I even want an attribute? =A0In all but the rarest=
of<br>
| =A0 =A0 circumstances<br>
| =A0 =A0 > (again, those reliant on increasing addresses) I would want =
the<br>
| =A0 =A0 unneeded<br>
| =A0 =A0 > space optimized away.<br>
|<br>
|<br>
| =A0 =A0 We just can't make such an attribute; attribute can not<br>
| =A0 =A0 change a program's observable behavior.<br>
|<br>
|<br>
| An attribute could change a program's observable behavior, and many o=
f<br>
| the vendor-specific C++11 attributes do. The question is whether the<br>
| committee would allow an attribute that changes the program's<br>
| observable behavior to be standardized. Some committee members have<br>
| been opposed to this before, but to my knowledge the committee has not<br=
>
| agreed that no standard attribute will ever change a program's<br>
| behavior.<br>
<br>
</div></div>In reality, the actual position was/is far more nuanced than th=
at.<br>
<br>
The gentlement agreement, and the general understanding, for voting<br>
attributes into C++11 was that if a program P with attribute A is<br>
well-formed and has a defined meaning, then the P' obtained from<br>
P ignoring attribute A should be well-formed with equivalent meaning.<br></=
blockquote><div><br></div><div>Thanks.</div><div><br></div><div>I think thi=
s rule is too strict -- "equivalent meaning" is sufficient, but n=
ot necessary. In general, we have a set of denotations for P, and all that =
seems necessary is that the denotations for P' are a subset of those fo=
r P, not that they are the same (this also removes the need for a "def=
ined meaning" clause).</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd6b4b27f785e04ec1e533b--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Tue, 26 Nov 2013 21:30:26 -0600
Raw View
Richard Smith <richard@metafoo.co.uk> writes:
| On Tue, Nov 26, 2013 at 4:57 PM, Gabriel Dos Reis <gdr@axiomatics.org>
| wrote:
|=20
| =20
| Richard Smith <richard@metafoo.co.uk> writes:
| =20
| | On Tue, Nov 26, 2013 at 12:49 PM, Zhihao Yuan <zy@miator.net>
| wrote:
| |
| | =A0 =A0 On Tue, Nov 26, 2013 at 2:54 PM, Nevin Liber
| | =A0 =A0 <nevin@eviloverlord.com> wrote:
| | =A0 =A0 > I understand that people can write final empty allocators=
,
| but I
| | =A0 =A0 don't
| | =A0 =A0 > understand why they would do so (other than "because it i=
s
| | =A0 =A0 possible").
| |
| |
| | =A0 =A0 I don' understand either. =A0AFAIK `final` only helps
| polymorphic
| | =A0 =A0 class (if not, we may want to add `final` everywhere in
| STL), and
| | =A0 =A0 a polymorphic class can not be empty :(
| |
| |
| | =A0 =A0 > Oh, I'd like a trait to know whether or not one can deriv=
e
| from
| | =A0 =A0 a type or
| | =A0 =A0 > not.
| |
| |
| | =A0 =A0 Ditto. =A0Different from is_final, this will include non-cl=
ass
| | =A0 =A0 types.
| | =A0 =A0 But looks more useful.
| |
| |
| | =A0 =A0 >> Really, an attribute would be so much simpler...
| | =A0 =A0 >
| | =A0 =A0 > Why would I even want an attribute? =A0In all but the rar=
est
| of
| | =A0 =A0 circumstances
| | =A0 =A0 > (again, those reliant on increasing addresses) I would
| want the
| | =A0 =A0 unneeded
| | =A0 =A0 > space optimized away.
| |
| |
| | =A0 =A0 We just can't make such an attribute; attribute can not
| | =A0 =A0 change a program's observable behavior.
| |
| |
| | An attribute could change a program's observable behavior, and
| many of
| | the vendor-specific C++11 attributes do. The question is whether
| the
| | committee would allow an attribute that changes the program's
| | observable behavior to be standardized. Some committee members
| have
| | been opposed to this before, but to my knowledge the committee
| has not
| | agreed that no standard attribute will ever change a program's
| | behavior.
| =20
| =20
| In reality, the actual position was/is far more nuanced than that.
| =20
| The gentlement agreement, and the general understanding, for
| voting
| attributes into C++11 was that if a program P with attribute A is
| well-formed and has a defined meaning, then the P' obtained from
| P ignoring attribute A should be well-formed with equivalent
| meaning.
| =20
|=20
| Thanks.
|=20
| I think this rule is too strict -- "equivalent meaning" is sufficient,
| but not necessary. In general, we have a set of denotations for P, and
| all that seems necessary is that the denotations for P' are a subset
| of those for P, not that they are the same (this also removes the need
| for a "defined meaning" clause).
I think I agree. Troubles come when people get to realize what the
complement of the denotations of P' would be, relatively to the denotations
of P. Which is how we got to "equivalent meaning", without in fact
elaborating on what that would mean or entail.
(It is the usual "people would do the reasonable thing")
-- Gaby
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 26 Nov 2013 21:13:41 -0800
Raw View
On ter=E7a-feira, 26 de novembro de 2013 16:26:48, Richard Smith wrote:
> > The change in behaviour is if you make a noreturn function actually
> > return.
> > It's not the fault of the compiler if you lied.
>=20
> Why should it matter how we can apportion blame? This is still a change i=
n
> behavior caused by adding the attribute.
I disagree, so let me try a different explanation: if an attribute is descr=
ibed=20
in the standard, then all compliant compilers must implement support for it=
=20
and the diagnostics that it requires. Here's the catch: the simplest suppor=
t=20
is to do nothing and that's valid.
For [[noreturn]], [[gnu::pure]] and [[gnu::const]], the "do nothing" soluti=
on=20
is to not optimise in any way. The generated code will still be compliant. =
In=20
all those cases, the only side-effect is dead or unnecessary code code.
For [[carries_dependency]], the "do nothing" solution is still not to optim=
ise=20
-- by assuming everything carries a dependency.
A later version of the compiler may decide to optimise any of those and the=
re=20
will be no ill effects, provided that no one lied to the compiler.
Now, for the proposed [[empty]], the compiler does not have that option. It=
=20
*must* implement support which is more than "do nothing". Doing otherwise=
=20
would definitely mean visible changes, since structures change sizes, and=
=20
whatnot.
> This program has defined behavior and prints "hello world":
>=20
> #include <stdio.h>
> void f() {}
> int main() {
> f();
> puts("hello world");
> }
> void g() {
> puts("nasal demons");
> }
>=20
> On my implementation, if I mark 'f' as [[noreturn]], it instead prints
> "nasal demons". The attribute has *changed* the set of meanings of the
> program from {print "hello world"} to the set of all possible meanings (a=
ka
> "undefined behavior"). That's a pretty huge change in behavior.
Only because you're depending on undefined behaviour. The standard defines =
that=20
returning from a [[noreturn]] function is undefined behaviour, which means =
the=20
compiler is allowed to do anything it wants, including emit code that assum=
es=20
that the function returned normally. That's the "do nothing" scenario from =
my=20
new explanation.
In a new version of the compiler, if it does implement handling of=20
[[noreturn]] by simply stopping code emission, all bets are lost. There's n=
o=20
telling what instructions follow the code stream after f().
If we examine the example of a program that does not rely on undefined=20
behaviour instead:
#include <stdio.h>
#include <stdlib.h>
[[noreturn]] void f() { exit(0); }
int main()
{
f();
puts("hello world");
}
A compiler that implements [[noreturn]] support as "do nothing" will emit t=
he=20
call to puts() after the call to exit(). That means it will never get execu=
ted=20
and the program will simply and reliably exit with status 0, with nothing=
=20
printed.
A compiler that implements [[noreturn]] handling will also behave the same=
=20
way. The only difference is that the call to puts() will have been eliminat=
ed=20
by dead-code elimination optimisation.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: John Bytheway <jbytheway@gmail.com>
Date: Wed, 27 Nov 2013 07:20:46 -0500
Raw View
On 2013-11-27 00:13, Thiago Macieira wrote:
> On ter=E7a-feira, 26 de novembro de 2013 16:26:48, Richard Smith wrote:
>>> The change in behaviour is if you make a noreturn function actually
>>> return.
>>> It's not the fault of the compiler if you lied.
>>
>> Why should it matter how we can apportion blame? This is still a change =
in
>> behavior caused by adding the attribute.
>=20
> I disagree, so let me try a different explanation: if an attribute is des=
cribed=20
> in the standard, then all compliant compilers must implement support for =
it=20
> and the diagnostics that it requires. Here's the catch: the simplest supp=
ort=20
> is to do nothing and that's valid.
>=20
> For [[noreturn]], [[gnu::pure]] and [[gnu::const]], the "do nothing" solu=
tion=20
> is to not optimise in any way. The generated code will still be compliant=
.. In=20
> all those cases, the only side-effect is dead or unnecessary code code.
>=20
> For [[carries_dependency]], the "do nothing" solution is still not to opt=
imise=20
> -- by assuming everything carries a dependency.
>=20
> A later version of the compiler may decide to optimise any of those and t=
here=20
> will be no ill effects, provided that no one lied to the compiler.
>=20
> Now, for the proposed [[empty]], the compiler does not have that option. =
It=20
> *must* implement support which is more than "do nothing". Doing otherwise=
=20
> would definitely mean visible changes, since structures change sizes, and=
=20
> whatnot.
Isn't the empty base optimization optional? If so, there are already
things compilers can optionally support which will change structure
sizes and observable behaviour. The standard could certainly be written
in such a way that ignoring [[empty]] was a valid implementation.
Still, I agree with you that this seems beyond the spirit of what
attributes were intended for.
John
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Wed, 27 Nov 2013 10:34:24 -0200
Raw View
On Wed, Nov 27, 2013 at 3:13 AM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On ter=E7a-feira, 26 de novembro de 2013 16:26:48, Richard Smith wrote:
>> > The change in behaviour is if you make a noreturn function actually
>> > return.
>> > It's not the fault of the compiler if you lied.
>>
>> Why should it matter how we can apportion blame? This is still a change =
in
>> behavior caused by adding the attribute.
>
> I disagree, so let me try a different explanation: if an attribute is des=
cribed
> in the standard, then all compliant compilers must implement support for =
it
> and the diagnostics that it requires. Here's the catch: the simplest supp=
ort
> is to do nothing and that's valid.
[snip]
> Now, for the proposed [[empty]], the compiler does not have that option. =
It
> *must* implement support which is more than "do nothing". Doing otherwise
> would definitely mean visible changes, since structures change sizes, and
> whatnot.
The compiler that ignores [[empty]] would work just as well. The size of th=
e
struct would be different, but that's implementation-defined anyway so no
harm done.
The problem I would have with attributes is that it creates class types tha=
t
do not obey some expectations already in-place w.r.t memory locations,
so that with [[empty]] there would be two complete subobjects that
share the same memory location. I still believe this is an important
optimization to have though, but if it should be an attribute or not I don'=
t
know. But compilers that ignores [[empty]] would work just as well
since ABI is not standardized by the C++ commitee.
[snip]
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
---
Felipe Magno de Almeida
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Xavi <gratal@gmail.com>
Date: Wed, 27 Nov 2013 13:46:35 +0100
Raw View
Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are used to =
make a promise to the compiler about how something is used or implemented. =
[[empty]] is misleading in that it seems to be telling the compiler that th=
e class is empty, which the compiler already knows and won't always be true=
in generic code.
What about instead having the attribute [[nolayoutassumptions]] (or somethi=
ng shorter) which is a promise to the compiler that the implementation of t=
hat class will make no assumptions about the layout? Then the compiler can =
optimize away the storage for empty (private) members, and even reorder the=
m to optimize space in presence of alignment requirements.
Of course this shouldn't apply to public members, since you can't make the =
promise on behalf of users, but I don't think that limits its usefulness.
> On 27 Nov 2013, at 13:34, Felipe Magno de Almeida <felipe.m.almeida@gmail=
..com> wrote:
>=20
>> On Wed, Nov 27, 2013 at 3:13 AM, Thiago Macieira <thiago@macieira.org> w=
rote:
>> On ter=E7a-feira, 26 de novembro de 2013 16:26:48, Richard Smith wrote:
>>>> The change in behaviour is if you make a noreturn function actually
>>>> return.
>>>> It's not the fault of the compiler if you lied.
>>>=20
>>> Why should it matter how we can apportion blame? This is still a change=
in
>>> behavior caused by adding the attribute.
>>=20
>> I disagree, so let me try a different explanation: if an attribute is de=
scribed
>> in the standard, then all compliant compilers must implement support for=
it
>> and the diagnostics that it requires. Here's the catch: the simplest sup=
port
>> is to do nothing and that's valid.
>=20
> [snip]
>=20
>> Now, for the proposed [[empty]], the compiler does not have that option.=
It
>> *must* implement support which is more than "do nothing". Doing otherwis=
e
>> would definitely mean visible changes, since structures change sizes, an=
d
>> whatnot.
>=20
> The compiler that ignores [[empty]] would work just as well. The size of =
the
> struct would be different, but that's implementation-defined anyway so no
> harm done.
>=20
> The problem I would have with attributes is that it creates class types t=
hat
> do not obey some expectations already in-place w.r.t memory locations,
> so that with [[empty]] there would be two complete subobjects that
> share the same memory location. I still believe this is an important
> optimization to have though, but if it should be an attribute or not I do=
n't
> know. But compilers that ignores [[empty]] would work just as well
> since ABI is not standardized by the C++ commitee.
>=20
> [snip]
>=20
>=20
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel Open Source Technology Center
>> PGP/GPG: 0x6EF45358; fingerprint:
>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>=20
> ---
> Felipe Magno de Almeida
>=20
> --=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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
Date: Wed, 27 Nov 2013 11:09:55 -0200
Raw View
On Wed, Nov 27, 2013 at 10:46 AM, Xavi <gratal@gmail.com> wrote:
> Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are used t=
o make a promise to the compiler about how something is used or implemented=
.. [[empty]] is misleading in that it seems to be telling the compiler that =
the class is empty, which the compiler already knows and won't always be tr=
ue in generic code.
>
> What about instead having the attribute [[nolayoutassumptions]] (or somet=
hing shorter) which is a promise to the compiler that the implementation of=
that class will make no assumptions about the layout? Then the compiler ca=
n optimize away the storage for empty (private) members, and even reorder t=
hem to optimize space in presence of alignment requirements.
I liked.
> Of course this shouldn't apply to public members, since you can't make th=
e promise on behalf of users, but I don't think that limits its usefulness.
I think it limits its usefulness because even if something is public
doesn't mean it is part of the interface of my library. It might just
be an implementation detail and I can control that any code that uses
this class knows that it is not a "standard layout"-class.
Regards,
--=20
Felipe Magno de Almeida
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Alex B <devalexb@gmail.com>
Date: Wed, 27 Nov 2013 09:24:45 -0500
Raw View
--e89a8ff1c822dec44804ec295b6e
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Nov 27, 2013 at 7:46 AM, Xavi <gratal@gmail.com> wrote:
> Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are used to
> make a promise to the compiler about how something is used or implemented.
> [[empty]] is misleading in that it seems to be telling the compiler that
> the class is empty, which the compiler already knows and won't always be
> true in generic code.
>
Hmmm... we could have something like this in generic code:
template <class T, bool = std::is_empty<T>::value>
struct _compressed_impl { using type = T; };
template <class T>
struct _compressed_impl<T, true> { using type = [[empty]] T; };
template <class T>
using compressed = typename _compressed_impl<T>::type;
template <class T>
struct B
{
compressed<T> t;
static constexpr bool IsCompressed = is_empty<B>::value ==
is_empty<T>::value;
};
Or better than this; just call the attribute [[compressed]] or something
like this instead.
[[compressed]] T t;
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--e89a8ff1c822dec44804ec295b6e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 27, 2013 at 7:46 AM, Xavi <span dir=3D"ltr"><<a href=3D"mailto:g=
ratal@gmail.com" target=3D"_blank">gratal@gmail.com</a>></span> wrote:<b=
r><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">
Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are used to =
make a promise to the compiler about how something is used or implemented. =
[[empty]] is misleading in that it seems to be telling the compiler that th=
e class is empty, which the compiler already knows and won't always be =
true in generic code.<br>
</blockquote><div><br></div><div>Hmmm... we could have something like this =
in generic code:</div><div><br></div></div></div><blockquote style=3D"margi=
n:0px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div><font face=3D"courier new, monospace">template <class T, bool =3D s=
td::is_empty<T>::value></font></div><div><font face=3D"courier new=
, monospace">struct _compressed_impl { using type =3D T; };</font></div><di=
v><font face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">template <class =
T></font></div><div><font face=3D"courier new, monospace">struct _compre=
ssed_impl<T, true> { using type =3D [[empty]] T; };</font></div><div>=
<font face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">template <class =
T></font></div><div><font face=3D"courier new, monospace">using compress=
ed =3D typename _compressed_impl<T>::type;</font></div><div><font fac=
e=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace"><br></font></div><d=
iv><font face=3D"courier new, monospace">template <class T></font></d=
iv><div><font face=3D"courier new, monospace">struct B</font></div><div><fo=
nt face=3D"courier new, monospace">{</font></div>
<div><font face=3D"courier new, monospace"><span class=3D"" style=3D"white-=
space:pre"> </span>compressed<T> t;</font></div><div><font face=3D"co=
urier new, monospace"><span class=3D"" style=3D"white-space:pre"> static co=
nstexpr bool IsCompressed =3D </span>is_empty<B>::value =3D=3D is_emp=
ty<T>::value;</font></div>
<div><font face=3D"courier new, monospace">};</font></div><div><br></div></=
div></div></blockquote>Or better than this; just call the attribute [[compr=
essed]] or something like this instead.<div><br></div><blockquote style=3D"=
margin:0 0 0 40px;border:none;padding:0px">
<div><div><span class=3D"" style=3D"font-family:'courier new',monos=
pace;white-space:pre"> [[</span><span style=3D"font-family:'courier new=
',monospace">compressed]] T t;</span></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8ff1c822dec44804ec295b6e--
.
Author: xavi <gratal@gmail.com>
Date: Thu, 28 Nov 2013 06:08:38 +0100
Raw View
--047d7bd75c94d6880404ec35b46a
Content-Type: text/plain; charset=ISO-8859-1
2013/11/27 Felipe Magno de Almeida <felipe.m.almeida@gmail.com>
> On Wed, Nov 27, 2013 at 10:46 AM, Xavi <gratal@gmail.com> wrote:
> > Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are used
> to make a promise to the compiler about how something is used or
> implemented. [[empty]] is misleading in that it seems to be telling the
> compiler that the class is empty, which the compiler already knows and
> won't always be true in generic code.
> >
> > What about instead having the attribute [[nolayoutassumptions]] (or
> something shorter) which is a promise to the compiler that the
> implementation of that class will make no assumptions about the layout?
> Then the compiler can optimize away the storage for empty (private)
> members, and even reorder them to optimize space in presence of alignment
> requirements.
>
> I liked.
>
> > Of course this shouldn't apply to public members, since you can't make
> the promise on behalf of users, but I don't think that limits its
> usefulness.
>
> I think it limits its usefulness because even if something is public
> doesn't mean it is part of the interface of my library. It might just
> be an implementation detail and I can control that any code that uses
> this class knows that it is not a "standard layout"-class.
>
> Maybe a better solution is to have it as an attribute of a private: or
public: block. I don't think it's currently possible for the access
specifiers to have attributes, but I don't think it would be too hard to
implement and it would allow for better fine-graining.
> Regards,
> --
> Felipe Magno de Almeida
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd75c94d6880404ec35b46a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/11/27 Felipe Magno de Almeida <span dir=3D"ltr"><<a href=3D=
"mailto:felipe.m.almeida@gmail.com" target=3D"_blank">felipe.m.almeida@gmai=
l.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Nov 27, 2013 at 10=
:46 AM, Xavi <<a href=3D"mailto:gratal@gmail.com">gratal@gmail.com</a>&g=
t; wrote:<br>
> Most Current attributes, such as [[noreturn]] or [[gnu::pure]] are use=
d to make a promise to the compiler about how something is used or implemen=
ted. [[empty]] is misleading in that it seems to be telling the compiler th=
at the class is empty, which the compiler already knows and won't alway=
s be true in generic code.<br>
><br>
> What about instead having the attribute [[nolayoutassumptions]] (or so=
mething shorter) which is a promise to the compiler that the implementation=
of that class will make no assumptions about the layout? Then the compiler=
can optimize away the storage for empty (private) members, and even reorde=
r them to optimize space in presence of alignment requirements.<br>
<br>
</div>I liked.<br>
<div class=3D"im"><br>
> Of course this shouldn't apply to public members, since you can=
9;t make the promise on behalf of users, but I don't think that limits =
its usefulness.<br>
<br>
</div>I think it limits its usefulness because even if something is public<=
br>
doesn't mean it is part of the interface of my library. It might just<b=
r>
be an implementation detail and I can control that any code that uses<br>
this class knows that it is not a "standard layout"-class.<br>
<br></blockquote><div>Maybe a better solution is to have it as an attribute=
of a private: or public: block. I don't think it's currently possi=
ble for the access specifiers to have attributes, but I don't think it =
would be too hard to implement and it would allow for better fine-graining.=
</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">Felipe Magno de Almei=
da<br>
<br>
--<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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd75c94d6880404ec35b46a--
.