Topic: Extend std::bitset to support enums ("named bits")
Author: "Ivan G." <nekotekina@gmail.com>
Date: Fri, 5 Oct 2018 06:22:00 -0700 (PDT)
Raw View
------=_Part_732_1359640768.1538745720785
Content-Type: multipart/alternative;
boundary="----=_Part_733_749702982.1538745720785"
------=_Part_733_749702982.1538745720785
Content-Type: text/plain; charset="UTF-8"
Hello, there are many enums that look roughly like this:
enum class my_enum {
value1,
value2,
value3,
MAX
};
Here MAX is the last parameter and it also happens to be the number of
enums in the simplest case.
std::bitset is currently defined as template< std::size_t
<http://en.cppreference.com/w/cpp/types/size_t> N > class bitset;
C++17 added auto in non-type template parameters, so the idea is to change
std::bitset definition to template < *auto N* > class bitset;
And allow using enum values like my_enum::MAX as its parameter.
1) If integer type or an unscoped enum type is used as N, the behaviour of
std::bitset is unchanged.
2) If a scoped enum type is used as N, std::bitset behaviour is altered to
work with "named bits". For example, operator[] would accept only an
argument of this enum type.
3) In any other cases, it should be a compilation error.
Motivation is having an alternative to currently used approaches for bit
mask enums, which have several cons:
1) Require typing shifts: 1 << 0, 1 << 1, etc for each value. This is
annoying and error-prone.
2) Limited in size, i.e. it's impossible to have more than 64 named bits.
But std::bitset doesn't have this limitation.
But std::bitset bits are "anonymous". The idea allows to map trivially
enumerated named bits to a bitset without size limitation, as an opt-in.
Maybe this is better implemented as a different class to prevent any
conflicts with existing std::bitset usage.
--
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/f349f116-17ca-46d4-9485-7353857f5e2c%40isocpp.org.
------=_Part_733_749702982.1538745720785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello, there are many enums that look roughly like th=
is:</div><div><br></div><div>enum class my_enum {</div><div>=C2=A0 value1,<=
/div><div>=C2=A0 value2,</div><div>=C2=A0 value3,</div><div><br></div><div>=
=C2=A0 MAX</div><div>};</div><div><br></div><div>Here MAX is the last param=
eter and it also happens to be the number of enums in the simplest case.</d=
iv><div><br></div><div>std::bitset is currently defined as <span class=3D"m=
w-geshi cpp source-cpp"><span class=3D"kw1">template</span><span class=3D"s=
y1"><</span> <a href=3D"http://en.cppreference.com/w/cpp/types/size_t" t=
abindex=3D"1"><span class=3D"kw100">std::<span class=3D"me2">size_t</span><=
/span></a> N <span class=3D"sy1">></span><span class=3D"kw1"> class</spa=
n> bitset<span class=3D"sy4">;</span></span><table class=3D"t-dcl-begin"><t=
body><tr class=3D"t-dcl"><td class=3D"t-dcl-nopad"></td>
<td class=3D"t-dcl-nopad"></td></tr></tbody></table></div><div><span class=
=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">C++17 added auto in non-ty=
pe template parameters, so the idea is to change std::bitset definition to =
template < <b>auto N</b></span></span><span class=3D"mw-geshi cpp source=
-cpp"><span class=3D"sy4"> > class bitset;</span></span><span class=3D"m=
w-geshi cpp source-cpp"><span class=3D"sy4"><br></span></span></div><div><s=
pan class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><br></span></span=
></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">And=
allow using enum values like my_enum::MAX as its parameter.<br></span></sp=
an></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><=
br></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span c=
lass=3D"sy4">1) If integer type or an unscoped enum type is used as N, the =
behaviour of std::bitset is unchanged.<br></span></span></div><div><span cl=
ass=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">2) If a scoped enum typ=
e is used as N, std::bitset behaviour is altered to work with "named b=
its". For example, operator[] would accept only an argument of this en=
um type.<br></span></span></div><div><span class=3D"mw-geshi cpp source-cpp=
"><span class=3D"sy4">3) In any other cases, it should be a compilation err=
or.<br></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><sp=
an class=3D"sy4"><br></span></span></div><div><span class=3D"mw-geshi cpp s=
ource-cpp"><span class=3D"sy4">Motivation is having an alternative to curre=
ntly used approaches for bit mask enums, which have several cons:<br></span=
></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"s=
y4">1) Require typing shifts: 1 << 0, 1 << 1, etc for each valu=
e. This is annoying and error-prone.<br></span></span></div><div><span clas=
s=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">2) Limited in size, i.e. =
it's impossible to have more than 64 named bits. But std::bitset doesn&=
#39;t have this limitation.<br></span></span></div><div><span class=3D"mw-g=
eshi cpp source-cpp"><span class=3D"sy4"><br></span></span></div><div><span=
class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">But std::bitset bits=
are "anonymous". The idea allows to map trivially enumerated nam=
ed bits to a bitset without size limitation, as an opt-in.<br></span></span=
></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><br=
></span></span></div><div><span class=3D"mw-geshi cpp source-cpp"><span cla=
ss=3D"sy4">Maybe this is better implemented as a different class to prevent=
any conflicts with existing std::bitset usage.<br></span></span></div><div=
><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4"><br></span></s=
pan></div><div><span class=3D"mw-geshi cpp source-cpp"><span class=3D"sy4">=
<br></span></span></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f349f116-17ca-46d4-9485-7353857f5e2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f349f116-17ca-46d4-9485-7353857f5e2c=
%40isocpp.org</a>.<br />
------=_Part_733_749702982.1538745720785--
------=_Part_732_1359640768.1538745720785--
.
Author: kruse.matthis@web.de
Date: Tue, 16 Oct 2018 02:46:54 -0700 (PDT)
Raw View
------=_Part_2088_282942735.1539683214503
Content-Type: multipart/alternative;
boundary="----=_Part_2089_1586634583.1539683214503"
------=_Part_2089_1586634583.1539683214503
Content-Type: text/plain; charset="UTF-8"
What should happen if my enum type is 'ill-formed' such that MAX is
bigger/smaller than the actual amount of possible enumeration values?
What I mean is there exists another enum value myEnum::A, for example, such
that !(myEnum::A < myEnum::MAX).
Other problematic candidates are `enum class Something { Interesting = 1,
MAX = 1};` or `enum class Something { With = 0, An = 1, Alias = 1, MAX = 2
};`.
Especially the last example can be a game-breaker, I don't see how this can
be made to work in a reliable and *predictable *way without more
information than just 'the amount of values in the enum and the enum type'.
--
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/2e0eec53-67f9-4d39-86df-3f85c6f1eb2c%40isocpp.org.
------=_Part_2089_1586634583.1539683214503
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What should happen if my enum type is 'ill-formed'=
such that MAX is bigger/smaller than the actual amount of possible enumera=
tion values?<br>What I mean is there exists another enum value myEnum::A, f=
or example, such that !(myEnum::A < myEnum::MAX).<br>Other problematic c=
andidates are `enum class Something { Interesting =3D 1, MAX =3D 1};` or `e=
num class Something { With =3D 0, An =3D 1, Alias =3D 1, MAX =3D 2 };`.<br>=
<br>Especially the last example can be a game-breaker, I don't see how =
this can be made to work in a reliable and <i>predictable </i>way without m=
ore information than just 'the amount of values in the enum and the enu=
m type'.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2e0eec53-67f9-4d39-86df-3f85c6f1eb2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e0eec53-67f9-4d39-86df-3f85c6f1eb2c=
%40isocpp.org</a>.<br />
------=_Part_2089_1586634583.1539683214503--
------=_Part_2088_282942735.1539683214503--
.
Author: "Ivan G." <nekotekina@gmail.com>
Date: Tue, 16 Oct 2018 06:17:22 -0700 (PDT)
Raw View
------=_Part_2103_205331134.1539695842506
Content-Type: multipart/alternative;
boundary="----=_Part_2104_1015090655.1539695842506"
------=_Part_2104_1015090655.1539695842506
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Last example should work as expected (2 bits, one of them has 2 names), but=
=20
I agree, it's too fragile overall.
The reflection should probably allow to make it safe.
=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=
=B1=D1=80=D1=8F 2018 =D0=B3., 12:46:54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthis Kruse=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> What should happen if my enum type is 'ill-formed' such that MAX is=20
> bigger/smaller than the actual amount of possible enumeration values?
> What I mean is there exists another enum value myEnum::A, for example,=20
> such that !(myEnum::A < myEnum::MAX).
> Other problematic candidates are `enum class Something { Interesting =3D =
1,=20
> MAX =3D 1};` or `enum class Something { With =3D 0, An =3D 1, Alias =3D 1=
, MAX =3D 2=20
> };`.
>
> Especially the last example can be a game-breaker, I don't see how this=
=20
> can be made to work in a reliable and *predictable *way without more=20
> information than just 'the amount of values in the enum and the enum type=
'.
>
--=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/1581c746-5251-4494-86fe-b8746139957e%40isocpp.or=
g.
------=_Part_2104_1015090655.1539695842506
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Last example should work as expected (2 bits, one of =
them has 2 names), but I agree, it's too fragile overall.<br></div><div=
>The reflection should probably allow to make it safe.</div><br>=D0=B2=D1=
=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=
=D1=8F 2018 =D0=B3., 12:46:54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=
=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthis Kruse =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">What should happen if my enum type is 'ill-formed' such that MAX=
is bigger/smaller than the actual amount of possible enumeration values?<b=
r>What I mean is there exists another enum value myEnum::A, for example, su=
ch that !(myEnum::A < myEnum::MAX).<br>Other problematic candidates are =
`enum class Something { Interesting =3D 1, MAX =3D 1};` or `enum class Some=
thing { With =3D 0, An =3D 1, Alias =3D 1, MAX =3D 2 };`.<br><br>Especially=
the last example can be a game-breaker, I don't see how this can be ma=
de to work in a reliable and <i>predictable </i>way without more informatio=
n than just 'the amount of values in the enum and the enum type'.<b=
r></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1581c746-5251-4494-86fe-b8746139957e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1581c746-5251-4494-86fe-b8746139957e=
%40isocpp.org</a>.<br />
------=_Part_2104_1015090655.1539695842506--
------=_Part_2103_205331134.1539695842506--
.
Author: Lawrence Emke <lawrence.emke@gmail.com>
Date: Tue, 16 Oct 2018 09:41:46 -0500
Raw View
--000000000000d0d4ee0578598f10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
My opinion! The enum type is trying to address to issues with one answer.
There are two "types" of objects in the one "enum" container. Poor design.
The current Enum is a 1) list of options, and 2) a list of constants.
A compromised solution was chosen, to have the least impact, on
current code. Now the "fly" that was swallowed, has led to the "spider".
Next the cat,...?
Using the "=3D" notation indicates a list of values in no specific order.
Without the "=3D" symbol, the list consist of valid ids.
The fact that it is implemented as an integer is also part of the problem.
It allows the comparison of the "values" for the list of options. Not good!
Comparing constant values is acceptable.
If you want a list of "values" (i.e. constants), then comparing values is
no problem.
If you want a list of "options" then the compare function should be limited
to "=3D=3D" or !=3D".
On Tue, Oct 16, 2018 at 8:17 AM Ivan G. <nekotekina@gmail.com> wrote:
> Last example should work as expected (2 bits, one of them has 2 names),
> but I agree, it's too fragile overall.
> The reflection should probably allow to make it safe.
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=BE=D0=BA=D1=82=D1=8F=
=D0=B1=D1=80=D1=8F 2018 =D0=B3., 12:46:54 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthis Kruse
> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> What should happen if my enum type is 'ill-formed' such that MAX is
>> bigger/smaller than the actual amount of possible enumeration values?
>> What I mean is there exists another enum value myEnum::A, for example,
>> such that !(myEnum::A < myEnum::MAX).
>> Other problematic candidates are `enum class Something { Interesting =3D=
1,
>> MAX =3D 1};` or `enum class Something { With =3D 0, An =3D 1, Alias =3D =
1, MAX =3D 2
>> };`.
>>
>> Especially the last example can be a game-breaker, I don't see how this
>> can be made to work in a reliable and *predictable *way without more
>> information than just 'the amount of values in the enum and the enum typ=
e'.
>>
> --
> 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/1581c746-525=
1-4494-86fe-b8746139957e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1581c746-52=
51-4494-86fe-b8746139957e%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/CA%2BAqvO2cmcGyqH6SoxOo1oakGqAsJ7Aai1MSuyQbXxX3V=
H81%3Dw%40mail.gmail.com.
--000000000000d0d4ee0578598f10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My opinion! The enum type is trying to address to issues w=
ith one answer.<div>There are two "types" of objects in the one &=
quot;enum" container. Poor design.</div><div><br></div><div>The curren=
t Enum is a 1) list of options, and 2) a list of constants.=C2=A0</div><div=
>A compromised solution was chosen, to have the least impact, on</div><div>=
current code. Now the "fly" that was swallowed, has led to the &q=
uot;spider".</div><div>Next the cat,...?</div><div><br></div><div>Usin=
g the "=3D" notation indicates a list of values in no specific or=
der.</div><div>Without the "=3D" symbol, the list consist of vali=
d ids.=C2=A0</div><div><br></div><div>The fact that it is implemented as an=
integer is also part of the problem.</div><div>It allows the comparison of=
the "values" for the list of options. Not good!</div><div>Compar=
ing constant values is acceptable.=C2=A0</div><div><br></div><div>If you wa=
nt a list of "values" (i.e. constants), then comparing values is =
no problem.</div><div>If you want a list of "options" then the co=
mpare function should be limited to "=3D=3D" or !=3D".</div>=
<div><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr">On Tue, Oct 16, 2018 at 8:17 AM Ivan G. <<a href=
=3D"mailto:nekotekina@gmail.com">nekotekina@gmail.com</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Last example should=
work as expected (2 bits, one of them has 2 names), but I agree, it's =
too fragile overall.<br></div><div>The reflection should probably allow to =
make it safe.</div><br>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 16 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2018 =D0=B3., 12:46:54 UTC+3 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthis =
Kruse =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">What should happen if my enum type is 'i=
ll-formed' such that MAX is bigger/smaller than the actual amount of po=
ssible enumeration values?<br>What I mean is there exists another enum valu=
e myEnum::A, for example, such that !(myEnum::A < myEnum::MAX).<br>Other=
problematic candidates are `enum class Something { Interesting =3D 1, MAX =
=3D 1};` or `enum class Something { With =3D 0, An =3D 1, Alias =3D 1, MAX =
=3D 2 };`.<br><br>Especially the last example can be a game-breaker, I don&=
#39;t see how this can be made to work in a reliable and <i>predictable </i=
>way without more information than just 'the amount of values in the en=
um and the enum type'.<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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1581c746-5251-4494-86fe-b8746139957e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1581c746-5251-=
4494-86fe-b8746139957e%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO2cmcGyqH6SoxOo1oakGqAsJ7Aai1=
MSuyQbXxX3VH81%3Dw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BAqvO2cmc=
GyqH6SoxOo1oakGqAsJ7Aai1MSuyQbXxX3VH81%3Dw%40mail.gmail.com</a>.<br />
--000000000000d0d4ee0578598f10--
.
Author: mihailnajdenov@gmail.com
Date: Tue, 16 Oct 2018 08:04:58 -0700 (PDT)
Raw View
------=_Part_2097_451401774.1539702298656
Content-Type: multipart/alternative;
boundary="----=_Part_2098_3705077.1539702298657"
------=_Part_2098_3705077.1539702298657
Content-Type: text/plain; charset="UTF-8"
Note that very, very soon the MAX will not be needed at all, std::bitset
will continue to use size_t,
but you will, be able to query the enum though reflection for its size
(among other things).
On Friday, October 5, 2018 at 4:22:00 PM UTC+3, Ivan G. wrote:
>
> Hello, there are many enums that look roughly like this:
>
> enum class my_enum {
> value1,
> value2,
> value3,
>
> MAX
> };
>
> Here MAX is the last parameter and it also happens to be the number of
> enums in the simplest case.
>
> std::bitset is currently defined as template< std::size_t
> <http://en.cppreference.com/w/cpp/types/size_t> N > class bitset;
> C++17 added auto in non-type template parameters, so the idea is to change
> std::bitset definition to template < *auto N* > class bitset;
>
> And allow using enum values like my_enum::MAX as its parameter.
>
> 1) If integer type or an unscoped enum type is used as N, the behaviour of
> std::bitset is unchanged.
> 2) If a scoped enum type is used as N, std::bitset behaviour is altered to
> work with "named bits". For example, operator[] would accept only an
> argument of this enum type.
> 3) In any other cases, it should be a compilation error.
>
> Motivation is having an alternative to currently used approaches for bit
> mask enums, which have several cons:
> 1) Require typing shifts: 1 << 0, 1 << 1, etc for each value. This is
> annoying and error-prone.
> 2) Limited in size, i.e. it's impossible to have more than 64 named bits.
> But std::bitset doesn't have this limitation.
>
> But std::bitset bits are "anonymous". The idea allows to map trivially
> enumerated named bits to a bitset without size limitation, as an opt-in.
>
> Maybe this is better implemented as a different class to prevent any
> conflicts with existing std::bitset usage.
>
>
>
--
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/d6a173fa-0ef1-437f-b693-791c687e36a4%40isocpp.org.
------=_Part_2098_3705077.1539702298657
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that very, very soon the MAX will not be needed at al=
l, std::bitset will continue to use size_t,=C2=A0<div>but you will, be able=
to query the enum though reflection for its size (among other things).<div=
>=C2=A0<br></div><div><br>On Friday, October 5, 2018 at 4:22:00 PM UTC+3, I=
van G. wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Hello, there are many enums that look roughly like this:</div><div><br=
></div><div>enum class my_enum {</div><div>=C2=A0 value1,</div><div>=C2=A0 =
value2,</div><div>=C2=A0 value3,</div><div><br></div><div>=C2=A0 MAX</div><=
div>};</div><div><br></div><div>Here MAX is the last parameter and it also =
happens to be the number of enums in the simplest case.</div><div><br></div=
><div>std::bitset is currently defined as <span><span>template</span><span>=
<</span> <a href=3D"http://en.cppreference.com/w/cpp/types/size_t" targe=
t=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.go=
ogle.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Ftypes%2Fsize=
_t\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEl30cZ4rZGt7sM3Z_lkX2mz0UzOg'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Ftypes%2Fsize_t\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNEl30cZ4rZGt7sM3Z_lkX2mz0UzOg';return true;"><s=
pan>std::<span>size_t</span></span></a> N <span>></span><span> class</sp=
an> bitset<span>;</span></span><table><tbody><tr><td></td>
<td></td></tr></tbody></table></div><div><span><span>C++17 added auto in no=
n-type template parameters, so the idea is to change std::bitset definition=
to template < <b>auto N</b></span></span><span><span> > class bitset=
;</span></span><span><span><br></span></span></div><div><span><span><br></s=
pan></span></div><div><span><span>And allow using enum values like my_enum:=
:MAX as its parameter.<br></span></span></div><div><span><span><br></span><=
/span></div><div><span><span>1) If integer type or an unscoped enum type is=
used as N, the behaviour of std::bitset is unchanged.<br></span></span></d=
iv><div><span><span>2) If a scoped enum type is used as N, std::bitset beha=
viour is altered to work with "named bits". For example, operator=
[] would accept only an argument of this enum type.<br></span></span></div>=
<div><span><span>3) In any other cases, it should be a compilation error.<b=
r></span></span></div><div><span><span><br></span></span></div><div><span><=
span>Motivation is having an alternative to currently used approaches for b=
it mask enums, which have several cons:<br></span></span></div><div><span><=
span>1) Require typing shifts: 1 << 0, 1 << 1, etc for each val=
ue. This is annoying and error-prone.<br></span></span></div><div><span><sp=
an>2) Limited in size, i.e. it's impossible to have more than 64 named =
bits. But std::bitset doesn't have this limitation.<br></span></span></=
div><div><span><span><br></span></span></div><div><span><span>But std::bits=
et bits are "anonymous". The idea allows to map trivially enumera=
ted named bits to a bitset without size limitation, as an opt-in.<br></span=
></span></div><div><span><span><br></span></span></div><div><span><span>May=
be this is better implemented as a different class to prevent any conflicts=
with existing std::bitset usage.<br></span></span></div><div><span><span><=
br></span></span></div><div><span><span><br></span></span></div></div></blo=
ckquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d6a173fa-0ef1-437f-b693-791c687e36a4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d6a173fa-0ef1-437f-b693-791c687e36a4=
%40isocpp.org</a>.<br />
------=_Part_2098_3705077.1539702298657--
------=_Part_2097_451401774.1539702298656--
.
Author: Bryce Adelstein Lelbach aka wash <brycelelbach@gmail.com>
Date: Sat, 20 Oct 2018 11:40:04 -0400
Raw View
--0000000000002bb9ca0578aad669
Content-Type: text/plain; charset="UTF-8"
Cool idea, but this may be an ABI break, if the type of a non-type template
parameter (NTTP) is mangled.
Suppose someone writes this in C++17:
void my_binary_interface(std::bitset<8>);
In C++17, the type of the NTTP is std::size_t. With your change, it would
become int.
On Fri, Oct 5, 2018, 9:22 AM Ivan G. <nekotekina@gmail.com> wrote:
> Hello, there are many enums that look roughly like this:
>
> enum class my_enum {
> value1,
> value2,
> value3,
>
> MAX
> };
>
> Here MAX is the last parameter and it also happens to be the number of
> enums in the simplest case.
>
> std::bitset is currently defined as template< std::size_t
> <http://en.cppreference.com/w/cpp/types/size_t> N > class bitset;
> C++17 added auto in non-type template parameters, so the idea is to change
> std::bitset definition to template < *auto N* > class bitset;
>
> And allow using enum values like my_enum::MAX as its parameter.
>
> 1) If integer type or an unscoped enum type is used as N, the behaviour of
> std::bitset is unchanged.
> 2) If a scoped enum type is used as N, std::bitset behaviour is altered to
> work with "named bits". For example, operator[] would accept only an
> argument of this enum type.
> 3) In any other cases, it should be a compilation error.
>
> Motivation is having an alternative to currently used approaches for bit
> mask enums, which have several cons:
> 1) Require typing shifts: 1 << 0, 1 << 1, etc for each value. This is
> annoying and error-prone.
> 2) Limited in size, i.e. it's impossible to have more than 64 named bits.
> But std::bitset doesn't have this limitation.
>
> But std::bitset bits are "anonymous". The idea allows to map trivially
> enumerated named bits to a bitset without size limitation, as an opt-in.
>
> Maybe this is better implemented as a different class to prevent any
> conflicts with existing std::bitset usage.
>
>
> --
> 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/f349f116-17ca-46d4-9485-7353857f5e2c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f349f116-17ca-46d4-9485-7353857f5e2c%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAP3wax_SyCvRbYL72NsN7O2sStC7zoWpGX9QD8UHoSQTZcmDBw%40mail.gmail.com.
--0000000000002bb9ca0578aad669
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Cool idea, but this may be an ABI break, if the type of a=
non-type template parameter (NTTP) is mangled.<div dir=3D"auto"><br></div>=
<div dir=3D"auto">Suppose someone writes this in C++17:</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">void my_binary_interface(std::bitset<8&g=
t;);</div><div dir=3D"auto"><br></div><div dir=3D"auto">In C++17, the type =
of the NTTP is std::size_t. With your change, it would become int.</div><br=
><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On Fri, Oct 5=
, 2018, 9:22 AM Ivan G. <<a href=3D"mailto:nekotekina@gmail.com">nekotek=
ina@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>Hello, there are many enums that look roughly like this:</d=
iv><div><br></div><div>enum class my_enum {</div><div>=C2=A0 value1,</div><=
div>=C2=A0 value2,</div><div>=C2=A0 value3,</div><div><br></div><div>=C2=A0=
MAX</div><div>};</div><div><br></div><div>Here MAX is the last parameter a=
nd it also happens to be the number of enums in the simplest case.</div><di=
v><br></div><div>std::bitset is currently defined as <span class=3D"m_-2805=
621303167258926mw-geshi m_-2805621303167258926cpp m_-2805621303167258926sou=
rce-cpp"><span class=3D"m_-2805621303167258926kw1">template</span><span cla=
ss=3D"m_-2805621303167258926sy1"><</span> <a href=3D"http://en.cpprefere=
nce.com/w/cpp/types/size_t" target=3D"_blank" rel=3D"noreferrer"><span clas=
s=3D"m_-2805621303167258926kw100">std::<span class=3D"m_-280562130316725892=
6me2">size_t</span></span></a> N <span class=3D"m_-2805621303167258926sy1">=
></span><span class=3D"m_-2805621303167258926kw1"> class</span> bitset<s=
pan class=3D"m_-2805621303167258926sy4">;</span></span><table class=3D"m_-2=
805621303167258926t-dcl-begin"><tbody><tr class=3D"m_-2805621303167258926t-=
dcl"><td class=3D"m_-2805621303167258926t-dcl-nopad"></td>
<td class=3D"m_-2805621303167258926t-dcl-nopad"></td></tr></tbody></table><=
/div><div><span class=3D"m_-2805621303167258926mw-geshi m_-2805621303167258=
926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-2805621303167258=
926sy4">C++17 added auto in non-type template parameters, so the idea is to=
change std::bitset definition to template < <b>auto N</b></span></span>=
<span class=3D"m_-2805621303167258926mw-geshi m_-2805621303167258926cpp m_-=
2805621303167258926source-cpp"><span class=3D"m_-2805621303167258926sy4"> &=
gt; class bitset;</span></span><span class=3D"m_-2805621303167258926mw-gesh=
i m_-2805621303167258926cpp m_-2805621303167258926source-cpp"><span class=
=3D"m_-2805621303167258926sy4"><br></span></span></div><div><span class=3D"=
m_-2805621303167258926mw-geshi m_-2805621303167258926cpp m_-280562130316725=
8926source-cpp"><span class=3D"m_-2805621303167258926sy4"><br></span></span=
></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-28056213031672=
58926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-28056213031672=
58926sy4">And allow using enum values like my_enum::MAX as its parameter.<b=
r></span></span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_=
-2805621303167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_=
-2805621303167258926sy4"><br></span></span></div><div><span class=3D"m_-280=
5621303167258926mw-geshi m_-2805621303167258926cpp m_-2805621303167258926so=
urce-cpp"><span class=3D"m_-2805621303167258926sy4">1) If integer type or a=
n unscoped enum type is used as N, the behaviour of std::bitset is unchange=
d.<br></span></span></div><div><span class=3D"m_-2805621303167258926mw-gesh=
i m_-2805621303167258926cpp m_-2805621303167258926source-cpp"><span class=
=3D"m_-2805621303167258926sy4">2) If a scoped enum type is used as N, std::=
bitset behaviour is altered to work with "named bits". For exampl=
e, operator[] would accept only an argument of this enum type.<br></span></=
span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-2805621303=
167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-2805621303=
167258926sy4">3) In any other cases, it should be a compilation error.<br><=
/span></span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-28=
05621303167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-28=
05621303167258926sy4"><br></span></span></div><div><span class=3D"m_-280562=
1303167258926mw-geshi m_-2805621303167258926cpp m_-2805621303167258926sourc=
e-cpp"><span class=3D"m_-2805621303167258926sy4">Motivation is having an al=
ternative to currently used approaches for bit mask enums, which have sever=
al cons:<br></span></span></div><div><span class=3D"m_-2805621303167258926m=
w-geshi m_-2805621303167258926cpp m_-2805621303167258926source-cpp"><span c=
lass=3D"m_-2805621303167258926sy4">1) Require typing shifts: 1 << 0, =
1 << 1, etc for each value. This is annoying and error-prone.<br></sp=
an></span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-28056=
21303167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-28056=
21303167258926sy4">2) Limited in size, i.e. it's impossible to have mor=
e than 64 named bits. But std::bitset doesn't have this limitation.<br>=
</span></span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-2=
805621303167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-2=
805621303167258926sy4"><br></span></span></div><div><span class=3D"m_-28056=
21303167258926mw-geshi m_-2805621303167258926cpp m_-2805621303167258926sour=
ce-cpp"><span class=3D"m_-2805621303167258926sy4">But std::bitset bits are =
"anonymous". The idea allows to map trivially enumerated named bi=
ts to a bitset without size limitation, as an opt-in.<br></span></span></di=
v><div><span class=3D"m_-2805621303167258926mw-geshi m_-2805621303167258926=
cpp m_-2805621303167258926source-cpp"><span class=3D"m_-2805621303167258926=
sy4"><br></span></span></div><div><span class=3D"m_-2805621303167258926mw-g=
eshi m_-2805621303167258926cpp m_-2805621303167258926source-cpp"><span clas=
s=3D"m_-2805621303167258926sy4">Maybe this is better implemented as a diffe=
rent class to prevent any conflicts with existing std::bitset usage.<br></s=
pan></span></div><div><span class=3D"m_-2805621303167258926mw-geshi m_-2805=
621303167258926cpp m_-2805621303167258926source-cpp"><span class=3D"m_-2805=
621303167258926sy4"><br></span></span></div><div><span class=3D"m_-28056213=
03167258926mw-geshi m_-2805621303167258926cpp m_-2805621303167258926source-=
cpp"><span class=3D"m_-2805621303167258926sy4"><br></span></span></div></di=
v>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/f349f116-17ca-46d4-9485-7353857f5e2c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/f349f116-17ca-46d4-9485-7353857f5e2c%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAP3wax_SyCvRbYL72NsN7O2sStC7zoWpGX9Q=
D8UHoSQTZcmDBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAP3wax_SyCvRbYL7=
2NsN7O2sStC7zoWpGX9QD8UHoSQTZcmDBw%40mail.gmail.com</a>.<br />
--0000000000002bb9ca0578aad669--
.