On 25 August 2016 at 16:47, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
> I searched this list for similar suggestions, but of course I may
> have overlooked something.
>
> I frequently use the following pattern:
>
>     enum class FooBar { KEKS, DOSE };
>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>
> I use the strings to in error messages, verbose output, etc.
>
>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>
> This has some disadvantages, e.g. enums with explicitly stated values
> may have gaps, negative values and may be defined out of order.
> Also, changing the enum also means changing the strings manually.
>
> What I'd like to see:
>
>     static_cast<char const *>(FooBar::KEKS) // "KEKS"


See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZiqeTBGir3fKehHzju6YDtbigdvThW%3DCsgkBSaExjrug%40mail.gmail.com.

.

------=_Part_261_424528993.1472138231816
Content-Type: multipart/alternative;
 boundary="----=_Part_262_1782411998.1472138231816"

------=_Part_262_1782411998.1472138231816
Content-Type: text/plain; charset=UTF-8

Note that enums can have duplicate values, which throws a wrench into the
reflection works.  E.g.:

enum class FooBar { KEKS = 2, DOSE = 2 };

What will the result be for:

FooBar fb = FooBar::KEKS;
cout << static_cast<char const*>(fb) ;




On Thursday, August 25, 2016 at 8:47:34 AM UTC-5, Kamikaze Dominic Fandrey
wrote:
>
> I searched this list for similar suggestions, but of course I may
> have overlooked something.
>
> I frequently use the following pattern:
>
>     enum class FooBar { KEKS, DOSE };
>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>
> I use the strings to in error messages, verbose output, etc.
>
>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>
> This has some disadvantages, e.g. enums with explicitly stated values
> may have gaps, negative values and may be defined out of order.
> Also, changing the enum also means changing the strings manually.
>
> What I'd like to see:
>
>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>
> I think this would be simple to add to an existing compiler and it's
> very unlikely to clash with existing code, because you have to jump
> through some hoops to cast a strongly typed enum to a pointer type.
>
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e585a9d9-c120-48a9-9ab7-2cbfbc206038%40isocpp.org.

------=_Part_262_1782411998.1472138231816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Note that enums can have duplicate values, which throws a =
wrench into the reflection works.=C2=A0 E.g.:<br><br><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">FooBar</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> KEKS </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> DOSE </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">2</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></div></c=
ode></div><br>What will the result be for:<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #606;" class=3D"styled-by-prettify">FooBar</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> fb </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">FooBar</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
KEKS</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>cout </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">const</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*&gt;(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">fb</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n></div></code></div><br><br><br><br>On Thursday, August 25, 2016 at 8:47:3=
4 AM UTC-5, Kamikaze Dominic Fandrey wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">I searched this list for similar suggestions, but of course I =
may
<br>have overlooked something.
<br>
<br>I frequently use the following pattern:
<br>
<br>=C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };
<br>=C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS&quot;, &quot;DO=
SE&quot;};
<br>
<br>I use the strings to in error messages, verbose output, etc.
<br>
<br>=C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(<wbr>FooBar::KEKS)] // &=
quot;KEKS&quot;
<br>
<br>This has some disadvantages, e.g. enums with explicitly stated values
<br>may have gaps, negative values and may be defined out of order.
<br>Also, changing the enum also means changing the strings manually.
<br>
<br>What I&#39;d like to see:
<br>
<br>=C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::KEKS) // &quot;KE=
KS&quot;
<br>
<br>I think this would be simple to add to an existing compiler and it&#39;=
s
<br>very unlikely to clash with existing code, because you have to jump
<br>through some hoops to cast a strongly typed enum to a pointer type.
<br>
<br>--=20
<br>A: Because it fouls the order in which people normally read text.
<br>Q: Why is top-posting such a bad thing?
<br>A: Top-posting.
<br>Q: What is the most annoying thing on usenet and in e-mail?
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e585a9d9-c120-48a9-9ab7-2cbfbc206038%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e585a9d9-c120-48a9-9ab7-2cbfbc206038=
%40isocpp.org</a>.<br />

------=_Part_262_1782411998.1472138231816--

------=_Part_261_424528993.1472138231816--

.

On 08/25/2016 09:12 AM, Ville Voutilainen wrote:
> On 25 August 2016 at 16:47, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
>> I searched this list for similar suggestions, but of course I may
>> have overlooked something.
>>
>> I frequently use the following pattern:
>>
>>     enum class FooBar { KEKS, DOSE };
>>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>>
>> I use the strings to in error messages, verbose output, etc.
>>
>>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>>
>> This has some disadvantages, e.g. enums with explicitly stated values
>> may have gaps, negative values and may be defined out of order.
>> Also, changing the enum also means changing the strings manually.
>>
>> What I'd like to see:
>>
>>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>
>
> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html
>
Could you be more specific.  I grepped for enumName, for char const*,
and scanned briefly for other strings that might show where
conversion from enum to char const* might be, without success :(


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/npn3iq%244ah%241%40blaine.gmane.org.

.

--94eb2c0b147a21a932053ae76241
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 25, 2016 at 8:41 AM, Larry Evans <cppljevans@suddenlink.net>
wrote:

> On 08/25/2016 09:12 AM, Ville Voutilainen wrote:
>
>> On 25 August 2016 at 16:47, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
>>
>>> I searched this list for similar suggestions, but of course I may
>>> have overlooked something.
>>>
>>> I frequently use the following pattern:
>>>
>>>     enum class FooBar { KEKS, DOSE };
>>>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>>>
>>> I use the strings to in error messages, verbose output, etc.
>>>
>>>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>>>
>>> This has some disadvantages, e.g. enums with explicitly stated values
>>> may have gaps, negative values and may be defined out of order.
>>> Also, changing the enum also means changing the strings manually.
>>>
>>> What I'd like to see:
>>>
>>>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>>>
>>
>>
>> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html
>>
>> Could you be more specific.  I grepped for enumName, for char const*,
> and scanned briefly for other strings that might show where
> conversion from enum to char const* might be, without success :(


In that proposal, the operation you want is spelled
get_name_v<reflexpr(FooBar::KEKS)>.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmFXB6WY%3DuUt6Qh3PzTGek9e0Av-0h4TLnFzXSY6mAR%2BA%40mail.gmail.com.

--94eb2c0b147a21a932053ae76241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 25, 2016 at 8:41 AM, Larry Evans <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:cppljevans@suddenlink.net" target=3D"_blank" class=3D"cremed">cppljev=
ans@suddenlink.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">On 08/25/2016 09:12 AM, Ville Voutilainen wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 25 August 2016 at 16:47, Dominic Fandrey &lt;<a href=3D"mailto:kamikaze@=
bsdforen.de" target=3D"_blank" class=3D"cremed">kamikaze@bsdforen.de</a>&gt=
; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I searched this list for similar suggestions, but of course I may<br>
have overlooked something.<br>
<br>
I frequently use the following pattern:<br>
<br>
=C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };<br>
=C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS&quot;, &quot;DOSE&q=
uot;};<br>
<br>
I use the strings to in error messages, verbose output, etc.<br>
<br>
=C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(Foo<wbr>Bar::KEKS)] // &quot=
;KEKS&quot;<br>
<br>
This has some disadvantages, e.g. enums with explicitly stated values<br>
may have gaps, negative values and may be defined out of order.<br>
Also, changing the enum also means changing the strings manually.<br>
<br>
What I&#39;d like to see:<br>
<br>
=C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::KEKS) // &quot;KEKS&q=
uot;<br>
</blockquote>
<br>
<br>
See <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.=
html" rel=3D"noreferrer" target=3D"_blank" class=3D"cremed">http://open-std=
..org/JTC1/SC22/<wbr>WG21/docs/papers/2016/p0194r1.<wbr>html</a><br>
<br>
</blockquote></span>
Could you be more specific.=C2=A0 I grepped for enumName, for char const*,<=
br>
and scanned briefly for other strings that might show where<br>
conversion from enum to char const* might be, without success :(</blockquot=
e><div><br></div><div>In that proposal, the operation you want is spelled g=
et_name_v&lt;reflexpr(FooBar::KEKS)&gt;.</div><div><br></div><div>Jeffrey=
=C2=A0</div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXmFXB6WY%3DuUt6Qh3PzTGek9e0Av-0=
h4TLnFzXSY6mAR%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmFXB6W=
Y%3DuUt6Qh3PzTGek9e0Av-0h4TLnFzXSY6mAR%2BA%40mail.gmail.com</a>.<br />

--94eb2c0b147a21a932053ae76241--

.

--047d7bf0dbf09d2175053ae76ee1
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross <antiquarktv@gmail.com> wrote:

> Note that enums can have duplicate values, which throws a wrench into the
> reflection works.  E.g.:
>
> enum class FooBar { KEKS = 2, DOSE = 2 };
>
> What will the result be for:
>
> FooBar fb = FooBar::KEKS;
> cout << static_cast<char const*>(fb) ;
>

that only "throws a wrench into the reflection works" as proposed by the
OP, by no means generally. the WG proposal linked (A) would not support
this because it is static and (B) has presumably already accounted for such
possibilities and effortlessly gets around them with compile-time
wizardry... again, *presumably.*

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG3EF5_%2BYtu9k3h8gtYdmLCkkA0e109u2RfmPtForNMcA%40mail.gmail.com.

--047d7bf0dbf09d2175053ae76ee1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 25, 2016 at 4:17 PM, Derek Ross <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:antiquarktv@gmail.com" target=3D"_blank">antiquarktv@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr">Note that enums can have duplicate values, which throws a wrench =
into the reflection works.=C2=A0 E.g.:<br><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px;word-wrap:break-word"><code><div><span style=3D"color:rgb(0,0,136=
)">enum</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color=
:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> </span><span s=
tyle=3D"color:rgb(102,0,102)">FooBar</span><span style=3D"color:rgb(0,0,0)"=
> </span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:=
rgb(0,0,0)"> KEKS </span><span style=3D"color:rgb(102,102,0)">=3D</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">=
2</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:r=
gb(0,0,0)"> DOSE </span><span style=3D"color:rgb(102,102,0)">=3D</span><spa=
n style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">2=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(10=
2,102,0)">};</span><span style=3D"color:rgb(0,0,0)"> </span></div></code></=
div><br>What will the result be for:<br><br><div style=3D"background-color:=
rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-wi=
dth:1px;word-wrap:break-word"><code><div><span style=3D"color:rgb(102,0,102=
)">FooBar</span><span style=3D"color:rgb(0,0,0)"> fb </span><span style=3D"=
color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(102,0,102)">FooBar</span><span style=3D"color:rgb(10=
2,102,0)">::</span><span style=3D"color:rgb(0,0,0)">KEKS</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>cout=
 </span><span style=3D"color:rgb(102,102,0)">&lt;&lt;</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">static_cast</s=
pan><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:rg=
b(0,0,136)">char</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(102,102,0)">*&=
gt;(</span><span style=3D"color:rgb(0,0,0)">fb</span><span style=3D"color:r=
gb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">;</span></div></code></div></div></blockquote><di=
v><br></div><div>that only &quot;throws a wrench into the reflection works&=
quot; as proposed by the OP, by no means generally. the WG proposal linked =
(A) would not support this because it is static and (B) has presumably alre=
ady accounted for such possibilities and effortlessly gets around them with=
 compile-time wizardry... again, <i>presumably.</i><br></div></div></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhG3EF5_%2BYtu9k3h8gtYdmLCkkA0e1=
09u2RfmPtForNMcA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG3EF5_%2=
BYtu9k3h8gtYdmLCkkA0e109u2RfmPtForNMcA%40mail.gmail.com</a>.<br />

--047d7bf0dbf09d2175053ae76ee1--

.

On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:
> On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross <antiquarktv@gmail.com> wrote=
:
>=20
> >=20
> > Note that enums can have duplicate values, which throws a wrench into t=
he
> > reflection works.=C2=A0=C2=A0E.g.:
> >=20
> > enum class FooBar { KEKS =3D 2, DOSE =3D 2 };
> >=20
> > What will the result be for:
> >=20
> > FooBar fb =3D FooBar::KEKS;
> > cout << static_cast<char const*>(fb) ;
> >=20
> that only "throws a wrench into the reflection works" as proposed by the
> OP, by no means generally. the WG proposal linked (A) would not support
> this because it is static and (B) has presumably already accounted for su=
ch
> possibilities and effortlessly gets around them with compile-time
> wizardry... again, *presumably.*
>=20

It's not really useful for what I'm doing if it's not runtime capable.

For multiple mentions I'd just leave it implementation defined or
establish a simple first definition rule.

I am assuming that in most cases overlapping definitions are aliases:

=C2=A0 =C2=A0 enum class Flags { NONE =3D 0, COMPATIBLE =3D 1, COMPAT =3D 1=
, EXPERIMENTAL =3D 2 };

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1472148645.17129.15.camel%40bsdforen.de.

.

--001a1146a0dcde811f053ae978e2
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 25, 2016 at 7:10 PM, Dominic Fandrey <kamikaze@bsdforen.de>
wrote:

> On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:
> > On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross <antiquarktv@gmail.com>
> wrote:
> >
> > >
> > > Note that enums can have duplicate values, which throws a wrench into
> the
> > > reflection works.  E.g.:
> > >
> > > enum class FooBar { KEKS = 2, DOSE = 2 };
> > >
> > > What will the result be for:
> > >
> > > FooBar fb = FooBar::KEKS;
> > > cout << static_cast<char const*>(fb) ;
> > >
> > that only "throws a wrench into the reflection works" as proposed by the
> > OP, by no means generally. the WG proposal linked (A) would not support
> > this because it is static and (B) has presumably already accounted for
> such
> > possibilities and effortlessly gets around them with compile-time
> > wizardry... again, *presumably.*
> >
>
> It's not really useful for what I'm doing if it's not runtime capable.
>


Then I am not an 'insider' and might well be wrong... but based on how
static C++ is, I would not expect such a feature to arrive, or really any
other dynamic features, beyond the 'necessary evils' of
dynamic_cast/typeinfo.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGBkjL_dw%2BfMx_GgYwZmg6O-gKLTVJVanerYU8AZN-kLA%40mail.gmail.com.

--001a1146a0dcde811f053ae978e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 25, 2016 at 7:10 PM, Dominic Fandrey <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kamikaze@bsdforen.de" target=3D"_blank">kamikaze@bsdforen.de</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Th=
u, 2016-08-25 at 16:55 +0100, D. B. wrote:<br>
&gt; On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross &lt;<a href=3D"mailto:anti=
quarktv@gmail.com">antiquarktv@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Note that enums can have duplicate values, which throws a wrench =
into the<br>
&gt; &gt; reflection works.=C2=A0=C2=A0E.g.:<br>
&gt; &gt;<br>
&gt; &gt; enum class FooBar { KEKS =3D 2, DOSE =3D 2 };<br>
&gt; &gt;<br>
&gt; &gt; What will the result be for:<br>
&gt; &gt;<br>
&gt; &gt; FooBar fb =3D FooBar::KEKS;<br>
&gt; &gt; cout &lt;&lt; static_cast&lt;char const*&gt;(fb) ;<br>
&gt; &gt;<br>
&gt; that only &quot;throws a wrench into the reflection works&quot; as pro=
posed by the<br>
&gt; OP, by no means generally. the WG proposal linked (A) would not suppor=
t<br>
&gt; this because it is static and (B) has presumably already accounted for=
 such<br>
&gt; possibilities and effortlessly gets around them with compile-time<br>
</span>&gt; wizardry... again, *presumably.*<br>
&gt;<br>
<br>
It&#39;s not really useful for what I&#39;m doing if it&#39;s not runtime c=
apable.<br></blockquote><div><br><br></div><div>Then I am not an &#39;insid=
er&#39; and might well be wrong... but based on how static C++ is, I would =
not expect such a feature to arrive, or really any other dynamic features, =
beyond the &#39;necessary evils&#39; of dynamic_cast/typeinfo.=C2=A0 <br></=
div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGBkjL_dw%2BfMx_GgYwZmg6O-gKLTV=
JVanerYU8AZN-kLA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGBkjL_dw=
%2BfMx_GgYwZmg6O-gKLTVJVanerYU8AZN-kLA%40mail.gmail.com</a>.<br />

--001a1146a0dcde811f053ae978e2--

.

Em quinta-feira, 25 de agosto de 2016, =C3=A0s 19:21:52 PDT, D. B. escreveu=
:
> On Thu, Aug 25, 2016 at 7:10 PM, Dominic Fandrey <kamikaze@bsdforen.de>
> > It's not really useful for what I'm doing if it's not runtime capable.
>=20
> Then I am not an 'insider' and might well be wrong... but based on how
> static C++ is, I would not expect such a feature to arrive, or really any
> other dynamic features, beyond the 'necessary evils' of
> dynamic_cast/typeinfo.

Dynamic reflection is to be a library solution on top of the core language=
=20
static reflection.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1791010.Brkuk3F7Nx%40tjmaciei-mobl1.

.

--001a113fe54075d944053ae9b97a
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 25, 2016 at 11:10 AM, Dominic Fandrey <kamikaze@bsdforen.de>
wrote:

> On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:
> > On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross <antiquarktv@gmail.com>
> wrote:
> >
> > >
> > > Note that enums can have duplicate values, which throws a wrench into
> the
> > > reflection works.  E.g.:
> > >
> > > enum class FooBar { KEKS = 2, DOSE = 2 };
> > >
> > > What will the result be for:
> > >
> > > FooBar fb = FooBar::KEKS;
> > > cout << static_cast<char const*>(fb) ;
> > >
> > that only "throws a wrench into the reflection works" as proposed by the
> > OP, by no means generally. the WG proposal linked (A) would not support
> > this because it is static and (B) has presumably already accounted for
> such
> > possibilities and effortlessly gets around them with compile-time
> > wizardry... again, *presumably.*
> >
>
> It's not really useful for what I'm doing if it's not runtime capable.
>
> For multiple mentions I'd just leave it implementation defined or
> establish a simple first definition rule.
>
> I am assuming that in most cases overlapping definitions are aliases:
>
>     enum class Flags { NONE = 0, COMPATIBLE = 1, COMPAT = 1, EXPERIMENTAL
> = 2 };
>

The static reflection proposal lets you iterate at compile time over all
the enum values inside an enumeration, which lets you write a generic
library function to do what you want. That function will have to pick an
answer to FlagsString(1), and we're hoping that some libraries appear to
show us some options before we put a choice into the standard library.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmhWtTBeEwBheNOApVwiCkMB6Hwqg8n%2Bxjt5aMvoW%2Bpbg%40mail.gmail.com.

--001a113fe54075d944053ae9b97a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 25, 2016 at 11:10 AM, Dominic Fandrey <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kamikaze@bsdforen.de" target=3D"_blank" class=3D"cremed">kamikaz=
e@bsdforen.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D"">On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:<br>
&gt; On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross &lt;<a href=3D"mailto:anti=
quarktv@gmail.com" class=3D"cremed">antiquarktv@gmail.com</a>&gt; wrote:<br=
>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Note that enums can have duplicate values, which throws a wrench =
into the<br>
&gt; &gt; reflection works.=C2=A0=C2=A0E.g.:<br>
&gt; &gt;<br>
&gt; &gt; enum class FooBar { KEKS =3D 2, DOSE =3D 2 };<br>
&gt; &gt;<br>
&gt; &gt; What will the result be for:<br>
&gt; &gt;<br>
&gt; &gt; FooBar fb =3D FooBar::KEKS;<br>
&gt; &gt; cout &lt;&lt; static_cast&lt;char const*&gt;(fb) ;<br>
&gt; &gt;<br>
&gt; that only &quot;throws a wrench into the reflection works&quot; as pro=
posed by the<br>
&gt; OP, by no means generally. the WG proposal linked (A) would not suppor=
t<br>
&gt; this because it is static and (B) has presumably already accounted for=
 such<br>
&gt; possibilities and effortlessly gets around them with compile-time<br>
</span>&gt; wizardry... again, *presumably.*<br>
&gt;<br>
<br>
It&#39;s not really useful for what I&#39;m doing if it&#39;s not runtime c=
apable.<br>
<br>
For multiple mentions I&#39;d just leave it implementation defined or<br>
establish a simple first definition rule.<br>
<br>
I am assuming that in most cases overlapping definitions are aliases:<br>
<br>
=C2=A0 =C2=A0 enum class Flags { NONE =3D 0, COMPATIBLE =3D 1, COMPAT =3D 1=
, EXPERIMENTAL =3D 2 };<span class=3D""><br></span></blockquote><div>=C2=A0=
</div><div>The static reflection proposal lets you iterate at compile time =
over all the enum values inside an enumeration, which lets you write a gene=
ric library function to do what you want. That function will have to pick a=
n answer to FlagsString(1), and we&#39;re hoping that some libraries appear=
 to show us some options before we put a choice into the standard library.<=
/div><div><br></div><div>Jeffrey</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXmhWtTBeEwBheNOApVwiCkMB6Hwqg8n=
%2Bxjt5aMvoW%2Bpbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmhWtTB=
eEwBheNOApVwiCkMB6Hwqg8n%2Bxjt5aMvoW%2Bpbg%40mail.gmail.com</a>.<br />

--001a113fe54075d944053ae9b97a--

.

>> It's not really useful for what I'm doing if it's not runtime
>> capable.
>
> Then I am not an 'insider' and might well be wrong... but based on how
> static C++ is, I would not expect such a feature to arrive, or really
> any other dynamic features, beyond the 'necessary evils' of
> dynamic_cast/typeinfo.

Well, you'd use `get_enum_values` to obtain all declared values, use
some TMP to build an array of the corresponding names, and then look up
your run-time value in that array.  Wrap into a function and you're good
to go.  I presume that writing a generic solution for this (working for
all enumeration types) would be fairly straight-forward.

Anyway, I don't think that the fact that static reflection -- should it
ever enter the language -- *could* be used to solve a problem means that
we cannot include a feature *now* that does the same task in a more
accessible manner.  (As I've said before, I'd prefer a library solution,
not `static_cast` magic.)  If standard library implementors can
re-implement that feature as a thin wrapper around static reflection in
the future, that's fine.  Looking up a human-readable name for an
enumeration constant is a reasonable thing a beginner C++ programmer
might want to do.  Writing template meta-programs using static
reflection is not an option for them and still not very convenient for
those programmers who would in theory be able to do it.

If you want an analogy, we already have, for example,
`std::underlying_type` in the standard library now and I don't think
that this is a potentially bad thing.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87bn0gwu6y.fsf%40klammler.eu.

.

Oops, I've written "as I've said before" in my last post but just
realized that I've failed to post to the list and accidentally only
replied to the OP then.  So here is my initial reply again for the
public.

I do think that this is a frequent issue and C++ ought to provide a
solution for it.  However, I think that a more comprehensive approach is
needed that also addresses the other conveniences that users of, say,
Java are used to.  Most importantly, obtaining an array of all
enumeration constants.  I have other useful features in mind (such as
the inverse of your function, looking up an enumeration constant
by-name) but they can be implemented in terms of the mentioned features.
I don't think that `static_cast`ing offers a pretty solution to these
use-cases.  Perhaps worst of all, it cannot be done in a library so
users cannot extend it for their own code.  If you are interested in
expanding the scope of your proposal, I'm looking forward to
collaborating with you on a proposal for this issue.  I'm currently
working on a code-generation approach to enumerations in order to
explore the space of useful features but I got somewhat distracted on
this.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8737lswtss.fsf%40gmail.com.

.

------=_Part_14_1920714079.1472153938051
Content-Type: multipart/alternative;
 boundary="----=_Part_15_677767136.1472153938051"

------=_Part_15_677767136.1472153938051
Content-Type: text/plain; charset=UTF-8

On Thursday, August 25, 2016 at 2:59:52 PM UTC-4, Moritz Klammler wrote:
>
> >> It's not really useful for what I'm doing if it's not runtime
> >> capable.
> >
> > Then I am not an 'insider' and might well be wrong... but based on how
> > static C++ is, I would not expect such a feature to arrive, or really
> > any other dynamic features, beyond the 'necessary evils' of
> > dynamic_cast/typeinfo.
>
> Well, you'd use `get_enum_values` to obtain all declared values, use
> some TMP to build an array of the corresponding names, and then look up
> your run-time value in that array.  Wrap into a function and you're good
> to go.  I presume that writing a generic solution for this (working for
> all enumeration types) would be fairly straight-forward.
>
> Anyway, I don't think that the fact that static reflection -- should it
> ever enter the language -- *could* be used to solve a problem means that
> we cannot include a feature *now* that does the same task in a more
> accessible manner.  (As I've said before, I'd prefer a library solution,
> not `static_cast` magic.)  If standard library implementors can
> re-implement that feature as a thin wrapper around static reflection in
> the future, that's fine.  Looking up a human-readable name for an
> enumeration constant is a reasonable thing a beginner C++ programmer
> might want to do.  Writing template meta-programs using static
> reflection is not an option for them and still not very convenient for
> those programmers who would in theory be able to do it.
>

The problem is that it's not a library feature. Well, not yet. Until static
reflection happens, it is *impossible* to implement these sorts of things
without either compiler magic or macros.

And therefore, you're not really asking for a library feature. You're
asking for a *compiler* feature, that just so happens to be exposed via the
library.

Obviously there are several places where it's impossible to implement a
standard library feature without using compiler hooks. The majority of
chapter 18, and many of the type traits rely on such things. But it's
important to recognize that what you're asking for is not a *normal*
library feature. It's not, "here's a library that I've implemented, let's
do that." That makes it a bit more complex.

I would say that the best thing your proposal could do is be defined *in
terms of static reflection*. It's not so much that your proposal should
*require* it. But at all times, you're making sure that the library
interface you develop could *eventually* be implemented using static
reflection.

And this would probably help the static reflection proposal too, since
they've got to make sure that the tools people need to do things like this
are available.

The other thing that's important to keep in mind is that runtime reflection
takes up *memory*. Those strings for enums have to come from somewhere.
Those arrays of enumeration values have to live somewhere. Whatever library
system you come up with needs to have a way to deal with that. You cannot
just force every enumerator in a program to have runtime reflected data.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58f032a8-65d5-4194-9ae1-817e0442ad23%40isocpp.org.

------=_Part_15_677767136.1472153938051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, August 25, 2016 at 2:59:52 PM UTC-4, Moritz K=
lammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt; It&#39;=
s not really useful for what I&#39;m doing if it&#39;s not runtime
<br>&gt;&gt; capable.
<br>&gt;
<br>&gt; Then I am not an &#39;insider&#39; and might well be wrong... but =
based on how
<br>&gt; static C++ is, I would not expect such a feature to arrive, or rea=
lly
<br>&gt; any other dynamic features, beyond the &#39;necessary evils&#39; o=
f
<br>&gt; dynamic_cast/typeinfo.
<br>
<br>Well, you&#39;d use `get_enum_values` to obtain all declared values, us=
e
<br>some TMP to build an array of the corresponding names, and then look up
<br>your run-time value in that array. =C2=A0Wrap into a function and you&#=
39;re good
<br>to go. =C2=A0I presume that writing a generic solution for this (workin=
g for
<br>all enumeration types) would be fairly straight-forward.
<br>
<br>Anyway, I don&#39;t think that the fact that static reflection -- shoul=
d it
<br>ever enter the language -- *could* be used to solve a problem means tha=
t
<br>we cannot include a feature *now* that does the same task in a more
<br>accessible manner. =C2=A0(As I&#39;ve said before, I&#39;d prefer a lib=
rary solution,
<br>not `static_cast` magic.) =C2=A0If standard library implementors can
<br>re-implement that feature as a thin wrapper around static reflection in
<br>the future, that&#39;s fine. =C2=A0Looking up a human-readable name for=
 an
<br>enumeration constant is a reasonable thing a beginner C++ programmer
<br>might want to do. =C2=A0Writing template meta-programs using static
<br>reflection is not an option for them and still not very convenient for
<br>those programmers who would in theory be able to do it.
<br></blockquote><div><br>The problem is that it&#39;s not a library featur=
e. Well, not yet. Until static reflection happens, it is <i>impossible</i> =
to implement these sorts of things without either compiler magic or macros.=
<br><br>And therefore, you&#39;re not really asking for a library feature. =
You&#39;re asking for a <i>compiler</i> feature, that just so happens to be=
 exposed via the library.<br><br>Obviously there are several places where i=
t&#39;s impossible to implement a standard library feature without using co=
mpiler hooks. The majority of chapter 18, and many of the type traits rely =
on such things. But it&#39;s important to recognize that what you&#39;re as=
king for is not a <i>normal</i> library feature. It&#39;s not, &quot;here&#=
39;s a library that I&#39;ve implemented, let&#39;s do that.&quot; That mak=
es it a bit more complex.<br><br>I would say that the best thing your propo=
sal could do is be defined <i>in terms of static reflection</i>. It&#39;s n=
ot so much that your proposal should <i>require</i> it. But at all times, y=
ou&#39;re making sure that the library interface you develop could <i>event=
ually</i> be implemented using static reflection.<br><br>And this would pro=
bably help the static reflection proposal too, since they&#39;ve got to mak=
e sure that the tools people need to do things like this are available.<br>=
<br>The other thing that&#39;s important to keep in mind is that runtime re=
flection takes up <i>memory</i>. Those strings for enums have to come from =
somewhere. Those arrays of enumeration values have to live somewhere. Whate=
ver library system you come up with needs to have a way to deal with that. =
You cannot just force every enumerator in a program to have runtime reflect=
ed data.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/58f032a8-65d5-4194-9ae1-817e0442ad23%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58f032a8-65d5-4194-9ae1-817e0442ad23=
%40isocpp.org</a>.<br />

------=_Part_15_677767136.1472153938051--

------=_Part_14_1920714079.1472153938051--

.

> The problem is that it's not a library feature. Well, not yet. Until
> static reflection happens, it is *impossible* to implement these sorts
> of things without either compiler magic or macros.
>
> And therefore, you're not really asking for a library feature. You're
> asking for a *compiler* feature, that just so happens to be exposed
> via the library.

Yes, that's what I mean, even though I didn't spell it out very
explicitly.

> I would say that the best thing your proposal could do is be defined
> *in terms of static reflection*. It's not so much that your proposal
> should *require* it. But at all times, you're making sure that the
> library interface you develop could *eventually* be implemented using
> static reflection.

I'm not the OP but I find this an interesting idea I might follow.  Do
you happen to know of any place where we can already play with static
reflection as currently proposed?  It would be immensely useful for this
task.

> The other thing that's important to keep in mind is that runtime
> reflection takes up *memory*. Those strings for enums have to come
> from somewhere.  Those arrays of enumeration values have to live
> somewhere. Whatever library system you come up with needs to have a
> way to deal with that. You cannot just force every enumerator in a
> program to have runtime reflected data.

Indeed.  Therefore, I think that using the template machinery for this
would be a good thing.  If your program never instantiates
`std::to_string<MyEnum>` (or whatever it is called), no string table of
`MyEnum`s names has to be set aside.  And if you do instantiate it, you
just pay for what you've explicitly asked for.  While static analysis
could also be used to do this when implemented differently, compilers
already do the right thing for templates so it wouldn't add extra
complexity.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com.

.

On Thu, 2016-08-25 at 11:39 -0700, 'Jeffrey Yasskin' via ISO C++ Standard -=
 Future Proposals wrote:
> On Thu, Aug 25, 2016 at 11:10 AM, Dominic Fandrey <kamikaze@bsdforen.de>
> wrote:
>=20
> >=20
> > On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:
> > >=20
> > > On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross <antiquarktv@gmail.com>
> > wrote:
> > >=20
> > >=20
> > > >=20
> > > >=20
> > > > Note that enums can have duplicate values, which throws a wrench in=
to
> > the
> > >=20
> > > >=20
> > > > reflection works.=C2=A0=C2=A0E.g.:
> > > >=20
> > > > enum class FooBar { KEKS =3D 2, DOSE =3D 2 };
> > > >=20
> > > > What will the result be for:
> > > >=20
> > > > FooBar fb =3D FooBar::KEKS;
> > > > cout << static_cast<char const*>(fb) ;
> > > >=20
> > > that only "throws a wrench into the reflection works" as proposed by =
the
> > > OP, by no means generally. the WG proposal linked (A) would not suppo=
rt
> > > this because it is static and (B) has presumably already accounted fo=
r
> > such
> > >=20
> > > possibilities and effortlessly gets around them with compile-time
> > > wizardry... again, *presumably.*
> > >=20
> > It's not really useful for what I'm doing if it's not runtime capable.
> >=20
> > For multiple mentions I'd just leave it implementation defined or
> > establish a simple first definition rule.
> >=20
> > I am assuming that in most cases overlapping definitions are aliases:
> >=20
> > =C2=A0=C2=A0=C2=A0=C2=A0enum class Flags { NONE =3D 0, COMPATIBLE =3D 1=
, COMPAT =3D 1, EXPERIMENTAL
> > =3D 2 };
> >=20
> The static reflection proposal lets you iterate at compile time over all
> the enum values inside an enumeration, which lets you write a generic
> library function to do what you want. That function will have to pick an
> answer to FlagsString(1), and we're hoping that some libraries appear to
> show us some options before we put a choice into the standard library.

That sounds fine to me, I prefer a generic approach over my limited
proposal. I guess it wouldn't be too difficult to build a nested type
containing the string and the enum value and a constexpr function
template that iterates through the type and returns the string for the
first enum match.

You could also build one that would return "COMPATIBLE|EXPERIMENTAL"
for Flags{3}, for enums that only have powers of two values. But that
would probably result in the creation in n! strings, so it might not
be a great idea (even if n is usually limited to 64).

--=20
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1472202710.17129.25.camel%40bsdforen.de.

.

This is a multi-part message in MIME format.
--------------DD9DB034350D46A9669678A1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 25/08/2016 =C3=A0 20:39, 'Jeffrey Yasskin' via ISO C++ Standard - Future=
=20
Proposals a =C3=A9crit :
> On Thu, Aug 25, 2016 at 11:10 AM, Dominic Fandrey=20
> <kamikaze@bsdforen.de <mailto:kamikaze@bsdforen.de>> wrote:
>
>     On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:
>     > On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross
>     <antiquarktv@gmail.com <mailto:antiquarktv@gmail.com>> wrote:
>     >
>     > >
>     > > Note that enums can have duplicate values, which throws a
>     wrench into the
>     > > reflection works.  E.g.:
>     > >
>     > > enum class FooBar { KEKS =3D 2, DOSE =3D 2 };
>     > >
>     > > What will the result be for:
>     > >
>     > > FooBar fb =3D FooBar::KEKS;
>     > > cout << static_cast<char const*>(fb) ;
>     > >
>     > that only "throws a wrench into the reflection works" as
>     proposed by the
>     > OP, by no means generally. the WG proposal linked (A) would not
>     support
>     > this because it is static and (B) has presumably already
>     accounted for such
>     > possibilities and effortlessly gets around them with compile-time
>     > wizardry... again, *presumably.*
>     >
>
>     It's not really useful for what I'm doing if it's not runtime capable=
..
>
>     For multiple mentions I'd just leave it implementation defined or
>     establish a simple first definition rule.
>
>     I am assuming that in most cases overlapping definitions are aliases:
>
>         enum class Flags { NONE =3D 0, COMPATIBLE =3D 1, COMPAT =3D 1,
>     EXPERIMENTAL =3D 2 };
>
> The static reflection proposal lets you iterate at compile time over=20
> all the enum values inside an enumeration, which lets you write a=20
> generic library function to do what you want. That function will have=20
> to pick an answer to FlagsString(1), and we're hoping that some=20
> libraries appear to show us some options before we put a choice into=20
> the standard library.
>

I'm working on a proposal for Ordinal types (types that are isomorphic=20
to 0..N. We could define an ordinal_set<Ordinal>, or an ordinal_array<T,=20
ordinal> or ordinal_range<Ordinal>.

Enums having all enumeration with a different value would be seen as=20
Ordinal. Associated to this enum could be a tag that defines the=20
algorithm to do the mappings. Possible mappings are arithmetic,=20
logarithmic or explicit. This tag can be calculated at compile time from=20
the static reflection library.

Defining a run-time function toString that takes such a ordinal enum=20
type and returns a const char * will be quite simple, once we are able=20
to have the position of a specific enumeration and the static reflection=20
library.

More soon.

Vicente


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c7969b41-3e76-c1d9-bd2f-b651be6e93f0%40wanadoo.f=
r.

--------------DD9DB034350D46A9669678A1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 25/08/2016 =C3=A0 20:39, 'Jeffrey
      Yasskin' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<=
br>
    </div>
    <blockquote
cite=3D"mid:CANh-dXmhWtTBeEwBheNOApVwiCkMB6Hwqg8n+xjt5aMvoW+pbg@mail.gmail.=
com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Thu, Aug 25, 2016 at 11:10 AM,
            Dominic Fandrey <span dir=3D"ltr">&lt;<a
                moz-do-not-send=3D"true"
                href=3D"mailto:kamikaze@bsdforen.de" target=3D"_blank"
                class=3D"cremed">kamikaze@bsdforen.de</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D"">On Thu, 2016-08-25 at 16:55 +0100, D. B. wrote:<=
br>
                &gt; On Thu, Aug 25, 2016 at 4:17 PM, Derek Ross &lt;<a
                  moz-do-not-send=3D"true"
                  href=3D"mailto:antiquarktv@gmail.com" class=3D"cremed">an=
tiquarktv@gmail.com</a>&gt;
                wrote:<br>
                &gt;<br>
                &gt; &gt;<br>
                &gt; &gt; Note that enums can have duplicate values,
                which throws a wrench into the<br>
                &gt; &gt; reflection works.=C2=A0=C2=A0E.g.:<br>
                &gt; &gt;<br>
                &gt; &gt; enum class FooBar { KEKS =3D 2, DOSE =3D 2 };<br>
                &gt; &gt;<br>
                &gt; &gt; What will the result be for:<br>
                &gt; &gt;<br>
                &gt; &gt; FooBar fb =3D FooBar::KEKS;<br>
                &gt; &gt; cout &lt;&lt; static_cast&lt;char
                const*&gt;(fb) ;<br>
                &gt; &gt;<br>
                &gt; that only "throws a wrench into the reflection
                works" as proposed by the<br>
                &gt; OP, by no means generally. the WG proposal linked
                (A) would not support<br>
                &gt; this because it is static and (B) has presumably
                already accounted for such<br>
                &gt; possibilities and effortlessly gets around them
                with compile-time<br>
              </span>&gt; wizardry... again, *presumably.*<br>
              &gt;<br>
              <br>
              It's not really useful for what I'm doing if it's not
              runtime capable.<br>
              <br>
              For multiple mentions I'd just leave it implementation
              defined or<br>
              establish a simple first definition rule.<br>
              <br>
              I am assuming that in most cases overlapping definitions
              are aliases:<br>
              <br>
              =C2=A0 =C2=A0 enum class Flags { NONE =3D 0, COMPATIBLE =3D 1=
, COMPAT =3D
              1, EXPERIMENTAL =3D 2 };<span class=3D""><br>
              </span></blockquote>
            <div>=C2=A0</div>
            <div>The static reflection proposal lets you iterate at
              compile time over all the enum values inside an
              enumeration, which lets you write a generic library
              function to do what you want. That function will have to
              pick an answer to FlagsString(1), and we're hoping that
              some libraries appear to show us some options before we
              put a choice into the standard library.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I'm working on a proposal for Ordinal types (types that are
    isomorphic to 0..N. We could define an ordinal_set&lt;Ordinal&gt;,
    or an ordinal_array&lt;T, ordinal&gt; or
    ordinal_range&lt;Ordinal&gt;.<br>
    <br>
    Enums having all enumeration with a different value would be seen as
    Ordinal. Associated to this enum could be a tag that defines the
    algorithm to do the mappings. Possible mappings are arithmetic,
    logarithmic or explicit. This tag can be calculated at compile time
    from the static reflection library.<br>
    <br>
    Defining a run-time function toString that takes such a ordinal enum
    type and returns a const char * will be quite simple, once we are
    able to have the position of a specific enumeration and the static
    reflection library.<br>
    <br>
    More soon.<br>
    <br>
    Vicente<br>
    <br>
    <br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c7969b41-3e76-c1d9-bd2f-b651be6e93f0%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7969b41-3e76-c1d9-bd2f-b651be6e93f0=
%40wanadoo.fr</a>.<br />

--------------DD9DB034350D46A9669678A1--

.

--001a11c0360a5502c1053afb7e23
Content-Type: text/plain; charset=UTF-8

The author of static reflection has been working on an implementation in
clang:
https://github.com/matus-chochlik/clang

It's still a work in progress and few things are little bit different from
the latest revision of the proposal.
But if I'm not wrong you should be able to list all the names and values
within an enum as suggested by others.


On Thu, Aug 25, 2016 at 3:21 PM, Moritz Klammler <moritz.klammler@gmail.com>
wrote:

> > The problem is that it's not a library feature. Well, not yet. Until
> > static reflection happens, it is *impossible* to implement these sorts
> > of things without either compiler magic or macros.
> >
> > And therefore, you're not really asking for a library feature. You're
> > asking for a *compiler* feature, that just so happens to be exposed
> > via the library.
>
> Yes, that's what I mean, even though I didn't spell it out very
> explicitly.
>
> > I would say that the best thing your proposal could do is be defined
> > *in terms of static reflection*. It's not so much that your proposal
> > should *require* it. But at all times, you're making sure that the
> > library interface you develop could *eventually* be implemented using
> > static reflection.
>
> I'm not the OP but I find this an interesting idea I might follow.  Do
> you happen to know of any place where we can already play with static
> reflection as currently proposed?  It would be immensely useful for this
> task.
>
> > The other thing that's important to keep in mind is that runtime
> > reflection takes up *memory*. Those strings for enums have to come
> > from somewhere.  Those arrays of enumeration values have to live
> > somewhere. Whatever library system you come up with needs to have a
> > way to deal with that. You cannot just force every enumerator in a
> > program to have runtime reflected data.
>
> Indeed.  Therefore, I think that using the template machinery for this
> would be a good thing.  If your program never instantiates
> `std::to_string<MyEnum>` (or whatever it is called), no string table of
> `MyEnum`s names has to be set aside.  And if you do instantiate it, you
> just pay for what you've explicitly asked for.  While static analysis
> could also be used to do this when implemented differently, compilers
> already do the right thing for templates so it wouldn't add extra
> complexity.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNGsK%3DYXhZfmU7%3DJPPGvdgpJ-MwTWThQwjxiACEMy9Tvg%40mail.gmail.com.

--001a11c0360a5502c1053afb7e23
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The author of static reflection has been working on an imp=
lementation in clang:<div><a href=3D"https://github.com/matus-chochlik/clan=
g">https://github.com/matus-chochlik/clang</a><br></div><div><br></div><div=
>It&#39;s still a work in progress and few things are little bit different =
from the latest revision of the proposal.</div><div>But if I&#39;m not wron=
g you should be able to list all the names and values within an enum as sug=
gested by others.<br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Thu, Aug 25, 2016 at 3:21 PM, Moritz Klam=
mler <span dir=3D"ltr">&lt;<a href=3D"mailto:moritz.klammler@gmail.com" tar=
get=3D"_blank">moritz.klammler@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">&gt; The problem is that it&#39;s not a library featu=
re. Well, not yet. Until<br>
&gt; static reflection happens, it is *impossible* to implement these sorts=
<br>
&gt; of things without either compiler magic or macros.<br>
&gt;<br>
&gt; And therefore, you&#39;re not really asking for a library feature. You=
&#39;re<br>
&gt; asking for a *compiler* feature, that just so happens to be exposed<br=
>
&gt; via the library.<br>
<br>
Yes, that&#39;s what I mean, even though I didn&#39;t spell it out very<br>
explicitly.<br>
<br>
&gt; I would say that the best thing your proposal could do is be defined<b=
r>
&gt; *in terms of static reflection*. It&#39;s not so much that your propos=
al<br>
&gt; should *require* it. But at all times, you&#39;re making sure that the=
<br>
&gt; library interface you develop could *eventually* be implemented using<=
br>
&gt; static reflection.<br>
<br>
I&#39;m not the OP but I find this an interesting idea I might follow.=C2=
=A0 Do<br>
you happen to know of any place where we can already play with static<br>
reflection as currently proposed?=C2=A0 It would be immensely useful for th=
is<br>
task.<br>
<br>
&gt; The other thing that&#39;s important to keep in mind is that runtime<b=
r>
&gt; reflection takes up *memory*. Those strings for enums have to come<br>
&gt; from somewhere.=C2=A0 Those arrays of enumeration values have to live<=
br>
&gt; somewhere. Whatever library system you come up with needs to have a<br=
>
&gt; way to deal with that. You cannot just force every enumerator in a<br>
&gt; program to have runtime reflected data.<br>
<br>
Indeed.=C2=A0 Therefore, I think that using the template machinery for this=
<br>
would be a good thing.=C2=A0 If your program never instantiates<br>
`std::to_string&lt;MyEnum&gt;` (or whatever it is called), no string table =
of<br>
`MyEnum`s names has to be set aside.=C2=A0 And if you do instantiate it, yo=
u<br>
just pay for what you&#39;ve explicitly asked for.=C2=A0 While static analy=
sis<br>
could also be used to do this when implemented differently, compilers<br>
already do the right thing for templates so it wouldn&#39;t add extra<br>
complexity.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com" rel=3D"no=
referrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/m=
sgid/std-<wbr>proposals/87vayosip3.fsf%<wbr>40gmail.com</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNGsK%3DYXhZfmU7%3DJPPGvdgpJ-=
MwTWThQwjxiACEMy9Tvg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNG=
sK%3DYXhZfmU7%3DJPPGvdgpJ-MwTWThQwjxiACEMy9Tvg%40mail.gmail.com</a>.<br />

--001a11c0360a5502c1053afb7e23--

.

------=_Part_2302_750984371.1472254257014
Content-Type: multipart/alternative;
 boundary="----=_Part_2303_989579670.1472254257014"

------=_Part_2303_989579670.1472254257014
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I hate to troll in (esp. since I'm top-posting :) ), but you know that you=
=20
can achieve this using macro-metaprogrammed FOREACH(); or, if you're okay=
=20
with uintptr_t values and don't care about enum values, you can use string=
=20
addresses (when you put strings in a struct using a macro), which is way=20
more readable?

Regards,
-lorro

2016. augusztus 25., cs=C3=BCt=C3=B6rt=C3=B6k 15:47:34 UTC+2 id=C5=91pontba=
n Kamikaze Dominic=20
Fandrey a k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> I searched this list for similar suggestions, but of course I may=20
> have overlooked something.=20
>
> I frequently use the following pattern:=20
>
>     enum class FooBar { KEKS, DOSE };=20
>     char const * const FooBarStr[]{"KEKS", "DOSE"};=20
>
> I use the strings to in error messages, verbose output, etc.=20
>
>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"=20
>
> This has some disadvantages, e.g. enums with explicitly stated values=20
> may have gaps, negative values and may be defined out of order.=20
> Also, changing the enum also means changing the strings manually.=20
>
> What I'd like to see:=20
>
>     static_cast<char const *>(FooBar::KEKS) // "KEKS"=20
>
> I think this would be simple to add to an existing compiler and it's=20
> very unlikely to clash with existing code, because you have to jump=20
> through some hoops to cast a strongly typed enum to a pointer type.=20
>
> --=20
> A: Because it fouls the order in which people normally read text.=20
> Q: Why is top-posting such a bad thing?=20
> A: Top-posting.=20
> Q: What is the most annoying thing on usenet and in e-mail?=20
>
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a057117d-4d32-4f39-ac2b-ada996a75ec3%40isocpp.or=
g.

------=_Part_2303_989579670.1472254257014
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>I hate to troll in (esp. since I&#39;m top-post=
ing :) ), but you know that you can achieve this using macro-metaprogrammed=
 FOREACH(); or, if you&#39;re okay with uintptr_t values and don&#39;t care=
 about enum values, you can use string addresses (when you put strings in a=
 struct using a macro), which is way more readable?<br><br>Regards,<br>-lor=
ro<br><br>2016. augusztus 25., cs=C3=BCt=C3=B6rt=C3=B6k 15:47:34 UTC+2 id=
=C5=91pontban Kamikaze Dominic Fandrey a k=C3=B6vetkez=C5=91t =C3=ADrta:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I searched this list for similar =
suggestions, but of course I may
<br>have overlooked something.
<br>
<br>I frequently use the following pattern:
<br>
<br>=C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };
<br>=C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS&quot;, &quot;DO=
SE&quot;};
<br>
<br>I use the strings to in error messages, verbose output, etc.
<br>
<br>=C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(<wbr>FooBar::KEKS)] // &=
quot;KEKS&quot;
<br>
<br>This has some disadvantages, e.g. enums with explicitly stated values
<br>may have gaps, negative values and may be defined out of order.
<br>Also, changing the enum also means changing the strings manually.
<br>
<br>What I&#39;d like to see:
<br>
<br>=C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::KEKS) // &quot;KE=
KS&quot;
<br>
<br>I think this would be simple to add to an existing compiler and it&#39;=
s
<br>very unlikely to clash with existing code, because you have to jump
<br>through some hoops to cast a strongly typed enum to a pointer type.
<br>
<br>--=20
<br>A: Because it fouls the order in which people normally read text.
<br>Q: Why is top-posting such a bad thing?
<br>A: Top-posting.
<br>Q: What is the most annoying thing on usenet and in e-mail?
<br>
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a057117d-4d32-4f39-ac2b-ada996a75ec3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a057117d-4d32-4f39-ac2b-ada996a75ec3=
%40isocpp.org</a>.<br />

------=_Part_2303_989579670.1472254257014--

------=_Part_2302_750984371.1472254257014--

.

--001a1140ffb6e9df2f053b027926
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 26/8/2016 20:30, <szollosi.lorand@gmail.com> escribi=C3=B3:
>
> Hi,
>
> I hate to troll in (esp. since I'm top-posting :) ), but you know that
you can achieve this using macro-metaprogrammed FOREACH(); or, if you're
okay with uintptr_t values and don't care about enum values, you can use
string addresses (when you put strings in a struct using a macro), which is
way more readable?

Even better, x-macros https://en.wikipedia.org/wiki/X_Macro?wprov=3Dsfla1

>
> Regards,
> -lorro
>
>
> 2016. augusztus 25., cs=C3=BCt=C3=B6rt=C3=B6k 15:47:34 UTC+2 id=C5=91pont=
ban Kamikaze Dominic
Fandrey a k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>> I searched this list for similar suggestions, but of course I may
>> have overlooked something.
>>
>> I frequently use the following pattern:
>>
>>     enum class FooBar { KEKS, DOSE };
>>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>>
>> I use the strings to in error messages, verbose output, etc.
>>
>>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>>
>> This has some disadvantages, e.g. enums with explicitly stated values
>> may have gaps, negative values and may be defined out of order.
>> Also, changing the enum also means changing the strings manually.
>>
>> What I'd like to see:
>>
>>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>>
>> I think this would be simple to add to an existing compiler and it's
>> very unlikely to clash with existing code, because you have to jump
>> through some hoops to cast a strongly typed enum to a pointer type.
>>
>> --
>> A: Because it fouls the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing on usenet and in e-mail?
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a057117d-4d32-=
4f39-ac2b-ada996a75ec3%40isocpp.org
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-19dYp6-x4PSFv5BXGVG2cdmaWu4a3h326FO8h%3DS=
%2B1Jdg%40mail.gmail.com.

--001a1140ffb6e9df2f053b027926
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">El 26/8/2016 20:30, &lt;<a href=3D"mailto:szollosi.lorand@gm=
ail.com">szollosi.lorand@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; I hate to troll in (esp. since I&#39;m top-posting :) ), but you know =
that you can achieve this using macro-metaprogrammed FOREACH(); or, if you&=
#39;re okay with uintptr_t values and don&#39;t care about enum values, you=
 can use string addresses (when you put strings in a struct using a macro),=
 which is way more readable?</p>
<p dir=3D"ltr">Even better, x-macros <a href=3D"https://en.wikipedia.org/wi=
ki/X_Macro?wprov=3Dsfla1">https://en.wikipedia.org/wiki/X_Macro?wprov=3Dsfl=
a1</a></p>
<p dir=3D"ltr">&gt;<br>
&gt; Regards,<br>
&gt; -lorro<br>
&gt;<br>
&gt;<br>
&gt; 2016. augusztus 25., cs=C3=BCt=C3=B6rt=C3=B6k 15:47:34 UTC+2 id=C5=91p=
ontban Kamikaze Dominic Fandrey a k=C3=B6vetkez=C5=91t =C3=ADrta:<br>
&gt;&gt;<br>
&gt;&gt; I searched this list for similar suggestions, but of course I may =
<br>
&gt;&gt; have overlooked something. <br>
&gt;&gt;<br>
&gt;&gt; I frequently use the following pattern: <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE }; <br>
&gt;&gt; =C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS&quot;, &qu=
ot;DOSE&quot;}; <br>
&gt;&gt;<br>
&gt;&gt; I use the strings to in error messages, verbose output, etc. <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(FooBar::KEKS)] // &=
quot;KEKS&quot; <br>
&gt;&gt;<br>
&gt;&gt; This has some disadvantages, e.g. enums with explicitly stated val=
ues <br>
&gt;&gt; may have gaps, negative values and may be defined out of order. <b=
r>
&gt;&gt; Also, changing the enum also means changing the strings manually. =
<br>
&gt;&gt;<br>
&gt;&gt; What I&#39;d like to see: <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::KEKS) // &qu=
ot;KEKS&quot; <br>
&gt;&gt;<br>
&gt;&gt; I think this would be simple to add to an existing compiler and it=
&#39;s <br>
&gt;&gt; very unlikely to clash with existing code, because you have to jum=
p <br>
&gt;&gt; through some hoops to cast a strongly typed enum to a pointer type=
.. <br>
&gt;&gt;<br>
&gt;&gt; -- <br>
&gt;&gt; A: Because it fouls the order in which people normally read text. =
<br>
&gt;&gt; Q: Why is top-posting such a bad thing? <br>
&gt;&gt; A: Top-posting. <br>
&gt;&gt; Q: What is the most annoying thing on usenet and in e-mail? <br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a057117d-4d32-4f39-ac2b-ada996a7=
5ec3%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/a057117d-4d32-4f39-ac2b-ada996a75ec3%40isocpp.org</a>.<br></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFdMc-19dYp6-x4PSFv5BXGVG2cdmaWu4a3h=
326FO8h%3DS%2B1Jdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-19dYp6=
-x4PSFv5BXGVG2cdmaWu4a3h326FO8h%3DS%2B1Jdg%40mail.gmail.com</a>.<br />

--001a1140ffb6e9df2f053b027926--

.

------=_Part_2370_1554864770.1472277739634
Content-Type: multipart/alternative;
 boundary="----=_Part_2371_1750018233.1472277739635"

------=_Part_2371_1750018233.1472277739635
Content-Type: text/plain; charset=UTF-8

Author of P0194Rx here.

Besides the clang fork, where you already can list all the members of an
enum (with the `std::meta::get_enumerators_v` operation) and get the name
of the enumerator (the `get_base_name_v` operation) and get the constant
value of the enumerator (the `get_constant_v` operation), there is also a
set of higher-level, experimental libraries built on top of the clang fork:
https://github.com/matus-chochlik/mirror . It's still  W.I.P. and without
docs, but you can have a look at the examples.



On Friday, August 26, 2016 at 5:51:56 PM UTC+2, Ricardo Andrade wrote:
>
> The author of static reflection has been working on an implementation in
> clang:
> https://github.com/matus-chochlik/clang
>
> It's still a work in progress and few things are little bit different from
> the latest revision of the proposal.
> But if I'm not wrong you should be able to list all the names and values
> within an enum as suggested by others.
>
>
> On Thu, Aug 25, 2016 at 3:21 PM, Moritz Klammler <moritz....@gmail.com
> <javascript:>> wrote:
>
>> > The problem is that it's not a library feature. Well, not yet. Until
>> > static reflection happens, it is *impossible* to implement these sorts
>> > of things without either compiler magic or macros.
>> >
>> > And therefore, you're not really asking for a library feature. You're
>> > asking for a *compiler* feature, that just so happens to be exposed
>> > via the library.
>>
>> Yes, that's what I mean, even though I didn't spell it out very
>> explicitly.
>>
>> > I would say that the best thing your proposal could do is be defined
>> > *in terms of static reflection*. It's not so much that your proposal
>> > should *require* it. But at all times, you're making sure that the
>> > library interface you develop could *eventually* be implemented using
>> > static reflection.
>>
>> I'm not the OP but I find this an interesting idea I might follow.  Do
>> you happen to know of any place where we can already play with static
>> reflection as currently proposed?  It would be immensely useful for this
>> task.
>>
>> > The other thing that's important to keep in mind is that runtime
>> > reflection takes up *memory*. Those strings for enums have to come
>> > from somewhere.  Those arrays of enumeration values have to live
>> > somewhere. Whatever library system you come up with needs to have a
>> > way to deal with that. You cannot just force every enumerator in a
>> > program to have runtime reflected data.
>>
>> Indeed.  Therefore, I think that using the template machinery for this
>> would be a good thing.  If your program never instantiates
>> `std::to_string<MyEnum>` (or whatever it is called), no string table of
>> `MyEnum`s names has to be set aside.  And if you do instantiate it, you
>> just pay for what you've explicitly asked for.  While static analysis
>> could also be used to do this when implemented differently, compilers
>> already do the right thing for templates so it wouldn't add extra
>> complexity.
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com
>> .
>>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3aed99ea-cdc0-4611-acd0-486996cac691%40isocpp.org.

------=_Part_2371_1750018233.1472277739635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Author of P0194Rx here.<br><br>Besides the clang fork, whe=
re you already can list all the members of an enum (with the `std::meta::ge=
t_enumerators_v` operation) and get the name of the enumerator (the `get_ba=
se_name_v` operation) and get the constant value of the enumerator (the `ge=
t_constant_v` operation), there is also a set of higher-level, experimental=
 libraries built on top of the clang fork: https://github.com/matus-chochli=
k/mirror . It&#39;s still=C2=A0 W.I.P. and without docs, but you can have a=
 look at the examples.<br><br><br><br>On Friday, August 26, 2016 at 5:51:56=
 PM UTC+2, Ricardo Andrade wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr">The author of static reflection has been working on an =
implementation in clang:<div><a href=3D"https://github.com/matus-chochlik/c=
lang" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fc=
lang\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFYtCWicvBiP1kDwT9XTkN0NP8DFQ&#=
39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fclang\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNFYtCWicvBiP1kDwT9XTkN0NP8DFQ&#39;;return true;">https://g=
ithub.com/matus-<wbr>chochlik/clang</a><br></div><div><br></div><div>It&#39=
;s still a work in progress and few things are little bit different from th=
e latest revision of the proposal.</div><div>But if I&#39;m not wrong you s=
hould be able to list all the names and values within an enum as suggested =
by others.<br></div><div><br></div></div><div><br><div class=3D"gmail_quote=
">On Thu, Aug 25, 2016 at 3:21 PM, Moritz Klammler <span dir=3D"ltr">&lt;<a=
 href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"JcelpC7iEA=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">moritz.=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; =
The problem is that it&#39;s not a library feature. Well, not yet. Until<br=
>
&gt; static reflection happens, it is *impossible* to implement these sorts=
<br>
&gt; of things without either compiler magic or macros.<br>
&gt;<br>
&gt; And therefore, you&#39;re not really asking for a library feature. You=
&#39;re<br>
&gt; asking for a *compiler* feature, that just so happens to be exposed<br=
>
&gt; via the library.<br>
<br>
Yes, that&#39;s what I mean, even though I didn&#39;t spell it out very<br>
explicitly.<br>
<br>
&gt; I would say that the best thing your proposal could do is be defined<b=
r>
&gt; *in terms of static reflection*. It&#39;s not so much that your propos=
al<br>
&gt; should *require* it. But at all times, you&#39;re making sure that the=
<br>
&gt; library interface you develop could *eventually* be implemented using<=
br>
&gt; static reflection.<br>
<br>
I&#39;m not the OP but I find this an interesting idea I might follow.=C2=
=A0 Do<br>
you happen to know of any place where we can already play with static<br>
reflection as currently proposed?=C2=A0 It would be immensely useful for th=
is<br>
task.<br>
<br>
&gt; The other thing that&#39;s important to keep in mind is that runtime<b=
r>
&gt; reflection takes up *memory*. Those strings for enums have to come<br>
&gt; from somewhere.=C2=A0 Those arrays of enumeration values have to live<=
br>
&gt; somewhere. Whatever library system you come up with needs to have a<br=
>
&gt; way to deal with that. You cannot just force every enumerator in a<br>
&gt; program to have runtime reflected data.<br>
<br>
Indeed.=C2=A0 Therefore, I think that using the template machinery for this=
<br>
would be a good thing.=C2=A0 If your program never instantiates<br>
`std::to_string&lt;MyEnum&gt;` (or whatever it is called), no string table =
of<br>
`MyEnum`s names has to be set aside.=C2=A0 And if you do instantiate it, yo=
u<br>
just pay for what you&#39;ve explicitly asked for.=C2=A0 While static analy=
sis<br>
could also be used to do this when implemented differently, compilers<br>
already do the right thing for templates so it wouldn&#39;t add extra<br>
complexity.<br>
<span><font color=3D"#888888"><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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
JcelpC7iEAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"JcelpC7iEAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://groups.go=
ogle.com/a/isocpp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com&#39;=
;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/87vayosip3.fsf%40gmail.com&#39;;return true;">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/87va=
yosip3.fsf%<wbr>40gmail.com</a>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3aed99ea-cdc0-4611-acd0-486996cac691%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3aed99ea-cdc0-4611-acd0-486996cac691=
%40isocpp.org</a>.<br />

------=_Part_2371_1750018233.1472277739635--

------=_Part_2370_1554864770.1472277739634--

.

chochlik@gmail.com writes:

> Author of P0194Rx here.
>
> Besides the clang fork, where you already can list all the members of
> an enum (with the `std::meta::get_enumerators_v` operation) and get
> the name of the enumerator (the `get_base_name_v` operation) and get
> the constant value of the enumerator (the `get_constant_v` operation),
> there is also a set of higher-level, experimental libraries built on
> top of the clang fork: https://github.com/matus-chochlik/mirror . It's
> still W.I.P. and without docs, but you can have a look at the
> examples.

Thanks a lot; I'll be looking into these.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87vaymy273.fsf%40gmail.com.

.

szollosi.lorand@gmail.com writes:

> Hi,
>
> I hate to troll in (esp. since I'm top-posting :) ), but you know that
> you can achieve this using macro-metaprogrammed FOREACH(); or, if
> you're okay with uintptr_t values and don't care about enum values,
> you can use string addresses (when you put strings in a struct using a
> macro), which is way more readable?
>
> Regards,
> -lorro


There are many hacks you can use to work around many current
limitations.  Besides aesthetic concerns about macro magic, the biggest
drawback I see is that it is something the library author explicitly has
to offer.  More redundant code to write means more chances for bugs and
subtly or not so subtly diverging solutions in different libraries.  A
general solution where the *consumer* of any library or other component
could just *ask* for the name of an enumerator instead of relying on the
library author to provide a feature for obtaining the desired
information seems sufficiently superior to me to push for such a
feature in the standard.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/87r39ay1vu.fsf%40gmail.com.

.

This is a multi-part message in MIME format.
--------------86C3882CFC8E2D41499A0DDB
Content-Type: text/plain; charset=UTF-8; format=flowed

On 08/25/2016 06:52 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals wrote:
> On Thu, Aug 25, 2016 at 8:41 AM, Larry Evans
> <cppljevans@suddenlink.net <mailto:cppljevans@suddenlink.net>> wrote:
>
>     On 08/25/2016 09:12 AM, Ville Voutilainen wrote:
>
>         On 25 August 2016 at 16:47, Dominic Fandrey
>         <kamikaze@bsdforen.de <mailto:kamikaze@bsdforen.de>> wrote:
>
>             I searched this list for similar suggestions, but of
>             course I may
>             have overlooked something.
>
>             I frequently use the following pattern:
>
>                 enum class FooBar { KEKS, DOSE };
>                 char const * const FooBarStr[]{"KEKS", "DOSE"};
>
>             I use the strings to in error messages, verbose output, etc.
>
>                 FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>
>             This has some disadvantages, e.g. enums with explicitly
>             stated values
>             may have gaps, negative values and may be defined out of
>             order.
>             Also, changing the enum also means changing the strings
>             manually.
>
>             What I'd like to see:
>
>                 static_cast<char const *>(FooBar::KEKS) // "KEKS"
>
>
>
>         See
>         http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html
>         <http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html>
>
>     Could you be more specific.  I grepped for enumName, for char const*,
>     and scanned briefly for other strings that might show where
>     conversion from enum to char const* might be, without success :(
>
>
> In that proposal, the operation you want is spelled
> get_name_v<reflexpr(FooBar::KEKS)>.
>
>

Likely, he wants to index the array with a non-constexpr value.  So he'd
need code to create a static array (or unordered_map, if the enum is
sparse) for a dynamic lookup.

Something like

const char* as_string(FooBar v) {
     if constexpr (is_sparse_enum_v<FooBar>) {
         return as_string_sparse(v);
     } else {
         return as_string_dense(b);
     }
}

template <typename Enum>
const char* as_string_dense(Enum v)
     static const char* tab[] = { magic code to populate the table with
reflexpr(Enum)... };
     return tab[static_cast<std::underlying_type_t<Enum>>(v)];
}

template <typename Enum>
const char* as_string_sparse(Enum v) {
     static std::unordered_map<std::underlying_type_t<Enum>, const
char*> = { more magic code to populate the table with reflexpr(Enum)... };
     return tab[static_cast<std::underlying_type_t<Enum>>(v)];
}

this is complex enough to merit a library, and common enough to be
standardized.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f2b9290-581d-1fec-a98d-5efe4f5f8fc9%40scylladb.com.

--------------86C3882CFC8E2D41499A0DDB
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">
    On 08/25/2016 06:52 PM, 'Jeffrey Yasskin' via ISO C++ Standard -
    Future Proposals wrote:<br>
    <blockquote
cite=3D"mid:CANh-dXmFXB6WY=3DuUt6Qh3PzTGek9e0Av-0h4TLnFzXSY6mAR+A@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Thu, Aug 25, 2016 at 8:41 AM,
            Larry Evans <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:cppljevans@suddenlink.net" target=3D"_blank"
                class=3D"cremed">cppljevans@suddenlink.net</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D"">On 08/25/2016 09:12 AM, Ville Voutilainen
                wrote:<br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  On 25 August 2016 at 16:47, Dominic Fandrey &lt;<a
                    moz-do-not-send=3D"true"
                    href=3D"mailto:kamikaze@bsdforen.de" target=3D"_blank"
                    class=3D"cremed">kamikaze@bsdforen.de</a>&gt; wrote:<br=
>
                  <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    I searched this list for similar suggestions, but of
                    course I may<br>
                    have overlooked something.<br>
                    <br>
                    I frequently use the following pattern:<br>
                    <br>
                    =C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };<br>
                    =C2=A0 =C2=A0 char const * const FooBarStr[]{"KEKS", "D=
OSE"};<br>
                    <br>
                    I use the strings to in error messages, verbose
                    output, etc.<br>
                    <br>
                    =C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(Foo<wbr>=
Bar::KEKS)]
                    // "KEKS"<br>
                    <br>
                    This has some disadvantages, e.g. enums with
                    explicitly stated values<br>
                    may have gaps, negative values and may be defined
                    out of order.<br>
                    Also, changing the enum also means changing the
                    strings manually.<br>
                    <br>
                    What I'd like to see:<br>
                    <br>
                    =C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::K=
EKS) //
                    "KEKS"<br>
                  </blockquote>
                  <br>
                  <br>
                  See <a moz-do-not-send=3D"true"
                    href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/=
2016/p0194r1.html"
                    rel=3D"noreferrer" target=3D"_blank" class=3D"cremed">h=
ttp://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2016/p0194r1.<wbr>html</=
a><br>
                  <br>
                </blockquote>
              </span>
              Could you be more specific.=C2=A0 I grepped for enumName, for
              char const*,<br>
              and scanned briefly for other strings that might show
              where<br>
              conversion from enum to char const* might be, without
              success :(</blockquote>
            <div><br>
            </div>
            <div>In that proposal, the operation you want is spelled
              get_name_v&lt;reflexpr(FooBar::KEKS)&gt;.</div>
            <div><br>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Likely, he wants to index the array with a non-constexpr value.=C2=A0 S=
o
    he'd need code to create a static array (or unordered_map, if the
    enum is sparse) for a dynamic lookup.<br>
    <br>
    Something like<br>
    <br>
    const char* as_string(FooBar v) {<br>
    =C2=A0=C2=A0=C2=A0 if constexpr (is_sparse_enum_v&lt;FooBar&gt;) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return as_string_sparse(v);<=
br>
    =C2=A0=C2=A0=C2=A0 } else {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return as_string_dense(b);<b=
r>
    =C2=A0=C2=A0=C2=A0 }<br>
    }<br>
    <br>
    template &lt;typename Enum&gt;<br>
    const char* as_string_dense(Enum v)<br>
    =C2=A0=C2=A0=C2=A0 static const char* tab[] =3D { magic code to populat=
e the table
    with reflexpr(Enum)... };<br>
    =C2=A0=C2=A0=C2=A0 return
    tab[static_cast&lt;std::underlying_type_t&lt;Enum&gt;&gt;(v)];<br>
    }<br>
    <br>
    template &lt;typename Enum&gt;<br>
    const char* as_string_sparse(Enum v) {<br>
    =C2=A0=C2=A0=C2=A0 static std::unordered_map&lt;std::underlying_type_t&=
lt;Enum&gt;,
    const char*&gt; =3D { more magic code to populate the table with
    reflexpr(Enum)... };<br>
    =C2=A0=C2=A0=C2=A0 return
    tab[static_cast&lt;std::underlying_type_t&lt;Enum&gt;&gt;(v)];<br>
    }<br>
    <br>
    this is complex enough to merit a library, and common enough to be
    standardized.<br>
    <br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1f2b9290-581d-1fec-a98d-5efe4f5f8fc9%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/1f2b9290-581d-1fec-a98d-5efe4f5f8f=
c9%40scylladb.com</a>.<br />

--------------86C3882CFC8E2D41499A0DDB--

.

--001a1143e20826a51e053b259366
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 28, 2016 at 9:35 AM, Avi Kivity <avi@scylladb.com> wrote:

> On 08/25/2016 06:52 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals wrote:
>
> On Thu, Aug 25, 2016 at 8:41 AM, Larry Evans <cppljevans@suddenlink.net>
> wrote:
>
>> On 08/25/2016 09:12 AM, Ville Voutilainen wrote:
>>
>>> On 25 August 2016 at 16:47, Dominic Fandrey <kamikaze@bsdforen.de>
>>> wrote:
>>>
>>>> I searched this list for similar suggestions, but of course I may
>>>> have overlooked something.
>>>>
>>>> I frequently use the following pattern:
>>>>
>>>>     enum class FooBar { KEKS, DOSE };
>>>>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>>>>
>>>> I use the strings to in error messages, verbose output, etc.
>>>>
>>>>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>>>>
>>>> This has some disadvantages, e.g. enums with explicitly stated values
>>>> may have gaps, negative values and may be defined out of order.
>>>> Also, changing the enum also means changing the strings manually.
>>>>
>>>> What I'd like to see:
>>>>
>>>>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>>>>
>>>
>>>
>>> See http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0194r1.html
>>>
>>> Could you be more specific.  I grepped for enumName, for char const*,
>> and scanned briefly for other strings that might show where
>> conversion from enum to char const* might be, without success :(
>
>
> In that proposal, the operation you want is spelled
> get_name_v<reflexpr(FooBar::KEKS)>.
>
>
>
> Likely, he wants to index the array with a non-constexpr value.  So he'd
> need code to create a static array (or unordered_map, if the enum is
> sparse) for a dynamic lookup.
>
> Something like
>
> const char* as_string(FooBar v) {
>     if constexpr (is_sparse_enum_v<FooBar>) {
>         return as_string_sparse(v);
>     } else {
>         return as_string_dense(b);
>     }
> }
>
> template <typename Enum>
> const char* as_string_dense(Enum v)
>     static const char* tab[] = { magic code to populate the table with
> reflexpr(Enum)... };
>     return tab[static_cast<std::underlying_type_t<Enum>>(v)];
> }
>
> template <typename Enum>
> const char* as_string_sparse(Enum v) {
>     static std::unordered_map<std::underlying_type_t<Enum>, const char*>
> = { more magic code to populate the table with reflexpr(Enum)... };
>     return tab[static_cast<std::underlying_type_t<Enum>>(v)];
> }
>
> this is complex enough to merit a library, and common enough to be
> standardized.
>

Yeah, we got there later in the thread.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXkhrjPSjFSyh8eP7de7mCCBgZ052hW3p2KJSvGT-fYYzw%40mail.gmail.com.

--001a1143e20826a51e053b259366
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Aug 28, 2016 at 9:35 AM, Avi Kivity <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:avi@scylladb.com" target=3D"_blank" class=3D"cremed">avi@scylladb.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    On 08/25/2016 06:52 PM, &#39;Jeffrey Yasskin&#39; via ISO C++ Standard =
-
    Future Proposals wrote:<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">
          <div class=3D"gmail_quote">On Thu, Aug 25, 2016 at 8:41 AM,
            Larry Evans <span dir=3D"ltr">&lt;<a href=3D"mailto:cppljevans@=
suddenlink.net" class=3D"m_9006396420514139832cremed cremed" target=3D"_bla=
nk">cppljevans@suddenlink.net</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span>On 08/25/2016 09:12 AM, Vi=
lle Voutilainen
                wrote:<br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
                  On 25 August 2016 at 16:47, Dominic Fandrey &lt;<a href=
=3D"mailto:kamikaze@bsdforen.de" class=3D"m_9006396420514139832cremed creme=
d" target=3D"_blank">kamikaze@bsdforen.de</a>&gt; wrote:<br>
                  <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
                    I searched this list for similar suggestions, but of
                    course I may<br>
                    have overlooked something.<br>
                    <br>
                    I frequently use the following pattern:<br>
                    <br>
                    =C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };<br>
                    =C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS=
&quot;, &quot;DOSE&quot;};<br>
                    <br>
                    I use the strings to in error messages, verbose
                    output, etc.<br>
                    <br>
                    =C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(Foo<wbr>=
Bar::KEKS)]
                    // &quot;KEKS&quot;<br>
                    <br>
                    This has some disadvantages, e.g. enums with
                    explicitly stated values<br>
                    may have gaps, negative values and may be defined
                    out of order.<br>
                    Also, changing the enum also means changing the
                    strings manually.<br>
                    <br>
                    What I&#39;d like to see:<br>
                    <br>
                    =C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::K=
EKS) //
                    &quot;KEKS&quot;<br>
                  </blockquote>
                  <br>
                  <br>
                  See <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/pa=
pers/2016/p0194r1.html" rel=3D"noreferrer" class=3D"m_9006396420514139832cr=
emed cremed" target=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG21/docs=
/papers/2016/p0194r1.<wbr>html</a><br>
                  <br>
                </blockquote>
              </span>
              Could you be more specific.=C2=A0 I grepped for enumName, for
              char const*,<br>
              and scanned briefly for other strings that might show
              where<br>
              conversion from enum to char const* might be, without
              success :(</blockquote>
            <div><br>
            </div>
            <div>In that proposal, the operation you want is spelled
              get_name_v&lt;reflexpr(FooBar::<wbr>KEKS)&gt;.</div>
            <div><br>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Likely, he wants to index the array with a non-constexpr value.=C2=A0 S=
o
    he&#39;d need code to create a static array (or unordered_map, if the
    enum is sparse) for a dynamic lookup.<br>
    <br>
    Something like<br>
    <br>
    const char* as_string(FooBar v) {<br>
    =C2=A0=C2=A0=C2=A0 if constexpr (is_sparse_enum_v&lt;FooBar&gt;) {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return as_string_sparse(v);<=
br>
    =C2=A0=C2=A0=C2=A0 } else {<br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return as_string_dense(b);<b=
r>
    =C2=A0=C2=A0=C2=A0 }<br>
    }<br>
    <br>
    template &lt;typename Enum&gt;<br>
    const char* as_string_dense(Enum v)<br>
    =C2=A0=C2=A0=C2=A0 static const char* tab[] =3D { magic code to populat=
e the table
    with reflexpr(Enum)... };<br>
    =C2=A0=C2=A0=C2=A0 return
    tab[static_cast&lt;std::<wbr>underlying_type_t&lt;Enum&gt;&gt;(v)];<br>
    }<br>
    <br>
    template &lt;typename Enum&gt;<br>
    const char* as_string_sparse(Enum v) {<br>
    =C2=A0=C2=A0=C2=A0 static std::unordered_map&lt;std::<wbr>underlying_ty=
pe_t&lt;Enum&gt;,
    const char*&gt; =3D { more magic code to populate the table with
    reflexpr(Enum)... };<br>
    =C2=A0=C2=A0=C2=A0 return
    tab[static_cast&lt;std::<wbr>underlying_type_t&lt;Enum&gt;&gt;(v)];<br>
    }<br>
    <br>
    this is complex enough to merit a library, and common enough to be
    standardized.</div></blockquote><div>=C2=A0</div><div>Yeah, we got ther=
e later in the thread.=C2=A0</div></div><br></div><div class=3D"gmail_extra=
">Jeffrey</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXkhrjPSjFSyh8eP7de7mCCBgZ052hW3=
p2KJSvGT-fYYzw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXkhrjPSjFSy=
h8eP7de7mCCBgZ052hW3p2KJSvGT-fYYzw%40mail.gmail.com</a>.<br />

--001a1143e20826a51e053b259366--

.

>  common enough to be standardized.

Honestly though, is it really that common? Raw enum value names are probabl=
y (hopefully) not what are presented to an end user. If it is used for erro=
r codes, you will have some table for actual descriptions. If it is flags, =
you probably have a proper parser that is able to handle combinations as we=
ll, and for printing you need that as well.

I would like to claim that only in very rare cases the raw name of an enume=
ration value is used, and if, they are for debugging purposes. The more com=
mon case with descriptions would not be covered. Languages like C# do that =
via annotations, and the full fledged runtime reflection. But then comes lo=
calization, =E2=80=A6

I obviously understand where the desire to just print readable enum values =
comes from and have been there myself, but this feature would encourage med=
iocre UX or would not help that much for more than debugging.=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/01F1ABC6-E4E6-4524-A29A-106FC4FE8470%40googlemai=
l.com.

.

--001a114dc7e8f95a0b053b261f3d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Aug 28, 2016 9:19 PM, "'Bernd L=C3=B6rwald' via ISO C++ Standard - Futur=
e
Proposals" <std-proposals@isocpp.org> wrote:
>
>
> >  common enough to be standardized.
>
> Honestly though, is it really that common? Raw enum value names are
probably (hopefully) not what are presented to an end user. If it is used
for error codes, you will have some table for actual descriptions. If it is
flags, you probably have a proper parser that is able to handle
combinations as well, and for printing you need that as well.
>
> I would like to claim that only in very rare cases the raw name of an
enumeration value is used, and if, they are for debugging purposes. The
more common case with descriptions would not be covered. Languages like C#
do that via annotations, and the full fledged runtime reflection. But then
comes localization, =E2=80=A6
>
> I obviously understand where the desire to just print readable enum
values comes from and have been there myself, but this feature would
encourage mediocre UX or would not help that much for more than debugging.

Even if it's just used for debugging/logging/tracing, it deserves a place.
Those are requirements for nearly every program.

>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01F1ABC6-E4E6-=
4524-A29A-106FC4FE8470%40googlemail.com
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAF950W%2BiGwLJT3-x82qwKj%3Dzsyq2S4F%2Bvqj5yB4tD=
cV1cJ_jtg%40mail.gmail.com.

--001a114dc7e8f95a0b053b261f3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On Aug 28, 2016 9:19 PM, &quot;&#39;Bernd L=C3=B6rwald&#39; =
via ISO C++ Standard - Future Proposals&quot; &lt;<a href=3D"mailto:std-pro=
posals@isocpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; &gt;=C2=A0 common enough to be standardized.<br>
&gt;<br>
&gt; Honestly though, is it really that common? Raw enum value names are pr=
obably (hopefully) not what are presented to an end user. If it is used for=
 error codes, you will have some table for actual descriptions. If it is fl=
ags, you probably have a proper parser that is able to handle combinations =
as well, and for printing you need that as well.<br>
&gt;<br>
&gt; I would like to claim that only in very rare cases the raw name of an =
enumeration value is used, and if, they are for debugging purposes. The mor=
e common case with descriptions would not be covered. Languages like C# do =
that via annotations, and the full fledged runtime reflection. But then com=
es localization, =E2=80=A6<br>
&gt;<br>
&gt; I obviously understand where the desire to just print readable enum va=
lues comes from and have been there myself, but this feature would encourag=
e mediocre UX or would not help that much for more than debugging.</p>
<p dir=3D"ltr">Even if it&#39;s just used for debugging/logging/tracing, it=
 deserves a place. Those are requirements for nearly every program.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/01F1ABC6-E4E6-4524-A29A-106FC4FE=
8470%40googlemail.com">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/01F1ABC6-E4E6-4524-A29A-106FC4FE8470%40googlemail.com</a>.<br></p>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAF950W%2BiGwLJT3-x82qwKj%3Dzsyq2S4F%=
2Bvqj5yB4tDcV1cJ_jtg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAF950W%2Bi=
GwLJT3-x82qwKj%3Dzsyq2S4F%2Bvqj5yB4tDcV1cJ_jtg%40mail.gmail.com</a>.<br />

--001a114dc7e8f95a0b053b261f3d--

.

------=_Part_298_1815826370.1472409917154
Content-Type: multipart/alternative;
 boundary="----=_Part_299_649921214.1472409917155"

------=_Part_299_649921214.1472409917155
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, August 28, 2016 at 2:19:24 PM UTC-4, Bernd L=C3=B6rwald wrote:
>
>
> >  common enough to be standardized.=20
>
> Honestly though, is it really that common? Raw enum value names are=20
> probably (hopefully) not what are presented to an end user. If it is used=
=20
> for error codes, you will have some table for actual descriptions. If it =
is=20
> flags, you probably have a proper parser that is able to handle=20
> combinations as well, and for printing you need that as well.=20
>
> I would like to claim that only in very rare cases the raw name of an=20
> enumeration value is used, and if, they are for debugging purposes. The=
=20
> more common case with descriptions would not be covered. Languages like C=
#=20
> do that via annotations, and the full fledged runtime reflection. But the=
n=20
> comes localization, =E2=80=A6=20
>
> I obviously understand where the desire to just print readable enum value=
s=20
> comes from and have been there myself, but this feature would encourage=
=20
> mediocre UX or would not help that much for more than debugging.=20


Well, here's the thing: if you give people compile-time reflection over=20
enumerator names (and we will), then they will write this library *anyway*.=
=20
However much it will "encourage mediocre UX", people are still going to do=
=20
it. A lot.

So we can either give people a standardized system to do something that=20
they clearly want to do, or we can make them do the work themselves. But=20
since it's going to happen with our without a standardized library=20
approach, I'd say that it's better to have it happen *with* one than=20
without one.

At least that way, we can track down code that's using the "mediocre UX".

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f8e8e94b-8b3f-4949-a31a-6369111a59e0%40isocpp.or=
g.

------=_Part_299_649921214.1472409917155
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, August 28, 2016 at 2:19:24 PM UTC-4, Bernd L=C3=
=B6rwald wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; =C2=A0common enough to be standardized.
<br>
<br>Honestly though, is it really that common? Raw enum value names are pro=
bably (hopefully) not what are presented to an end user. If it is used for =
error codes, you will have some table for actual descriptions. If it is fla=
gs, you probably have a proper parser that is able to handle combinations a=
s well, and for printing you need that as well.
<br>
<br>I would like to claim that only in very rare cases the raw name of an e=
numeration value is used, and if, they are for debugging purposes. The more=
 common case with descriptions would not be covered. Languages like C# do t=
hat via annotations, and the full fledged runtime reflection. But then come=
s localization, =E2=80=A6
<br>
<br>I obviously understand where the desire to just print readable enum val=
ues comes from and have been there myself, but this feature would encourage=
 mediocre UX or would not help that much for more than debugging. </blockqu=
ote><div><br>Well, here&#39;s the thing: if you give people compile-time re=
flection over enumerator names (and we will), then they will write this lib=
rary <i>anyway</i>. However much it will &quot;encourage mediocre UX&quot;,=
 people are still going to do it. A lot.<br><br>So we can either give peopl=
e a standardized system to do something that they clearly want to do, or we=
 can make them do the work themselves. But since it&#39;s going to happen w=
ith our without a standardized library approach, I&#39;d say that it&#39;s =
better to have it happen <i>with</i> one than without one.<br><br>At least =
that way, we can track down code that&#39;s using the &quot;mediocre UX&quo=
t;.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f8e8e94b-8b3f-4949-a31a-6369111a59e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8e8e94b-8b3f-4949-a31a-6369111a59e0=
%40isocpp.org</a>.<br />

------=_Part_299_649921214.1472409917155--

------=_Part_298_1815826370.1472409917154--

.

>>  common enough to be standardized.
>
> Honestly though, is it really that common? Raw enum value names are
> probably (hopefully) not what are presented to an end user. If it is
> used for error codes, you will have some table for actual
> descriptions. If it is flags, you probably have a proper parser that
> is able to handle combinations as well, and for printing you need that
> as well.
>
> I would like to claim that only in very rare cases the raw name of an
> enumeration value is used, and if, they are for debugging
> purposes. The more common case with descriptions would not be
> covered. Languages like C# do that via annotations, and the full
> fledged runtime reflection. But then comes localization, =E2=80=A6
>
> I obviously understand where the desire to just print readable enum
> values comes from and have been there myself, but this feature would
> encourage mediocre UX or would not help that much for more than
> debugging.

I don't know how C# does it but I'd like to mention that Java uses the
declared identifier verbatim, too.  For example:

    public class Demo {
   =20
        enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; }
   =20
        public static void main(final String[] args) {
            for (final String a : args) {
                try {
                    final Seasons season =3D Seasons.valueOf(a);
                    System.out.println(season.toString());
                } catch (final IllegalArgumentException e) {
                    System.err.printf("No valid enumerator: %s%n", a);
                }
            }
        }
    }

Here it is in action:

    $ javac Demo.java && java -cp . Demo SPRING WINTER FALL
    SPRING
    WINTER
    No valid enumerator: FALL

While I agree that even if the only useful application for this feature
were for debugging, it would still be worthy of standard library
support, I have to say that I've actually used the Java feature for
business logic in the past.  Using the declared identifiers of
enumeration constants directly in graphical user-interfaces might not be
the best choice.  But I think they are perfectly fine for use in, say,
configuration files or IPC messages.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/878tvfl89r.fsf%40gmail.com.

.

--001a114277d0bdfc1d053b4089de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

C# does something similar. The funny thing is that out of bounds enum
values print too : https://dotnetfiddle.net/0qwDZk

I often do the enum-to-string tricks. I'd be interested if we could really
describe what the expected behavior would be. Not sure C# does that right,
but not sure what =C2=ABright=C2=BB would be in general...

2016-08-29 14:50 GMT-04:00 Moritz Klammler <moritz.klammler@gmail.com>:

> >>  common enough to be standardized.
> >
> > Honestly though, is it really that common? Raw enum value names are
> > probably (hopefully) not what are presented to an end user. If it is
> > used for error codes, you will have some table for actual
> > descriptions. If it is flags, you probably have a proper parser that
> > is able to handle combinations as well, and for printing you need that
> > as well.
> >
> > I would like to claim that only in very rare cases the raw name of an
> > enumeration value is used, and if, they are for debugging
> > purposes. The more common case with descriptions would not be
> > covered. Languages like C# do that via annotations, and the full
> > fledged runtime reflection. But then comes localization, =E2=80=A6
> >
> > I obviously understand where the desire to just print readable enum
> > values comes from and have been there myself, but this feature would
> > encourage mediocre UX or would not help that much for more than
> > debugging.
>
> I don't know how C# does it but I'd like to mention that Java uses the
> declared identifier verbatim, too.  For example:
>
>     public class Demo {
>
>         enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; }
>
>         public static void main(final String[] args) {
>             for (final String a : args) {
>                 try {
>                     final Seasons season =3D Seasons.valueOf(a);
>                     System.out.println(season.toString());
>                 } catch (final IllegalArgumentException e) {
>                     System.err.printf("No valid enumerator: %s%n", a);
>                 }
>             }
>         }
>     }
>
> Here it is in action:
>
>     $ javac Demo.java && java -cp . Demo SPRING WINTER FALL
>     SPRING
>     WINTER
>     No valid enumerator: FALL
>
> While I agree that even if the only useful application for this feature
> were for debugging, it would still be worthy of standard library
> support, I have to say that I've actually used the Java feature for
> business logic in the past.  Using the declared identifiers of
> enumeration constants directly in graphical user-interfaces might not be
> the best choice.  But I think they are perfectly fine for use in, say,
> configuration files or IPC messages.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/878tvfl89r.fsf%40gmail.com.
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8=
d0A83sw%40mail.gmail.com.

--001a114277d0bdfc1d053b4089de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>C# does something similar. The funny thing is that ou=
t of bounds enum values print too : <a href=3D"https://dotnetfiddle.net/0qw=
DZk">https://dotnetfiddle.net/0qwDZk</a><br><br></div>I often do the enum-t=
o-string tricks. I&#39;d be interested if we could really describe what the=
 expected behavior would be. Not sure C# does that right, but not sure what=
 =C2=ABright=C2=BB would be in general...<br></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">2016-08-29 14:50 GMT-04:00 Moritz Klammle=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:moritz.klammler@gmail.com" target=
=3D"_blank">moritz.klammler@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"">&gt;&gt;=C2=A0 common enough to be standardi=
zed.<br>
&gt;<br>
&gt; Honestly though, is it really that common? Raw enum value names are<br=
>
&gt; probably (hopefully) not what are presented to an end user. If it is<b=
r>
&gt; used for error codes, you will have some table for actual<br>
&gt; descriptions. If it is flags, you probably have a proper parser that<b=
r>
&gt; is able to handle combinations as well, and for printing you need that=
<br>
&gt; as well.<br>
&gt;<br>
&gt; I would like to claim that only in very rare cases the raw name of an<=
br>
&gt; enumeration value is used, and if, they are for debugging<br>
&gt; purposes. The more common case with descriptions would not be<br>
&gt; covered. Languages like C# do that via annotations, and the full<br>
&gt; fledged runtime reflection. But then comes localization, =E2=80=A6<br>
&gt;<br>
&gt; I obviously understand where the desire to just print readable enum<br=
>
&gt; values comes from and have been there myself, but this feature would<b=
r>
&gt; encourage mediocre UX or would not help that much for more than<br>
&gt; debugging.<br>
<br>
</span>I don&#39;t know how C# does it but I&#39;d like to mention that Jav=
a uses the<br>
declared identifier verbatim, too.=C2=A0 For example:<br>
<br>
=C2=A0 =C2=A0 public class Demo {<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; =
}<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 public static void main(final String[] args) {<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (final String a : args) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 try {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 final=
 Seasons season =3D Seasons.valueOf(a);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Syste=
m.out.println(season.<wbr>toString());<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } catch (final Ille=
galArgumentException e) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Syste=
m.err.printf(&quot;No valid enumerator: %s%n&quot;, a);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 }<br>
<br>
Here it is in action:<br>
<br>
=C2=A0 =C2=A0 $ javac Demo.java &amp;&amp; java -cp . Demo SPRING WINTER FA=
LL<br>
=C2=A0 =C2=A0 SPRING<br>
=C2=A0 =C2=A0 WINTER<br>
=C2=A0 =C2=A0 No valid enumerator: FALL<br>
<br>
While I agree that even if the only useful application for this feature<br>
were for debugging, it would still be worthy of standard library<br>
support, I have to say that I&#39;ve actually used the Java feature for<br>
business logic in the past.=C2=A0 Using the declared identifiers of<br>
enumeration constants directly in graphical user-interfaces might not be<br=
>
the best choice.=C2=A0 But I think they are perfectly fine for use in, say,=
<br>
configuration files or IPC messages.<br>
<span class=3D""><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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/878tvfl89r.fsf%40gmail.com" re=
l=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.=
org/d/msgid/std-<wbr>proposals/878tvfl89r.fsf%<wbr>40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06ai=
QVnaCJ%3DF8d0A83sw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3O2piE=
Zy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.com</a>.<br />

--001a114277d0bdfc1d053b4089de--

.

I've added few examples showing simple implementation of
enumerator-to-string and string-to-enumerator using both the TMP and
constexpr MP libraries to the mirror reflection utilities:

https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/005_en=
um_to_string.cpp
https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/006_st=
ring_to_enum.cpp
https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/005_en=
um_to_string.cpp
https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/006_st=
ring_to_enum.cpp


On Tue, Aug 30, 2016 at 4:14 AM, Patrice Roy <patricer@gmail.com> wrote:
> C# does something similar. The funny thing is that out of bounds enum val=
ues
> print too : https://dotnetfiddle.net/0qwDZk
>
> I often do the enum-to-string tricks. I'd be interested if we could reall=
y
> describe what the expected behavior would be. Not sure C# does that right=
,
> but not sure what =C2=ABright=C2=BB would be in general...
>
> 2016-08-29 14:50 GMT-04:00 Moritz Klammler <moritz.klammler@gmail.com>:
>>
>> >>  common enough to be standardized.
>> >
>> > Honestly though, is it really that common? Raw enum value names are
>> > probably (hopefully) not what are presented to an end user. If it is
>> > used for error codes, you will have some table for actual
>> > descriptions. If it is flags, you probably have a proper parser that
>> > is able to handle combinations as well, and for printing you need that
>> > as well.
>> >
>> > I would like to claim that only in very rare cases the raw name of an
>> > enumeration value is used, and if, they are for debugging
>> > purposes. The more common case with descriptions would not be
>> > covered. Languages like C# do that via annotations, and the full
>> > fledged runtime reflection. But then comes localization, =E2=80=A6
>> >
>> > I obviously understand where the desire to just print readable enum
>> > values comes from and have been there myself, but this feature would
>> > encourage mediocre UX or would not help that much for more than
>> > debugging.
>>
>> I don't know how C# does it but I'd like to mention that Java uses the
>> declared identifier verbatim, too.  For example:
>>
>>     public class Demo {
>>
>>         enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; }
>>
>>         public static void main(final String[] args) {
>>             for (final String a : args) {
>>                 try {
>>                     final Seasons season =3D Seasons.valueOf(a);
>>                     System.out.println(season.toString());
>>                 } catch (final IllegalArgumentException e) {
>>                     System.err.printf("No valid enumerator: %s%n", a);
>>                 }
>>             }
>>         }
>>     }
>>
>> Here it is in action:
>>
>>     $ javac Demo.java && java -cp . Demo SPRING WINTER FALL
>>     SPRING
>>     WINTER
>>     No valid enumerator: FALL
>>
>> While I agree that even if the only useful application for this feature
>> were for debugging, it would still be worthy of standard library
>> support, I have to say that I've actually used the Java feature for
>> business logic in the past.  Using the declared identifiers of
>> enumeration constants directly in graphical user-interfaces might not be
>> the best choice.  But I think they are perfectly fine for use in, say,
>> configuration files or IPC messages.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/878tvfl89r.=
fsf%40gmail.com.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-VbCUDBqJNM/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3O2pi=
EZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.com.



--=20
-- Matus Chochlik

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPVNwa9R8EQm_py0x4%3DsneEog39Ksgxp%2BoVNiqerxLT=
O2qxH8w%40mail.gmail.com.

.

------=_Part_197_529381507.1472555036973
Content-Type: multipart/alternative;
 boundary="----=_Part_198_1808498120.1472555036973"

------=_Part_198_1808498120.1472555036973
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, 30 August 2016 03:14:20 UTC+1, Patrice Roy wrote:
>
> C# does something similar. The funny thing is that out of bounds enum=20
> values print too : https://dotnetfiddle.net/0qwDZk
>
> I often do the enum-to-string tricks. I'd be interested if we could reall=
y=20
> describe what the expected behavior would be. Not sure C# does that right=
,=20
> but not sure what =C2=ABright=C2=BB would be in general...
>

It depends on context, unfortunately. Sometimes you don't want to waste=20
time on error cases, so a valid enum argument would be required; other=20
times (e.g. logging) it's more important to be able to handle every=20
possibility, and indeed to provide as much information as is available to=
=20
help diagnose bugs. So there are several desirable behaviors:

char const* toStringUnchecked(Enum e) noexcept;       // #1 UB on invalid=
=20
value
char const* toStringChecked(Enum e) noexcept(false);  // #2 throws=20
std::invalid_argument
std::ostream& operator<<(std::ostream&, Enum e);      // #3 writes=20
underlying value if invalid

Plus non-throwing disappointment-handling variants of #2 (optional,=20
expected or error_code).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/593fb2db-da8d-42f3-a899-5b6fab37e880%40isocpp.or=
g.

------=_Part_198_1808498120.1472555036973
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, 30 August 2016 03:14:20 UTC+1, Patrice Roy  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>C# d=
oes something similar. The funny thing is that out of bounds enum values pr=
int too : <a href=3D"https://dotnetfiddle.net/0qwDZk" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fdotnetfiddle.net%2F0qwDZk\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHK-MitmMg_jymFxz71f8Fh2779JQ&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdotnetfiddle.net%2F0=
qwDZk\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHK-MitmMg_jymFxz71f8Fh2779JQ&=
#39;;return true;">https://dotnetfiddle.net/<wbr>0qwDZk</a><br><br></div>I =
often do the enum-to-string tricks. I&#39;d be interested if we could reall=
y describe what the expected behavior would be. Not sure C# does that right=
, but not sure what =C2=ABright=C2=BB would be in general...</div></blockqu=
ote><div><br></div><div>It depends on context, unfortunately. Sometimes you=
 don&#39;t want to waste time on error cases, so a valid enum argument woul=
d be required; other times (e.g. logging) it&#39;s more important to be abl=
e to handle every possibility, and indeed to provide as much information as=
 is available to help diagnose bugs. So there are several desirable behavio=
rs:</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 25=
0, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> toStringUnchecked</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Enum</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> e</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> noexcept</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// #1 UB on invalid value</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">char</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nst</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> toStringChecked=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Enum</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> noexcept</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">false</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// #2 throws std::invalid_argument</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">ostream</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">operator</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;&lt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">ostream</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Enum</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// #3 writes underlying value if invali=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n></div></code></div><div><br></div><div>Plus non-throwing disappointment-h=
andling variants of #2 (optional, expected or error_code).<br><br></div></d=
iv>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/593fb2db-da8d-42f3-a899-5b6fab37e880%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/593fb2db-da8d-42f3-a899-5b6fab37e880=
%40isocpp.org</a>.<br />

------=_Part_198_1808498120.1472555036973--

------=_Part_197_529381507.1472555036973--

.

------=_Part_387_1586594571.1472555101750
Content-Type: multipart/alternative;
 boundary="----=_Part_388_401661167.1472555101751"

------=_Part_388_401661167.1472555101751
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochlik wrote:
>
> I've added few examples showing simple implementation of=20
> enumerator-to-string and string-to-enumerator using both the TMP and=20
> constexpr MP libraries to the mirror reflection utilities:=20
>
>
> https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/005_=
enum_to_string.cpp=20
>
> https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/006_=
string_to_enum.cpp=20
>
> https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/005_=
enum_to_string.cpp=20
>
> https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/006_=
string_to_enum.cpp
> =20
>
=20
Is it really necessary to construct the lookup table as a library=20
container? Wouldn't a switch statement perform better?

On Tue, Aug 30, 2016 at 4:14 AM, Patrice Roy <patr...@gmail.com=20
> <javascript:>> wrote:=20
> > C# does something similar. The funny thing is that out of bounds enum=
=20
> values=20
> > print too : https://dotnetfiddle.net/0qwDZk=20
> >=20
> > I often do the enum-to-string tricks. I'd be interested if we could=20
> really=20
> > describe what the expected behavior would be. Not sure C# does that=20
> right,=20
> > but not sure what =C2=ABright=C2=BB would be in general...=20
> >=20
> > 2016-08-29 14:50 GMT-04:00 Moritz Klammler <moritz....@gmail.com=20
> <javascript:>>:=20
> >>=20
> >> >>  common enough to be standardized.=20
> >> >=20
> >> > Honestly though, is it really that common? Raw enum value names are=
=20
> >> > probably (hopefully) not what are presented to an end user. If it is=
=20
> >> > used for error codes, you will have some table for actual=20
> >> > descriptions. If it is flags, you probably have a proper parser that=
=20
> >> > is able to handle combinations as well, and for printing you need=20
> that=20
> >> > as well.=20
> >> >=20
> >> > I would like to claim that only in very rare cases the raw name of a=
n=20
> >> > enumeration value is used, and if, they are for debugging=20
> >> > purposes. The more common case with descriptions would not be=20
> >> > covered. Languages like C# do that via annotations, and the full=20
> >> > fledged runtime reflection. But then comes localization, =E2=80=A6=
=20
> >> >=20
> >> > I obviously understand where the desire to just print readable enum=
=20
> >> > values comes from and have been there myself, but this feature would=
=20
> >> > encourage mediocre UX or would not help that much for more than=20
> >> > debugging.=20
> >>=20
> >> I don't know how C# does it but I'd like to mention that Java uses the=
=20
> >> declared identifier verbatim, too.  For example:=20
> >>=20
> >>     public class Demo {=20
> >>=20
> >>         enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; }=20
> >>=20
> >>         public static void main(final String[] args) {=20
> >>             for (final String a : args) {=20
> >>                 try {=20
> >>                     final Seasons season =3D Seasons.valueOf(a);=20
> >>                     System.out.println(season.toString());=20
> >>                 } catch (final IllegalArgumentException e) {=20
> >>                     System.err.printf("No valid enumerator: %s%n", a);=
=20
> >>                 }=20
> >>             }=20
> >>         }=20
> >>     }=20
> >>=20
> >> Here it is in action:=20
> >>=20
> >>     $ javac Demo.java && java -cp . Demo SPRING WINTER FALL=20
> >>     SPRING=20
> >>     WINTER=20
> >>     No valid enumerator: FALL=20
> >>=20
> >> While I agree that even if the only useful application for this featur=
e=20
> >> were for debugging, it would still be worthy of standard library=20
> >> support, I have to say that I've actually used the Java feature for=20
> >> business logic in the past.  Using the declared identifiers of=20
> >> enumeration constants directly in graphical user-interfaces might not=
=20
> be=20
> >> the best choice.  But I think they are perfectly fine for use in, say,=
=20
> >> configuration files or IPC messages.=20
> >>=20
> >> --=20
> >> You received this message because you are subscribed to the Google=20
> Groups=20
> >> "ISO C++ Standard - Future Proposals" group.=20
> >> To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> >> email to std-proposal...@isocpp.org <javascript:>.=20
> >> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>.=20
>
> >> To view this discussion on the web visit=20
> >>=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/878tvfl89r.f=
sf%40gmail.com.=20
>
> >=20
> >=20
> > --=20
> > You received this message because you are subscribed to a topic in the=
=20
> > Google Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this topic, visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-VbCUDBqJNM/=
unsubscribe.=20
>
> > To unsubscribe from this group and all its topics, send an email to=20
> > std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3O2pi=
EZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.com.=20
>
>
>
>
> --=20
> -- Matus Chochlik=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e8e400ef-d60f-448c-9594-15c75e9728e9%40isocpp.or=
g.

------=_Part_388_401661167.1472555101751
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochlik =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I&#39;ve added few exam=
ples showing simple implementation of
<br>enumerator-to-string and string-to-enumerator using both the TMP and
<br>constexpr MP libraries to the mirror reflection utilities:
<br>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/mirror/005_enum_to_string.cpp" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F005_=
enum_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE9DbRX5PSZWtt8yz=
7NNep01JMqVQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%=
2Fdevelop%2Fexample%2Fmirror%2F005_enum_to_string.cpp\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNE9DbRX5PSZWtt8yz7NNep01JMqVQ&#39;;return true;">https://=
github.com/matus-<wbr>chochlik/mirror/blob/develop/<wbr>example/mirror/005_=
enum_to_<wbr>string.cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/mirror/006_string_to_enum.cpp" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F006_=
string_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHesQobXeGJS94EFI=
kfUtUMX9HWow&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%=
2Fdevelop%2Fexample%2Fmirror%2F006_string_to_enum.cpp\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNHesQobXeGJS94EFIkfUtUMX9HWow&#39;;return true;">https://=
github.com/matus-<wbr>chochlik/mirror/blob/develop/<wbr>example/mirror/006_=
string_to_<wbr>enum.cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/puddle/005_enum_to_string.cpp" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F005_=
enum_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGo7yI9BEgjnzUsb4=
kN2x1BNJHCWg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%=
2Fdevelop%2Fexample%2Fpuddle%2F005_enum_to_string.cpp\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNGo7yI9BEgjnzUsb4kN2x1BNJHCWg&#39;;return true;">https://=
github.com/matus-<wbr>chochlik/mirror/blob/develop/<wbr>example/puddle/005_=
enum_to_<wbr>string.cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/puddle/006_string_to_enum.cpp" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgith=
ub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F006_=
string_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF4eoKJLDWYT6U8yx=
VJt7P1xHjOsQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goo=
gle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%=
2Fdevelop%2Fexample%2Fpuddle%2F006_string_to_enum.cpp\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNF4eoKJLDWYT6U8yxVJt7P1xHjOsQ&#39;;return true;">https://=
github.com/matus-<wbr>chochlik/mirror/blob/develop/<wbr>example/puddle/006_=
string_to_<wbr>enum.cpp</a>=C2=A0<br></blockquote><div>=C2=A0</div><div>Is =
it really necessary to construct the lookup table as a library container? W=
ouldn&#39;t a switch statement perform better?</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Tue, Aug 30, 2016 at 4:14 AM, Patri=
ce Roy &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"HJ0q4y_6EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">patr...@gmail.com</a>&gt; wrote:
<br>&gt; C# does something similar. The funny thing is that out of bounds e=
num values
<br>&gt; print too : <a href=3D"https://dotnetfiddle.net/0qwDZk" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fdotnetfiddle.net%2F0qwDZk\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNHK-MitmMg_jymFxz71f8Fh2779JQ&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdotnetfi=
ddle.net%2F0qwDZk\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHK-MitmMg_jymFxz7=
1f8Fh2779JQ&#39;;return true;">https://dotnetfiddle.net/<wbr>0qwDZk</a>
<br>&gt;
<br>&gt; I often do the enum-to-string tricks. I&#39;d be interested if we =
could really
<br>&gt; describe what the expected behavior would be. Not sure C# does tha=
t right,
<br>&gt; but not sure what =C2=ABright=C2=BB would be in general...
<br>&gt;
<br>&gt; 2016-08-29 14:50 GMT-04:00 Moritz Klammler &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"HJ0q4y_6EQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">moritz....@gmail.com</a=
>&gt;:
<br>&gt;&gt;
<br>&gt;&gt; &gt;&gt; =C2=A0common enough to be standardized.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Honestly though, is it really that common? Raw enum value=
 names are
<br>&gt;&gt; &gt; probably (hopefully) not what are presented to an end use=
r. If it is
<br>&gt;&gt; &gt; used for error codes, you will have some table for actual
<br>&gt;&gt; &gt; descriptions. If it is flags, you probably have a proper =
parser that
<br>&gt;&gt; &gt; is able to handle combinations as well, and for printing =
you need that
<br>&gt;&gt; &gt; as well.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; I would like to claim that only in very rare cases the ra=
w name of an
<br>&gt;&gt; &gt; enumeration value is used, and if, they are for debugging
<br>&gt;&gt; &gt; purposes. The more common case with descriptions would no=
t be
<br>&gt;&gt; &gt; covered. Languages like C# do that via annotations, and t=
he full
<br>&gt;&gt; &gt; fledged runtime reflection. But then comes localization, =
=E2=80=A6
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; I obviously understand where the desire to just print rea=
dable enum
<br>&gt;&gt; &gt; values comes from and have been there myself, but this fe=
ature would
<br>&gt;&gt; &gt; encourage mediocre UX or would not help that much for mor=
e than
<br>&gt;&gt; &gt; debugging.
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t know how C# does it but I&#39;d like to mention th=
at Java uses the
<br>&gt;&gt; declared identifier verbatim, too. =C2=A0For example:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 public class Demo {
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum Seasons { SPRING, SUMMER, AUT=
UMN, WINTER; }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public static void main(final Stri=
ng[] args) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (final String a =
: args) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 try {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 final Seasons season =3D Seasons.valueOf(a);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 System.out.println(season.<wbr>toString());
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } catc=
h (final IllegalArgumentException e) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 System.err.printf(&quot;No valid enumerator: %s%n&quot;, a);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; Here it is in action:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 $ javac Demo.java &amp;&amp; java -cp . Demo SPR=
ING WINTER FALL
<br>&gt;&gt; =C2=A0 =C2=A0 SPRING
<br>&gt;&gt; =C2=A0 =C2=A0 WINTER
<br>&gt;&gt; =C2=A0 =C2=A0 No valid enumerator: FALL
<br>&gt;&gt;
<br>&gt;&gt; While I agree that even if the only useful application for thi=
s feature
<br>&gt;&gt; were for debugging, it would still be worthy of standard libra=
ry
<br>&gt;&gt; support, I have to say that I&#39;ve actually used the Java fe=
ature for
<br>&gt;&gt; business logic in the past. =C2=A0Using the declared identifie=
rs of
<br>&gt;&gt; enumeration constants directly in graphical user-interfaces mi=
ght not be
<br>&gt;&gt; the best choice. =C2=A0But I think they are perfectly fine for=
 use in, say,
<br>&gt;&gt; configuration files or IPC messages.
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br>&gt;&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"HJ0q4y_6EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt;&gt; To post to this group, send email to <a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"HJ0q4y_6EQAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt;&gt; To view this discussion on the web visit
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/878tvfl89r.fsf%40gmail.com" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/878tvfl89r.fsf%40gmail.com&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/878tvfl89r.fsf%40gmail.com&#39;;return true;">https://groups.google.com/a/=
<wbr>isocpp.org/d/msgid/std-<wbr>proposals/878tvfl89r.fsf%<wbr>40gmail.com<=
/a>.
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to a topic in=
 the
<br>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; grou=
p.
<br>&gt; To unsubscribe from this topic, visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/-VbCUDBqJNM/unsubscribe" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/topic/std-p=
roposals/-VbCUDBqJNM/unsubscribe&#39;;return true;" onclick=3D"this.href=3D=
&#39;https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-VbCUDBqJ=
NM/unsubscribe&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/topic/std-<wbr>proposals/-VbCUDBqJNM/<wbr>unsubscribe</a>.
<br>&gt; To unsubscribe from this group and all its topics, send an email t=
o
<br>&gt; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"HJ0q4y_6EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"HJ0q4y_6EQAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.=
com" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3O2piEZy7D=
r4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.com&#39;;return true;" =
onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/=
std-proposals/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mai=
l.gmail.com&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/=
d/msgid/std-<wbr>proposals/<wbr>CAKiZDp3O2piEZy7Dr4XSPQqO%<wbr>2BZd-rv06aiQ=
VnaCJ%3DF8d0A83sw%<wbr>40mail.gmail.com</a>.
<br>
<br>
<br>
<br>--=20
<br>-- Matus Chochlik
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8e400ef-d60f-448c-9594-15c75e9728e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8e400ef-d60f-448c-9594-15c75e9728e9=
%40isocpp.org</a>.<br />

------=_Part_388_401661167.1472555101751--

------=_Part_387_1586594571.1472555101750--

.

--001a11425a320138b5053b539b8e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

An important issue I was trying to bring up (but failed :) ) is the
handling of values from the underlying type that don't match effective enum
values. C# does something, it might not be what we want, and what one of us
wants does not necessarily match what another one of us wants.

I think Edward saw this : the difficulty in making standard enum-to-string
behavior is (a) what to do with values that don't map to an enum constant,
and (b) choosing what to do with scope names (class, namespace, ...) with
the relevant string values. These issues don't seem easy to settle in a
standard fashion, at least in my eyes, as there are valid arguments for
various behaviors.

Now, if someone could write a proposal that both offers language support
for some behavior, and backs it up with library functions that let users
control the conversion behavior efficiently, then... :)

2016-08-30 7:05 GMT-04:00 Edward Catmur <ed@catmur.co.uk>:

> On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochlik wrote:
>>
>> I've added few examples showing simple implementation of
>> enumerator-to-string and string-to-enumerator using both the TMP and
>> constexpr MP libraries to the mirror reflection utilities:
>>
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/mirror/005_enum_to_string.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/mirror/006_string_to_enum.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/puddle/005_enum_to_string.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/puddle/006_string_to_enum.cpp
>>
>
> Is it really necessary to construct the lookup table as a library
> container? Wouldn't a switch statement perform better?
>
> On Tue, Aug 30, 2016 at 4:14 AM, Patrice Roy <patr...@gmail.com> wrote:
>> > C# does something similar. The funny thing is that out of bounds enum
>> values
>> > print too : https://dotnetfiddle.net/0qwDZk
>> >
>> > I often do the enum-to-string tricks. I'd be interested if we could
>> really
>> > describe what the expected behavior would be. Not sure C# does that
>> right,
>> > but not sure what =C2=ABright=C2=BB would be in general...
>> >
>> > 2016-08-29 14:50 GMT-04:00 Moritz Klammler <moritz....@gmail.com>:
>> >>
>> >> >>  common enough to be standardized.
>> >> >
>> >> > Honestly though, is it really that common? Raw enum value names are
>> >> > probably (hopefully) not what are presented to an end user. If it i=
s
>> >> > used for error codes, you will have some table for actual
>> >> > descriptions. If it is flags, you probably have a proper parser tha=
t
>> >> > is able to handle combinations as well, and for printing you need
>> that
>> >> > as well.
>> >> >
>> >> > I would like to claim that only in very rare cases the raw name of
>> an
>> >> > enumeration value is used, and if, they are for debugging
>> >> > purposes. The more common case with descriptions would not be
>> >> > covered. Languages like C# do that via annotations, and the full
>> >> > fledged runtime reflection. But then comes localization, =E2=80=A6
>> >> >
>> >> > I obviously understand where the desire to just print readable enum
>> >> > values comes from and have been there myself, but this feature woul=
d
>> >> > encourage mediocre UX or would not help that much for more than
>> >> > debugging.
>> >>
>> >> I don't know how C# does it but I'd like to mention that Java uses th=
e
>> >> declared identifier verbatim, too.  For example:
>> >>
>> >>     public class Demo {
>> >>
>> >>         enum Seasons { SPRING, SUMMER, AUTUMN, WINTER; }
>> >>
>> >>         public static void main(final String[] args) {
>> >>             for (final String a : args) {
>> >>                 try {
>> >>                     final Seasons season =3D Seasons.valueOf(a);
>> >>                     System.out.println(season.toString());
>> >>                 } catch (final IllegalArgumentException e) {
>> >>                     System.err.printf("No valid enumerator: %s%n", a)=
;
>> >>                 }
>> >>             }
>> >>         }
>> >>     }
>> >>
>> >> Here it is in action:
>> >>
>> >>     $ javac Demo.java && java -cp . Demo SPRING WINTER FALL
>> >>     SPRING
>> >>     WINTER
>> >>     No valid enumerator: FALL
>> >>
>> >> While I agree that even if the only useful application for this
>> feature
>> >> were for debugging, it would still be worthy of standard library
>> >> support, I have to say that I've actually used the Java feature for
>> >> business logic in the past.  Using the declared identifiers of
>> >> enumeration constants directly in graphical user-interfaces might not
>> be
>> >> the best choice.  But I think they are perfectly fine for use in, say=
,
>> >> configuration files or IPC messages.
>> >>
>> >> --
>> >> 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, sen=
d
>> an
>> >> email to std-proposal...@isocpp.org.
>> >> To post to this group, send email to std-pr...@isocpp.org.
>> >> To view this discussion on the web visit
>> >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>> /878tvfl89r.fsf%40gmail.com.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/a/isocpp.org/d/topic/std-proposals
>> /-VbCUDBqJNM/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > To view this discussion on the web visit
>> > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals
>> /CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.co=
m.
>>
>>
>>
>>
>> --
>> -- Matus Chochlik
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/e8e400ef-d60f-448c-
> 9594-15c75e9728e9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8e400ef-d6=
0f-448c-9594-15c75e9728e9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp2%2B5Mh2y-uzp9Oc6gqvtam4-QNocLGipQNHLp9y1=
A-ODQ%40mail.gmail.com.

--001a11425a320138b5053b539b8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>An important issue I was trying to bring up (but=
 failed :) ) is the handling of values from the underlying type that don&#3=
9;t match effective enum values. C# does something, it might not be what we=
 want, and what one of us wants does not necessarily match what another one=
 of us wants.<br><br></div>I think Edward saw this : the difficulty in maki=
ng standard enum-to-string behavior is (a) what to do with values that don&=
#39;t map to an enum constant, and (b) choosing what to do with scope names=
 (class, namespace, ...) with the relevant string values. These issues don&=
#39;t seem easy to settle in a standard fashion, at least in my eyes, as th=
ere are valid arguments for various behaviors.<br><br></div>Now, if someone=
 could write a proposal that both offers language support for some behavior=
, and backs it up with library functions that let users control the convers=
ion behavior efficiently, then... :)<br></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">2016-08-30 7:05 GMT-04:00 Edward Catmur <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@cat=
mur.co.uk</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"">On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochli=
k  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve added few example=
s showing simple implementation of
<br>enumerator-to-string and string-to-enumerator using both the TMP and
<br>constexpr MP libraries to the mirror reflection utilities:
<br>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/mirror/005_enum_to_string.cpp" rel=3D"nofollow" target=3D"_blank">https:/=
/github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/mirror/005=
_enum_to_string.<wbr>cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/mirror/006_string_to_enum.cpp" rel=3D"nofollow" target=3D"_blank">https:/=
/github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/mirror/006=
_string_to_enum.<wbr>cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/puddle/005_enum_to_string.cpp" rel=3D"nofollow" target=3D"_blank">https:/=
/github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/puddle/005=
_enum_to_string.<wbr>cpp</a>
<br><a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/exampl=
e/puddle/006_string_to_enum.cpp" rel=3D"nofollow" target=3D"_blank">https:/=
/github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/puddle/006=
_string_to_enum.<wbr>cpp</a>=C2=A0<br></blockquote><div>=C2=A0</div></span>=
<div>Is it really necessary to construct the lookup table as a library cont=
ainer? Wouldn&#39;t a switch statement perform better?</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, Aug 30, 20=
16 at 4:14 AM, Patrice Roy &lt;<a rel=3D"nofollow">patr...@gmail.com</a>&gt=
; wrote:
<br>&gt; C# does something similar. The funny thing is that out of bounds e=
num values
<br>&gt; print too : <a href=3D"https://dotnetfiddle.net/0qwDZk" rel=3D"nof=
ollow" target=3D"_blank">https://dotnetfiddle.net/0qwDZ<wbr>k</a>
<br>&gt;
<br>&gt; I often do the enum-to-string tricks. I&#39;d be interested if we =
could really
<br>&gt; describe what the expected behavior would be. Not sure C# does tha=
t right,
<br>&gt; but not sure what =C2=ABright=C2=BB would be in general...
<br>&gt;
<br></span><div><div class=3D"h5">&gt; 2016-08-29 14:50 GMT-04:00 Moritz Kl=
ammler &lt;<a rel=3D"nofollow">moritz....@gmail.com</a>&gt;:
<br>&gt;&gt;
<br>&gt;&gt; &gt;&gt; =C2=A0common enough to be standardized.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Honestly though, is it really that common? Raw enum value=
 names are
<br>&gt;&gt; &gt; probably (hopefully) not what are presented to an end use=
r. If it is
<br>&gt;&gt; &gt; used for error codes, you will have some table for actual
<br>&gt;&gt; &gt; descriptions. If it is flags, you probably have a proper =
parser that
<br>&gt;&gt; &gt; is able to handle combinations as well, and for printing =
you need that
<br>&gt;&gt; &gt; as well.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; I would like to claim that only in very rare cases the ra=
w name of an
<br>&gt;&gt; &gt; enumeration value is used, and if, they are for debugging
<br>&gt;&gt; &gt; purposes. The more common case with descriptions would no=
t be
<br>&gt;&gt; &gt; covered. Languages like C# do that via annotations, and t=
he full
<br>&gt;&gt; &gt; fledged runtime reflection. But then comes localization, =
=E2=80=A6
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; I obviously understand where the desire to just print rea=
dable enum
<br>&gt;&gt; &gt; values comes from and have been there myself, but this fe=
ature would
<br>&gt;&gt; &gt; encourage mediocre UX or would not help that much for mor=
e than
<br>&gt;&gt; &gt; debugging.
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t know how C# does it but I&#39;d like to mention th=
at Java uses the
<br>&gt;&gt; declared identifier verbatim, too.=C2=A0 For example:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 public class Demo {
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum Seasons { SPRING, SUMMER, AUT=
UMN, WINTER; }
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 public static void main(final Stri=
ng[] args) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (final String a =
: args) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 try {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 final Seasons season =3D Seasons.valueOf(a);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 System.out.println(season.toSt<wbr>ring());
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } catc=
h (final IllegalArgumentException e) {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 System.err.printf(&quot;No valid enumerator: %s%n&quot;, a);
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt;
<br>&gt;&gt; Here it is in action:
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 =C2=A0 $ javac Demo.java &amp;&amp; java -cp . Demo SPR=
ING WINTER FALL
<br>&gt;&gt; =C2=A0 =C2=A0 SPRING
<br>&gt;&gt; =C2=A0 =C2=A0 WINTER
<br>&gt;&gt; =C2=A0 =C2=A0 No valid enumerator: FALL
<br>&gt;&gt;
<br>&gt;&gt; While I agree that even if the only useful application for thi=
s feature
<br>&gt;&gt; were for debugging, it would still be worthy of standard libra=
ry
<br>&gt;&gt; support, I have to say that I&#39;ve actually used the Java fe=
ature for
<br>&gt;&gt; business logic in the past.=C2=A0 Using the declared identifie=
rs of
<br>&gt;&gt; enumeration constants directly in graphical user-interfaces mi=
ght not be
<br>&gt;&gt; the best choice.=C2=A0 But I think they are perfectly fine for=
 use in, say,
<br>&gt;&gt; configuration files or IPC messages.
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br></div></div>&gt;&gt; email to <a rel=3D"nofollow">std-proposal...@isocp=
p.org</a>.
<br>&gt;&gt; To post to this group, send email to <a rel=3D"nofollow">std-p=
r...@isocpp.org</a>.
<br><span class=3D"">&gt;&gt; To view this discussion on the web visit
<br>&gt;&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-=
proposals/878tvfl89r.fsf%40gmail.com" rel=3D"nofollow" target=3D"_blank">ht=
tps://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/878tvf=
l89r.fsf%40gmail.com</a>.
<br>&gt;
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to a topic in=
 the
<br>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; grou=
p.
<br>&gt; To unsubscribe from this topic, visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/-VbCUDBqJNM/unsubscribe" rel=3D"nofollow" target=3D"_blank">https://g=
roups.google.com/a/is<wbr>ocpp.org/d/topic/std-proposals<wbr>/-VbCUDBqJNM/u=
nsubscribe</a>.
<br>&gt; To unsubscribe from this group and all its topics, send an email t=
o
<br></span>&gt; <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.
<br>&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br><span class=3D"">&gt; To view this discussion on the web visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZd-rv06aiQVnaCJ%3DF8d0A83sw%40mail.gmail.=
com" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/a/is<wbr>=
ocpp.org/d/msgid/std-proposals<wbr>/CAKiZDp3O2piEZy7Dr4XSPQqO%2BZ<wbr>d-rv0=
6aiQVnaCJ%3DF8d0A83sw%40m<wbr>ail.gmail.com</a>.
<br>
<br>
<br>
<br>--=20
<br>-- Matus Chochlik
<br></span></blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8e400ef-d60f-448c-9594-15c75e9728e9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e8e4=
00ef-d60f-448c-<wbr>9594-15c75e9728e9%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2%2B5Mh2y-uzp9Oc6gqvtam4-QNocL=
GipQNHLp9y1A-ODQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2%2B5Mh2=
y-uzp9Oc6gqvtam4-QNocLGipQNHLp9y1A-ODQ%40mail.gmail.com</a>.<br />

--001a11425a320138b5053b539b8e--

.

This is a multi-part message in MIME format.
--------------C3C4909328531A2728497738
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 30/08/2016 =C3=A0 13:05, Edward Catmur a =C3=A9crit :
> On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochlik wrote:
>
>     I've added few examples showing simple implementation of
>     enumerator-to-string and string-to-enumerator using both the TMP and
>     constexpr MP libraries to the mirror reflection utilities:
>
>     https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/=
005_enum_to_string.cpp
>     <https://github.com/matus-chochlik/mirror/blob/develop/example/mirror=
/005_enum_to_string.cpp>
>
>     https://github.com/matus-chochlik/mirror/blob/develop/example/mirror/=
006_string_to_enum.cpp
>     <https://github.com/matus-chochlik/mirror/blob/develop/example/mirror=
/006_string_to_enum.cpp>
>
>     https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/=
005_enum_to_string.cpp
>     <https://github.com/matus-chochlik/mirror/blob/develop/example/puddle=
/005_enum_to_string.cpp>
>
>     https://github.com/matus-chochlik/mirror/blob/develop/example/puddle/=
006_string_to_enum.cpp
>     <https://github.com/matus-chochlik/mirror/blob/develop/example/puddle=
/006_string_to_enum.cpp>
>
>
> Is it really necessary to construct the lookup table as a library=20
> container? Wouldn't a switch statement perform better?
>
No, we don't need a map, but I believe that Matus wanted to show a probe=20
of concept.

I don't know how we can generate a switch with the current language. We=20
can do some recursive if and expect that the compiler optimize it.

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ce4634af-e0ab-251b-d804-8fb721e855f9%40wanadoo.f=
r.

--------------C3C4909328531A2728497738
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">Le 30/08/2016 =C3=A0 13:05, Edward Catmu=
r a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:e8e400ef-d60f-448c-9594-15c75e9728e9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus
        Chochlik wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I've
          added few examples showing simple implementation of
          <br>
          enumerator-to-string and string-to-enumerator using both the
          TMP and
          <br>
          constexpr MP libraries to the mirror reflection utilities:
          <br>
          <br>
          <a moz-do-not-send=3D"true"
href=3D"https://github.com/matus-chochlik/mirror/blob/develop/example/mirro=
r/005_enum_to_string.cpp"
            target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F0=
05_enum_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE9DbRX5PSZWtt=
8yz7NNep01JMqVQ';return
            true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F005_e=
num_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE9DbRX5PSZWtt8yz7=
NNep01JMqVQ';return
            true;">https://github.com/matus-<wbr>chochlik/mirror/blob/devel=
op/<wbr>example/mirror/005_enum_to_<wbr>string.cpp</a>
          <br>
          <a moz-do-not-send=3D"true"
href=3D"https://github.com/matus-chochlik/mirror/blob/develop/example/mirro=
r/006_string_to_enum.cpp"
            target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F0=
06_string_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHesQobXeGJS94=
EFIkfUtUMX9HWow';return
            true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fmirror%2F006_s=
tring_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHesQobXeGJS94EFIk=
fUtUMX9HWow';return
            true;">https://github.com/matus-<wbr>chochlik/mirror/blob/devel=
op/<wbr>example/mirror/006_string_to_<wbr>enum.cpp</a>
          <br>
          <a moz-do-not-send=3D"true"
href=3D"https://github.com/matus-chochlik/mirror/blob/develop/example/puddl=
e/005_enum_to_string.cpp"
            target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F0=
05_enum_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGo7yI9BEgjnzU=
sb4kN2x1BNJHCWg';return
            true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F005_e=
num_to_string.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGo7yI9BEgjnzUsb4k=
N2x1BNJHCWg';return
            true;">https://github.com/matus-<wbr>chochlik/mirror/blob/devel=
op/<wbr>example/puddle/005_enum_to_<wbr>string.cpp</a>
          <br>
          <a moz-do-not-send=3D"true"
href=3D"https://github.com/matus-chochlik/mirror/blob/develop/example/puddl=
e/006_string_to_enum.cpp"
            target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fg=
ithub.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F0=
06_string_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF4eoKJLDWYT6U=
8yxVJt7P1xHjOsQ';return
            true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fmatus-chochlik%2Fmirror%2Fblob%2Fdevelop%2Fexample%2Fpuddle%2F006_s=
tring_to_enum.cpp\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF4eoKJLDWYT6U8yxV=
Jt7P1xHjOsQ';return
            true;">https://github.com/matus-<wbr>chochlik/mirror/blob/devel=
op/<wbr>example/puddle/006_string_to_<wbr>enum.cpp</a>=C2=A0<br>
        </blockquote>
        <div>=C2=A0</div>
        <div>Is it really necessary to construct the lookup table as a
          library container? Wouldn't a switch statement perform better?</d=
iv>
        <div><br>
        </div>
      </div>
    </blockquote>
    No, we don't need a map, but I believe that Matus wanted to show a
    probe of concept. <br>
    <br>
    I don't know how we can generate a switch with the current language.
    We can do some recursive if and expect that the compiler optimize
    it.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ce4634af-e0ab-251b-d804-8fb721e855f9%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ce4634af-e0ab-251b-d804-8fb721e855f9=
%40wanadoo.fr</a>.<br />

--------------C3C4909328531A2728497738--

.

Le 31/08/2016 =C3=A0 02:59, Patrice Roy a =C3=A9crit :
> An important issue I was trying to bring up (but failed :) ) is the=20
> handling of values from the underlying type that don't match effective=20
> enum values. C# does something, it might not be what we want, and what=20
> one of us wants does not necessarily match what another one of us wants.
>
> I think Edward saw this : the difficulty in making standard=20
> enum-to-string behavior is (a) what to do with values that don't map=20
> to an enum constant, and (b) choosing what to do with scope names=20
> (class, namespace, ...) with the relevant string values. These issues=20
> don't seem easy to settle in a standard fashion, at least in my eyes,=20
> as there are valid arguments for various behaviors.
You are right that there are some variation points.

(a) I believe the C# option is a good one. If the user wants to check=20
for validity of an enum constant another function can be provided and=20
the user could combine them. This is a subset of enums.

(b) I believe that having the string for the enumerators is the minimal=20
feature and it is already beter than the number. We can as well have=20
another function that allows to obtain the string associated to the scope.

>
> Now, if someone could write a proposal that both offers language=20
> support for some behavior, and backs it up with library functions that=20
> let users control the conversion behavior efficiently, then... :)

I hope that someone would propose something once we have reflection=20
delivered by a major compiler ;-)

Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/791a04ce-3dd7-fc31-8798-ee4fe812d7fb%40wanadoo.f=
r.

.

--94eb2c0560d68fce98053b6489ef
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 31, 2016 at 9:20 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:

> Le 30/08/2016 =C3=A0 13:05, Edward Catmur a =C3=A9crit :
>
> On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus Chochlik wrote:
>>
>> I've added few examples showing simple implementation of
>> enumerator-to-string and string-to-enumerator using both the TMP and
>> constexpr MP libraries to the mirror reflection utilities:
>>
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/mirror/005_enum_to_string.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/mirror/006_string_to_enum.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/puddle/005_enum_to_string.cpp
>> https://github.com/matus-chochlik/mirror/blob/develop/exampl
>> e/puddle/006_string_to_enum.cpp
>>
>
> Is it really necessary to construct the lookup table as a library
> container? Wouldn't a switch statement perform better?
>
> No, we don't need a map, but I believe that Matus wanted to show a probe
> of concept.
>
> I don't know how we can generate a switch with the current language. We
> can do some recursive if and expect that the compiler optimize it.
>

Fair enough; recursive templates are even worse, so a container is the
simplest option for now. You can generate a switch with the preprocessor,
but then you have to set an (arbitrary) upper limit on the number of cases.
We really need variadic expansion of case labels, but I guess it's a fairly
niche interest.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJnLdOZAFnHVov-%2BRWp2JwjFjLp5ZpnRW7PmLgAiFCv%3=
Dx_4a_w%40mail.gmail.com.

--94eb2c0560d68fce98053b6489ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Aug 31, 2016 at 9:20 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr">&lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
    <div>Le 30/08/2016 =C3=A0 13:05, Edward Catmur a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Tuesday, 30 August 2016 06:23:04 UTC+1, Matus
        Chochlik wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve
          added few examples showing simple implementation of
          <br>
          enumerator-to-string and string-to-enumerator using both the
          TMP and
          <br>
          constexpr MP libraries to the mirror reflection utilities:
          <br>
          <br>
          <a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/=
example/mirror/005_enum_to_string.cpp" rel=3D"nofollow" target=3D"_blank">h=
ttps://github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/mirr=
or/005_enum_to_string.<wbr>cpp</a>
          <br>
          <a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/=
example/mirror/006_string_to_enum.cpp" rel=3D"nofollow" target=3D"_blank">h=
ttps://github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/mirr=
or/006_string_to_enum.<wbr>cpp</a>
          <br>
          <a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/=
example/puddle/005_enum_to_string.cpp" rel=3D"nofollow" target=3D"_blank">h=
ttps://github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/pudd=
le/005_enum_to_string.<wbr>cpp</a>
          <br>
          <a href=3D"https://github.com/matus-chochlik/mirror/blob/develop/=
example/puddle/006_string_to_enum.cpp" rel=3D"nofollow" target=3D"_blank">h=
ttps://github.com/matus-choch<wbr>lik/mirror/blob/develop/exampl<wbr>e/pudd=
le/006_string_to_enum.<wbr>cpp</a>=C2=A0<br>
        </blockquote>
        <div>=C2=A0</div>
        <div>Is it really necessary to construct the lookup table as a
          library container? Wouldn&#39;t a switch statement perform better=
?</div>
        <div><br>
        </div>
      </div>
    </blockquote></span>
    No, we don&#39;t need a map, but I believe that Matus wanted to show a
    probe of concept. <br>
    <br>
    I don&#39;t know how we can generate a switch with the current language=
..
    We can do some recursive if and expect that the compiler optimize
    it.</div></blockquote><div><br></div><div>Fair enough; recursive templa=
tes are even worse, so a container is the simplest option for now. You can =
generate a switch with the preprocessor, but then you have to set an (arbit=
rary) upper limit on the number of cases. We really need variadic expansion=
 of case labels, but I guess it&#39;s a fairly niche interest.</div></div><=
br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZAFnHVov-%2BRWp2JwjFjLp5ZpnRW7=
PmLgAiFCv%3Dx_4a_w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZAFnHV=
ov-%2BRWp2JwjFjLp5ZpnRW7PmLgAiFCv%3Dx_4a_w%40mail.gmail.com</a>.<br />

--94eb2c0560d68fce98053b6489ef--

.

On 08/31/2016 04:11 PM, 'Edward Catmur' via ISO C++ Standard - Future
Proposals wrote:
>
>
> On Wed, Aug 31, 2016 at 9:20 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
[snip]
>     No, we don't need a map, but I believe that Matus wanted to show a
>     probe of concept.
>
>     I don't know how we can generate a switch with the current language.
>     We can do some recursive if and expect that the compiler optimize it.
>
>
> Fair enough; recursive templates are even worse, so a container is the
> simplest option for now. You can generate a switch with the
> preprocessor, but then you have to set an (arbitrary) upper limit on the
> number of cases. We really need variadic expansion of case labels, but I
> guess it's a fairly niche interest.
>
Would the proposal here:

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/statement$20expansion/std-proposals/LoDJDCDDyH8/omuPHEjpJJkJ

help?



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nq83ju%24ch1%241%40blaine.gmane.org.

.

------=_Part_2695_932849456.1537958488632
Content-Type: multipart/alternative;
 boundary="----=_Part_2696_1282017642.1537958488632"

------=_Part_2696_1282017642.1537958488632
Content-Type: text/plain; charset="UTF-8"

While the reflection proposal is very nice and generic, has anyone so far
brought up the idea of building something like this on top of the "=
default" style syntax, e.g. "constexpr std::string to_string(MyEnum) =
default;" or a similar style for operator<<, or perhaps even building it
upon using attributes "[[printable]]", or even automatically and silently
generating enum-to-string functions (as constexpr to_string(MyEnum)"
implicitly if ever used in the code, similar to existing default c-tor
generation (or always for multiple compile units, with elimination by
linker stage optimization if unused)? Out of these options, I prefer the
last one - automatic generation if used.

I know that the C++ standards committee policy is usually to prefer generic
solutions over specific solutions, but couldn't building "enum to  string"
on top of reflection be considered an exaggeration of that rule? It seems
to me that the generic approaches listed above may have to build on
recursive templates or otherwise potentially slow-to-compile operations, so
certainly one argument in favor of more specific language support would be
potentially faster compile times for generating what is really a very
common pattern in most large C++ code bases.

Moreover, I'm not usre there's any good reason to force the user to
implement enum-to-string functionality manually. It's certainly less
convenient for the user to do it manually (which the reflection based
approach would require), and it's also certainly possible for a compiler to
determine whether a call to enum-to-string is ever made in the code base
and in that way know whether such a method would need to be generated. If
for some reason certain users would desire compiler warnings for
unnecessarily generated to_string methods or a way to more easily detect
whether a method is implicitly generated, perhaps automatic generation
could be expressed by an attribute: [[printable]].

In order to be more generic than only applying to enums, this idea could be
supported also for structs/classes, where the default option could be to
print all members in a similar to how they are printed in GDB, i.e.
delimited by suitable delimiters and with some form of hierarchy in cases
where a member is of struct type.


Den torsdag 25 augusti 2016 kl. 15:47:34 UTC+2 skrev Kamikaze Dominic
Fandrey:
>
> I searched this list for similar suggestions, but of course I may
> have overlooked something.
>
> I frequently use the following pattern:
>
>     enum class FooBar { KEKS, DOSE };
>     char const * const FooBarStr[]{"KEKS", "DOSE"};
>
> I use the strings to in error messages, verbose output, etc.
>
>     FooBarStr[static_cast<int>(FooBar::KEKS)] // "KEKS"
>
> This has some disadvantages, e.g. enums with explicitly stated values
> may have gaps, negative values and may be defined out of order.
> Also, changing the enum also means changing the strings manually.
>
> What I'd like to see:
>
>     static_cast<char const *>(FooBar::KEKS) // "KEKS"
>
> I think this would be simple to add to an existing compiler and it's
> very unlikely to clash with existing code, because you have to jump
> through some hoops to cast a strongly typed enum to a pointer type.
>
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2%40isocpp.org.

------=_Part_2696_1282017642.1537958488632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While the reflection proposal is very nice and generic, ha=
s anyone so far brought up the idea of building something like this on top =
of the &quot;=3D default&quot; style syntax, e.g. &quot;constexpr std::stri=
ng to_string(MyEnum) =3D default;&quot; or a similar style for operator&lt;=
&lt;, or perhaps even building it upon using attributes &quot;[[printable]]=
&quot;, or even automatically and silently generating enum-to-string functi=
ons (as constexpr to_string(MyEnum)&quot; implicitly if ever used in the co=
de, similar to existing default c-tor generation (or always for multiple co=
mpile units, with elimination by linker stage optimization if unused)? Out =
of these options, I prefer the last one - automatic generation if used.<div=
><br></div><div>I know that the C++ standards committee policy is usually t=
o prefer generic solutions over specific solutions, but couldn&#39;t buildi=
ng &quot;enum to=C2=A0 string&quot; on top of reflection be considered an e=
xaggeration of that rule? It seems to me that the generic approaches listed=
 above may have to build on recursive templates or otherwise potentially sl=
ow-to-compile operations, so certainly one argument in favor of more specif=
ic language support would be potentially faster compile times for generatin=
g what is really a very common pattern in most large C++ code bases.</div><=
div><div><br></div><div>Moreover, I&#39;m not usre there&#39;s any good rea=
son to force the user to implement enum-to-string functionality manually. I=
t&#39;s certainly less convenient for the user to do it manually (which the=
 reflection based approach would require), and it&#39;s also certainly poss=
ible for a compiler to determine whether a call to enum-to-string is ever m=
ade in the code base and in that way know whether such a method would need =
to be generated. If for some reason certain users would desire compiler war=
nings for unnecessarily generated to_string methods or a way to more easily=
 detect whether a method is implicitly generated, perhaps automatic generat=
ion could be expressed by an attribute: [[printable]].</div><div><br></div>=
<div>In order to be more generic than only applying to enums, this idea cou=
ld be supported also for structs/classes, where the default option could be=
 to print all members in a similar to how they are printed in GDB, i.e. del=
imited by suitable delimiters and with some form of hierarchy in cases wher=
e a member is of struct type.</div><div><br><br>Den torsdag 25 augusti 2016=
 kl. 15:47:34 UTC+2 skrev Kamikaze Dominic Fandrey:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">I searched this list for similar suggestions, but of c=
ourse I may
<br>have overlooked something.
<br>
<br>I frequently use the following pattern:
<br>
<br>=C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };
<br>=C2=A0 =C2=A0 char const * const FooBarStr[]{&quot;KEKS&quot;, &quot;DO=
SE&quot;};
<br>
<br>I use the strings to in error messages, verbose output, etc.
<br>
<br>=C2=A0 =C2=A0 FooBarStr[static_cast&lt;int&gt;(<wbr>FooBar::KEKS)] // &=
quot;KEKS&quot;
<br>
<br>This has some disadvantages, e.g. enums with explicitly stated values
<br>may have gaps, negative values and may be defined out of order.
<br>Also, changing the enum also means changing the strings manually.
<br>
<br>What I&#39;d like to see:
<br>
<br>=C2=A0 =C2=A0 static_cast&lt;char const *&gt;(FooBar::KEKS) // &quot;KE=
KS&quot;
<br>
<br>I think this would be simple to add to an existing compiler and it&#39;=
s
<br>very unlikely to clash with existing code, because you have to jump
<br>through some hoops to cast a strongly typed enum to a pointer type.
<br>
<br>--=20
<br>A: Because it fouls the order in which people normally read text.
<br>Q: Why is top-posting such a bad thing?
<br>A: Top-posting.
<br>Q: What is the most annoying thing on usenet and in e-mail?
<br>
<br>
<br></blockquote></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2=
%40isocpp.org</a>.<br />

------=_Part_2696_1282017642.1537958488632--

------=_Part_2695_932849456.1537958488632--

.