Topic: Shouldn't the constexpr variables be treated as
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Sun, 30 Mar 2014 13:55:58 -0700 (PDT)
Raw View
------=_Part_393_15446460.1396212958914
Content-Type: text/plain; charset=UTF-8
There is a recommendation to define all *constexpr* variables as static.
Shouldn't they be defined like that by default, meaning wherever we write
*constexpr double x = 5.1;*
the variable x will be assumed always to have *static storage duration*?
--
---
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_393_15446460.1396212958914
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>There is a recommendation to define all <strong>const=
expr</strong> variables as static. </div><div>Shouldn't they be defined lik=
e that by default, meaning wherever we write</div><div><strong><br></strong=
></div><div><strong>constexpr double x =3D 5.1;</strong> </div><div><br></d=
iv><div>the variable x will be assumed always to have <strong>s=
tatic storage duration</strong>?</div><div><br></div><div><br></div><div><b=
r></div><div><br></div><div><br></div><div><br></div><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 />
------=_Part_393_15446460.1396212958914--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 30 Mar 2014 23:02:28 +0200
Raw View
--047d7bf0c106a5ef8504f5d94076
Content-Type: text/plain; charset=ISO-8859-1
This would be a breaking change:
#include <cstdio>
void f(int y)
{
if (y == 0)
return;
constexpr int x = 3;
const int* p = &x;
std::printf("%p\n", p);
f(y-1);
}
int main()
{
f(3);
}
prints:
0x7fff125fdad8
0x7fff125fdaa8
0x7fff125fda78
whereas with static constexpr it prints:
0x400714
0x400714
0x400714
On Sun, Mar 30, 2014 at 10:55 PM, Mikhail Semenov <
mikhailsemenov1957@gmail.com> wrote:
> There is a recommendation to define all *constexpr* variables as static.
> Shouldn't they be defined like that by default, meaning wherever we write
>
> *constexpr double x = 5.1;*
>
> the variable x will be assumed always to have *static storage duration*?
>
>
>
>
>
>
>
> --
>
> ---
> 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/.
--047d7bf0c106a5ef8504f5d94076
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This would be a breaking change:<div><br></div><div><div>#=
include <cstdio></div><div><br></div><div>void f(int y)</div><div>{</=
div><div>=A0 =A0 =A0 =A0 if (y =3D=3D 0)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 return;</div><div><br>
</div><div>=A0 =A0 =A0 =A0 constexpr int x =3D 3;</div><div>=A0 =A0 =A0 =A0=
const int* p =3D &x;</div><div><br></div><div>=A0 =A0 =A0 =A0 std::pri=
ntf("%p\n", p);</div><div><br></div><div>=A0 =A0 =A0 =A0 f(y-1);<=
/div><div>}</div><div><br></div>
<div>int main()</div><div>{</div><div>=A0 =A0 =A0 =A0 f(3);</div><div>}</di=
v><div><br></div></div><div>prints:</div><div><br></div><div><div>0x7fff125=
fdad8</div><div>0x7fff125fdaa8</div><div>0x7fff125fda78</div></div><div><br=
></div>
<div>whereas with static constexpr it prints:</div><div><br></div><div><div=
>0x400714</div><div>0x400714</div><div>0x400714</div></div><div><br></div><=
div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">
On Sun, Mar 30, 2014 at 10:55 PM, Mikhail Semenov <span dir=3D"ltr"><<a =
href=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemen=
ov1957@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>There is a recommendation to define all <strong>const=
expr</strong> variables as static. </div><div>Shouldn't they be defined=
like that by default, meaning wherever we write</div><div><strong><br></st=
rong></div>
<div><strong>constexpr double x =3D 5.1;</strong> </div><div><br></div><div=
>the variable x will be assumed=A0 always to have =A0<strong>static storage=
duration</strong>?</div><span class=3D"HOEnZb"><font color=3D"#888888"><di=
v><br>
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div></font></span></div><span class=3D"HOEnZb"><font color=
=3D"#888888">
<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>
</font></span></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 <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 />
--047d7bf0c106a5ef8504f5d94076--
.
Author: Geoffrey Romer <gromer@google.com>
Date: Sun, 30 Mar 2014 20:17:48 -0700
Raw View
--001a113306b0f60ab804f5de7e2d
Content-Type: text/plain; charset=UTF-8
It sounds to me like you're saying that moving x from one part of the
address space to another would constitute a breaking change. Are you really
making that claim?
To put it another way, what in the current standard prevents that code from
printing this?
0x400714
0x400714
0x400714
And under this proposed change, what would prevent that code from printing
this?
0x7fff125fdad8
0x7fff125fdaa8
0x7fff125fda78
On Mar 30, 2014 2:02 PM, "Andrew Tomazos" <andrewtomazos@gmail.com> wrote:
> This would be a breaking change:
>
> #include <cstdio>
>
> void f(int y)
> {
> if (y == 0)
> return;
>
> constexpr int x = 3;
> const int* p = &x;
>
> std::printf("%p\n", p);
>
> f(y-1);
> }
>
> int main()
> {
> f(3);
> }
>
> prints:
>
> 0x7fff125fdad8
> 0x7fff125fdaa8
> 0x7fff125fda78
>
> whereas with static constexpr it prints:
>
> 0x400714
> 0x400714
> 0x400714
>
>
>
>
>
> On Sun, Mar 30, 2014 at 10:55 PM, Mikhail Semenov <
> mikhailsemenov1957@gmail.com> wrote:
>
>> There is a recommendation to define all *constexpr* variables as static.
>> Shouldn't they be defined like that by default, meaning wherever we write
>>
>> *constexpr double x = 5.1;*
>>
>> the variable x will be assumed always to have *static storage duration*
>> ?
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> ---
>> 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/.
>
--
---
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/.
--001a113306b0f60ab804f5de7e2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">It sounds to me like you're saying that moving x from on=
e part of the address space to another would constitute a breaking change. =
Are you really making that claim?</p>
<p dir=3D"ltr">To put it another way, what in the current standard prevents=
that code from printing this?</p>
<p dir=3D"ltr">0x400714<br>
0x400714<br>
0x400714</p>
<p dir=3D"ltr">And under this proposed change, what would prevent that code=
from printing this?</p>
<p dir=3D"ltr">0x7fff125fdad8<br>
0x7fff125fdaa8<br>
0x7fff125fda78</p>
<div class=3D"gmail_quote">On Mar 30, 2014 2:02 PM, "Andrew Tomazos&qu=
ot; <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com<=
/a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">This would be a breaking change:<div><br></div><div><div>#=
include <cstdio></div><div><br></div><div>void f(int y)</div><div>{</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (y =3D=3D 0)</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;</div><div>
<br>
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 constexpr int x =3D 3;</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 const int* p =3D &x;</div><div><br></div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::printf("%p\n", p);</div><div><br=
></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f(y-1);</div><div>}</div><div><br><=
/div>
<div>int main()</div><div>{</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 f(3);</di=
v><div>}</div><div><br></div></div><div>prints:</div><div><br></div><div><d=
iv>0x7fff125fdad8</div><div>0x7fff125fdaa8</div><div>0x7fff125fda78</div></=
div><div><br></div>
<div>whereas with static constexpr it prints:</div><div><br></div><div><div=
>0x400714</div><div>0x400714</div><div>0x400714</div></div><div><br></div><=
div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">
On Sun, Mar 30, 2014 at 10:55 PM, Mikhail Semenov <span dir=3D"ltr"><<a =
href=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemen=
ov1957@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>There is a recommendation to define all <strong>const=
expr</strong> variables as static. </div><div>Shouldn't they be defined=
like that by default, meaning wherever we write</div><div><strong><br></st=
rong></div>
<div><strong>constexpr double x =3D 5.1;</strong> </div><div><br></div><div=
>the variable x will be assumed=C2=A0 always to have =C2=A0<strong>static s=
torage duration</strong>?</div><span><font color=3D"#888888"><div><br>
</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>=
</div><div><br></div></font></span></div><span><font color=3D"#888888">
<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>
</font></span></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113306b0f60ab804f5de7e2d--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 30 Mar 2014 20:28:58 -0700
Raw View
Em dom 30 mar 2014, =E0s 20:17:48, Geoffrey Romer escreveu:
> To put it another way, what in the current standard prevents that code fr=
om
> printing this?
>=20
> 0x400714
> 0x400714
> 0x400714
>=20
> And under this proposed change, what would prevent that code from printin=
g
> this?
>=20
> 0x7fff125fdad8
> 0x7fff125fdaa8
> 0x7fff125fda78
The point is not the address, but the fact that currently the variable has=
=20
automatic storage duration and changing it to have static storage would be =
a=20
huge change.
That said, I think the OP was not talking about constexpr variables inside=
=20
functions, but about global ones.
--=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: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 30 Mar 2014 21:39:58 -0700 (PDT)
Raw View
------=_Part_686_12064553.1396240798301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer wrote:
>
> It sounds to me like you're saying that moving x from one part of the=20
> address space to another would constitute a breaking change. Are you real=
ly=20
> making that claim?
>
The feature of interest is whether the three addresses are equal or=20
distinct...
=20
> To put it another way, what in the current standard prevents that code=20
> from printing this?
>
> 0x400714
> 0x400714
> 0x400714
>
[intro.object]/6 prevents this:
Two objects that are not bit-=EF=AC=81elds may have the same address if one=
is a=20
subobject of the other, or if at least one is a base class subobject of=20
zero size and they are of di=EF=AC=80erent types; otherwise, *they shall ha=
ve=20
distinct addresses*
With automatic storage duration, the three objects must have distinct=20
addresses. The three above are not distinct addresses.
And under this proposed change, what would prevent that code from printing=
=20
> this?
>
> 0x7fff125fdad8
> 0x7fff125fdaa8
> 0x7fff125fda78
>
With static storage duration, all names x refer to the same object, so all=
=20
variables p must be equal. The above three addresses are not equal.
--=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_686_12064553.1396240798301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">It sound=
s to me like you're saying that moving x from one part of the address space=
to another would constitute a breaking change. Are you really making that =
claim?</p></blockquote><div>The feature of interest is whether the three ad=
dresses are equal or distinct...</div><div> </div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
<p dir=3D"ltr">To put it another way, what in the current standard prevents=
that code from printing this?</p>
<p dir=3D"ltr">0x400714<br>
0x400714<br>
0x400714</p></blockquote><div> [intro.object]/6 prevents this:</div><d=
iv><br></div><div>Two objects that are not bit-=EF=AC=81elds may have the s=
ame address if one is a subobject of the other, or if at least one is a bas=
e class subobject of zero size and they are of di=EF=AC=80erent types; othe=
rwise, <b>they shall have distinct addresses</b></div><div><br></div><div>W=
ith automatic storage duration, the three objects must have distinct addres=
ses. The three above are not distinct addresses.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">And under this proposed change, what would prevent that code=
from printing this?</p>
<p dir=3D"ltr">0x7fff125fdad8<br>
0x7fff125fdaa8<br>
0x7fff125fda78</p></blockquote><div>With static storage duration, all names=
x refer to the same object, so all variables p must be equal. The ab=
ove three addresses are not equal.</div><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 />
------=_Part_686_12064553.1396240798301--
.
Author: Geoffrey Romer <gromer@google.com>
Date: Sun, 30 Mar 2014 22:18:43 -0700
Raw View
--001a113a661473c16a04f5e02fbd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ah, I hadn't noticed the addresses were varying in the static example. I
grant that this could theoretically be a breaking change, but how much real
code would be broken? The kinds of things you'd have to do to notice the
difference seem like things that you'd normally never do with a constexpr
variable.
On Mar 30, 2014 9:39 PM, "Andrew Tomazos" <andrewtomazos@gmail.com> wrote:
> On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer wrote:
>>
>> It sounds to me like you're saying that moving x from one part of the
>> address space to another would constitute a breaking change. Are you rea=
lly
>> making that claim?
>>
> The feature of interest is whether the three addresses are equal or
> distinct...
>
>
>> To put it another way, what in the current standard prevents that code
>> from printing this?
>>
>> 0x400714
>> 0x400714
>> 0x400714
>>
> [intro.object]/6 prevents this:
>
> Two objects that are not bit-=EF=AC=81elds may have the same address if o=
ne is a
> subobject of the other, or if at least one is a base class subobject of
> zero size and they are of di=EF=AC=80erent types; otherwise, *they shall =
have
> distinct addresses*
>
> With automatic storage duration, the three objects must have distinct
> addresses. The three above are not distinct addresses.
>
> And under this proposed change, what would prevent that code from printin=
g
>> this?
>>
>> 0x7fff125fdad8
>> 0x7fff125fdaa8
>> 0x7fff125fda78
>>
> With static storage duration, all names x refer to the same object, so al=
l
> variables p must be equal. The above three addresses are not equal.
>
> --
>
> ---
> 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/.
>
--=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/.
--001a113a661473c16a04f5e02fbd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Ah, I hadn't noticed the addresses were varying in the s=
tatic example. I grant that this could theoretically be a breaking change, =
but how much real code would be broken? The kinds of things you'd have =
to do to notice the difference seem like things that you'd normally nev=
er do with a constexpr variable.</p>
<div class=3D"gmail_quote">On Mar 30, 2014 9:39 PM, "Andrew Tomazos&qu=
ot; <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com<=
/a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Monday, March 31, 2014 5:17:48 AM UTC+2, Geoffrey Romer=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">It sounds to =
me like you're saying that moving x from one part of the address space =
to another would constitute a breaking change. Are you really making that c=
laim?</p>
</blockquote><div>The feature of interest is whether the three addresses ar=
e equal or distinct...</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex">
<p dir=3D"ltr">To put it another way, what in the current standard prevents=
that code from printing this?</p>
<p dir=3D"ltr">0x400714<br>
0x400714<br>
0x400714</p></blockquote><div>=C2=A0[intro.object]/6 prevents this:</div><d=
iv><br></div><div>Two objects that are not bit-=EF=AC=81elds may have the s=
ame address if one is a subobject of the other, or if at least one is a bas=
e class subobject of zero size and they are of di=EF=AC=80erent types; othe=
rwise, <b>they shall have distinct addresses</b></div>
<div><br></div><div>With automatic storage duration, the three objects must=
have distinct addresses. =C2=A0The three above are not distinct addresses.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">And under this proposed change, what would prevent that code=
from printing this?</p>
<p dir=3D"ltr">0x7fff125fdad8<br>
0x7fff125fdaa8<br>
0x7fff125fda78</p></blockquote><div>With static storage duration, all names=
x refer to the same object, so all variables p must be equal. =C2=A0The ab=
ove three addresses are not equal.</div><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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113a661473c16a04f5e02fbd--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 30 Mar 2014 23:27:34 -0700
Raw View
Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu:
> Ah, I hadn't noticed the addresses were varying in the static example. I
> grant that this could theoretically be a breaking change, but how much re=
al
> code would be broken? The kinds of things you'd have to do to notice the
> difference seem like things that you'd normally never do with a constexpr
> variable.
I'd say that for anyone who caused the address to be taken, they really wan=
t=20
the current behaviour. So it will break a lot of code.
What's the benefit you were looking for?
--=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: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Mon, 31 Mar 2014 00:47:09 -0700 (PDT)
Raw View
------=_Part_1298_23890464.1396252029220
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The rules for odr-used in lambda are rather complicated, for a start: we've=
=20
got const, static const.
In general , it is recommended to write static constexpr anyway: why write=
=20
two words instead of one?
Another point is that it is constant, no matter how you look at it, why=20
should it be automatic?
=20
I haven't written a proposal yet, but I meant all the contexts of defining=
=20
constexpr variables:
top-level, member and local.
On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira wrote:
> Em dom 30 mar 2014, =C3=A0s 22:18:43, Geoffrey Romer escreveu:=20
> > Ah, I hadn't noticed the addresses were varying in the static example. =
I=20
> > grant that this could theoretically be a breaking change, but how much=
=20
> real=20
> > code would be broken? The kinds of things you'd have to do to notice th=
e=20
> > difference seem like things that you'd normally never do with a=20
> constexpr=20
> > variable.=20
>
> I'd say that for anyone who caused the address to be taken, they really=
=20
> want=20
> the current behaviour. So it will break a lot of code.=20
>
> What's the benefit you were looking for?=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=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 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_1298_23890464.1396252029220
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The rules for odr-used in lambda are rather complicat=
ed, for a start: we've got const, static const.</div><div>In general ,=
it is recommended to write static constexpr anyway: why write two words in=
stead of one?</div><div>Another point is that it is constant, no matter how=
you look at it, why should it be automatic?</div><div> </div><div>I h=
aven't written a proposal yet, but I meant all the contexts of definin=
g constexpr variables:</div><div>top-level, member and local.</div><div><br=
>On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira wrote:</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">Em dom 30 mar 2014, =C3=A0s 22:18:43, Geoffrey R=
omer escreveu:
<br>> Ah, I hadn't noticed the addresses were varying in the static exam=
ple. I
<br>> grant that this could theoretically be a breaking change, but how =
much real
<br>> code would be broken? The kinds of things you'd have to do to noti=
ce the
<br>> difference seem like things that you'd normally never do with a co=
nstexpr
<br>> variable.
<br>
<br>I'd say that for anyone who caused the address to be taken, they really=
want=20
<br>the current behaviour. So it will break a lot of code.
<br>
<br>What's the benefit you were looking for?
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_1298_23890464.1396252029220--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 00:47:23 -0700
Raw View
--089e013a1fcc19d76504f5e243de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sun, Mar 30, 2014 at 11:27 PM, Thiago Macieira <thiago@macieira.org>wrot=
e:
> Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu:
> > Ah, I hadn't noticed the addresses were varying in the static example. =
I
> > grant that this could theoretically be a breaking change, but how much
> real
> > code would be broken? The kinds of things you'd have to do to notice th=
e
> > difference seem like things that you'd normally never do with a constex=
pr
> > variable.
>
> I'd say that for anyone who caused the address to be taken, they really
> want
> the current behaviour. So it will break a lot of code.
>
Can you point to any code it would break? I'm having a hard time seeing why
you would ever want an automatic storage duration constexpr variable.
> What's the benefit you were looking for?
It'd fix this weirdness:
void f() {
constexpr auto x =3D { 1, 2, 3 }; // ill-formed
static constexpr auto y =3D { 1, 2, 3 }; // ok
// or more obviously...
constexpr auto &&a =3D 1; // ill-formed
static constexpr auto &&b =3D 1; // ok
}
The problem in these cases is that a temporary is lifetime-extended to the
lifetime of the variable (an array temporary in the first cases, and an int
temporary in the last cases), and a constexpr reference can't bind to an
automatic storage duration object.
It'd also remove the unnecessary stack usage in common cases like:
void g(const char*);
void h() {
constexpr char foo[] =3D "some string literal goes here";
g(foo);
}
Under the current language rules, the compiler is *required* to allocate
stack space and copy that string literal onto the stack each time through
this function (assuming it can't see the definition of 'g').
--=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/.
--089e013a1fcc19d76504f5e243de
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 S=
un, Mar 30, 2014 at 11:27 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey =
Romer escreveu:<br>
<div class=3D"">> Ah, I hadn't noticed the addresses were varying in=
the static example. I<br>
> grant that this could theoretically be a breaking change, but how much=
real<br>
> code would be broken? The kinds of things you'd have to do to noti=
ce the<br>
> difference seem like things that you'd normally never do with a co=
nstexpr<br>
> variable.<br>
<br>
</div>I'd say that for anyone who caused the address to be taken, they =
really want<br>
the current behaviour. So it will break a lot of code.<br></blockquote><div=
><br></div><div>Can you point to any code it would break? I'm having a =
hard time seeing why you would ever want an automatic storage duration cons=
texpr variable.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
What's the benefit you were looking for?</blockquote><div><br></div><di=
v>It'd fix this weirdness:</div><div><br></div><div>void f() {<br></div=
><div>=A0 constexpr auto x =3D { 1, 2, 3 }; // ill-formed</div><div>=A0 sta=
tic constexpr auto y =3D { 1, 2, 3 }; // ok</div>
<div><br></div><div>=A0 // or more obviously...</div><div>=A0 constexpr aut=
o &&a =3D 1; // ill-formed</div><div>=A0 static constexpr auto &=
;&b =3D 1; // ok</div><div>}</div><div><br></div><div>The problem in th=
ese cases is that a temporary is lifetime-extended to the lifetime of the v=
ariable (an array temporary in the first cases, and an int temporary in the=
last cases), and a constexpr reference can't bind to an automatic stor=
age duration object.</div>
<div><br></div><div>It'd also remove the unnecessary stack usage in com=
mon cases like:</div><div><br></div><div>void g(const char*);</div><div>voi=
d h() {</div><div>=A0 constexpr char foo[] =3D "some string literal go=
es here";</div>
<div>=A0 g(foo);</div><div>}</div><div><br></div><div>Under the current lan=
guage rules, the compiler is *required* to allocate stack space and copy th=
at string literal onto the stack each time through this function (assuming =
it can't see the definition of 'g').</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 <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 />
--089e013a1fcc19d76504f5e243de--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 31 Mar 2014 00:57:25 -0700
Raw View
--001a1136526af72cf904f5e266a2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 31, 2014 at 12:47 AM, Mikhail Semenov <
mikhailsemenov1957@gmail.com> wrote:
> The rules for odr-used in lambda are rather complicated, for a start:
> we've got const, static const.
> In general , it is recommended to write static constexpr anyway: why writ=
e
> two words instead of one?
> Another point is that it is constant, no matter how you look at it, why
> should it be automatic?
>
> I haven't written a proposal yet, but I meant all the contexts of definin=
g
> constexpr variables:
> top-level, member and local.
>
These are three very different changes.
For top-level variables, 'constexpr' already implies internal linkage (if
the variable is not a reference and is not declared with 'extern'), because
it gives it a const-qualified type. So I'm not sure that any change is
really warranted here.
For member variables, 'constexpr' implying 'static' would eliminate a
possible evolution route for the language (constexpr non-static data
members, whatever that might mean). The win here seems marginal, and it
would make code more difficult to read, because it would no longer be
obvious which members of a class are static. (thread_local implying static
is already pretty bad in this regard.) I'm not sure you'll find consensus
for a change here.
For local variables (declared 'constexpr' and not 'extern'), there are
several compelling advantages. This case seems easiest to argue, and
there's even implementation experience -- Clang's default compilation mode
treats large, local, constant-enough variables as if they were static.
(Here, "constant enough" means basically: a const-qualified type, a
constant-foldable initializer, a trivial destructor, and no mutable
members.) To my knowledge, only contrived test cases have ever had problems
with this behavior.
On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira wrote:
>
>> Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu:
>> > Ah, I hadn't noticed the addresses were varying in the static example.
>> I
>> > grant that this could theoretically be a breaking change, but how much
>> real
>> > code would be broken? The kinds of things you'd have to do to notice
>> the
>> > difference seem like things that you'd normally never do with a
>> constexpr
>> > variable.
>>
>> I'd say that for anyone who caused the address to be taken, they really
>> want
>> the current behaviour. So it will break a lot of code.
>>
>> What's the benefit you were looking for?
>> --
>> 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/.
>
--=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/.
--001a1136526af72cf904f5e266a2
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 M=
on, Mar 31, 2014 at 12:47 AM, Mikhail Semenov <span dir=3D"ltr"><<a href=
=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov19=
57@gmail.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>The rules for odr-used=
in lambda are rather complicated, for a start: we've got const, static=
const.</div>
<div>In general=A0, it is recommended to write static constexpr anyway: why=
write two words instead of one?</div><div>Another point is that it is cons=
tant, no matter how you look at it, why should it be automatic?</div><div>
=A0</div><div>I haven't written a proposal yet, but I=A0meant all the c=
ontexts of defining constexpr variables:</div><div>top-level, member and lo=
cal.</div></div></blockquote><div><br></div><div>These are three very diffe=
rent changes.</div>
<div><br></div><div>For top-level variables, 'constexpr' already im=
plies internal linkage (if the variable is not a reference and is not decla=
red with 'extern'), because it gives it a const-qualified type. So =
I'm not sure that any change is really warranted here.</div>
<div><br></div><div>For member variables, 'constexpr' implying '=
;static' would eliminate a possible evolution route for the language (c=
onstexpr non-static data members, whatever that might mean). The win here s=
eems marginal, and it would make code more difficult to read, because it wo=
uld no longer be obvious which members of a class are static. (thread_local=
implying static is already pretty bad in this regard.) I'm not sure yo=
u'll find consensus for a change here.</div>
<div><br></div><div>For local variables (declared 'constexpr' and n=
ot 'extern'), there are several compelling advantages. This case se=
ems easiest to argue, and there's even implementation experience -- Cla=
ng's default compilation mode treats large, local, constant-enough vari=
ables as if they were static. (Here, "constant enough" means basi=
cally: a const-qualified type, a constant-foldable initializer, a trivial d=
estructor, and no mutable members.) To my knowledge, only contrived test ca=
ses have ever had problems with this 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"><div dir=3D"ltr"><div><div cl=
ass=3D"h5"><div>On Monday, March 31, 2014 7:27:34 AM UTC+1, Thiago Macieira=
wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">Em dom 30 mar 2014, =E0s 22:18:43, Geoffrey Romer escreveu=
:
<br>> Ah, I hadn't noticed the addresses were varying in the static =
example. I
<br>> grant that this could theoretically be a breaking change, but how =
much real
<br>> code would be broken? The kinds of things you'd have to do to =
notice the
<br>> difference seem like things that you'd normally never do with =
a constexpr
<br>> variable.
<br>
<br>I'd say that for anyone who caused the address to be taken, they re=
ally want=20
<br>the current behaviour. So it will break a lot of code.
<br>
<br>What's the benefit you were looking for?
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=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>
<br></blockquote></div></div></div><div class=3D"HOEnZb"><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 />
--001a1136526af72cf904f5e266a2--
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Mon, 31 Mar 2014 01:49:34 -0700 (PDT)
Raw View
------=_Part_1433_2070144.1396255775109
Content-Type: text/plain; charset=UTF-8
I agree with the top level, that the values are already in the static
segment. I think if change is to be made, it should be done for both member
variables and local variables.
Otherwise, it will be confusing. After all it is recommended, that
constexpr members should be static.
Anyway, my point is that static segment should cover all the cases of
constexpr usage, no cherry-picking.
--
---
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_1433_2070144.1396255775109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I agree with the top level, that the values are alrea=
dy in the static segment. I think if change is to be made, it should be don=
e for both member variables and local variables.</div><div>Otherwise, it wi=
ll be confusing. After all it is recommended, that constexpr members should=
be static. </div><div> </div><div>Anyway, my point is that static seg=
ment should cover all the cases of constexpr usage, no cherry-picking. </di=
v><div> </div><div><br><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_1433_2070144.1396255775109--
.
Author: "Paul A. Tessier" <phernost@gmail.com>
Date: Mon, 31 Mar 2014 05:48:13 -0400
Raw View
This is a multi-part message in MIME format.
--------------090007080300010907090806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 03/31/2014 03:47 AM, Richard Smith wrote:
> On Sun, Mar 30, 2014 at 11:27 PM, Thiago Macieira <thiago@macieira.org=20
> <mailto:thiago@macieira.org>> wrote:
>
> Em dom 30 mar 2014, =C3=A0s 22:18:43, Geoffrey Romer escreveu:
> > Ah, I hadn't noticed the addresses were varying in the static
> example. I
> > grant that this could theoretically be a breaking change, but
> how much real
> > code would be broken? The kinds of things you'd have to do to
> notice the
> > difference seem like things that you'd normally never do with a
> constexpr
> > variable.
>
> I'd say that for anyone who caused the address to be taken, they
> really want
> the current behaviour. So it will break a lot of code.
>
>
> Can you point to any code it would break? I'm having a hard time=20
> seeing why you would ever want an automatic storage duration constexpr=20
> variable.
>
> What's the benefit you were looking for?
>
>
> It'd fix this weirdness:
>
> void f() {
> constexpr auto x =3D { 1, 2, 3 }; // ill-formed
> static constexpr auto y =3D { 1, 2, 3 }; // ok
>
> // or more obviously...
> constexpr auto &&a =3D 1; // ill-formed
> static constexpr auto &&b =3D 1; // ok
> }
>
> The problem in these cases is that a temporary is lifetime-extended to=20
> the lifetime of the variable (an array temporary in the first cases,=20
> and an int temporary in the last cases), and a constexpr reference=20
> can't bind to an automatic storage duration object.
>
> It'd also remove the unnecessary stack usage in common cases like:
>
> void g(const char*);
> void h() {
> constexpr char foo[] =3D "some string literal goes here";
> g(foo);
> }
>
> Under the current language rules, the compiler is *required* to=20
> allocate stack space and copy that string literal onto the stack each=20
> time through this function (assuming it can't see the definition of 'g').
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
I've slammed my head into this a few time while using constexpr. The=20
logical assumption is that it's static, and your examples point this out=20
nicely.
Until reading this thread I hadn't realized they weren't static.=20
Assuming you didn't want your variables to be static, why wouldn't you=20
just use const for a local copy?
class A {
// assumed to be staticin a sane world
constexpr auto cx =3D some_thing();
// non-static copy in every object
const auto x =3D cx;
};
Currently we have this conundrum:
class A {
// non-static, why?
constexpr auto cx =3D some_thing();
};
Which is internally translated to this:
// ok ...
static constexpr auto __hidden_internal_A_cx_ =3D some_thing();
class A {
// great a hidden copy every instantiation
constexpr auto cx =3D __hidden_internal_A_cx_;
};
Seems wasteful and limiting for no good reason I can think of. It also=20
places odd restrictions on constexpr that you showed above in your=20
examples. A constexpr variable *must* have static storage at some point,=20
it's baked in when the program is compiled. Allowing it to be treated as=20
non-static creates a weird set of corner cases.
--=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/.
--------------090007080300010907090806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 03/31/2014 03:47 AM, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQqnHgctE8Wgq3v-aDH-dRoY98Bodgg4n82m3vqLBDo6w7g@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Sun, Mar 30, 2014 at 11:27 PM,
Thiago Macieira <span dir=3D"ltr"><<a
moz-do-not-send=3D"true" 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:1px #ccc solid;padding-left:1ex">Em dom
30 mar 2014, =C3=A0s 22:18:43, Geoffrey Romer escreveu:<br>
<div class=3D"">> Ah, I hadn't noticed the addresses were
varying in the static example. I<br>
> grant that this could theoretically be a breaking
change, but how much real<br>
> code would be broken? The kinds of things you'd
have to do to notice the<br>
> difference seem like things that you'd normally
never do with a constexpr<br>
> variable.<br>
<br>
</div>
I'd say that for anyone who caused the address to be
taken, they really want<br>
the current behaviour. So it will break a lot of code.<br>
</blockquote>
<div><br>
</div>
<div>Can you point to any code it would break? I'm having a
hard time seeing why you would ever want an automatic
storage duration constexpr variable.</div>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
What's the benefit you were looking for?</blockquote>
<div><br>
</div>
<div>It'd fix this weirdness:</div>
<div><br>
</div>
<div>void f() {<br>
</div>
<div>=C2=A0 constexpr auto x =3D { 1, 2, 3 }; // ill-formed</di=
v>
<div>=C2=A0 static constexpr auto y =3D { 1, 2, 3 }; // ok</div=
>
<div><br>
</div>
<div>=C2=A0 // or more obviously...</div>
<div>=C2=A0 constexpr auto &&a =3D 1; // ill-formed</di=
v>
<div>=C2=A0 static constexpr auto &&b =3D 1; // ok</div=
>
<div>}</div>
<div><br>
</div>
<div>The problem in these cases is that a temporary is
lifetime-extended to the lifetime of the variable (an
array temporary in the first cases, and an int temporary
in the last cases), and a constexpr reference can't bind
to an automatic storage duration object.</div>
<div><br>
</div>
<div>It'd also remove the unnecessary stack usage in common
cases like:</div>
<div><br>
</div>
<div>void g(const char*);</div>
<div>void h() {</div>
<div>=C2=A0 constexpr char foo[] =3D "some string literal goes
here";</div>
<div>=C2=A0 g(foo);</div>
<div>}</div>
<div><br>
</div>
<div>Under the current language rules, the compiler is
*required* to allocate stack space and copy that string
literal onto the stack each time through this function
(assuming it can't see the definition of 'g').</div>
</div>
</div>
</div>
-- <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 <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
I've slammed my head into this a few time while using constexpr. The
logical assumption is that it's static, and your examples point this
out nicely.<br>
<br>
Until reading this thread I hadn't realized they weren't static.
Assuming you didn't want your variables to be static, why wouldn't
you just use const for a local copy?<br>
<br>
<tt>class A {</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 </tt><tt>// assumed to be static</tt><tt> i=
n a sane
world</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 constexpr auto cx =3D some_thing();</tt><tt=
><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 </tt><tt><tt><br>
=C2=A0=C2=A0=C2=A0 // non-static copy in every object</tt><tt><br>
</tt>=C2=A0=C2=A0=C2=A0 const auto x =3D cx;</tt><tt><br>
</tt><tt>};</tt><br>
<br>
Currently we have this conundrum:<br>
<br>
<tt>class A {</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 // non-static, why?</tt><tt><br>
</tt><tt>
=C2=A0=C2=A0=C2=A0 constexpr auto cx =3D some_thing();</tt><tt><br>
</tt><tt>};</tt><tt><br>
</tt><br>
Which is internally translated to this:<br>
<br>
<tt> // ok ...</tt><tt><br>
</tt><tt>static constexpr auto __hidden_internal_A_cx_ =3D
some_thing();</tt><tt><br>
</tt><tt><br>
class A {</tt><tt><br>
</tt><tt>=C2=A0=C2=A0=C2=A0 // great a hidden copy every instantiation<=
/tt><tt><br>
</tt><tt>
=C2=A0=C2=A0=C2=A0 constexpr auto cx =3D __hidden_internal_A_cx_;</tt=
><tt><br>
</tt><tt>
};</tt><br>
<br>
Seems wasteful and limiting for no good reason I can think of. It
also places odd restrictions on constexpr that you showed above in
your examples. A constexpr variable <b>must</b> have static storage
at some point, it's baked in when the program is compiled. Allowing
it to be treated as non-static creates a weird set of corner cases.<br>
<br>
</body>
</html>
<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 />
--------------090007080300010907090806--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 31 Mar 2014 09:57:33 -0500
Raw View
--047d7bd6c21ad7148004f5e8475c
Content-Type: text/plain; charset=ISO-8859-1
I'd like to separate the syntactical issue (whether or not to use 'static')
from the semantic issues.
On 31 March 2014 02:57, Richard Smith <richard@metafoo.co.uk> wrote:
>
> For member variables, 'constexpr' implying 'static' would eliminate a
> possible evolution route for the language (constexpr non-static data
> members, whatever that might mean). The win here seems marginal, and it
> would make code more difficult to read, because it would no longer be
> obvious which members of a class are static. (thread_local implying static
> is already pretty bad in this regard.) I'm not sure you'll find consensus
> for a change here.
>
For this reason, I am against saying that constexpr variables are also
implicitly static. I don't want that anywhere, as it just requires
developers to have more arcane knowledge to understand the code.
For local variables (declared 'constexpr' and not 'extern'), there are
> several compelling advantages. This case seems easiest to argue, and
> there's even implementation experience -- Clang's default compilation mode
> treats large, local, constant-enough variables as if they were static.
> (Here, "constant enough" means basically: a const-qualified type, a
> constant-foldable initializer, a trivial destructor, and no mutable
> members.) To my knowledge, only contrived test cases have ever had problems
> with this behavior.
>
I am not against requiring constexpr local variables to be explicitly
marked static.
--
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/.
--047d7bd6c21ad7148004f5e8475c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'd like to separate the syntactical issue (wheth=
er or not to use 'static') from the semantic issues.</div><div><br>=
</div>On 31 March 2014 02:57, Richard Smith <span dir=3D"ltr"><<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
a>></span> wrote:<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div=
dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br><=
/div><div>For member variables, 'constexpr' implying 'static=
9; would eliminate a possible evolution route for the language (constexpr n=
on-static data members, whatever that might mean). The win here seems margi=
nal, and it would make code more difficult to read, because it would no lon=
ger be obvious which members of a class are static. (thread_local implying =
static is already pretty bad in this regard.) I'm not sure you'll f=
ind consensus for a change here.</div>
</div></div></div></blockquote><div><br></div><div><div class=3D"gmail_quot=
e"><div>For this reason, I am against saying that constexpr variables are a=
lso implicitly static. =A0I don't want that anywhere, as it just requir=
es developers to have more arcane knowledge to understand the code.</div>
</div></div><div><br></div><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"><div dir=3D"ltr"><div class=3D"=
gmail_extra">
<div class=3D"gmail_quote">
<div>For local variables (declared 'constexpr' and not 'extern&=
#39;), there are several compelling advantages. This case seems easiest to =
argue, and there's even implementation experience -- Clang's defaul=
t compilation mode treats large, local, constant-enough variables as if the=
y were static. (Here, "constant enough" means basically: a const-=
qualified type, a constant-foldable initializer, a trivial destructor, and =
no mutable members.) To my knowledge, only contrived test cases have ever h=
ad problems with this behavior.<br>
</div></div></div></div></blockquote><div><br></div><div><div class=3D"gmai=
l_quote">I am not against requiring constexpr local variables to be explici=
tly marked static.</div></div></div>-- <br>=A0Nevin ":-)" 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 <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 />
--047d7bd6c21ad7148004f5e8475c--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 31 Mar 2014 08:02:01 -0700 (PDT)
Raw View
------=_Part_540_31857339.1396278121518
Content-Type: text/plain; charset=UTF-8
On Monday, March 31, 2014 7:18:43 AM UTC+2, Geoffrey Romer wrote:
>
> Ah, I hadn't noticed the addresses were varying in the static example. I
> grant that this could theoretically be a breaking change, but how much real
> code would be broken? The kinds of things you'd have to do to notice the
> difference seem like things that you'd normally never do with a constexpr
> variable.
>
A breaking change means that one or more well-formed C++ programs would
have to exhibit different behavior under the change. My example shows one
such program, proving it is a breaking change.
The committee can and does make breaking changes if they feel the number of
real world programs that would be so broken is small enough compared to the
benefit of the change.
How many real-world programs would be broken by this change is a good
question. I'm not really sure - however if the variable x in question was
a complex user-defined literal type, and not just an int, the p address
would be the this pointer within its member functions. In this light, are
we so sure the three objects sharing the same storage couldn't cause real
world problems? What if they have mutable data members?
In general, constexpr asserts that an entity can be used in certain ways at
compile-time, it doesn't mean that the entity cannot also be used at
run-time as well. Arguments can and have been made that we should also be
able to assert that an entity may not be used at run-time, but this isn't
what constexpr does.
--
---
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_540_31857339.1396278121518
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, March 31, 2014 7:18:43 AM UTC+2, Geoffrey Romer=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">Ah, I ha=
dn't noticed the addresses were varying in the static example. I grant that=
this could theoretically be a breaking change, but how much real code woul=
d be broken? The kinds of things you'd have to do to notice the difference =
seem like things that you'd normally never do with a constexpr variable.</p=
></blockquote><div>A breaking change means that one or more well-formed C++=
programs would have to exhibit different behavior under the change. =
My example shows one such program, proving it is a breaking change.</div><d=
iv><br></div><div>The committee can and does make breaking changes if they =
feel the number of real world programs that would be so broken is small eno=
ugh compared to the benefit of the change.</div><div><br></div><div>How man=
y real-world programs would be broken by this change is a good question. &n=
bsp;I'm not really sure - however if the variable x in question was a compl=
ex user-defined literal type, and not just an int, the p address would be t=
he <font face=3D"courier new, monospace">this</font> pointer within its mem=
ber functions. In this light, are we so sure the three objects sharin=
g the same storage couldn't cause real world problems? What if they h=
ave mutable data members?</div><div><br></div><div>In general, constexpr as=
serts that an entity can be used in certain ways at compile-time, it doesn'=
t mean that the entity cannot also be used at run-time as well. Argum=
ents can and have been made that we should also be able to assert that an e=
ntity may not be used at run-time, but this isn't what constexpr does.</div=
><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 />
------=_Part_540_31857339.1396278121518--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 2 Apr 2014 01:46:27 +0800
Raw View
--Apple-Mail=_4629F802-BB5D-42CE-8B81-F7EBD0FD5FAD
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-31, at 5:48 PM, Paul A. Tessier <phernost@gmail.com> wrote:
> A constexpr variable must have static storage at some point, it's baked in when the program is compiled. Allowing it to be treated as non-static creates a weird set of corner cases.
I'm pretty sure you're allowed to embed runtime data in a constexpr object using mutable.
This thread does touch on the behavior of extern constexpr, which I believe to be a defect... need to write a paper...
--
---
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/.
--Apple-Mail=_4629F802-BB5D-42CE-8B81-F7EBD0FD5FAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–31, at 5:48 PM, Paul A. Tessier <<a href=3D"mailto:pherno=
st@gmail.com">phernost@gmail.com</a>> wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">A constexpr variable <b>must</b> have st=
atic storage
at some point, it's baked in when the program is compiled. Allowing
it to be treated as non-static creates a weird set of corner cases.</di=
v>
</div></blockquote></div><br><div>I’m pretty sure you’re al=
lowed to embed runtime data in a constexpr object using <font face=3D"Couri=
er">mutable</font>.</div><div><br></div><div>This thread does touch on the =
behavior of <font face=3D"Courier">extern constexpr</font>, which I be=
lieve to be a defect… need to write a paper…</div><div><br></=
div></body></html>
<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 />
--Apple-Mail=_4629F802-BB5D-42CE-8B81-F7EBD0FD5FAD--
.
Author: "Paul A. Tessier" <phernost@gmail.com>
Date: Tue, 01 Apr 2014 14:11:01 -0400
Raw View
This is a multi-part message in MIME format.
--------------010605070300050201030905
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 04/01/2014 01:46 PM, David Krauss wrote:
>
> On 2014=E2=80=9303=E2=80=9331, at 5:48 PM, Paul A. Tessier <phernost@gmai=
l.com=20
> <mailto:phernost@gmail.com>> wrote:
>
>> A constexpr variable *must* have static storage at some point, it's=20
>> baked in when the program is compiled. Allowing it to be treated as=20
>> non-static creates a weird set of corner cases.
>
> I=E2=80=99m pretty sure you=E2=80=99re allowed to embed runtime data in a=
constexpr=20
> object using mutable.
>
> This thread does touch on the behavior of extern constexpr, which I=20
> believe to be a defect=E2=80=A6 need to write a paper=E2=80=A6
>
>
You still'd get a copy from the immutable static version. The copy just=20
happens to have a mutable field, which in my opinion isn't really=20
constexpr object as much as it is a const object with a mutable field.
Were basically stuck with poor semantics and too much variability on=20
something that has hard defined limits. All constexpr objects have=20
static storage, irregardless of extra features that confound their use.=20
Therefore I believe the syntax should be cleaned to show this, but we're=20
probably too far into the weeds now to ever fix this in a clear and=20
concise manner. Making all constexpr objects static by default is at=20
least a step in the right direction.
--=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/.
--------------010605070300050201030905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 04/01/2014 01:46 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:B2799926-D60C-43C4-A06A-C1796C33B4B8@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
<br>
<div>
<div>On 2014=E2=80=9303=E2=80=9331, at 5:48 PM, Paul A. Tessier <=
;<a
moz-do-not-send=3D"true" href=3D"mailto:phernost@gmail.com">phe=
rnost@gmail.com</a>>
wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<meta content=3D"text/html; charset=3DUTF-8"
http-equiv=3D"Content-Type">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">A constexpr variable <b>must</b>
have static storage at some point, it's baked in when the
program is compiled. Allowing it to be treated as
non-static creates a weird set of corner cases.</div>
</div>
</blockquote>
</div>
<br>
<div>I=E2=80=99m pretty sure you=E2=80=99re allowed to embed runtime =
data in a
constexpr object using <font face=3D"Courier">mutable</font>.</div>
<div><br>
</div>
<div>This thread does touch on the behavior of=C2=A0<font
face=3D"Courier">extern constexpr</font>, which I believe to be
a defect=E2=80=A6 need to write a paper=E2=80=A6</div>
<div><br>
</div>
<br>
</blockquote>
<br>
You still'd get a copy from the immutable static version. The copy
just happens to have a <font face=3D"Courier">mutable</font> field,
which in my opinion isn't really <font face=3D"Courier">constexpr</font=
>
object as much as it is a <font face=3D"Courier">const</font> object
with a <font face=3D"Courier">mutable</font> field.<br>
<br>
Were basically stuck with poor semantics and too much variability on
something that has hard defined limits. All <font face=3D"Courier">cons=
texpr</font>
objects have static storage, irregardless of extra features that
confound their use. Therefore I believe the syntax should be cleaned
to show this, but we're probably too far into the weeds now to ever
fix this in a clear and concise manner. Making all <font
face=3D"Courier">constexpr</font> objects static by default is at
least a step in the right direction.<br>
<br>
</body>
</html>
<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 />
--------------010605070300050201030905--
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Tue, 1 Apr 2014 12:00:10 -0700 (PDT)
Raw View
------=_Part_540_32226965.1396378810248
Content-Type: text/plain; charset=UTF-8
I see three issues here:
(1) Is there a strong case for* mutable* fields in a *constexpr* object?
(2) The advantage of having *constexpr *variables in a *static* segment is:
(a) in a lambda expression, you don't have to capture them because
they are *static* (automatically), no matter on which level they are
defined;
(b) if they are used as class members, you don't have to write
special assignment operators for class objects;
(despite what some of you think, both these issues make it easier to use
them by novices; as I mentioned before "odr-used" definition is too
complicated; missing the word *static* leads to unexpected results; the
language looks cleaner if static is implied);
(3) There is an issue is with the other semantics of the word "static"
(this word, on its own, is confusing enough): should* constexpr* variables
be hidden from external usage? (I actually did not argue this case, but
maybe it should be considered as well).
Actually, in C++, there is a general approach not to use the word *static *quite
often: it's pretty bad with member variables (leads to difficult-to-find
errors); on top level, it can be avoided by using anonymous namespaces. It
looks like it's going to be used often with *constexpr*.
--
---
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_540_32226965.1396378810248
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I see three issues here:</div><div>(1) Is there a str=
ong case for<strong> mutable</strong> fields in a <strong>constexpr</strong=
> object?</div><div>(2) The advantage of having <strong>constexpr </strong>=
variables in a <strong>static</strong> segment is:</div><div> &n=
bsp; (a) in a lambda expression, you don't have to capture them becau=
se they are <strong>static</strong> (automatically), no matter on which lev=
el they are defined;</div><div> (b) if they a=
re used as class members, you don't have to write special assignment operat=
ors for class objects;</div><div>(despite what some of you think, both thes=
e issues make it easier to use them by novices; as I mentioned before "odr-=
used" definition is too complicated; missing the word <strong>static</stron=
g> leads to unexpected results; the language looks cleaner if static is imp=
lied);</div><div>(3) There is an issue is with the other semantic=
s of the word "static" (this word, on its own, is confusing enough): s=
hould<strong> constexpr</strong> variables be hidden from external usage? (=
I actually did not argue this case, but maybe it should be considered as we=
ll).<br></div><div><br></div><div>Actually, in C++, there is a general appr=
oach not to use the word <strong>static </strong>quite often: it's pr=
etty bad with member variables (leads to difficult-to-find errors); on top =
level, it can be avoided by using anonymous namespaces. It looks like it's =
going to be used often with <strong>constexpr</strong>. </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_540_32226965.1396378810248--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 1 Apr 2014 12:05:29 -0700
Raw View
--089e0111dc6802393704f5ffda2b
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 1, 2014 at 10:46 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-03-31, at 5:48 PM, Paul A. Tessier <phernost@gmail.com> wrote:
>
> A constexpr variable *must* have static storage at some point, it's
> baked in when the program is compiled. Allowing it to be treated as
> non-static creates a weird set of corner cases.
>
>
> I'm pretty sure you're allowed to embed runtime data in a constexpr object
> using mutable.
>
> This thread does touch on the behavior of extern constexpr, which I
> believe to be a defect... need to write a paper...
>
What do you think is wrong with 'extern constexpr'? It seems practically
useful and consistent with the other language rules...
--
---
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/.
--089e0111dc6802393704f5ffda2b
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, Apr 1, 2014 at 10:46 AM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.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 style=3D"word-wrap:break-word"><div cla=
ss=3D""><br><div><div>On 2014–03–31, at 5:48 PM, Paul A. Tessie=
r <<a href=3D"mailto:phernost@gmail.com" target=3D"_blank">phernost@gmai=
l.com</a>> wrote:</div>
<br><blockquote type=3D"cite">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>A constexpr variable <b>must</b> have static storage
at some point, it's baked in when the program is compiled. Allowing
it to be treated as non-static creates a weird set of corner cases.</di=
v>
</div></blockquote></div><br></div><div>I’m pretty sure you&rsquo=
;re allowed to embed runtime data in a constexpr object using <font face=3D=
"Courier">mutable</font>.</div><div><br></div><div>This thread does touch o=
n the behavior of <font face=3D"Courier">extern constexpr</font>, whic=
h I believe to be a defect… need to write a paper…</div>
</div></blockquote><div><br></div><div>What do you think is wrong with '=
;extern constexpr'? It seems practically useful and consistent with the=
other language rules... </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 <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 />
--089e0111dc6802393704f5ffda2b--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 1 Apr 2014 12:10:51 -0700
Raw View
--047d7bacc59e2b237304f5ffed71
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 1, 2014 at 12:00 PM, Mikhail Semenov <
mikhailsemenov1957@gmail.com> wrote:
> I see three issues here:
> (1) Is there a strong case for* mutable* fields in a *constexpr* object?
>
Yes.
template<typename T> struct static_init { mutable T value; };
// this object is guaranteed to have static initialization and trivial
destruction (safe for access before main() and during program shutdown),
not const
constexpr static_init<my_type> my_object = { ... };
(2) The advantage of having *constexpr *variables in a *static* segment is:
> (a) in a lambda expression, you don't have to capture them because
> they are *static* (automatically), no matter on which level they are
> defined;
> (b) if they are used as class members, you don't have to write
> special assignment operators for class objects;
>
I don't follow this. If they're class members, they're already required to
be static.
Another is, static storage duration constexpr variables can refer to
lifetime-extended temporaries (and thus can be std::initializer_lists);
automatic (or thread) storage duration constexpr variables cannot.
> (despite what some of you think, both these issues make it easier to use
> them by novices; as I mentioned before "odr-used" definition is too
> complicated; missing the word *static* leads to unexpected results; the
> language looks cleaner if static is implied);
> (3) There is an issue is with the other semantics of the word "static"
> (this word, on its own, is confusing enough): should* constexpr*variables be hidden from external usage? (I actually did not argue this
> case, but maybe it should be considered as well).
>
They already are (except in the corner case of a constexpr reference),
because const type implies internal linkage.
--
---
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/.
--047d7bacc59e2b237304f5ffed71
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, Apr 1, 2014 at 12:00 PM, Mikhail Semenov <span dir=3D"ltr"><<a href=
=3D"mailto:mikhailsemenov1957@gmail.com" target=3D"_blank">mikhailsemenov19=
57@gmail.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>I see three issues her=
e:</div><div>(1) Is there a strong case for<strong> mutable</strong> fields=
in a <strong>constexpr</strong> object?</div>
</div></blockquote><div><br></div><div>Yes.</div><div><br></div><div>templa=
te<typename T> struct static_init { mutable T value; };</div><div><br=
></div><div>// this object is guaranteed to have static initialization and =
trivial destruction (safe for access before main() and during program shutd=
own), not const</div>
<div>constexpr static_init<my_type> my_object =3D { ... };</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>(2) The adva=
ntage of having <strong>constexpr </strong>variables in a <strong>static</s=
trong> segment is:</div>
<div>=A0=A0=A0=A0 (a) in a lambda expression, you don't have to capture=
them because they are <strong>static</strong> (automatically), no matter o=
n which level they are defined;</div><div>=A0=A0=A0=A0 (b) if=A0 they are u=
sed as class members, you don't have to write special assignment operat=
ors for class objects;</div>
</div></blockquote><div><br></div><div>I don't follow this. If they'=
;re class members, they're already required to be static.</div><div><br=
></div><div>Another is, static storage duration constexpr variables can ref=
er to lifetime-extended temporaries (and thus can be std::initializer_lists=
); automatic (or thread) storage duration constexpr variables cannot.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>(despite=
what some of you think, both these issues make it easier to use them by no=
vices; as I mentioned before "odr-used" definition is too complic=
ated; missing the word <strong>static</strong> leads to unexpected results;=
the language looks cleaner if static is implied);</div>
<div>(3) There is an=A0issue is=A0with the other semantics of the word &quo=
t;static" (this word, on its own, is=A0confusing enough): should<stron=
g> constexpr</strong> variables be hidden from external usage? (I actually =
did not argue this case, but maybe it should be considered as well).</div>
</div></blockquote><div><br></div><div>They already are (except in the corn=
er case of a constexpr reference), because const type implies internal link=
age.</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 <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 />
--047d7bacc59e2b237304f5ffed71--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 2 Apr 2014 03:35:33 +0800
Raw View
--Apple-Mail=_CCD353F5-8F14-4572-B854-325B49F310DC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-04-02, at 3:05 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> What do you think is wrong with 'extern constexpr'? It seems practically =
useful and consistent with the other language rules...=20
I think we already discussed this? Perhaps it was Ville. I'll summarize.
Internal linkage, which is the default, does not allow safe usage in inline=
function bodies, particularly for objects of class type.
External linkage requires definition in exactly one TU. Successfully using =
extern constexpr requires non-constexpr declarations in all other TUs.
There needs to be a way to declare constexpr class objects without an inlin=
e accessor function. The C++11 standard already has a couple of them, and t=
hey cannot safely be used in inline functions. As a result, there must be a=
ton of ill-formed code out there, with ODR optional diagnosis.
Perhaps extern constexpr isn't broken, because you can still access the obj=
ect from another TU without constexpr, but it seems pretty clear to me that=
the status quo is far from optimal.
The paper would essentially point out how broken things are, and how little=
could break by changing things. There's no need, for example, to disallow =
non-constexpr extern declarations from linking to an extern constexpr varia=
ble with identical definitions in several TUs. So all valid usages of exter=
n constexpr would remain so.
--=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/.
--Apple-Mail=_CCD353F5-8F14-4572-B854-325B49F310DC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04–02, at 3:05 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>What do you think is wrong=
with 'extern constexpr'? It seems practically useful and consistent with t=
he other language rules… </div></div></div></div></blockquote><=
div><br></div>I think we already discussed this? Perhaps it was Ville. I&rs=
quo;ll summarize.</div><div><br></div><div>Internal linkage, which is the d=
efault, does not allow safe usage in inline function bodies, particularly f=
or objects of class type.</div><div><br></div><div>External linkage require=
s definition in exactly one TU. Successfully using <font face=3D"Courier">e=
xtern constexpr</font> requires non-constexpr declarations in all other TUs=
..</div><div><br></div><div>There needs to be a way to declare constexpr cla=
ss objects without an inline accessor function. The C++11 standard already =
has a couple of them, and they cannot safely be used in inline functions. A=
s a result, there must be a ton of ill-formed code out there, with ODR opti=
onal diagnosis.</div><div><br></div><div>Perhaps <font face=3D"Courier">ext=
ern constexpr</font> isn’t broken, because you can still access =
the object from another TU without <font face=3D"Courier">constexpr</font>,=
but it seems pretty clear to me that the status quo is far from optimal.</=
div><div><br></div><div>The paper would essentially point out how broken th=
ings are, and how little could break by changing things. There’s no n=
eed, for example, to disallow non-constexpr extern declarations from linkin=
g to an extern constexpr variable with identical definitions in several TUs=
.. So all valid usages of <font face=3D"Courier">extern constexpr</font> wou=
ld remain so.</div><div><br></div></body></html>
<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 />
--Apple-Mail=_CCD353F5-8F14-4572-B854-325B49F310DC--
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Tue, 1 Apr 2014 12:59:08 -0700 (PDT)
Raw View
------=_Part_9_649374.1396382348142
Content-Type: text/plain; charset=UTF-8
>I don't follow this. If they're class members, they're already required to
be static.
I only meant "members in a class", which may belong to the class or an
object of this class:
struct A
{
constexpr int x = 5;
int y;
};
vs
struct A1
{
static constexpr int x = 5;
int y;
};
You have to write a special assignment for A, but not for A1.
________________________________________________________________
As for lambda:
#include <iostream>
const int& f(int a, const int& x) { return x;}
int f(char a, int x) { return x;}
int main()
{
constexpr int x = 17; // it will be OK if static is used here!
auto g = [](auto a)
{
const int i = f(a,x);
std::cout << "i:" << i << std::endl;
};
g('a'); // okay: does not capture x
g(17); // error: captures , but ok with static
};
_____________________________________________________________
>They already are (except in the corner case of a constexpr reference),
because const type implies internal linkage.
Yes, they are. I mentioned that I did not consider this case in my initial
message.
Show trimmed content
--
---
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_9_649374.1396382348142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><font color=3D"#ff00ff">>I don't follow this. If t=
hey're class members, they're already required to be static.</font></div><d=
iv><font color=3D"#ff00ff"><br></font></div><div><font color=3D"#000000">I =
only meant "members in a class", which may belong to the class or an o=
bject of this class:</font></div><div><font color=3D"#000000"><br></font></=
div><div><font color=3D"#000000">struct A</font></div><div><font color=3D"#=
000000">{</font></div><div><font color=3D"#000000"> =
constexpr int x =3D 5; </font></div><div><font color=3D"#000000">&nb=
sp; int y;</font></div><div><font color=3D"#000000"=
>};</font></div><p><br></p><div><font color=3D"#ff00ff">vs</font></div><div=
><font color=3D"#ff00ff"><br></font></div><div><font color=3D"#ff00ff"><div=
><font color=3D"#000000">struct A1</font></div><div><font color=3D"#000000"=
>{</font></div><div><font color=3D"#000000"> =
static constexpr int x =3D 5;</font></div><div><font color=3D"#000000">&nbs=
p; int y;</font></div><div><font color=3D"#000000">=
};</font></div></font></div><div><font color=3D"#ff00ff"><br></font></div><=
div><font color=3D"#ff00ff"><font color=3D"#000000">You have to write a spe=
cial assignment for A, but not for A1.</font></font></div><div><font color=
=3D"#000000">______________________________________________________________=
__</font></div><div><font color=3D"#000000">As for lambda:</font></div><div=
><font color=3D"#000000"><div><br></div><div>#include <iostream></div=
><div><br></div><div>const int& f(int a, const int& x) { return x;}=
</div><div>int f(char a, int x) { return x;}</div><div><br></div><div>int m=
ain() </div><div>{</div><div> constexpr int x =3D 17; // =
it will be OK if static is used here!</div><div> auto g =3D []=
(auto a) </div><div> {</div><div> &nb=
sp; const int i =3D f(a,x);</div><div> std::cout=
<< "i:" << i << std::endl;</div><div> };</d=
iv><div> g('a'); // okay: does not capture x</div><div> =
g(17); // error: captures , but ok with static</div><div>};</div><di=
v>_____________________________________________________________</div><div><=
br></div><div><div><font color=3D"#9900ff">>They already are (except in =
the corner case of a constexpr reference), because const type implies inter=
nal linkage.</font></div><div><font color=3D"#9900ff"><br></font></div><div=
><font color=3D"#000000">Yes, they are. I mentioned that I did not consider=
this case in my initial message.</font></div><div><br></div><a class=
=3D"gwt-Anchor" aria-hidden=3D"true" style=3D"display: none;">Show trimmed =
content</a> <div class=3D"GKA2MROCFFB" style=3D"display: none;"><div></div>=
</div><div></div><div></div><div style=3D"display: none;"></div><div style=
=3D"display: none;"></div><div style=3D"display: none;"></div><div><div cla=
ss=3D"GKA2MROCBXD"></div></div><div class=3D"GKA2MROCNCB"><div class=3D"GKA=
2MROCMCB GKA2MROCCGB"><div><div style=3D"display: inline-block;"><div style=
=3D"display: none;"></div></div> </div></div></div></div></font></div><div>=
<font color=3D"#000000"><br></font></div><div><font color=3D"#000000"><br><=
/font></div><div><font color=3D"#000000"><br></font></div><div><font color=
=3D"#000000"><br></font></div><div><font color=3D"#ff00ff"><font color=3D"#=
000000"></font><br></font>
</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_9_649374.1396382348142--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 2 Apr 2014 04:20:18 +0800
Raw View
--Apple-Mail=_4F1EADDE-9934-44A9-BD47-E99562373AE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-04-02, at 3:10 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> I don't follow this. If they're class members, they're already required t=
o be static.
Hmm, I didn't know this. Isn't it over-restrictive?
As with the other cases in this thread, I would expect nonstatic constexpr =
to maybe produce a warning in the event of no mutable members, but otherwis=
e the default meaning would seem to be fine, except that a mem-initializer =
or aggregate initialization should be forbidden. A brace-or-equal-initializ=
er would be required.
A use case would be a subobject with some tags or flags interpreted by temp=
late code (or, say, controlling conditional branches), along with a variabl=
e payload. The workaround would be to use instances of std::integral_consta=
nt with implicit conversion, but that's not nearly as elegant. The tags and=
flags would be runtime variant when inspected through a non-constexpr path=
..
> (despite what some of you think, both these issues make it easier to use =
them by novices; as I mentioned before "odr-used" definition is too complic=
ated; missing the word static leads to unexpected results; the language loo=
ks cleaner if static is implied);
> (3) There is an issue is with the other semantics of the word "static" (t=
his word, on its own, is confusing enough): should constexpr variables be h=
idden from external usage? (I actually did not argue this case, but maybe i=
t should be considered as well).
>=20
> They already are (except in the corner case of a constexpr reference), be=
cause const type implies internal linkage.
Well, unless you say extern. But I don't see how internal (static) is clean=
er; quite the opposite. Usually constants don't vary between TUs, and the O=
DR is much simpler for external linkage.
--=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/.
--Apple-Mail=_4F1EADDE-9934-44A9-BD47-E99562373AE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04–02, at 3:10 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>I don't follow this. If th=
ey're class members, they're already required to be static.</div></div></di=
v></div></blockquote><div><br></div><div>Hmm, I didn’t know this. Isn=
’t it over-restrictive?</div><div><br></div><div>As with the other ca=
ses in this thread, I would expect nonstatic constexpr to maybe produce a w=
arning in the event of no mutable members, but otherwise the default meanin=
g would seem to be fine, except that a mem-initializer or aggregate initial=
ization should be forbidden. A brace-or-equal-initializer would be required=
..</div><div><br></div><div>A use case would be a subobject with some tags o=
r flags interpreted by template code (or, say, controlling conditional bran=
ches), along with a variable payload. The workaround would be to use instan=
ces of <font face=3D"Courier">std::integral_constant</font> with impli=
cit conversion, but that’s not nearly as elegant. The tags and flags =
would be runtime variant when inspected through a non-constexpr path.</div>=
<div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><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(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto;"><div dir=3D"ltr"><div>(despite what some of you thi=
nk, both these issues make it easier to use them by novices; as I mentioned=
before "odr-used" definition is too complicated; missing the word <strong>=
static</strong> leads to unexpected results; the language looks cleaner if =
static is implied);</div>
<div>(3) There is an issue is with the other semantics of the wor=
d "static" (this word, on its own, is confusing enough): should<strong=
> constexpr</strong> variables be hidden from external usage? (I actually d=
id not argue this case, but maybe it should be considered as well).</div>
</div></blockquote><div><br></div><div>They already are (except in the corn=
er case of a constexpr reference), because const type implies internal link=
age.</div></div></div></div></blockquote><div><br></div><div>Well, unless y=
ou say <font face=3D"Courier">extern</font>. But I don’t see how inte=
rnal (<font face=3D"Courier">static</font>) is cleaner; quite the opposite.=
Usually constants don’t vary between TUs, and the ODR is much simple=
r for external linkage.</div></div><br></body></html>
<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 />
--Apple-Mail=_4F1EADDE-9934-44A9-BD47-E99562373AE1--
.