------=_Part_1364_431145022.1410318408887
Content-Type: text/plain; charset=UTF-8

It would be useful to be able to control the underlying integral type used
for std::bitset. I have a use case now where I want a compact object to
have a set of up to 32 bit flags but because std::bitset<32> uses 64 bits
on my system, I cannot use it.

It would be nice if you could pass an integral type as template parameter
to bitset to fix its implementation to have the size and alignment
constraints of that type.

//Assume char is 8 bits, short is 16 bits, int is 32 bits, and  long is 64
bits


bitset<32,int> a; //Ok
bitset<33,int> b; //Error: 33 bits cannot fit in an int!
bitset<int> c; //Ok: same as bitset<sizeof(int)*CHAR_BIT,int>
bitset<char> d; //Ok

An alternative to this would be to invent another type like
std::small_bitset which behaves identically to bitset but uses as few bits
as possible to implement the type. This alternative is less flexible and
could lead to easy to miss efficiency bugs for odd sizes like
std::small_bitset<24> due to overzealous space conservation.

--

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

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

<div dir=3D"ltr">It would be useful to be able to control the underlying in=
tegral type used for std::bitset. I have a use case now where I want a comp=
act object to have a set of up to 32 bit flags but because std::bitset&lt;3=
2&gt; uses 64 bits on my system, I cannot use it.<div><br><div>It would be =
nice if you could pass an integral type as template parameter to bitset to =
fix its implementation to have the size and alignment constraints of that t=
ype.<br><div><br></div><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//Assume char is 8 bits, =
short is 16 bits, int is 32 bits, and &nbsp;long is 64 bits</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>bitset</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">32</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Ok<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>bitset<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">33</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//Error: 33 bits cannot fit in an int!</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>bitset</span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//Ok: same as bitset&lt;sizeof(int)*CHAR_BIT,int&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>bitset</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify">&lt;char&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> d</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//Ok</span></div></code></div><div><br></div></div>=
</div><div>An alternative to this would be to invent another type like std:=
:small_bitset which behaves identically to bitset but uses as few bits as p=
ossible to implement the type. This alternative is less flexible and could =
lead to easy to miss efficiency bugs for odd sizes like std::small_bitset&l=
t;24&gt; due to overzealous space conservation.</div></div>

<p></p>

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

------=_Part_1364_431145022.1410318408887--

.

On 09/10/2014 05:06 AM, Matthew Fioravante wrote:
> It would be useful to be able to control the underlying integral type used for std::bitset. I have a use case now where I want a compact object to have a set of up to 32 bit flags but because std::bitset<32> uses 64 bits on my system, I cannot use it.

As quality-of-implementation, your standard library could certainly
specialize std::bitset such that

  std::bitset<1..8>   uses   std::uint8_t
  std::bitset<9..16>  uses   std::uint16_t
  std::bitset<17..32> uses   std::uint32_t
  std::bitset<33..64> uses   std::uint64_t

This seems to be purely a quality-of-implementation issue that doesn't
require an interface change.

Jens

--

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

.

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

I don't think this is really a quality of implementation issue. There are
many qualities that we may want to optimize for (space, performance)  -- in
this case we wish to optimize for space, whereas perhaps the implementation
is optimizing for performance.

On Wed, Sep 10, 2014 at 12:49 AM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> On 09/10/2014 05:06 AM, Matthew Fioravante wrote:
> > It would be useful to be able to control the underlying integral type
> used for std::bitset. I have a use case now where I want a compact object
> to have a set of up to 32 bit flags but because std::bitset<32> uses 64
> bits on my system, I cannot use it.
>
> As quality-of-implementation, your standard library could certainly
> specialize std::bitset such that
>
>   std::bitset<1..8>   uses   std::uint8_t
>   std::bitset<9..16>  uses   std::uint16_t
>   std::bitset<17..32> uses   std::uint32_t
>   std::bitset<33..64> uses   std::uint64_t
>
> This seems to be purely a quality-of-implementation issue that doesn't
> require an interface change.
>
> Jens
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">I don&#39;t think this is really a quality of implementati=
on issue. There are many qualities that we may want to optimize for (space,=
 performance) =C2=A0-- in this case we wish to optimize for space, whereas =
perhaps the implementation is optimizing for performance.</div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Sep 10, 2014 at 12:=
49 AM, Jens Maurer <span dir=3D"ltr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.=
net" target=3D"_blank">Jens.Maurer@gmx.net</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">On 09/10/2014 05:06 AM, Matthew Fi=
oravante wrote:<br>
&gt; It would be useful to be able to control the underlying integral type =
used for std::bitset. I have a use case now where I want a compact object t=
o have a set of up to 32 bit flags but because std::bitset&lt;32&gt; uses 6=
4 bits on my system, I cannot use it.<br>
<br>
</span>As quality-of-implementation, your standard library could certainly<=
br>
specialize std::bitset such that<br>
<br>
=C2=A0 std::bitset&lt;1..8&gt;=C2=A0 =C2=A0uses=C2=A0 =C2=A0std::uint8_t<br=
>
=C2=A0 std::bitset&lt;9..16&gt;=C2=A0 uses=C2=A0 =C2=A0std::uint16_t<br>
=C2=A0 std::bitset&lt;17..32&gt; uses=C2=A0 =C2=A0std::uint32_t<br>
=C2=A0 std::bitset&lt;33..64&gt; uses=C2=A0 =C2=A0std::uint64_t<br>
<br>
This seems to be purely a quality-of-implementation issue that doesn&#39;t<=
br>
require an interface change.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jens<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a113483b4d388430502b06dca--

.

--Apple-Mail=_AE0E1D2C-4102-40EC-904F-5ECBDA611548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-10, at 2:47 PM, Brent Friedman <fourthgeek@gmail.com> wrote:

> I don't think this is really a quality of implementation issue. There are=
 many qualities that we may want to optimize for (space, performance)  -- i=
n this case we wish to optimize for space, whereas perhaps the implementati=
on is optimizing for performance.

Some types are faster than others on some hardware implementations, but any=
thing capable of string processing can fetch a char.

I doubt that any implementation ever tried flexible bitset representation a=
nd then rejected the change for performance reasons. Unfortunately, library=
 ABIs create a lot of inertia, and such changes tend to be discouraged in t=
he first place. Progress would be better if libraries branched early and ma=
intained a couple (or more) ABIs at once. (Of course, DLL compatibility wou=
ld be worse. I'm not a fan of DLLs, though.)

--=20

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

--Apple-Mail=_AE0E1D2C-4102-40EC-904F-5ECBDA611548
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;10, at 2:47 PM, Brent Friedman &lt;<a href=3D"mailto:fourthg=
eek@gmail.com">fourthgeek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I don't thi=
nk this is really a quality of implementation issue. There are many qualiti=
es that we may want to optimize for (space, performance) &nbsp;-- in this c=
ase we wish to optimize for space, whereas perhaps the implementation is op=
timizing for performance.</div></blockquote><div><br></div><div>Some types =
are faster than others on some hardware implementations, but anything capab=
le of string processing can fetch a <font face=3D"Courier">char</font>.</di=
v><div><br></div><div>I doubt that any implementation ever tried flexible&n=
bsp;<font face=3D"Courier">bitset</font>&nbsp;representation and then rejec=
ted the change for performance reasons. Unfortunately, library ABIs create =
a lot of inertia, and such changes tend to be discouraged in the first plac=
e. Progress would be better if libraries branched early and maintained a co=
uple (or more) ABIs at once. (Of course, DLL compatibility would be worse. =
I&rsquo;m not a fan of DLLs, though.)</div><div><br></div></div></body></ht=
ml>

<p></p>

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

--Apple-Mail=_AE0E1D2C-4102-40EC-904F-5ECBDA611548--

.

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

Did you know that sizeof(bool) ranges between 1 byte and 8 bytes depending
on implementation? I have no trouble doubting that a library vendor would
do whatever they thought sounded good to improve performance -- and that a
library consumer would balk at using a loosely defined and unpredictable
data structure.

On Wed, Sep 10, 2014 at 1:59 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9309=E2=80=9310, at 2:47 PM, Brent Friedman <fourthgeek@gma=
il.com> wrote:
>
> I don't think this is really a quality of implementation issue. There are
> many qualities that we may want to optimize for (space, performance)  -- =
in
> this case we wish to optimize for space, whereas perhaps the implementati=
on
> is optimizing for performance.
>
>
> Some types are faster than others on some hardware implementations, but
> anything capable of string processing can fetch a char.
>
> I doubt that any implementation ever tried flexible bitset representation
> and then rejected the change for performance reasons. Unfortunately,
> library ABIs create a lot of inertia, and such changes tend to be
> discouraged in the first place. Progress would be better if libraries
> branched early and maintained a couple (or more) ABIs at once. (Of course=
,
> DLL compatibility would be worse. I=E2=80=99m not a fan of DLLs, though.)
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Did you know that sizeof(bool) ranges between 1 byte and 8=
 bytes depending on implementation? I have no trouble doubting that a libra=
ry vendor would do whatever they thought sounded good to improve performanc=
e -- and that a library consumer would balk at using a loosely defined and =
unpredictable data structure.</div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Wed, Sep 10, 2014 at 1:59 AM, David Krauss <span dir=
=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@g=
mail.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"><div sty=
le=3D"word-wrap:break-word"><br><div><span class=3D""><div>On 2014=E2=80=93=
09=E2=80=9310, at 2:47 PM, Brent Friedman &lt;<a href=3D"mailto:fourthgeek@=
gmail.com" target=3D"_blank">fourthgeek@gmail.com</a>&gt; wrote:</div><br><=
blockquote type=3D"cite"><div dir=3D"ltr">I don&#39;t think this is really =
a quality of implementation issue. There are many qualities that we may wan=
t to optimize for (space, performance) =C2=A0-- in this case we wish to opt=
imize for space, whereas perhaps the implementation is optimizing for perfo=
rmance.</div></blockquote><div><br></div></span><div>Some types are faster =
than others on some hardware implementations, but anything capable of strin=
g processing can fetch a <font face=3D"Courier">char</font>.</div><div><br>=
</div><div>I doubt that any implementation ever tried flexible=C2=A0<font f=
ace=3D"Courier">bitset</font>=C2=A0representation and then rejected the cha=
nge for performance reasons. Unfortunately, library ABIs create a lot of in=
ertia, and such changes tend to be discouraged in the first place. Progress=
 would be better if libraries branched early and maintained a couple (or mo=
re) ABIs at once. (Of course, DLL compatibility would be worse. I=E2=80=99m=
 not a fan of DLLs, though.)</div><div><br></div></div></div><div class=3D"=
HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7b2e4ede974dcf0502b11626--

.

--Apple-Mail=_58D4FA0D-5B4A-404C-9A9B-21AF9AACBF84
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-10, at 3:34 PM, Brent Friedman <fourthgeek@gmail.com> wrote:

> Did you know that sizeof(bool) ranges between 1 byte and 8 bytes depending on implementation? I have no trouble doubting that a library vendor would do whatever they thought sounded good to improve performance

Large bool is not usually for performance; it's for compatibility with C code using typedef int bool;. I've yet to see 8 bytes though. Which implementation is that?

> -- and that a library consumer would balk at using a loosely defined and unpredictable data structure.

Hyperbole.

--

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

--Apple-Mail=_58D4FA0D-5B4A-404C-9A9B-21AF9AACBF84
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;10, at 3:34 PM, Brent Friedman &lt;<a href=3D"mailto:fourthg=
eek@gmail.com">fourthgeek@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Did you kno=
w that sizeof(bool) ranges between 1 byte and 8 bytes depending on implemen=
tation? I have no trouble doubting that a library vendor would do whatever =
they thought sounded good to improve performance </div></blockquote><div><b=
r></div><div>Large <font face=3D"Courier">bool</font> is not usually for pe=
rformance; it&rsquo;s for compatibility with C code using <font face=3D"Cou=
rier">typedef int bool;</font>. I&rsquo;ve yet to see 8 bytes though. Which=
 implementation is that?</div><br><blockquote type=3D"cite"><div dir=3D"ltr=
">-- and that a library consumer would balk at using a loosely defined and =
unpredictable data structure.</div></blockquote><div><br></div><div>Hyperbo=
le.</div><div><br></div></div></body></html>

<p></p>

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

--Apple-Mail=_58D4FA0D-5B4A-404C-9A9B-21AF9AACBF84--

.

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

Libraries may choose to optimize for performance or space, or they may have=
=20
choose a particular size for any reason whatsoever. Once the library has=20
chosen what it will do, that choice is usually fixed as to not break ABI=20
compatibility. If I have strict space requirements and want to remain=20
portable, I cannot rely on the library as I have no control over what=20
underlying type they will use.

I'd really like to stop using unsigned ints for this purpose and just stick=
=20
to std::bitset. This issue is in the way of that.

On Wednesday, September 10, 2014 7:28:49 AM UTC-4, David Krauss wrote:
>
>
> Large bool is not usually for performance; it=E2=80=99s for compatibility=
 with C=20
> code using typedef int bool;. I=E2=80=99ve yet to see 8 bytes though. Whi=
ch=20
> implementation is that?
>

Gcc x86_64 libstdc++ sizeof(std::bitset<1>) =3D=3D 8, you can try it on=20
gcc.godbolt.org. I was very disappointed by this. Maybe the implementors=20
were just lazy? I have a hard time believing that doing bitset operations=
=20
on a 32 bit int is slow.

--=20

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

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

<div dir=3D"ltr"><div>Libraries may choose to optimize for performance or s=
pace, or they may have choose a particular size for any reason whatsoever. =
<span style=3D"font-size: 13px;">Once the library has chosen what it will d=
o, that choice is usually fixed as to not break ABI compatibility.&nbsp;</s=
pan><span style=3D"font-size: 13px;">If I have strict space requirements an=
d want to remain portable, I cannot rely on the library as I have no contro=
l over what underlying type they will use.</span></div><div><br></div><div>=
I'd really like to stop using unsigned ints for this purpose and just stick=
 to std::bitset. This issue is in the way of that.<br><br>On Wednesday, Sep=
tember 10, 2014 7:28:49 AM UTC-4, David Krauss wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div><br></=
div><div>Large <font face=3D"Courier">bool</font> is not usually for perfor=
mance; it=E2=80=99s for compatibility with C code using <font face=3D"Couri=
er">typedef int bool;</font>. I=E2=80=99ve yet to see 8 bytes though. Which=
 implementation is that?</div></div></div></blockquote><div><br></div><div>=
Gcc x86_64 libstdc++ sizeof(std::bitset&lt;1&gt;) =3D=3D 8, you can try it =
on gcc.godbolt.org. I was very disappointed by this. Maybe the implementors=
 were just lazy? I have a hard time believing that doing bitset operations =
on a 32 bit int is slow.</div></div></div>

<p></p>

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

------=_Part_1787_602984410.1410353484591--

.

Matthew Fioravante skrev den 2014-09-10 14:51:
> Libraries may choose to optimize for performance or space, or they may
> have choose a particular size for any reason whatsoever. Once the
> library has chosen what it will do, that choice is usually fixed as to
> not break ABI compatibility. If I have strict space requirements and
> want to remain portable, I cannot rely on the library as I have no
> control over what underlying type they will use.
>
> I'd really like to stop using unsigned ints for this purpose and just
> stick to std::bitset. This issue is in the way of that.
>
> On Wednesday, September 10, 2014 7:28:49 AM UTC-4, David Krauss wrote:
>
>
>     Large bool is not usually for performance; it=E2=80=99s for compatibi=
lity
>     with C code using typedef int bool;. I=E2=80=99ve yet to see 8 bytes =
though.
>     Which implementation is that?
>
>
> Gcc x86_64 libstdc++ sizeof(std::bitset<1>) =3D=3D 8, you can try it on
> gcc.godbolt.org. I was very disappointed by this. Maybe the implementors
> were just lazy? I have a hard time believing that doing bitset
> operations on a 32 bit int is slow.
>

The std::bitset interface has conversions to and from unsigned long=20
long. This strongly hints at using that type as the default underlying type=
..

Did the library team see a high priority interest in other=20
specializations? Obviously not - there are lots of other things to code=20
for a standard library.


Bo Persson


--=20

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

.

------=_Part_435_1345715868.1410367922949
Content-Type: text/plain; charset=UTF-8



On Wednesday, September 10, 2014 12:26:07 PM UTC-4, Bo Persson wrote:

> The std::bitset interface has conversions to and from unsigned long
> long. This strongly hints at using that type as the default underlying
> type.
>

I wouldn't take the existence of these methods as a hint that unsigned long
long should be used under the hood. Converting a smaller integer to
unsigned long long is easy. I would assume they chose the largest integral
type in order to support integral conversion using one method which would
work for most bitset instantiations.

It is more common to optimize for speed than size, so probably a good
default for std::bitset<M> is to use uint_fastN_t, where N is the smallest
integer size (8, 16, 32, 64) >= M. It would be nice if the standard
mandated that implementations optimize for speed, then we have a nice
usable default with known performance characteristics on all platforms.

Giving users the ability to override this choice with their own chosen type
would allow them to override this choice and optimize for space.


>
> Did the library team see a high priority interest in other
> specializations? Obviously not - there are lots of other things to code
> for a standard library.
>

Understandable as working on the standard library is no small task. The
problem is that choosing the size affects the ABI. This is not something
you can just get working now and optimize later because ABI breakage is a
big deal. Its why we're still stuck with CoW std::string in libstdc++.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, September 10, 2014 12:26:07 PM UTC-4=
, Bo Persson wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The std=
::bitset interface has conversions to and from unsigned long=20
<br>long. This strongly hints at using that type as the default underlying =
type.
<br></blockquote><div><br>I wouldn't take the existence of these methods as=
 a hint that unsigned long long should be used under the hood. Converting a=
 smaller integer to unsigned long long is easy. I would assume they chose t=
he largest integral type in order to support integral conversion using one =
method which would work for most bitset instantiations.<br><br>It is more c=
ommon to optimize for speed than size, so probably a good default for std::=
bitset&lt;M&gt; is to use uint_fastN_t, where N is the smallest integer siz=
e (8, 16, 32, 64) &gt;=3D M. It would be nice if the standard mandated that=
 implementations optimize for speed, then we have a nice usable default wit=
h known performance characteristics on all platforms.<br><br>Giving users t=
he ability to override this choice with their own chosen type would allow t=
hem to override this choice and optimize for space.<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
<br>Did the library team see a high priority interest in other=20
<br>specializations? Obviously not - there are lots of other things to code=
=20
<br>for a standard library.
<br></blockquote><div><br>Understandable as working on the standard library=
 is no small task. The problem is that choosing the size affects the ABI. T=
his is not something you can just get working now and optimize later becaus=
e ABI breakage is a big deal. Its why we're still stuck with CoW std::strin=
g in libstdc++.<br><br></div></div>

<p></p>

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

------=_Part_435_1345715868.1410367922949--

.

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

I don't think it's entirely hyperbolic to say that bitset has unpredictable
characteristics. This issue has implications in structure packing,
alignment, and of course memory utilization. These, in turn, impact our
ability to have nice cross-platform implementations of reflection and
serialization. When faced with the above issues, you can see why many
developers would rather implement their own bitset rather than leave their
fate in the hands of hope or drastically increase complexity of their
cross-platform build systems.

On Wed, Sep 10, 2014 at 6:28 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9309=E2=80=9310, at 3:34 PM, Brent Friedman <fourthgeek@gma=
il.com> wrote:
>
> Did you know that sizeof(bool) ranges between 1 byte and 8 bytes dependin=
g
> on implementation? I have no trouble doubting that a library vendor would
> do whatever they thought sounded good to improve performance
>
>
> Large bool is not usually for performance; it=E2=80=99s for compatibility=
 with C
> code using typedef int bool;. I=E2=80=99ve yet to see 8 bytes though. Whi=
ch
> implementation is that?
>
> -- and that a library consumer would balk at using a loosely defined and
> unpredictable data structure.
>
>
> Hyperbole.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">I don&#39;t think it&#39;s entirely hyperbolic to say that=
 bitset has unpredictable characteristics. This issue has implications in s=
tructure packing, alignment, and of course memory utilization. These, in tu=
rn, impact our ability to have nice cross-platform implementations of refle=
ction and serialization. When faced with the above issues, you can see why =
many developers would rather implement their own bitset rather than leave t=
heir fate in the hands of hope or drastically increase complexity of their =
cross-platform build systems.</div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Wed, Sep 10, 2014 at 6:28 AM, David Krauss <span dir=
=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@g=
mail.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"><div sty=
le=3D"word-wrap:break-word"><br><div><span class=3D""><div>On 2014=E2=80=93=
09=E2=80=9310, at 3:34 PM, Brent Friedman &lt;<a href=3D"mailto:fourthgeek@=
gmail.com" target=3D"_blank">fourthgeek@gmail.com</a>&gt; wrote:</div><br><=
blockquote type=3D"cite"><div dir=3D"ltr">Did you know that sizeof(bool) ra=
nges between 1 byte and 8 bytes depending on implementation? I have no trou=
ble doubting that a library vendor would do whatever they thought sounded g=
ood to improve performance </div></blockquote><div><br></div></span><div>La=
rge <font face=3D"Courier">bool</font> is not usually for performance; it=
=E2=80=99s for compatibility with C code using <font face=3D"Courier">typed=
ef int bool;</font>. I=E2=80=99ve yet to see 8 bytes though. Which implemen=
tation is that?</div><span class=3D""><br><blockquote type=3D"cite"><div di=
r=3D"ltr">-- and that a library consumer would balk at using a loosely defi=
ned and unpredictable data structure.</div></blockquote><div><br></div></sp=
an><div>Hyperbole.</div><div><br></div></div></div><div class=3D"HOEnZb"><d=
iv class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e013a0792c5a7280502b8e72b--

.

On Wednesday 10 September 2014 05:51:24 Matthew Fioravante wrote:
> Gcc x86_64 libstdc++ sizeof(std::bitset<1>) == 8, you can try it on
> gcc.godbolt.org. I was very disappointed by this. Maybe the implementors
> were just lazy? I have a hard time believing that doing bitset operations
> on a 32 bit int is slow.

On x86, there probably isn't a performance difference.

On other architectures, accessing word-sized chunks is often faster. The
std::bitset implementation uses "unsigned long" for all architectures and GCC
makes "long" have the same size as the machine's word (except for Windows
builds).

Anyway, bitset was discussed a few months ago on this list and it was left
alone.

Changing bitset now is a no-no. You can't add new template arguments. At most,
you'd need to add a new type to the Standard Library.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On 09/10/2014 11:07 PM, Thiago Macieira wrote:
>   You can't add new template arguments.

Why?

Which currently valid program would be invalidated by extending
the current

  template<size_t N>
  class bitset;

to

  template<size_t N, class T = /* implementation-defined */>
  class bitset;

?

(Yes, it's detectable using template template-parameters,
but that's a rather arcane use of a seldom-used feature.)

Jens

--

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

.

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

On Wed, Sep 10, 2014 at 5:50 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

>
>   template<size_t N>
>   class bitset;
>
> to
>
>   template<size_t N, class T = /* implementation-defined */>
>   class bitset;
>

This changes mangled name.

Whether it's worth the change is another question.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

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

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

<div dir=3D"ltr">On Wed, Sep 10, 2014 at 5:50 PM, Jens Maurer <span dir=3D"=
ltr">&lt;<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maur=
er@gmx.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
=C2=A0 template&lt;size_t N&gt;<br>
=C2=A0 class bitset;<br>
<br>
to<br>
<br>
=C2=A0 template&lt;size_t N, class T =3D /* implementation-defined */&gt;<b=
r>
=C2=A0 class bitset;<br></blockquote></div><br></div><div class=3D"gmail_ex=
tra">This changes mangled name.<br><br></div><div class=3D"gmail_extra">Whe=
ther it&#39;s worth the change is another question.<br clear=3D"all"></div>=
<div class=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID lichray<br>The best w=
ay to predict the future is to invent it.<br>______________________________=
_____________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=
=3D"_blank">http://bit.ly/blog4bsd</a>
</div></div>

<p></p>

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

--001a1133375c4569c90502bd4b62--

.

On Wednesday 10 September 2014 23:50:01 Jens Maurer wrote:
> On 09/10/2014 11:07 PM, Thiago Macieira wrote:
> >   You can't add new template arguments.
>
> Why?
>
> Which currently valid program would be invalidated by extending
> the current
>
>   template<size_t N>
>   class bitset;
>
> to
>
>   template<size_t N, class T = /* implementation-defined */>
>   class bitset;
>
> ?
>
> (Yes, it's detectable using template template-parameters,
> but that's a rather arcane use of a seldom-used feature.)

Any program that uses the bitset class in a function or template parameter.

This changes the external name (mangled name) of the type.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_1110_588180881.1410400904021
Content-Type: text/plain; charset=UTF-8

On Wednesday, September 10, 2014 5:08:01 PM UTC-4, Thiago Macieira wrote:
>
>
> On x86, there probably isn't a performance difference.


That is what I would suspect as well. In that case, x86 should use uint32_t
to save space when N <= 32. Smaller objects mean more things can fit in a
single cache line. This is a big deal for performance.

Would it be so horrible to sometimes break ABI compatibility between some
major revisions of the language? What I would classify as a major revision
is C++98, C++11, and C++17, with 03 and 14 being minor revisions.

bitset is a fundamental and extremely useful tool with an interface which
is lacking. Adding additional types such as std::bitset2, std::bitset_fast
/ std::bitset_small, std::int_bitset, etc... seems counter productive.

Its already pretty much a bad idea to mix C++11 and non C++11 enabled
binaries as it is. You basically have to compile everything in C++11 mode
or not in C++11 mode. While it is possible to link different binaries
together, this requires a lot of special cases and in general is not worth
it.

On Wednesday, September 10, 2014 6:12:55 PM UTC-4, Thiago Macieira wrote:
>
> On Wednesday 10 September 2014 23:50:01 Jens Maurer wrote:
> > On 09/10/2014 11:07 PM, Thiago Macieira wrote:
> > >   You can't add new template arguments.
> >
> > Why?
> >
> > Which currently valid program would be invalidated by extending
> > the current
> >
> >   template<size_t N>
> >   class bitset;
> >
> > to
> >
> >   template<size_t N, class T = /* implementation-defined */>
> >   class bitset;
> >
> > ?
> >
> > (Yes, it's detectable using template template-parameters,
> > but that's a rather arcane use of a seldom-used feature.)
>
> Any program that uses the bitset class in a function or template
> parameter.
>
> This changes the external name (mangled name) of the type.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

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

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

<div dir=3D"ltr"><div>On Wednesday, September 10, 2014 5:08:01 PM UTC-4, Th=
iago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204=
); border-left-style: solid; padding-left: 1ex;"><br>On x86, there probably=
 isn't a performance difference.&nbsp;</blockquote><div><br></div><div>That=
 is what I would suspect as well. In that case, x86 should use uint32_t to =
save space when N &lt;=3D 32. Smaller objects mean more things can fit in a=
 single cache line. This is a big deal for performance.</div></div><div><br=
></div><div>Would it be so horrible to sometimes break ABI compatibility be=
tween some major revisions of the language? What I would classify as a majo=
r revision is C++98, C++11, and C++17, with 03 and 14 being minor revisions=
..</div><div><br></div><div>bitset is a fundamental and extremely useful too=
l with an interface which is lacking. Adding additional types such as std::=
bitset2, std::bitset_fast / std::bitset_small, std::int_bitset, etc... seem=
s counter productive.</div><div><br></div><div>Its already pretty much a ba=
d idea to mix C++11 and non C++11 enabled binaries as it is. You basically =
have to compile everything in C++11 mode or not in C++11 mode. While it is =
possible to link different binaries together, this requires a lot of specia=
l cases and in general is not worth it.<br><br>On Wednesday, September 10, =
2014 6:12:55 PM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On Wednesday 10 September 2014 23:50:01 Jens Maurer wrote:
<br>&gt; On 09/10/2014 11:07 PM, Thiago Macieira wrote:
<br>&gt; &gt; &nbsp; You can't add new template arguments.
<br>&gt;=20
<br>&gt; Why?
<br>&gt;=20
<br>&gt; Which currently valid program would be invalidated by extending
<br>&gt; the current
<br>&gt;=20
<br>&gt; &nbsp; template&lt;size_t N&gt;
<br>&gt; &nbsp; class bitset;
<br>&gt;=20
<br>&gt; to
<br>&gt;=20
<br>&gt; &nbsp; template&lt;size_t N, class T =3D /* implementation-defined=
 */&gt;
<br>&gt; &nbsp; class bitset;
<br>&gt;=20
<br>&gt; ?
<br>&gt;=20
<br>&gt; (Yes, it's detectable using template template-parameters,
<br>&gt; but that's a rather arcane use of a seldom-used feature.)
<br>
<br>Any program that uses the bitset class in a function or template parame=
ter.
<br>
<br>This changes the external name (mangled name) of the type.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_1110_588180881.1410400904021--

.

On 09/11/2014 12:12 AM, Thiago Macieira wrote:
> On Wednesday 10 September 2014 23:50:01 Jens Maurer wrote:
>> On 09/10/2014 11:07 PM, Thiago Macieira wrote:
>>>   You can't add new template arguments.
>>
>> Why?
>>
>> Which currently valid program would be invalidated by extending
>> the current

> Any program that uses the bitset class in a function or template parameter.
>
> This changes the external name (mangled name) of the type.

Ah, so it's (only) about ABI compatibility, not about source
compatibility.

I believe we'll break ABI compatibility for about any major
C++ release (C++11, C++17), so that seems like a minor concern
to me.

Thanks,
Jens

--

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

.

On Wednesday 10 September 2014 19:01:43 Matthew Fioravante wrote:
> Would it be so horrible to sometimes break ABI compatibility between some
> major revisions of the language?

Yes.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On Thursday 11 September 2014 08:21:23 Jens Maurer wrote:
> I believe we'll break ABI compatibility for about any major
> C++ release (C++11, C++17), so that seems like a minor concern
> to me.

I don't believe that's in the agenda. The standard does not even discuss ABI,
but has so far managed to only make incremental changes that compiler
implementors and library writers can keep stable ABI for (except for
std::string with libstdc++).

It also goes against Herb Sutter's proposal for a more stable ABI.

No, I believe maintaining the ABI is actually very much the goal here.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

On 2014-09-11, at 3:21 PM, Thiago Macieira <thiago@macieira.org> wrote:

> It also goes against Herb Sutter's proposal for a more stable ABI.

Sutter proposed a degree of ABI versioning to enable future progress, not a commitment to eternal stagnation. The overall goal is to get the ABIs unstuck.

> No, I believe maintaining the ABI is actually very much the goal here.

The proposal here only calls for fixing a longstanding efficiency issue. Library ABIs, DLL distribution, and their brittleness are library implementers' own fault. At some point the band-aid has to be pulled.

Fortunately, this particular issue can be solved opportunistically at any point in the future. It's a good idea to report it as a bug to your implementation, so they can record it as "blocking" the longstanding issue of ABI revision.

--

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

.

On 09/11/2014 09:21 AM, Thiago Macieira wrote:
> On Thursday 11 September 2014 08:21:23 Jens Maurer wrote:
>> I believe we'll break ABI compatibility for about any major
>> C++ release (C++11, C++17), so that seems like a minor concern
>> to me.
>
> I don't believe that's in the agenda. The standard does not even discuss ABI,
> but has so far managed to only make incremental changes that compiler
> implementors and library writers can keep stable ABI for (except for
> std::string with libstdc++).

Well, for the signature / name mangling issue, we now have inline
namespaces, which should help.

I believe we did break the ABI for C++11 (new allocator design seems a candidate),
and it's conceivable we'll break it again for C++17 (conceptualized standard
library containers come to mind).

Jens

--

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

.

On 11 September 2014 15:55, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> I believe we did break the ABI for C++11 (new allocator design seems a candidate),
> and it's conceivable we'll break it again for C++17 (conceptualized standard
> library containers come to mind).


Yep, there are other things that resulted in ABI breaks, like the
time_put in locale,
and I think move operations for iostreams can result in ABI breakage as well.
Jonathan Wakely knows more about the various details that cause ABI breakage
in C++11. C++17 is likely to result in ABI breaks for the things that were added
to the Fundamentals TS, if we manage to roll up those changes into C++17.
So while we try and avoid such ABI breaks, they do happen on major C++
releases sometimes.

--

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

.

On Thursday 11 September 2014 14:55:04 Jens Maurer wrote:
> On 09/11/2014 09:21 AM, Thiago Macieira wrote:
> > On Thursday 11 September 2014 08:21:23 Jens Maurer wrote:
> >> I believe we'll break ABI compatibility for about any major
> >> C++ release (C++11, C++17), so that seems like a minor concern
> >> to me.
> >
> > I don't believe that's in the agenda. The standard does not even discuss
> > ABI, but has so far managed to only make incremental changes that
> > compiler implementors and library writers can keep stable ABI for (except
> > for std::string with libstdc++).
>
> Well, for the signature / name mangling issue, we now have inline
> namespaces, which should help.

Not in this case. If I have a current std::bitset<32> in my class and call a
library method with a pointer to my class, then std::bitset<32> can't change
sizes.

An inline namespace would replace a binary compatibility issue with a source
compatibility one. I'd need to replace all uses of std::bitset<32> in my
sources with std::oldbitset<32> (assuming oldbitset is a typedef to the actual
bitset type and doesn't get overridden in the inline namespace).

> I believe we did break the ABI for C++11 (new allocator design seems a
> candidate), and it's conceivable we'll break it again for C++17
> (conceptualized standard library containers come to mind).

I have no clue about allocators, so I can't comment on what might have broken.
As for C++17, since it isn't out, there's no saying what will break.

My point is that there are years between releases of the standard, so we do
have enough time to perfect interfaces before they get set on stone. For
things that aren't ready, we have TS and libraries outside the standard that
can experiment. I really think the standard should really, really avoid
requiring an ABI break and should accumulate them to one major release and not
do it more frequently than once every 10 years.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_204_1587833621.1410454249622
Content-Type: text/plain; charset=UTF-8



On Thursday, September 11, 2014 12:28:44 PM UTC-4, Thiago Macieira wrote:
>
>
> My point is that there are years between releases of the standard, so we
> do
> have enough time to perfect interfaces before they get set on stone. For
> things that aren't ready, we have TS and libraries outside the standard
> that
> can experiment. I really think the standard should really, really avoid
> requiring an ABI break and should accumulate them to one major release and
> not
> do it more frequently than once every 10 years.
>

We have time to think about new features. We have time to test them in a
TS. Unfortunately sometimes even that is not enough and a deficiency is
discovered after the feature has made it into the standard. I don't think
its realistic to assume ABI breakage can never occur. It's unfortunate but
it can and will happen from time to time.

Now back to the question of template <size_t N, typename T = /* impl
defined */> std::bitset; Other than ABI breakage, does anyone see problems
with this idea?


--

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

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

<div dir=3D"ltr"><br><br>On Thursday, September 11, 2014 12:28:44 PM UTC-4,=
 Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>My =
point is that there are years between releases of the standard, so we do=20
<br>have enough time to perfect interfaces before they get set on stone. Fo=
r=20
<br>things that aren't ready, we have TS and libraries outside the standard=
 that=20
<br>can experiment. I really think the standard should really, really avoid=
=20
<br>requiring an ABI break and should accumulate them to one major release =
and not=20
<br>do it more frequently than once every 10 years.=20
<br></blockquote><div><br>We have time to think about new features. We have=
 time to test them in a TS. Unfortunately sometimes even that is not enough=
 and a deficiency is discovered after the feature has made it into the stan=
dard. I don't think its realistic to assume ABI breakage can never occur. I=
t's unfortunate but it can and will happen from time to time.<br><br>Now ba=
ck to the question of template &lt;size_t N, typename T =3D /* impl defined=
 */&gt; std::bitset; Other than ABI breakage, does anyone see problems with=
 this idea?<br><br><br></div></div>

<p></p>

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

------=_Part_204_1587833621.1410454249622--

.

On Thursday 11 September 2014 09:50:49 Matthew Fioravante wrote:
> Now back to the question of template <size_t N, typename T = /* impl
> defined */> std::bitset; Other than ABI breakage, does anyone see problems
> with this idea?

I still see one: there's still no clear idea of what that T would do and what
the requirements would be. Let's assume you require it to be an integral type,
possibly even an unsigned one. What then? Is there a requirement on the
sizeof? Is there a requirement on the alignof?

bitset<64, uint32_t> would do what? Why should that be allowed if
bitset<64, uint64_t> is more efficient? And what happens when
bitset<64, uint32_t> is more efficient than bitset<64, uint64_t>?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_127_2097690937.1410467668247
Content-Type: text/plain; charset=UTF-8



On Thursday, September 11, 2014 3:06:50 PM UTC-4, Thiago Macieira wrote:
>
> On Thursday 11 September 2014 09:50:49 Matthew Fioravante wrote:
> > Now back to the question of template <size_t N, typename T = /* impl
> > defined */> std::bitset; Other than ABI breakage, does anyone see
> problems
> > with this idea?
>
> I still see one: there's still no clear idea of what that T would do and
> what
> the requirements would be. Let's assume you require it to be an integral
> type,
> possibly even an unsigned one. What then? Is there a requirement on the
> sizeof? Is there a requirement on the alignof?
>

These are the requirements:
sizeof(bitset<N,T>) == sizeof(T) * (N / (sizeof(T) * CHAR_BIT)+1)
alignof(bitset<N,T>) == alignof(T)

The underlying bitset doesn't have to even be implemented using T, it just
needs to satisfy the alignment and size requirements.


>
> bitset<64, uint32_t> would do what?


This would be like a hand rolled bitset using uint32_t[2];


> Why should that be allowed if
> bitset<64, uint64_t> is more efficient?


The user wants to have a smaller alignment constraint, so that they can
pack the bitset tightly into a small object.

For example:
struct Instruction {
  uint32_t ordinal;
  std::bitset<64, uint32_t> flags;
  uint32_t operands[5];
};

static_assert(sizeof(Instruction) == 32);


And what happens when
> bitset<64, uint32_t> is more efficient than bitset<64, uint64_t>?
>

This seems unlikely, but if it is the case then std::bitset<64> on that
platform should be implemented as std::bitset<64, uint32_t>.

In addition to the new syntax, the standard should mandate that the default
bitset<N> should first optimize for speed, and then if all else is
equivalent optimize for space. I say standard mandated because by leaving
the issue as a QoI problem means that some implementations would optimize
for space, some for speed, some balance between the 2, or not at all.

The default should be speed because the optimal integer size is different
on each platform. The user cannot know this unless they test and have
ifdefs for each platform. Platform specific changes like this should be
hidden in the standard library.

If the user has space requirements, then they can fix the type as needed.

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, September 11, 2014 3:06:50 PM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thurs=
day 11 September 2014 09:50:49 Matthew Fioravante wrote:
<br>&gt; Now back to the question of template &lt;size_t N, typename T =3D =
/* impl=20
<br>&gt; defined */&gt; std::bitset; Other than ABI breakage, does anyone s=
ee problems=20
<br>&gt; with this idea?
<br>
<br>I still see one: there's still no clear idea of what that T would do an=
d what=20
<br>the requirements would be. Let's assume you require it to be an integra=
l type,=20
<br>possibly even an unsigned one. What then? Is there a requirement on the=
=20
<br>sizeof? Is there a requirement on the alignof?
<br></blockquote><div><br>These are the requirements:<br>sizeof(bitset&lt;N=
,T&gt;) =3D=3D sizeof(T) * (N / (sizeof(T) * CHAR_BIT)+1)<br>alignof(bitset=
&lt;N,T&gt;) =3D=3D alignof(T)<br><br>The underlying bitset doesn't have to=
 even be implemented using T, it just needs to satisfy the alignment and si=
ze requirements. <br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">
<br>bitset&lt;64, uint32_t&gt; would do what? </blockquote><div><br>This wo=
uld be like a hand rolled bitset using uint32_t[2];<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Why should that be allowed if=20
<br>bitset&lt;64, uint64_t&gt; is more efficient? </blockquote><div><br>The=
 user wants to have a smaller alignment constraint, so that they can pack t=
he bitset tightly into a small object.<br><br>For example:<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: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Instruction</span><span style=3D"colo=
r: #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"><br>&nbsp; uint32_t ordinal</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; std</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">bitset</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">64</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> u=
int32_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> flags</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; uint32_t op=
erands</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static_assert</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Instruction</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">32</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">And what happens w=
hen=20
<br>bitset&lt;64, uint32_t&gt; is more efficient than bitset&lt;64, uint64_=
t&gt;?
<br></blockquote><div><br>This seems unlikely, but if it is the case then s=
td::bitset&lt;64&gt; on that platform should be implemented as std::bitset&=
lt;64, uint32_t&gt;.<br><br>In addition to the new syntax, the standard sho=
uld mandate that the default bitset&lt;N&gt; should first optimize for spee=
d, and then if all else is equivalent optimize for space. I say standard ma=
ndated because by leaving the issue as a QoI problem means that some implem=
entations would optimize for space, some for speed, some balance between th=
e 2, or not at all. <br><br>The default should be speed because the optimal=
 integer size is different on each platform. The user cannot know this unle=
ss they test and have ifdefs for each platform. Platform specific changes l=
ike this should be hidden in the standard library.<br><br>If the user has s=
pace requirements, then they can fix the type as needed.<br><br></div></div=
>

<p></p>

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

------=_Part_127_2097690937.1410467668247--

.

On Thursday 11 September 2014 13:34:28 Matthew Fioravante wrote:
> These are the requirements:
> sizeof(bitset<N,T>) == sizeof(T) * (N / (sizeof(T) * CHAR_BIT)+1)
> alignof(bitset<N,T>) == alignof(T)

This doesn't work on Linux/x86 already.

struct X { long long d; };
alignof(X) != alignof(long long)

Why? Because the ABI went to great lengths to avoid getting broken when the
compiler decided that aligning 8-byte types on 8 byte boundaries was more
efficient.

Imposing the alignment like you ask means you cannot replace a long long with
a bitset<64, long long> in a structure and still keep binary compatibility.

I'd stick to the sizeof requirement and let alignof be anything.

> > bitset<64, uint32_t> would do what?
>
> This would be like a hand rolled bitset using uint32_t[2];
>
> > Why should that be allowed if
> > bitset<64, uint64_t> is more efficient?
>
> The user wants to have a smaller alignment constraint, so that they can
> pack the bitset tightly into a small object.
>
> For example:
> struct Instruction {
>   uint32_t ordinal;
>   std::bitset<64, uint32_t> flags;
>   uint32_t operands[5];
> };
>
> static_assert(sizeof(Instruction) == 32);

Fair enough.

> In addition to the new syntax, the standard should mandate that the default
> bitset<N> should first optimize for speed, and then if all else is
> equivalent optimize for space. I say standard mandated because by leaving
> the issue as a QoI problem means that some implementations would optimize
> for space, some for speed, some balance between the 2, or not at all.

I'd say the standard should not mandate either way. It's really something that
should be QoI: an implementation could decide that space is more important
than speed (tightly constrained system) or the other way around (slow bit
instructions).

The standard could recommend what you said, but implementations should be free
to ignore the recommendation if they have overriding priorities.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_235_1221870748.1410481061774
Content-Type: text/plain; charset=UTF-8



On Thursday, September 11, 2014 7:03:39 PM UTC-4, Thiago Macieira wrote:
>
> On Thursday 11 September 2014 13:34:28 Matthew Fioravante wrote:
> > These are the requirements:
> > sizeof(bitset<N,T>) == sizeof(T) * (N / (sizeof(T) * CHAR_BIT)+1)
> > alignof(bitset<N,T>) == alignof(T)
>
> This doesn't work on Linux/x86 already.
>
> struct X { long long d; };
> alignof(X) != alignof(long long)
>
> Why? Because the ABI went to great lengths to avoid getting broken when
> the
> compiler decided that aligning 8-byte types on 8 byte boundaries was more
> efficient.
>
> Imposing the alignment like you ask means you cannot replace a long long
> with
> a bitset<64, long long> in a structure and still keep binary
> compatibility.
>

Great catch, how about we relax the requirements in this way.

template <typename T, size_t N>
constexpr size_t struct_size {
  struct { T x[N]; } t;
  return sizeof(t);
}

template <typename T, size_t N>
constexpr size_t struct_align {
  struct { Tx[N]; } t;
  return alignof(t);
}

static_assert(alignof(bitset<N,T>) == struct_align<T,N>())):
static_assert(sizeof(bitset<N,T>) == struct_size<T,N>() * (N /
(struct_size<T,N> * CHAR_BIT)+1);

>
> I'd stick to the sizeof requirement and let alignof be anything.
>

I think we should try to anchor it more. The additional strength will make
it more reliable for binary IO, IPC, and GPU buffer packing, marshalling,
stuff like that.

Another of int types in <cstdint> could give exact alignment and size
requirements.  (This would be a different idea to explore).

using uint32a32s_t = /* implementation defined */


> I'd say the standard should not mandate either way. It's really something
> that
> should be QoI: an implementation could decide that space is more important
> than speed (tightly constrained system) or the other way around (slow bit
> instructions).
>
> The standard could recommend what you said, but implementations should be
> free
> to ignore the recommendation if they have overriding priorities.
>

This seems reasonable. There at least should be official wording in the
standard.


>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, September 11, 2014 7:03:39 PM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thurs=
day 11 September 2014 13:34:28 Matthew Fioravante wrote:
<br>&gt; These are the requirements:
<br>&gt; sizeof(bitset&lt;N,T&gt;) =3D=3D sizeof(T) * (N / (sizeof(T) * CHA=
R_BIT)+1)
<br>&gt; alignof(bitset&lt;N,T&gt;) =3D=3D alignof(T)
<br>
<br>This doesn't work on Linux/x86 already.
<br>
<br>struct X { long long d; };
<br>alignof(X) !=3D alignof(long long)
<br>
<br>Why? Because the ABI went to great lengths to avoid getting broken when=
 the=20
<br>compiler decided that aligning 8-byte types on 8 byte boundaries was mo=
re=20
<br>efficient.
<br>
<br>Imposing the alignment like you ask means you cannot replace a long lon=
g with=20
<br>a bitset&lt;64, long long&gt; in a structure and still keep binary comp=
atibility.
<br></blockquote><div><br></div><div>Great catch, how about we relax the re=
quirements in this way.</div><div><br></div><div>template &lt;typename T, s=
ize_t N&gt;</div><div>constexpr size_t struct_size {</div><div>&nbsp; struc=
t { T x[N]; } t;</div><div>&nbsp; return sizeof(t);</div><div>}</div><div><=
br></div><div><div>template &lt;typename T, size_t N&gt;</div><div>constexp=
r size_t struct_align {</div><div>&nbsp; struct { Tx[N]; } t;</div><div>&nb=
sp; return alignof(t);</div><div>}</div></div><div><br></div><div>static_as=
sert(alignof(bitset&lt;N,T&gt;) =3D=3D struct_align&lt;T,N&gt;())):</div><d=
iv>static_assert(sizeof(bitset&lt;N,T&gt;) =3D=3D struct_size&lt;T,N&gt;() =
* (N / (struct_size&lt;T,N&gt; * CHAR_BIT)+1);</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
<br>I'd stick to the sizeof requirement and let alignof be anything.
<br></blockquote><div><br></div><div>I think we should try to anchor it mor=
e. The additional strength will make it more reliable for binary IO, IPC, a=
nd GPU buffer packing, marshalling, stuff like that.</div><div><br></div><d=
iv>Another of int types in &lt;cstdint&gt; could give exact alignment and s=
ize requirements. &nbsp;(This would be a different idea to explore).</div><=
div><br></div><div>using uint32a32s_t =3D /* implementation defined */</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I'd say th=
e standard should not mandate either way. It's really something that=20
<br>should be QoI: an implementation could decide that space is more import=
ant=20
<br>than speed (tightly constrained system) or the other way around (slow b=
it=20
<br>instructions).
<br>
<br>The standard could recommend what you said, but implementations should =
be free=20
<br>to ignore the recommendation if they have overriding priorities.
<br></blockquote><div><br></div><div>This seems reasonable. There at least =
should be official wording in the standard.</div><div>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_235_1221870748.1410481061774--

.

------=_Part_359_1078433953.1410493485216
Content-Type: text/plain; charset=UTF-8

Actually, I think it might still be ok to keep the original constraints.

alignof(T) == alignof(std::bitset<N,T>);

It can be implemented on linux i386 as

template <size_t N, typename T>
class bitset {
  T[N / (sizeof(T) * CHAR_BIT) +1] x;
} alignas(T);

--

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

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

<div dir=3D"ltr">Actually, I think it might still be ok to keep the origina=
l constraints.<div><br></div><div>alignof(T) =3D=3D alignof(std::bitset&lt;=
N,T&gt;);</div><div><br></div><div>It can be implemented on linux i386 as</=
div><div><br></div><div>template &lt;size_t N, typename T&gt;</div><div>cla=
ss bitset {</div><div>&nbsp; T[N / (sizeof(T) * CHAR_BIT) +1] x;</div><div>=
} alignas(T);</div><div><br></div></div>

<p></p>

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

------=_Part_359_1078433953.1410493485216--

.

On Thursday 11 September 2014 20:44:45 Matthew Fioravante wrote:
> template <size_t N, typename T>
> class bitset {
>   T[N / (sizeof(T) * CHAR_BIT) +1] x;
> } alignas(T);

Which means you can't replace an uint64_t in a struct with a
bitset<64,uint64_t>. You may argue that this was never guaranteed to work
anyway and that's probably right.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_2279_775044535.1410643930635
Content-Type: text/plain; charset=UTF-8

Just to throw something crazy into the mix:

What about a bitset of a strong enum? Such that

  enum class my_enum { ... };
  std::bitset<my_enum> bits;

is equivalent to:

  enum class my_enum { ... };
  std::bitset<sizeof(my_enum) * CHAR_BIT, std::underlying_type_t<my_enum>>
bits;

This might play well with a standard library set of extensions for treating
strong enums as flag sets (e.g. allowing the bitwise operators on them to
produce a library type like std::bitset<>, assuming that's determined to be
better than a new std::flags<> or the like). We had a discussion about this
a year or two ago I started based on C#'s approach (an attribute that
modifies enum behavior slightly) and now use a library traits approach that
specializes a std::is_flagset<> for an enum and then overloads the bitwise
operators for any enumerations with std::is_flagset<> of true, but I just
reuse the base enum type as the storage (which has the disadvantage of
allowing a "strong" enum to contain values not in its formal list, though
at least MSVS's debugger seems to recognize and handle this in a very
useful and friendly manner).

On Tuesday, September 9, 2014 8:06:49 PM UTC-7, Matthew Fioravante wrote:
>
> It would be useful to be able to control the underlying integral type used
> for std::bitset. I have a use case now where I want a compact object to
> have a set of up to 32 bit flags but because std::bitset<32> uses 64 bits
> on my system, I cannot use it.
>
> It would be nice if you could pass an integral type as template parameter
> to bitset to fix its implementation to have the size and alignment
> constraints of that type.
>
> //Assume char is 8 bits, short is 16 bits, int is 32 bits, and  long is 64
> bits
>
>
> bitset<32,int> a; //Ok
> bitset<33,int> b; //Error: 33 bits cannot fit in an int!
> bitset<int> c; //Ok: same as bitset<sizeof(int)*CHAR_BIT,int>
> bitset<char> d; //Ok
>
> An alternative to this would be to invent another type like
> std::small_bitset which behaves identically to bitset but uses as few bits
> as possible to implement the type. This alternative is less flexible and
> could lead to easy to miss efficiency bugs for odd sizes like
> std::small_bitset<24> due to overzealous space conservation.
>

--

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

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

<div dir=3D"ltr">Just to throw something crazy into the mix:<div><br></div>=
<div>What about a bitset of a strong enum? Such that</div><div><br></div><d=
iv>&nbsp; enum class my_enum { ... };</div><div>&nbsp; std::bitset&lt;my_en=
um&gt; bits;</div><div><br></div><div>is equivalent to:</div><div><br></div=
><div>&nbsp; enum class my_enum { ... };<br></div><div>&nbsp; std::bitset&l=
t;sizeof(my_enum) * CHAR_BIT, std::underlying_type_t&lt;my_enum&gt;&gt; bit=
s;</div><div><br></div><div>This might play well with a standard library se=
t of extensions for treating strong enums as flag sets (e.g. allowing the b=
itwise operators on them to produce a library type like std::bitset&lt;&gt;=
, assuming that's determined to be better than a new std::flags&lt;&gt; or =
the like). We had a discussion about this a year or two ago I started based=
 on C#'s approach (an attribute that modifies enum behavior slightly) and n=
ow use a library traits approach that specializes a std::is_flagset&lt;&gt;=
 for an enum and then overloads the bitwise operators for any enumerations =
with std::is_flagset&lt;&gt; of true, but I just reuse the base enum type a=
s the storage (which has the disadvantage of allowing a "strong" enum to co=
ntain values not in its formal list, though at least MSVS's debugger seems =
to recognize and handle this in a very useful and friendly manner).</div><d=
iv><br></div><div>On Tuesday, September 9, 2014 8:06:49 PM UTC-7, Matthew F=
ioravante 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"lt=
r">It would be useful to be able to control the underlying integral type us=
ed for std::bitset. I have a use case now where I want a compact object to =
have a set of up to 32 bit flags but because std::bitset&lt;32&gt; uses 64 =
bits on my system, I cannot use it.<div><br><div>It would be nice if you co=
uld pass an integral type as template parameter to bitset to fix its implem=
entation to have the size and alignment constraints of that type.<br><div><=
br></div><div style=3D"background-color:rgb(250,250,250);border:1px solid r=
gb(187,187,187);word-wrap:break-word"><code><div><span style=3D"color:#800"=
>//Assume char is 8 bits, short is 16 bits, int is 32 bits, and &nbsp;long =
is 64 bits</span><span style=3D"color:#000"><br><br><br>bitset</span><span =
style=3D"color:#660">&lt;</span><span style=3D"color:#066">32</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#008">int</span><span styl=
e=3D"color:#660">&gt;</span><span style=3D"color:#000"> a</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#800">//Ok</span><span style=3D"color:#000"><br>bitset</span><span sty=
le=3D"color:#660">&lt;</span><span style=3D"color:#066">33</span><span styl=
e=3D"color:#660">,</span><span style=3D"color:#008">int</span><span style=
=3D"color:#660">&gt;</span><span style=3D"color:#000"> b</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#800">//Error: 33 bits cannot fit in an int!</span><span style=3D"colo=
r:#000"><br>bitset</span><span style=3D"color:#080">&lt;int&gt;</span><span=
 style=3D"color:#000"> c</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#800">//Ok: same as bitset&l=
t;sizeof(int)*CHAR_BIT,<wbr>int&gt;</span><span style=3D"color:#000"><br>bi=
tset</span><span style=3D"color:#080">&lt;char&gt;</span><span style=3D"col=
or:#000"> d</span><span style=3D"color:#660">;</span><span style=3D"color:#=
000"> </span><span style=3D"color:#800">//Ok</span></div></code></div><div>=
<br></div></div></div><div>An alternative to this would be to invent anothe=
r type like std::small_bitset which behaves identically to bitset but uses =
as few bits as possible to implement the type. This alternative is less fle=
xible and could lead to easy to miss efficiency bugs for odd sizes like std=
::small_bitset&lt;24&gt; due to overzealous space conservation.</div></div>=
</blockquote></div></div>

<p></p>

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

------=_Part_2279_775044535.1410643930635--

.