Topic: Syntax for Empty Base Optimization
Author: Avi Kivity <avi@cloudius-systems.com>
Date: Thu, 26 Nov 2015 07:34:14 -0800 (PST)
Raw View
------=_Part_639_401898800.1448552054209
Content-Type: multipart/alternative;
boundary="----=_Part_640_1976525111.1448552054209"
------=_Part_640_1976525111.1448552054209
Content-Type: text/plain; charset=UTF-8
Library writers often find themselves wrapping possibly-empty objects in
synthetic structs to take advantage of EBO:
template <typename T, typename Allocator>
class my_container {
struct alloc_n_size : Allocator {
size_t size;
// ctor etc.
} _M_alloc_n_size; // only occupies sizeof(size_t) if
is_empty<Allocator>.
...
};
Would it not be more comfortable to supply some syntax for this:
template <typename T, typename Allocator>
class my_container {
size_t _M_size;
Allocator _M_allocator [[allow_zero_size]];
...
};
the user would be responsible for any problems arising with _M_allocator's
address aliasing another object's (for example, by never taking the address
of _M_allocator or by never allowing it to be compared to anything).
--
---
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_640_1976525111.1448552054209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Library writers often find themselves wrapping possibly-em=
pty objects in synthetic structs to take advantage of EBO:<div><br></div><d=
iv>=C2=A0 template <typename T, typename Allocator></div><div>=C2=A0 =
class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : A=
llocator {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0=
=C2=A0 } _M_alloc_n_size; =C2=A0 // only occupies sizeof(size_t) if is_emp=
ty<Allocator>.</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };=
</div><div><br></div><div>Would it not be more comfortable to supply some s=
yntax for this:</div><div><br></div><div><div>=C2=A0 template <typename =
T, typename Allocator></div><div>=C2=A0 class my_container {</div><div>=
=C2=A0 =C2=A0 =C2=A0 size_t _M_size;<br></div><div>=C2=A0 =C2=A0 =C2=A0 All=
ocator _M_allocator [[allow_zero_size]];</div><div>=C2=A0 =C2=A0 =C2=A0 ...=
</div><div>=C2=A0 };<br></div></div><div><br></div><div>the user would be r=
esponsible for any problems arising with _M_allocator's address aliasin=
g another object's (for example, by never taking the address of _M_allo=
cator or by never allowing it to be compared to anything).</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_640_1976525111.1448552054209--
------=_Part_639_401898800.1448552054209--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Nov 2015 07:59:15 -0800 (PST)
Raw View
------=_Part_6665_940970142.1448553555887
Content-Type: multipart/alternative;
boundary="----=_Part_6666_991075008.1448553555887"
------=_Part_6666_991075008.1448553555887
Content-Type: text/plain; charset=UTF-8
On Thursday, November 26, 2015 at 10:34:14 AM UTC-5, Avi Kivity wrote:
>
> Library writers often find themselves wrapping possibly-empty objects in
> synthetic structs to take advantage of EBO:
>
> template <typename T, typename Allocator>
> class my_container {
> struct alloc_n_size : Allocator {
> size_t size;
> // ctor etc.
> } _M_alloc_n_size; // only occupies sizeof(size_t) if
> is_empty<Allocator>.
> ...
> };
>
> Would it not be more comfortable to supply some syntax for this:
>
> template <typename T, typename Allocator>
> class my_container {
> size_t _M_size;
> Allocator _M_allocator [[allow_zero_size]];
> ...
> };
>
> the user would be responsible for any problems arising with _M_allocator's
> address aliasing another object's (for example, by never taking the address
> of _M_allocator or by never allowing it to be compared to anything).
>
That would be a behavioral difference (the size of `my_container` would be
changed). And attributes should never cause a behavioral difference.
--
---
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_6666_991075008.1448553555887
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 26, 2015 at 10:34:14 AM UTC-5, Avi Kivity wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Library writers of=
ten find themselves wrapping possibly-empty objects in synthetic structs to=
take advantage of EBO:<div><br></div><div>=C2=A0 template <typename T, =
typename Allocator></div><div>=C2=A0 class my_container {</div><div>=C2=
=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=
=A0 // only occupies sizeof(size_t) if is_empty<Allocator>.</div><div=
>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><div>Woul=
d it not be more comfortable to supply some syntax for this:</div><div><br>=
</div><div><div>=C2=A0 template <typename T, typename Allocator></div=
><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size_t _M_=
size;<br></div><div>=C2=A0 =C2=A0 =C2=A0 Allocator _M_allocator [[allow_zer=
o_size]];</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };<br></div><=
/div><div><br></div><div>the user would be responsible for any problems ari=
sing with _M_allocator's address aliasing another object's (for exa=
mple, by never taking the address of _M_allocator or by never allowing it t=
o be compared to anything).</div></div></blockquote><div><br>That would be =
a behavioral difference (the size of `my_container` would be changed). And =
attributes should never cause a behavioral difference.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6666_991075008.1448553555887--
------=_Part_6665_940970142.1448553555887--
.
Author: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Date: Thu, 26 Nov 2015 08:37:08 -0800 (PST)
Raw View
------=_Part_212_1801983478.1448555828957
Content-Type: multipart/alternative;
boundary="----=_Part_213_1633606556.1448555828958"
------=_Part_213_1633606556.1448555828958
Content-Type: text/plain; charset=UTF-8
I often see people mentioning this self-imposed restriction, but it always
looks like it does more harm than good.
Suppose that we do want a behavioral difference, like in this case, but we
don't want introduce new productions to the grammar, keywords, etc, just
some ad hoc syntax.
The we need something else looking and behaving exactly like attributes,
but without this restriction on behavioral difference. Why not just reuse
attributes?
On Thursday, November 26, 2015 at 6:59:16 PM UTC+3, Nicol Bolas wrote:
>
> On Thursday, November 26, 2015 at 10:34:14 AM UTC-5, Avi Kivity wrote:
>>
>> Library writers often find themselves wrapping possibly-empty objects in
>> synthetic structs to take advantage of EBO:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> struct alloc_n_size : Allocator {
>> size_t size;
>> // ctor etc.
>> } _M_alloc_n_size; // only occupies sizeof(size_t) if
>> is_empty<Allocator>.
>> ...
>> };
>>
>> Would it not be more comfortable to supply some syntax for this:
>>
>> template <typename T, typename Allocator>
>> class my_container {
>> size_t _M_size;
>> Allocator _M_allocator [[allow_zero_size]];
>> ...
>> };
>>
>> the user would be responsible for any problems arising with
>> _M_allocator's address aliasing another object's (for example, by never
>> taking the address of _M_allocator or by never allowing it to be compared
>> to anything).
>>
>
> That would be a behavioral difference (the size of `my_container` would be
> changed). And attributes should never cause a behavioral difference.
>
--
---
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_213_1633606556.1448555828958
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I often see people mentioning this self-imposed restrictio=
n, but it always looks like it does more harm than good.<div>Suppose that w=
e do want a=C2=A0behavioral difference, like in this case, but we don't=
want introduce new productions to the grammar, keywords, etc, just some=C2=
=A0ad hoc syntax.</div><div>The we need something else looking and behaving=
exactly like attributes, but without this restriction on behavioral differ=
ence. Why not just reuse attributes?</div><div><br>On Thursday, November 26=
, 2015 at 6:59:16 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On Thursday, November 26, 2015 at 10:34:14 AM UTC-5, Avi Ki=
vity wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Library=
writers often find themselves wrapping possibly-empty objects in synthetic=
structs to take advantage of EBO:<div><br></div><div>=C2=A0 template <t=
ypename T, typename Allocator></div><div>=C2=A0 class my_container {</di=
v><div>=C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 // ctor etc.</div><div>=C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_siz=
e; =C2=A0 // only occupies sizeof(size_t) if is_empty<Allocator>.</di=
v><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };</div><div><br></div><di=
v>Would it not be more comfortable to supply some syntax for this:</div><di=
v><br></div><div><div>=C2=A0 template <typename T, typename Allocator>=
;</div><div>=C2=A0 class my_container {</div><div>=C2=A0 =C2=A0 =C2=A0 size=
_t _M_size;<br></div><div>=C2=A0 =C2=A0 =C2=A0 Allocator _M_allocator [[all=
ow_zero_size]];</div><div>=C2=A0 =C2=A0 =C2=A0 ...</div><div>=C2=A0 };<br><=
/div></div><div><br></div><div>the user would be responsible for any proble=
ms arising with _M_allocator's address aliasing another object's (f=
or example, by never taking the address of _M_allocator or by never allowin=
g it to be compared to anything).</div></div></blockquote><div><br>That wou=
ld be a behavioral difference (the size of `my_container` would be changed)=
.. And attributes should never cause a behavioral difference.<br></div></blo=
ckquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_213_1633606556.1448555828958--
------=_Part_212_1801983478.1448555828957--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Nov 2015 08:52:41 -0800 (PST)
Raw View
------=_Part_9385_333408011.1448556761293
Content-Type: multipart/alternative;
boundary="----=_Part_9386_1196004446.1448556761293"
------=_Part_9386_1196004446.1448556761293
Content-Type: text/plain; charset=UTF-8
On Thursday, November 26, 2015 at 11:37:09 AM UTC-5, Vadim Petrochenkov
wrote:
>
> I often see people mentioning this self-imposed restriction, but it always
> looks like it does more harm than good.
>
The standards committee has made it clear by now that making it easy to add
keywords is something they don't want to do. Indeed, a proposal for a
special feature to make adding keywords easier <http://wg21.link/P0071> was
shot down because "the difficulty of adding keywords to C++ is a feature
<https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
".
Using attributes to back-door this restriction is not going to happen.
> Suppose that we do want a behavioral difference, like in this case, but we
> don't want introduce new productions to the grammar, keywords, etc, just
> some ad hoc syntax.
>
Why don't we want some actual syntax here? Why is an "ad hoc" solution
better than a real one?
And more importantly, why should the syntax be on the use of the type
rather than on the type itself? That is, why not just have types that, when
used as member subobjects, take up no space?
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0>
--
---
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_9386_1196004446.1448556761293
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 26, 2015 at 11:37:09 AM UTC-5, Vadim=
Petrochenkov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I often see people mentioning this self-imposed restriction, but i=
t always looks like it does more harm than good.</div></blockquote><div><br=
>The standards committee has made it clear by now that making it easy to ad=
d keywords is something they don't want to do. Indeed, a <a href=3D"htt=
p://wg21.link/P0071">proposal for a special feature to make adding keywords=
easier</a> was shot down because "<a href=3D"https://botondballo.word=
press.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/"=
>the difficulty of adding keywords to C++ is a feature</a>".<br><br>Us=
ing attributes to back-door this restriction is not going to happen.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
>Suppose that we do want a=C2=A0behavioral difference, like in this case, b=
ut we don't want introduce new productions to the grammar, keywords, et=
c, just some=C2=A0ad hoc syntax.</div></div></blockquote><div><br>Why don&#=
39;t we want some actual syntax here? Why is an "ad hoc" solution=
better than a real one?<br><br>And more importantly, why should the syntax=
be on the use of the type rather than on the type itself? That is, <a href=
=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGu=
jSdKXX0">why not just have types that, when used as member subobjects, take=
up no space?</a><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9386_1196004446.1448556761293--
------=_Part_9385_333408011.1448556761293--
.
Author: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Date: Thu, 26 Nov 2015 09:02:02 -0800 (PST)
Raw View
------=_Part_515_1279531329.1448557322781
Content-Type: multipart/alternative;
boundary="----=_Part_516_1992568313.1448557322781"
------=_Part_516_1992568313.1448557322781
Content-Type: text/plain; charset=UTF-8
>Why don't we want some actual syntax here? Why is an "ad hoc" solution
better than a real one?
I explained why, to avoid new extending the language grammar and reuse
existing attribute grammar instead.
Many languages do this to introduce niche features, not important enough to
deserve a full blown piece of syntax in the core language, many pre-ISO
attributes provided by C++ compilers do this as well.
On Thursday, November 26, 2015 at 7:52:41 PM UTC+3, Nicol Bolas wrote:
>
> On Thursday, November 26, 2015 at 11:37:09 AM UTC-5, Vadim Petrochenkov
> wrote:
>>
>> I often see people mentioning this self-imposed restriction, but it
>> always looks like it does more harm than good.
>>
>
> The standards committee has made it clear by now that making it easy to
> add keywords is something they don't want to do. Indeed, a proposal for a
> special feature to make adding keywords easier <http://wg21.link/P0071>
> was shot down because "the difficulty of adding keywords to C++ is a
> feature
> <https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
> ".
>
> Using attributes to back-door this restriction is not going to happen.
>
>
>> Suppose that we do want a behavioral difference, like in this case, but
>> we don't want introduce new productions to the grammar, keywords, etc, just
>> some ad hoc syntax.
>>
>
> Why don't we want some actual syntax here? Why is an "ad hoc" solution
> better than a real one?
>
> And more importantly, why should the syntax be on the use of the type
> rather than on the type itself? That is, why not just have types that,
> when used as member subobjects, take up no space?
> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0>
>
--
---
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_516_1992568313.1448557322781
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>Why don't we want some actual syntax here? Wh=
y is an "ad hoc" solution better than a real one?</div><div><br><=
/div><div>I explained why, to avoid new extending the language grammar and =
reuse existing attribute grammar instead.</div><div>Many languages do this =
to introduce niche features, not important enough to deserve a full blown p=
iece of syntax in the core language, many pre-ISO attributes provided by C+=
+ compilers do this as well.</div><div><br></div>On Thursday, November 26, =
2015 at 7:52:41 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">On Thursday, November 26, 2015 at 11:37:09 A=
M UTC-5, Vadim Petrochenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">I often see people mentioning this self-imposed restricti=
on, but it always looks like it does more harm than good.</div></blockquote=
><div><br>The standards committee has made it clear by now that making it e=
asy to add keywords is something they don't want to do. Indeed, a <a hr=
ef=3D"http://wg21.link/P0071" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%=
2FP0071\46sa\75D\46sntz\0751\46usg\75AFQjCNEUnwWrtpVpBLjjH-Cz6lJFhJGs5w'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75h=
ttp%3A%2F%2Fwg21.link%2FP0071\46sa\75D\46sntz\0751\46usg\75AFQjCNEUnwWrtpVp=
BLjjH-Cz6lJFhJGs5w';return true;">proposal for a special feature to mak=
e adding keywords easier</a> was shot down because "<a href=3D"https:/=
/botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-ko=
na-october-2015/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'https://www.google.com/url?q\75https%3A%2F%2Fbotondballo.wordpres=
s.com%2F2015%2F11%2F09%2Ftrip-report-c-standards-meeting-in-kona-october-20=
15%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH0fDsHBDmgIXlDvga9RNUVFObifw';=
return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75ht=
tps%3A%2F%2Fbotondballo.wordpress.com%2F2015%2F11%2F09%2Ftrip-report-c-stan=
dards-meeting-in-kona-october-2015%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH0=
fDsHBDmgIXlDvga9RNUVFObifw';return true;">the difficulty of adding keyw=
ords to C++ is a feature</a>".<br><br>Using attributes to back-door th=
is restriction is not going to happen.<br>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div>Suppose that we do want a=C2=A0beh=
avioral difference, like in this case, but we don't want introduce new =
productions to the grammar, keywords, etc, just some=C2=A0ad hoc syntax.</d=
iv></div></blockquote><div><br>Why don't we want some actual syntax her=
e? Why is an "ad hoc" solution better than a real one?<br><br>And=
more importantly, why should the syntax be on the use of the type rather t=
han on the type itself? That is, <a href=3D"https://groups.google.com/a/iso=
cpp.org/forum/#!topic/std-proposals/HjGujSdKXX0" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp=
..org/forum/#!topic/std-proposals/HjGujSdKXX0';return true;" onclick=3D"=
this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/HjGujSdKXX0';return true;">why not just have types that, when =
used as member subobjects, take up no space?</a><br></div></div></blockquot=
e></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_516_1992568313.1448557322781--
------=_Part_515_1279531329.1448557322781--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 26 Nov 2015 09:20:37 -0800 (PST)
Raw View
------=_Part_4363_759164092.1448558437373
Content-Type: multipart/alternative;
boundary="----=_Part_4364_560846060.1448558437373"
------=_Part_4364_560846060.1448558437373
Content-Type: text/plain; charset=UTF-8
On Thursday, November 26, 2015 at 4:52:41 PM UTC, Nicol Bolas wrote:
>
> On Thursday, November 26, 2015 at 11:37:09 AM UTC-5, Vadim Petrochenkov
> wrote:
>>
>> I often see people mentioning this self-imposed restriction, but it
>> always looks like it does more harm than good.
>>
>
> The standards committee has made it clear by now that making it easy to
> add keywords is something they don't want to do. Indeed, a proposal for a
> special feature to make adding keywords easier <http://wg21.link/P0071>
> was shot down because "the difficulty of adding keywords to C++ is a
> feature
> <https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
> ".
>
> Using attributes to back-door this restriction is not going to happen.
>
>
>> Suppose that we do want a behavioral difference, like in this case, but
>> we don't want introduce new productions to the grammar, keywords, etc, just
>> some ad hoc syntax.
>>
>
> Why don't we want some actual syntax here? Why is an "ad hoc" solution
> better than a real one?
>
It seems a perfect use of attributes to me. The feature is niche enough not
to really warrant its own syntax or keyword and has a very minor effect on
the program.
The "no behaviour change" restriction get repeated many times, but it is
hardly respected ([[noreturn]], [[carries_dependency]]); The rule that
seems to be followed is that a program stripped of all (or some) attributes
is still a valid program.
>
> And more importantly, why should the syntax be on the use of the type
> rather than on the type itself? That is, why not just have types that,
> when used as member subobjects, take up no space?
> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0>
>
Because often the type is a template parameter (a function object, an
allocator) and the library can't assume it has been correctly marked but
might still want to take advantage of the optimization. Of course it should
also be possible to tag a type.
-- gpd
--
---
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_4364_560846060.1448558437373
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 26, 2015 at 4:52:41 PM UTC, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thursday, Novembe=
r 26, 2015 at 11:37:09 AM UTC-5, Vadim Petrochenkov wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">I often see people mentioning this =
self-imposed restriction, but it always looks like it does more harm than g=
ood.</div></blockquote><div><br>The standards committee has made it clear b=
y now that making it easy to add keywords is something they don't want =
to do. Indeed, a <a href=3D"http://wg21.link/P0071" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fwg21.link%2FP0071\46sa\75D\46sntz\0751\46usg\75AFQjCNEUnwWrtp=
VpBLjjH-Cz6lJFhJGs5w';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP0071\46sa\75D\46sntz\0751\=
46usg\75AFQjCNEUnwWrtpVpBLjjH-Cz6lJFhJGs5w';return true;">proposal for =
a special feature to make adding keywords easier</a> was shot down because =
"<a href=3D"https://botondballo.wordpress.com/2015/11/09/trip-report-c=
-standards-meeting-in-kona-october-2015/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fbotondballo.wordpress.com%2F2015%2F11%2F09%2Ftrip-report-c-standards-me=
eting-in-kona-october-2015%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH0fDsHBDmg=
IXlDvga9RNUVFObifw';return true;" onclick=3D"this.href=3D'https://w=
ww.google.com/url?q\75https%3A%2F%2Fbotondballo.wordpress.com%2F2015%2F11%2=
F09%2Ftrip-report-c-standards-meeting-in-kona-october-2015%2F\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNH0fDsHBDmgIXlDvga9RNUVFObifw';return true;">the d=
ifficulty of adding keywords to C++ is a feature</a>".<br><br>Using at=
tributes to back-door this restriction is not going to happen.<br>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Suppose th=
at we do want a=C2=A0behavioral difference, like in this case, but we don&#=
39;t want introduce new productions to the grammar, keywords, etc, just som=
e=C2=A0ad hoc syntax.</div></div></blockquote><div><br>Why don't we wan=
t some actual syntax here? Why is an "ad hoc" solution better tha=
n a real one?<br></div></div></blockquote><div><br>It seems a perfect use o=
f attributes to me. The feature is niche enough not to really warrant its o=
wn syntax or keyword and has a very minor effect on the program. <br><br>Th=
e "no behaviour change" restriction get repeated many times, but =
it is hardly respected ([[noreturn]], [[carries_dependency]]); The rule tha=
t seems to be followed is that a program stripped of all (or some) attribut=
es is still a valid program.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><br>And more importantly, why should th=
e syntax be on the use of the type rather than on the type itself? That is,=
<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-propos=
als/HjGujSdKXX0" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals=
/HjGujSdKXX0';return true;" onclick=3D"this.href=3D'https://groups.=
google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0';return=
true;">why not just have types that, when used as member subobjects, take =
up no space?</a><br></div></div></blockquote><div><br>Because often the typ=
e is a template parameter (a function object, an allocator) and the library=
can't assume it has been correctly marked but might still want to take=
advantage of the optimization. Of course it should also be possible to tag=
a type.<br><br>-- gpd <br><br>=C2=A0</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4364_560846060.1448558437373--
------=_Part_4363_759164092.1448558437373--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Nov 2015 10:07:20 -0800 (PST)
Raw View
------=_Part_5940_718488351.1448561240298
Content-Type: multipart/alternative;
boundary="----=_Part_5941_346570569.1448561240298"
------=_Part_5941_346570569.1448561240298
Content-Type: text/plain; charset=UTF-8
On Thursday, November 26, 2015 at 12:20:37 PM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Thursday, November 26, 2015 at 4:52:41 PM UTC, Nicol Bolas wrote:
>>
>> On Thursday, November 26, 2015 at 11:37:09 AM UTC-5, Vadim Petrochenkov
>> wrote:
>>>
>>> I often see people mentioning this self-imposed restriction, but it
>>> always looks like it does more harm than good.
>>>
>>
>> The standards committee has made it clear by now that making it easy to
>> add keywords is something they don't want to do. Indeed, a proposal for
>> a special feature to make adding keywords easier <http://wg21.link/P0071>
>> was shot down because "the difficulty of adding keywords to C++ is a
>> feature
>> <https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-october-2015/>
>> ".
>>
>> Using attributes to back-door this restriction is not going to happen.
>>
>>
>>> Suppose that we do want a behavioral difference, like in this case, but
>>> we don't want introduce new productions to the grammar, keywords, etc, just
>>> some ad hoc syntax.
>>>
>>
>> Why don't we want some actual syntax here? Why is an "ad hoc" solution
>> better than a real one?
>>
>
> It seems a perfect use of attributes to me. The feature is niche enough
> not to really warrant its own syntax or keyword and has a very minor effect
> on the program.
>
How "niche" a feature is is not a reason to make something an attribute.
The "no behaviour change" restriction get repeated many times, but it is
> hardly respected ([[noreturn]], [[carries_dependency]]); The rule that
> seems to be followed is that a program stripped of all (or some) attributes
> is still a valid program.
>
OK, let's use that reasoning instead. A program should still be valid if
all of the attributes are stripped out.
Consider this:
template <typename T>
class test {
size_t size;
T internal [[allow_zero_size]];
};
struct empty_t {};
static_assert(sizeof(size_t) == sizeof(test<empty_t>), "Is the attribute
set?");
If we had derived `test` from `T` instead of using the attribute, then
`test<empty_t>` would be *required* to be the same size as `size_t`. The
rules of standard layout require than, and therefore you can depend on it
and even static_assert on it.
With your attribute, if you pass an empty_t, again, you want the standard
to *require* the same behavior: that `internal` take up no space.
Therefore, you can `static_assert` on it and everything's fine.
Until you take out the attribute. Then the program becomes *invalid*, since
the static_assert now fires.
Therefore, by your own definition, this is not an appropriate tool for an
attribute.
>> And more importantly, why should the syntax be on the use of the type
>> rather than on the type itself? That is, why not just have types that,
>> when used as member subobjects, take up no space?
>> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0>
>>
>
> Because often the type is a template parameter (a function object, an
> allocator) and the library can't assume it has been correctly marked but
> might still want to take advantage of the optimization. Of course it should
> also be possible to tag a type.
>
Tagging a type with such an attribute is not only observable behavior (as
shown above), it also implies various compile-time checks. Namely, that the
type really is empty: it has no NSDMs that aren't themselves empty, no
virtual base classes, and no base classes that aren't themselves empty.
These are also things attributes should never impose.
--
---
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_5941_346570569.1448561240298
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 26, 2015 at 12:20:37 PM UTC-5, Giovanni Piero Deretta=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, November 2=
6, 2015 at 4:52:41 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">On Thursday, November 26, 2015 at 11:37:09 AM UT=
C-5, Vadim Petrochenkov wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">I often see people mentioning this self-imposed restriction, bu=
t it always looks like it does more harm than good.</div></blockquote><div>=
<br>The standards committee has made it clear by now that making it easy to=
add keywords is something they don't want to do. Indeed, a <a href=3D"=
http://wg21.link/P0071" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP007=
1\46sa\75D\46sntz\0751\46usg\75AFQjCNEUnwWrtpVpBLjjH-Cz6lJFhJGs5w';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fwg21.link%2FP0071\46sa\75D\46sntz\0751\46usg\75AFQjCNEUnwWrtpVpBLjjH-=
Cz6lJFhJGs5w';return true;">proposal for a special feature to make addi=
ng keywords easier</a> was shot down because "<a href=3D"https://boton=
dballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-in-kona-oct=
ober-2015/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\75https%3A%2F%2Fbotondballo.wordpress.com%=
2F2015%2F11%2F09%2Ftrip-report-c-standards-meeting-in-kona-october-2015%2F\=
46sa\75D\46sntz\0751\46usg\75AFQjCNH0fDsHBDmgIXlDvga9RNUVFObifw';return=
true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fbotondballo.wordpress.com%2F2015%2F11%2F09%2Ftrip-report-c-standards-=
meeting-in-kona-october-2015%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH0fDsHBD=
mgIXlDvga9RNUVFObifw';return true;">the difficulty of adding keywords t=
o C++ is a feature</a>".<br><br>Using attributes to back-door this res=
triction is not going to happen.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>Suppose that we do want a=C2=A0behaviora=
l difference, like in this case, but we don't want introduce new produc=
tions to the grammar, keywords, etc, just some=C2=A0ad hoc syntax.</div></d=
iv></blockquote><div><br>Why don't we want some actual syntax here? Why=
is an "ad hoc" solution better than a real one?<br></div></div><=
/blockquote><div><br>It seems a perfect use of attributes to me. The featur=
e is niche enough not to really warrant its own syntax or keyword and has a=
very minor effect on the program.<br></div></blockquote><div><br>How "=
;niche" a feature is is not a reason to make something an attribute.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The "no =
behaviour change" restriction get repeated many times, but it is hardl=
y respected ([[noreturn]], [[carries_dependency]]); The rule that seems to =
be followed is that a program stripped of all (or some) attributes is still=
a valid program.<br></div></blockquote><div><br>OK, let's use that rea=
soning instead. A program should still be valid if all of the attributes ar=
e stripped out.<br><br>Consider this:<br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t=
est </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 size_t size</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 T </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">internal</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>allow_zero_size</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">]];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> empty_t </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">size_t</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">s=
izeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">test</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify"><empty_t></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #080;" class=3D"styled-by-prettify">"Is the attribute set?"=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
</div></code></div><br>If we had derived `test` from `T` instead of using t=
he attribute, then `test<empty_t>` would be <i>required</i> to be the=
same size as `size_t`. The rules of standard layout require than, and ther=
efore you can depend on it and even static_assert on it.<br><br>With your a=
ttribute, if you pass an empty_t, again, you want the standard to <i>requir=
e</i> the same behavior: that `internal` take up no space. Therefore, you c=
an `static_assert` on it and everything's fine.<br><br>Until you take o=
ut the attribute. Then the program becomes <i>invalid</i>, since the static=
_assert now fires.<br><br>Therefore, by your own definition, this is not an=
appropriate tool for an attribute.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><br>And more importantly, why should the syntax be on the =
use of the type rather than on the type itself? That is, <a href=3D"https:/=
/groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://gr=
oups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HjGujSdKXX0';r=
eturn true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp=
..org/forum/#!topic/std-proposals/HjGujSdKXX0';return true;">why not jus=
t have types that, when used as member subobjects, take up no space?</a><br=
></div></div></blockquote><div><br>Because often the type is a template par=
ameter (a function object, an allocator) and the library can't assume i=
t has been correctly marked but might still want to take advantage of the o=
ptimization. Of course it should also be possible to tag a type.</div></blo=
ckquote><div><br>Tagging a type with such an attribute is not only observab=
le behavior (as shown above), it also implies various compile-time checks. =
Namely, that the type really is empty: it has no NSDMs that aren't them=
selves empty, no virtual base classes, and no base classes that aren't =
themselves empty. These are also things attributes should never impose.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5941_346570569.1448561240298--
------=_Part_5940_718488351.1448561240298--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 26 Nov 2015 13:54:09 -0500
Raw View
On 2015-11-26 10:34, Avi Kivity wrote:
> Library writers often find themselves wrapping possibly-empty objects in=
=20
> synthetic structs to take advantage of EBO:
>=20
> template <typename T, typename Allocator>
> class my_container {
> struct alloc_n_size : Allocator {
> size_t size;
> // ctor etc.
> } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
> is_empty<Allocator>.
> ...
> };
>=20
> Would it not be more comfortable to supply some syntax for this:
>=20
> template <typename T, typename Allocator>
> class my_container {
> size_t _M_size;
> Allocator _M_allocator [[allow_zero_size]];
> ...
> };
>=20
> the user would be responsible for any problems arising with _M_allocator'=
s=20
> address aliasing another object's (for example, by never taking the addre=
ss=20
> of _M_allocator or by never allowing it to be compared to anything).
It seems like the stateless classes proposal=C2=B9 would cover this better,
would it not?
(=C2=B9 http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/221=
17)
--=20
Matthew
--=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: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Nov 2015 12:54:57 -0800 (PST)
Raw View
------=_Part_909_1541964877.1448571297874
Content-Type: multipart/alternative;
boundary="----=_Part_910_767624946.1448571297875"
------=_Part_910_767624946.1448571297875
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 26, 2015 at 1:54:20 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-26 10:34, Avi Kivity wrote:=20
> > Library writers often find themselves wrapping possibly-empty objects i=
n=20
> > synthetic structs to take advantage of EBO:=20
> >=20
> > template <typename T, typename Allocator>=20
> > class my_container {=20
> > struct alloc_n_size : Allocator {=20
> > size_t size;=20
> > // ctor etc.=20
> > } _M_alloc_n_size; // only occupies sizeof(size_t) if=20
> > is_empty<Allocator>.=20
> > ...=20
> > };=20
> >=20
> > Would it not be more comfortable to supply some syntax for this:=20
> >=20
> > template <typename T, typename Allocator>=20
> > class my_container {=20
> > size_t _M_size;=20
> > Allocator _M_allocator [[allow_zero_size]];=20
> > ...=20
> > };=20
> >=20
> > the user would be responsible for any problems arising with=20
> _M_allocator's=20
> > address aliasing another object's (for example, by never taking the=20
> address=20
> > of _M_allocator or by never allowing it to be compared to anything).=20
>
> It seems like the stateless classes proposal=C2=B9 would cover this bette=
r,=20
> would it not?=20
>
> (=C2=B9 http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2=
2117)=20
>
> --=20
> Matthew=20
>
>
To be fair, what he's wanting is slightly different (though it might be=20
worth adding to that proposal). He's saying that a particular variable=20
declaration can be optimized into being stateless if the type happens to be=
=20
empty by the usual C++ rules (if the type is not empty, then the usual=20
rules apply). This way, the writer of that type does not have to use=20
explicit syntax in order for users to gain the optimization. And therefore,=
=20
people don't have to derived from possibly empty types in order to get=20
empty optimization.
--=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_910_767624946.1448571297875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 26, 2015 at 1:54:20 PM UTC-5, Matthew Woehlke wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-26 10:34, Avi Kivity=
wrote:
<br>> Library writers often find themselves wrapping possibly-empty obje=
cts in=20
<br>> synthetic structs to take advantage of EBO:
<br>>=20
<br>> =C2=A0 template <typename T, typename Allocator>
<br>> =C2=A0 class my_container {
<br>> =C2=A0 =C2=A0 =C2=A0 struct alloc_n_size : Allocator {
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t size;
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // ctor etc.
<br>> =C2=A0 =C2=A0 =C2=A0 } _M_alloc_n_size; =C2=A0 // only occupies si=
zeof(size_t) if=20
<br>> is_empty<Allocator>.
<br>> =C2=A0 =C2=A0 =C2=A0 ...
<br>> =C2=A0 };
<br>>=20
<br>> Would it not be more comfortable to supply some syntax for this:
<br>>=20
<br>> =C2=A0 template <typename T, typename Allocator>
<br>> =C2=A0 class my_container {
<br>> =C2=A0 =C2=A0 =C2=A0 size_t _M_size;
<br>> =C2=A0 =C2=A0 =C2=A0 Allocator _M_allocator [[allow_zero_size]];
<br>> =C2=A0 =C2=A0 =C2=A0 ...
<br>> =C2=A0 };
<br>>=20
<br>> the user would be responsible for any problems arising with _M_all=
ocator's=20
<br>> address aliasing another object's (for example, by never takin=
g the address=20
<br>> of _M_allocator or by never allowing it to be compared to anything=
).
<br>
<br>It seems like the stateless classes proposal=C2=B9 would cover this bet=
ter,
<br>would it not?
<br>
<br>(=C2=B9 <a href=3D"http://permalink.gmane.org/gmane.comp.lang.c++.isocp=
p.proposals/22117" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fpermalink.gmane.org%2=
Fgmane.comp.lang.c%2B%2B.isocpp.proposals%2F22117\46sa\75D\46sntz\0751\46us=
g\75AFQjCNFy3Qz2HcIMBawpEuJ-OgpKfmsXCw';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fpermalink.gmane.org%2=
Fgmane.comp.lang.c%2B%2B.isocpp.proposals%2F22117\46sa\75D\46sntz\0751\46us=
g\75AFQjCNFy3Qz2HcIMBawpEuJ-OgpKfmsXCw';return true;">http://permalink.=
gmane.org/<wbr>gmane.comp.lang.c++.isocpp.<wbr>proposals/22117</a>)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br>To be fair, what he's wanting is slightly dif=
ferent (though it might be worth adding to that proposal). He's saying =
that a particular variable declaration can be optimized into being stateles=
s if the type happens to be empty by the usual C++ rules (if the type is no=
t empty, then the usual rules apply). This way, the writer of that type doe=
s not have to use explicit syntax in order for users to gain the optimizati=
on. And therefore, people don't have to derived from possibly empty typ=
es in order to get empty optimization.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_910_767624946.1448571297875--
------=_Part_909_1541964877.1448571297874--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Nov 2015 13:27:21 -0800 (PST)
Raw View
------=_Part_973_1579865405.1448573241149
Content-Type: multipart/alternative;
boundary="----=_Part_974_321885674.1448573241149"
------=_Part_974_321885674.1448573241149
Content-Type: text/plain; charset=UTF-8
On Thursday, November 26, 2015 at 12:02:02 PM UTC-5, Vadim Petrochenkov
wrote:
>
> >Why don't we want some actual syntax here? Why is an "ad hoc" solution
> better than a real one?
>
> I explained why, to avoid new extending the language grammar and reuse
> existing attribute grammar instead.
>
OK, fair enough. Here's a better question.
Can you give a reason that the standards committee has not already heard
and rejected several times over? Can you give a reason that would satisfy Herb
Sutter
<http://herbsutter.com/2012/04/05/reader-qa-what-does-it-mean-for-attributes-to-affect-language-semantics/>
?
Many languages do this to introduce niche features, not important enough to
> deserve a full blown piece of syntax in the core language,
>
Can you give me some examples these "many languages" that use attributes
for syntactic constructs? I'm hardly an expert in numerous languages, so
I'm not contesting your statement.
But the only one I know of that makes extensive use of attributes (or
syntax like attributes) is C#. And those are primarily for tagging C#
constructs with arbitrary data that can be fetched via reflection.
> many pre-ISO attributes provided by C++ compilers do this as well.
>
Sure they do. Compilers had ways to set the alignment of types and various
other things. But notice that, when it came time to *standardize* this
functionality, they became keywords. When those proposals were initially
made, they did indeed use attribute syntax. But various people on the
committee made them actual keywords, because they wanted attributes to be
reserved for things that compilers could ignore.
When it comes time to standardize features, actual features go into the
language, not into 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/.
------=_Part_974_321885674.1448573241149
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 26, 2015 at 12:02:02 PM UTC-5, Vadim=
Petrochenkov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>>Why don't we want some actual syntax here? Why is an =
"ad hoc" solution better than a real one?</div><div><br></div><di=
v>I explained why, to avoid new extending the language grammar and reuse ex=
isting attribute grammar instead.</div></div></blockquote><div><br>OK, fair=
enough. Here's a better question.<br><br>Can you give a reason that th=
e standards committee has not already heard and rejected several times over=
? Can you give a reason that would satisfy <a href=3D"http://herbsutter.com=
/2012/04/05/reader-qa-what-does-it-mean-for-attributes-to-affect-language-s=
emantics/">Herb Sutter</a>?<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>Many languages do this to introduce niche =
features, not important enough to deserve a full blown piece of syntax in t=
he core language,</div></div></blockquote><div><br>Can you give me some exa=
mples these "many languages" that use attributes for syntactic co=
nstructs? I'm hardly an expert in numerous languages, so I'm not co=
ntesting your statement.<br><br>But the only one I know of that makes exten=
sive use of attributes (or syntax like attributes) is C#. And those are pri=
marily for tagging C# constructs with arbitrary data that can be fetched vi=
a reflection.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>many pre-ISO attributes provided by C++ compilers do t=
his as well.</div></div></blockquote><br>Sure they do. Compilers had ways t=
o set the alignment of types and various other things. But notice that, whe=
n it came time to <i>standardize</i> this functionality, they became keywor=
ds. When those proposals were initially made, they did indeed use attribute=
syntax. But various people on the committee made them actual keywords, bec=
ause they wanted attributes to be reserved for things that compilers could =
ignore.<br><br>When it comes time to standardize features, actual features =
go into the language, not into attributes.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_974_321885674.1448573241149--
------=_Part_973_1579865405.1448573241149--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 27 Nov 2015 02:27:04 +0100
Raw View
--001a1148e62ac5e8df05257b9666
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 26, 2015 at 10:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, November 26, 2015 at 12:02:02 PM UTC-5, Vadim Petrochenkov
> wrote:
>>
>> >Why don't we want some actual syntax here? Why is an "ad hoc" solution
>> better than a real one?
>>
>> I explained why, to avoid new extending the language grammar and reuse
>> existing attribute grammar instead.
>>
>
> OK, fair enough. Here's a better question.
>
> Can you give a reason that the standards committee has not already heard
> and rejected several times over? Can you give a reason that would satisfy Herb
> Sutter
> <http://herbsutter.com/2012/04/05/reader-qa-what-does-it-mean-for-attributes-to-affect-language-semantics/>
> ?
>
> Many languages do this to introduce niche features, not important enough
>> to deserve a full blown piece of syntax in the core language,
>>
>
> Can you give me some examples these "many languages" that use attributes
> for syntactic constructs? I'm hardly an expert in numerous languages, so
> I'm not contesting your statement.
>
http://stackoverflow.com/q/553857/1131467
>
>
But the only one I know of that makes extensive use of attributes (or
> syntax like attributes) is C#. And those are primarily for tagging C#
> constructs with arbitrary data that can be fetched via reflection.
>
>
>> many pre-ISO attributes provided by C++ compilers do this as well.
>>
>
> Sure they do. Compilers had ways to set the alignment of types and various
> other things. But notice that, when it came time to *standardize* this
> functionality, they became keywords. When those proposals were initially
> made, they did indeed use attribute syntax. But various people on the
> committee made them actual keywords, because they wanted attributes to be
> reserved for things that compilers could ignore.
>
> When it comes time to standardize features, actual features go into the
> language, not into 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/.
>
--
---
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/.
--001a1148e62ac5e8df05257b9666
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Nov 26, 2015 at 10:27 PM, Nicol Bolas <span dir=3D"ltr"><<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">=
On Thursday, November 26, 2015 at 12:02:02 PM UTC-5, Vadim Petrochenkov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>>Why don't we want some ac=
tual syntax here? Why is an "ad hoc" solution better than a real =
one?</div><div><br></div><div>I explained why, to avoid new extending the l=
anguage grammar and reuse existing attribute grammar instead.</div></div></=
blockquote></span><div><br>OK, fair enough. Here's a better question.<b=
r><br>Can you give a reason that the standards committee has not already he=
ard and rejected several times over? Can you give a reason that would satis=
fy <a href=3D"http://herbsutter.com/2012/04/05/reader-qa-what-does-it-mean-=
for-attributes-to-affect-language-semantics/" target=3D"_blank">Herb Sutter=
</a>?<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Many languages do this to introduce niche features, not important enough to=
deserve a full blown piece of syntax in the core language,</div></div></bl=
ockquote></span><div><br>Can you give me some examples these "many lan=
guages" that use attributes for syntactic constructs? I'm hardly a=
n expert in numerous languages, so I'm not contesting your statement.</=
div></div></blockquote><div><br></div><div><a href=3D"http://stackoverflow.=
com/q/553857/1131467">http://stackoverflow.com/q/553857/1131467</a><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0<br></div><=
/div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>But the only one I=
know of that makes extensive use of attributes (or syntax like attributes)=
is C#. And those are primarily for tagging C# constructs with arbitrary da=
ta that can be fetched via reflection.<br>=C2=A0</div><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>many pre-ISO attributes provided by C++ =
compilers do this as well.</div></div></blockquote><br></span>Sure they do.=
Compilers had ways to set the alignment of types and various other things.=
But notice that, when it came time to <i>standardize</i> this functionalit=
y, they became keywords. When those proposals were initially made, they did=
indeed use attribute syntax. But various people on the committee made them=
actual keywords, because they wanted attributes to be reserved for things =
that compilers could ignore.<br><br>When it comes time to standardize featu=
res, actual features go into the language, not into attributes.<br></div><d=
iv class=3D""><div class=3D"h5">
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1148e62ac5e8df05257b9666--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 26 Nov 2015 23:16:54 -0800
Raw View
On Thursday 26 November 2015 09:02:02 Vadim Petrochenkov wrote:
> >Why don't we want some actual syntax here? Why is an "ad hoc" solution
>
> better than a real one?
>
> I explained why, to avoid new extending the language grammar and reuse
> existing attribute grammar instead.
Avoiding extending the language is not a reason for avoiding extending the
language.
Your proposal to use attributes is the "how". The question was "why"
attributes, instead of a non-attribute keyword?
> Many languages do this to introduce niche features, not important enough to
> deserve a full blown piece of syntax in the core language, many pre-ISO
> attributes provided by C++ compilers do this as well.
And the committee explicitly changed that. Take the example of forcing
alignment: prior to C++11, all compilers had it in some form of attribute. For
GCC and compatible compilers, it is __attribute__((aligned(n))).
C++11 added a keyword for it: alignas(n)
And you may note that this keyword is defined in the standard in the same
section as attributes. It just doesn't use the [[]] syntax.
--
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
--
---
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/.
.