Topic: Struct containing static constexpr instance of itself


Author: lodovico@giaretart.net
Date: Fri, 3 Apr 2015 06:39:53 -0700 (PDT)
Raw View
------=_Part_566_1790321384.1428068393735
Content-Type: multipart/alternative;
 boundary="----=_Part_567_1538122771.1428068393735"

------=_Part_567_1538122771.1428068393735
Content-Type: text/plain; charset=UTF-8


I'm not an expert of the C++ standard.

I had this piece of (illegal) C++ code. I understand why it can't work (at
least in C++11), but I'd like to know if it will be legal in some future
version of the language, because I find it quite logical and useful.

struct Cursor
{
    size_t row, column;

    static constexpr Cursor ZERO {0,0};
}

See also this StackOverflow question:
http://stackoverflow.com/questions/29432283/c-static-constexpr-field-with-incomplete-type

Thanks in advance.

                    Lodovico Giaretta

--

---
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_567_1538122771.1428068393735
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div>I'm not an expert of the C++ standard.</div><div>=
<br></div><div>I had this piece of (illegal) C++ code. I understand why it =
can't work (at least in C++11), but I'd like to know if it will be legal in=
 some future version of the language, because I find it quite logical and u=
seful.</div><div><br></div><div>struct Cursor</div><div>{</div><div>&nbsp; =
&nbsp; size_t row, column;</div><div><br></div><div>&nbsp; &nbsp; static co=
nstexpr Cursor ZERO {0,0};</div><div>}</div><div><br></div><div>See also th=
is StackOverflow question:</div><div>http://stackoverflow.com/questions/294=
32283/c-static-constexpr-field-with-incomplete-type<br></div><div><br></div=
><div>Thanks in advance.</div><div><br></div><div>&nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Lodovico Giaretta</div></div>

<p></p>

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

------=_Part_567_1538122771.1428068393735--
------=_Part_566_1790321384.1428068393735--

.


Author: David Krauss <potswa@gmail.com>
Date: Sat, 4 Apr 2015 12:52:05 +0800
Raw View
--Apple-Mail=_1195A056-C072-4894-B830-E88F8A83F489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9304=E2=80=9303, at 9:39 PM, lodovico@giaretart.net wrote:
>=20
>=20
> I'm not an expert of the C++ standard.
>=20
> I had this piece of (illegal) C++ code. I understand why it can't work (a=
t least in C++11), but I'd like to know if it will be legal in some future =
version of the language, because I find it quite logical and useful.

There=E2=80=99s no such proposal, but this is a known issue. The problem is=
 that static constexpr members are usable (as constant expressions) within =
subsequent member declarations. So you can have

struct Cursor
{
    size_t row, column;

    static constexpr Cursor ZERO {0,0};

    char foo[ ZERO.row + 1 ];
};

Waiting for the class to be complete before creating ZERO is incompatible w=
ith this commonplace usage. Any fix would need to propose more sophisticate=
d rules for processing declarations and initializers.

Note, these issues come up frequently enough that extra rules are implement=
ed in practice. GCC 5 accepts your example if a dummy template parameter is=
 added:

template< typename =3D void >
struct Cursor_gen
{
    size_t row, column;

    static constexpr Cursor ZERO {0,0};
};

typedef Cursor_gen<> Cursor;
Cursor x =3D Cursor::ZERO;

Clang rejects this, however there are other similar cases involving interde=
pendent member declarations that Clang accepts and GCC rejects. If I recall=
 correctly, the issue is tracked by a defect report without a proposed reso=
lution. Perhaps one issue for templates and one issue for different behavio=
r between templates and non-templates.

The fancy footwork amounts to lazy evaluation of declarators and initialize=
rs, which potentially introduces nondeterministic compile-time behavior. It=
=E2=80=99s a rough area for standardization, and IMHO it should all be firm=
ly illegal. If the alternative approaches need more polish, then evolution =
effort should focus on that.

--=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=_1195A056-C072-4894-B830-E88F8A83F489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9303, at 9:39 PM, <a href=3D"mailto:lodovico@giaretart.net" class=3D=
"">lodovico@giaretart.net</a> wrote:</div><br class=3D"Apple-interchange-ne=
wline"><div class=3D""><div dir=3D"ltr" class=3D""><br class=3D""><div clas=
s=3D"">I'm not an expert of the C++ standard.</div><div class=3D""><br clas=
s=3D""></div><div class=3D"">I had this piece of (illegal) C++ code. I unde=
rstand why it can't work (at least in C++11), but I'd like to know if it wi=
ll be legal in some future version of the language, because I find it quite=
 logical and useful.</div></div></div></blockquote><div><br class=3D""></di=
v><div>There=E2=80=99s no such proposal, but this is a known issue. The pro=
blem is that <font face=3D"Courier" class=3D"">static constexpr</font> memb=
ers are usable (as constant expressions) within subsequent member declarati=
ons. So you can have</div><br class=3D""><div class=3D""><div dir=3D"ltr" c=
lass=3D""><div class=3D""><font face=3D"Courier" class=3D"">struct Cursor</=
font></div><div class=3D""><font face=3D"Courier" class=3D"">{</font></div>=
<div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; size_t row,=
 column;</font></div><div class=3D""><font face=3D"Courier" class=3D""><br =
class=3D""></font></div><div class=3D""><font face=3D"Courier" class=3D"">&=
nbsp; &nbsp; static constexpr Cursor ZERO {0,0};</font></div><div class=3D"=
"><font face=3D"Courier" class=3D""><br class=3D""></font></div><div class=
=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; char foo[ ZERO.row + =
1 ];</font></div><div class=3D""><font face=3D"Courier" class=3D"">};</font=
></div><div class=3D""><br class=3D""></div><div class=3D"">Waiting for the=
 class to be complete before creating ZERO is incompatible with this common=
place usage. Any fix would need to propose more sophisticated rules for pro=
cessing declarations and initializers.</div><div class=3D""><br class=3D"">=
</div><div class=3D"">Note, these issues come up frequently enough that ext=
ra rules are implemented in practice. GCC 5 accepts your example if a dummy=
 template parameter is added:</div><div class=3D""><br class=3D""></div><di=
v class=3D""><div class=3D""><font face=3D"Courier" class=3D"">template&lt;=
 typename =3D void &gt;</font></div><div class=3D""><font face=3D"Courier" =
class=3D"">struct Cursor_gen</font></div><div class=3D""><font face=3D"Cour=
ier" class=3D"">{</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">&nbsp; &nbsp; size_t row, column;</font></div><div class=3D""><font f=
ace=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><fon=
t face=3D"Courier" class=3D"">&nbsp; &nbsp; static constexpr Cursor ZERO {0=
,0};</font></div><div class=3D""><span style=3D"font-family: Courier;" clas=
s=3D"">};</span></div><div class=3D""><span style=3D"font-family: Courier;"=
 class=3D""><br class=3D""></span></div><div class=3D""><span style=3D"font=
-family: Courier;" class=3D"">typedef Cursor_gen&lt;&gt; Cursor;</span></di=
v><div class=3D""><span style=3D"font-family: Courier;" class=3D"">Cursor x=
 =3D Cursor::ZERO;</span></div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">Clang rejects this, however there are other similar cases involvin=
g interdependent member declarations that Clang accepts and GCC rejects. If=
 I recall correctly, the issue is tracked by a defect report without a prop=
osed resolution. Perhaps one issue for templates and one issue for differen=
t behavior between templates and non-templates.</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">The fancy footwork amounts to lazy evaluatio=
n of declarators and initializers, which potentially introduces nondetermin=
istic compile-time behavior. It=E2=80=99s a rough area for standardization,=
 and IMHO it should all be firmly illegal. If the alternative approaches ne=
ed more polish, then evolution effort should focus on that.</div></div></di=
v></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_1195A056-C072-4894-B830-E88F8A83F489--

.


Author: lodovico@giaretart.net
Date: Wed, 8 Apr 2015 00:29:14 -0700 (PDT)
Raw View
------=_Part_4429_413179819.1428478154475
Content-Type: multipart/alternative;
 boundary="----=_Part_4430_1498587182.1428478154475"

------=_Part_4430_1498587182.1428478154475
Content-Type: text/plain; charset=UTF-8

Thank you for your reply, David.

--

---
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_4430_1498587182.1428478154475
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Thank you for your reply, David.</div>

<p></p>

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

------=_Part_4430_1498587182.1428478154475--
------=_Part_4429_413179819.1428478154475--

.