------=_Part_1360_1787704521.1478291132784
Content-Type: multipart/alternative;
 boundary="----=_Part_1361_2036398783.1478291132784"

------=_Part_1361_2036398783.1478291132784
Content-Type: text/plain; charset=UTF-8

In a certain codebase that I've been using lately, the following pattern
shows up often enough:

class SomeType {
unsigned ST1 : 1;
unsigned ST2: 2;
unsigned ST3: 3;
};
enum { SomeTypeBits = 6};

class OtherType {
unsigned : SomeTypeBits;
unsigned OT1 : 1;
};
enum {OtherTypeBits = 7};

I note that this is a very fragile mechanism, and will often cause issues.
In this case, I believe the idea is that OtherType can be cast to SomeType,
but still be bitpacked.  It would be nice if the definitions for the
anonymous enum were to be compile-time calculated, like:


enum {SomeTypeBits = std::num_bits_in_bitfield_v<SomeType> };  // Name
obviously not very good


Thoughts?  Is there a good name someone could think of?  The compiler could
easily determine this, so this might end up having to be a builtin, but
otherwise, I suspect this would be pretty useful.

--
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/da882f07-5a9b-46cc-8779-9dfab7d054b2%40isocpp.org.

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

<div dir=3D"ltr">In a certain codebase that I&#39;ve been using lately, the=
 following pattern shows up often enough:<br><br>class SomeType {<br>unsign=
ed ST1 : 1;<br>unsigned ST2: 2;<br>unsigned ST3: 3;<br>};<br>enum { SomeTyp=
eBits =3D 6};<br><br>class OtherType {<br>unsigned : SomeTypeBits;<br>unsig=
ned OT1 : 1;<br>};<br>enum {OtherTypeBits =3D 7};<br><br>I note that this i=
s a very fragile mechanism, and will often cause issues.=C2=A0 In this case=
, I believe the idea is that OtherType can be cast to SomeType, but still b=
e bitpacked.=C2=A0 It would be nice if the definitions for the anonymous en=
um were to be compile-time calculated, like:<br><br><br>enum {SomeTypeBits =
=3D std::num_bits_in_bitfield_v&lt;SomeType&gt; };=C2=A0 // Name obviously =
not very good<br><br><br>Thoughts?=C2=A0 Is there a good name someone could=
 think of?=C2=A0 The compiler could easily determine this, so this might en=
d up having to be a builtin, but otherwise, I suspect this would be pretty =
useful.<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/da882f07-5a9b-46cc-8779-9dfab7d054b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/da882f07-5a9b-46cc-8779-9dfab7d054b2=
%40isocpp.org</a>.<br />

------=_Part_1361_2036398783.1478291132784--

------=_Part_1360_1787704521.1478291132784--

.

Le 04/11/2016 =C3=A0 21:25, Erich Keane a =C3=A9crit :
> In a certain codebase that I've been using lately, the following=20
> pattern shows up often enough:
>
> class SomeType {
> unsigned ST1 : 1;
> unsigned ST2: 2;
> unsigned ST3: 3;
> };
> enum { SomeTypeBits =3D 6};
>
> class OtherType {
> unsigned : SomeTypeBits;
> unsigned OT1 : 1;
> };
> enum {OtherTypeBits =3D 7};
>
> I note that this is a very fragile mechanism, and will often cause=20
> issues.  In this case, I believe the idea is that OtherType can be=20
> cast to SomeType, but still be bitpacked.  It would be nice if the=20
> definitions for the anonymous enum were to be compile-time calculated,=20
> like:
>
>
> enum {SomeTypeBits =3D std::num_bits_in_bitfield_v<SomeType> };  // Name=
=20
> obviously not very good
>
>
Wondering how do you want to use these classes.
> Thoughts?  Is there a good name someone could think of?  The compiler=20
> could easily determine this, so this might end up having to be a=20
> builtin, but otherwise, I suspect this would be pretty useful.

What about a library solution.

using  SomeType =3D bitfields<
     field<unsigned, struct ST1, 1>,
     field<unsigned, struct ST2, 2>,
     field<unsigned, struct ST3, 3>
 >;
enum { SomeTypeBits =3D SomeType::bits };

using OtherType =3D bitfields<
     SomeType::fields,
     field<unsigned, struct OT1, 1>
 >;
enum { OtherTypeBits =3D OtherType::bits };


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/75e484c7-ffee-5506-054c-35e3a44b414e%40wanadoo.f=
r.

.

------=_Part_1524_1816839692.1478482185948
Content-Type: multipart/alternative;
 boundary="----=_Part_1525_709036967.1478482185948"

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



On Saturday, November 5, 2016 at 5:44:05 PM UTC-7, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 04/11/2016 =C3=A0 21:25, Erich Keane a =C3=A9crit :=20
> > In a certain codebase that I've been using lately, the following=20
> > pattern shows up often enough:=20
> >=20
> > class SomeType {=20
> > unsigned ST1 : 1;=20
> > unsigned ST2: 2;=20
> > unsigned ST3: 3;=20
> > };=20
> > enum { SomeTypeBits =3D 6};=20
> >=20
> > class OtherType {=20
> > unsigned : SomeTypeBits;=20
> > unsigned OT1 : 1;=20
> > };=20
> > enum {OtherTypeBits =3D 7};=20
> >=20
> > I note that this is a very fragile mechanism, and will often cause=20
> > issues.  In this case, I believe the idea is that OtherType can be=20
> > cast to SomeType, but still be bitpacked.  It would be nice if the=20
> > definitions for the anonymous enum were to be compile-time calculated,=
=20
> > like:=20
> >=20
> >=20
> > enum {SomeTypeBits =3D std::num_bits_in_bitfield_v<SomeType> };  // Nam=
e=20
> > obviously not very good=20
> >=20
> >=20
> Wondering how do you want to use these classes.=20
>

They are used essentially as an inheritence structure it seems.  OtherType=
=20
is meant to be cast-able to SomeType, which it does with the anonymous=20
bitfield. =20
=20

> > Thoughts?  Is there a good name someone could think of?  The compiler=
=20
> > could easily determine this, so this might end up having to be a=20
> > builtin, but otherwise, I suspect this would be pretty useful.=20
>
> What about a library solution.=20
>
> using  SomeType =3D bitfields<=20
>      field<unsigned, struct ST1, 1>,=20
>      field<unsigned, struct ST2, 2>,=20
>      field<unsigned, struct ST3, 3>=20
>  >;=20
> enum { SomeTypeBits =3D SomeType::bits };=20
>
> using OtherType =3D bitfields<=20
>      SomeType::fields,=20
>      field<unsigned, struct OT1, 1>=20
>  >;=20
> enum { OtherTypeBits =3D OtherType::bits };=20
>
>
> Vicente=20
>

That is a little awkward it seems in my opinion.  I suspect that a solution=
=20
like that wouldn't really be accepted into the codebases that use this=20
mechanism.  It seems that a type-trait would be way easier to accept, and=
=20
wouldn't create such strange looking structs.  I believe a builtin would be=
=20
sufficient, though I think that if we could come up with a good name for it=
=20
that it would make a useful type trait.

--=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/bf6739ff-9df2-435e-bee1-f549f32f5220%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, November 5, 2016 at 5:44:05 PM UTC-7,=
 Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">Le 04/11/2016 =C3=A0 21:25, Erich Keane a =C3=A9crit :
<br>&gt; In a certain codebase that I&#39;ve been using lately, the followi=
ng=20
<br>&gt; pattern shows up often enough:
<br>&gt;
<br>&gt; class SomeType {
<br>&gt; unsigned ST1 : 1;
<br>&gt; unsigned ST2: 2;
<br>&gt; unsigned ST3: 3;
<br>&gt; };
<br>&gt; enum { SomeTypeBits =3D 6};
<br>&gt;
<br>&gt; class OtherType {
<br>&gt; unsigned : SomeTypeBits;
<br>&gt; unsigned OT1 : 1;
<br>&gt; };
<br>&gt; enum {OtherTypeBits =3D 7};
<br>&gt;
<br>&gt; I note that this is a very fragile mechanism, and will often cause=
=20
<br>&gt; issues. =C2=A0In this case, I believe the idea is that OtherType c=
an be=20
<br>&gt; cast to SomeType, but still be bitpacked. =C2=A0It would be nice i=
f the=20
<br>&gt; definitions for the anonymous enum were to be compile-time calcula=
ted,=20
<br>&gt; like:
<br>&gt;
<br>&gt;
<br>&gt; enum {SomeTypeBits =3D std::num_bits_in_bitfield_v&lt;<wbr>SomeTyp=
e&gt; }; =C2=A0// Name=20
<br>&gt; obviously not very good
<br>&gt;
<br>&gt;
<br>Wondering how do you want to use these classes.
<br></blockquote><div><br>They are used essentially as an inheritence struc=
ture it seems.=C2=A0 OtherType is meant to be cast-able to SomeType, which =
it does with the anonymous bitfield.=C2=A0 <br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">&gt; Thoughts? =C2=A0Is there a good name some=
one could think of? =C2=A0The compiler=20
<br>&gt; could easily determine this, so this might end up having to be a=
=20
<br>&gt; builtin, but otherwise, I suspect this would be pretty useful.
<br>
<br>What about a library solution.
<br>
<br>using =C2=A0SomeType =3D bitfields&lt;
<br>=C2=A0 =C2=A0 =C2=A0field&lt;unsigned, struct ST1, 1&gt;,
<br>=C2=A0 =C2=A0 =C2=A0field&lt;unsigned, struct ST2, 2&gt;,
<br>=C2=A0 =C2=A0 =C2=A0field&lt;unsigned, struct ST3, 3&gt;
<br>=C2=A0&gt;;
<br>enum { SomeTypeBits =3D SomeType::bits };
<br>
<br>using OtherType =3D bitfields&lt;
<br>=C2=A0 =C2=A0 =C2=A0SomeType::fields,
<br>=C2=A0 =C2=A0 =C2=A0field&lt;unsigned, struct OT1, 1&gt;
<br>=C2=A0&gt;;
<br>enum { OtherTypeBits =3D OtherType::bits };
<br>
<br>
<br>Vicente
<br></blockquote><div><br>That is a little awkward it seems in my opinion.=
=C2=A0 I suspect that a solution like that wouldn&#39;t really be accepted =
into the codebases that use this mechanism.=C2=A0 It seems that a type-trai=
t would be way easier to accept, and wouldn&#39;t create such strange looki=
ng structs.=C2=A0 I believe a builtin would be sufficient, though I think t=
hat if we could come up with a good name for it that it would make a useful=
 type trait.<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/bf6739ff-9df2-435e-bee1-f549f32f5220%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf6739ff-9df2-435e-bee1-f549f32f5220=
%40isocpp.org</a>.<br />

------=_Part_1525_709036967.1478482185948--

------=_Part_1524_1816839692.1478482185948--

.

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

On Mon, Nov 7, 2016 at 1:29 AM, Erich Keane <erich.keane@verizon.net> wrote:

>
>
> On Saturday, November 5, 2016 at 5:44:05 PM UTC-7, Vicente J. Botet
> Escriba wrote:
>
>> Wondering how do you want to use these classes.
>>
>
> They are used essentially as an inheritence structure it seems.
>

"it seems", so you don't have any real example or motivation for this? It
doesn't *seem* to make any sense, and then there's this:

OtherType is meant to be cast-able to SomeType, which it does with the
> anonymous bitfield.


That can't work, surely, as they are not related types and so any such cast
would be undefined/violate aliasing -  IIRC - as I don't think allowances
for casting between structs and their first member apply when said member
is a bitfield.

--
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/CACGiwhHr_H1q%3D_FT5Wd6zSGT6vsnPMDwj0AqvKJn3D-oUheQfQ%40mail.gmail.com.

--047d7b86e2f88bda670540b1dc5e
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 M=
on, Nov 7, 2016 at 1:29 AM, Erich Keane <span dir=3D"ltr">&lt;<a target=3D"=
_blank" href=3D"mailto:erich.keane@verizon.net">erich.keane@verizon.net</a>=
&gt;</span> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v dir=3D"ltr"><span class=3D"gmail-"><br><br>On Saturday, November 5, 2016 =
at 5:44:05 PM UTC-7, Vicente J. Botet Escriba wrote:</span><br><span class=
=3D"gmail-"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Wondering how=
 do you want to use these classes.
<br></blockquote></span><div><br>They are used essentially as an inheritenc=
e structure it seems.=C2=A0 <br></div></div></blockquote></div><br></div><d=
iv class=3D"gmail_extra">&quot;it seems&quot;, so you don&#39;t have any re=
al example or motivation for this? It doesn&#39;t <i>seem</i> to make any s=
ense, and then there&#39;s this:<br><br><blockquote style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote">OtherType is meant to be cast-able to SomeType, which it d=
oes with the anonymous bitfield.=C2=A0=C2=A0 </blockquote><div><br></div><d=
iv>That can&#39;t work, surely, as they are not related types and so any su=
ch cast would be undefined/violate aliasing -=C2=A0 IIRC - as I don&#39;t t=
hink allowances for casting between structs and their first member apply wh=
en said member is a bitfield. <br></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/CACGiwhHr_H1q%3D_FT5Wd6zSGT6vsnPMDwj0=
AqvKJn3D-oUheQfQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHr_H1q%3=
D_FT5Wd6zSGT6vsnPMDwj0AqvKJn3D-oUheQfQ%40mail.gmail.com</a>.<br />

--047d7b86e2f88bda670540b1dc5e--

.

This type trait could maybe be handled as an extension to the facility
proposed in P0381
(https://github.com/johnmcfarlane/fixed_point/blob/develop/doc/p0381r1.md)
as it is essentially querying the width in bits:

enum {SomeTypeBits = std::width_v<SomeType> };  // not sure my name is
any better

John

On Fri, Nov 4, 2016 at 1:25 PM, Erich Keane <erich.keane@verizon.net> wrote:
> In a certain codebase that I've been using lately, the following pattern
> shows up often enough:
>
> class SomeType {
> unsigned ST1 : 1;
> unsigned ST2: 2;
> unsigned ST3: 3;
> };
> enum { SomeTypeBits = 6};
>
> class OtherType {
> unsigned : SomeTypeBits;
> unsigned OT1 : 1;
> };
> enum {OtherTypeBits = 7};
>
> I note that this is a very fragile mechanism, and will often cause issues.
> In this case, I believe the idea is that OtherType can be cast to SomeType,
> but still be bitpacked.  It would be nice if the definitions for the
> anonymous enum were to be compile-time calculated, like:
>
>
> enum {SomeTypeBits = std::num_bits_in_bitfield_v<SomeType> };  // Name
> obviously not very good
>
>
> Thoughts?  Is there a good name someone could think of?  The compiler could
> easily determine this, so this might end up having to be a builtin, but
> otherwise, I suspect this would be pretty useful.
>
> --
> 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/da882f07-5a9b-46cc-8779-9dfab7d054b2%40isocpp.org.

--
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/CABPJVnRYNPTnWdqr4B2NOkKNWtKzR_OYVTDNOfQJOrfJZwLrrQ%40mail.gmail.com.

.

------=_Part_2336_1034570402.1478549720844
Content-Type: text/plain; charset=UTF-8

I'll note the codebase this appears in is clang/LLVM, so while making a modification to this type, I noticed this issue. I'm not completely versed in its usage sadly, and am only knowledge able of it from scanning usages in that admittedly large codebase.

--
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/a3a1b706-304c-40f1-9902-3888d2cd7f7a%40isocpp.org.

------=_Part_2336_1034570402.1478549720844--

.

------=_Part_1581_414605365.1478552503535
Content-Type: text/plain; charset=UTF-8

John: that is perhaps a question I should ask when that paper comes up! I'm currently in LWG, so I might walk over to LEWG when papers start.

--
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/11d16750-1084-4a22-9f0d-99ac825f5f5f%40isocpp.org.

------=_Part_1581_414605365.1478552503535--

.