------=_Part_709_3010481.1398283333403
Content-Type: text/plain; charset=UTF-8


I noticed the other day that regardless of the number of bits you specify
std::bitset (at least GNU's libstdc++ implementation) the size of the type
is always the size of a pointer. For example the following code:

//----------------

#include <bitset>
#include <iostream>

int main() {
    std::bitset<8> b8;
    std::bitset<16> b16;
    std::bitset<32> b32;
    std::bitset<64> b64;
    std::cout << sizeof(b8) << "\n";
    std::cout << sizeof(b16) << "\n";
    std::cout << sizeof(b32) << "\n";
    std::cout << sizeof(b64) << "\n";
}

//----------------

prints:

8
8
8
8

It seems obvious to me why this is the case. the implementation of
std::bitset clearly uses the heap for storage regardless of how many bits
you are trying to store. Certainly, this is the simplest implementation.
But I think we can do better.

Now that <cstdint> is part of c++11. I would love to see the standard
require the following:

If a given uintN_t type is present, an object of type std::bitset<N> shall
have a sizeof of precisely N bits and use no heap allocations for storage.

If any of those types are not present on the system, the implementation is
free to use the heap as in current implementations.

To me this has multiple benefits:

1. Meets the "efficiency while maintain abstraction" mentality of C++. Why
should I use std::bitset<64> when a uint64_t is more efficient? I would
*expect* them to be equally efficient.

2. Smaller memory footprint if using many std::bitset<> instances. If I
have an array of 100 std::bitset<8> objects. My proposal would occupy no
more than 100 bytes. The current version occupies at least: 900 bytes (100
pointers, and 100 bytes pointed too. Possibly more if they simply the
implementation by always storing an array of unsigned longs and a bitmask,
but 900 is the minimum).

3. Makes the type more useful for systems programming.

4. it's more efficient! No dereferences of memory, and less generally work
to do the bit twiddling in std::bitset's implementation for the special
cases where the underlying type is a native size.

I know that library writers have been free to do this for basically forever
and obviously have chosen not to. But it seems to be an obvious
optimization. Perhaps they just overlooked it? Or perhaps they just don't
find it worth it. Either way, I think that would be nice to have the
standard insist on an efficient implementation when it's possible to do.
It's not a particularly hard specialization to do, I've made an
experimental one myself in the past which worked beautifully if an example
is desired.

As a secondary improvement, I'd love to see std::bitset have
first_set_bit() and last_set_bit() members which a particularly clever
implementation could implement with O(1) compiler intrinsics when dealing
with these "native sized types"

Thoughts?

--

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

<div dir=3D"ltr"><br><div>I noticed the other day that regardless of the nu=
mber of bits you specify std::bitset (at least GNU's libstdc++ implementati=
on) the size of the type is always the size of a pointer. For example the f=
ollowing code:</div><div><br></div><div>//----------------<br></div><div><d=
iv><br></div><div>#include &lt;bitset&gt;</div><div>#include &lt;iostream&g=
t;</div><div><br></div><div>int main() {</div><div>&nbsp; &nbsp; std::bitse=
t&lt;8&gt; b8;</div><div>&nbsp; &nbsp; std::bitset&lt;16&gt; b16;</div><div=
>&nbsp; &nbsp; std::bitset&lt;32&gt; b32;</div><div>&nbsp; &nbsp; std::bits=
et&lt;64&gt; b64;</div><div>&nbsp; &nbsp; std::cout &lt;&lt; sizeof(b8) &lt=
;&lt; "\n";</div><div>&nbsp; &nbsp; std::cout &lt;&lt; sizeof(b16) &lt;&lt;=
 "\n";</div><div>&nbsp; &nbsp; std::cout &lt;&lt; sizeof(b32) &lt;&lt; "\n"=
;</div><div>&nbsp; &nbsp; std::cout &lt;&lt; sizeof(b64) &lt;&lt; "\n";</di=
v><div>}</div></div><div><br></div><div>//----------------<br></div><div><b=
r></div><div>prints:</div><div><br></div><div>8</div><div>8</div><div>8</di=
v><div>8</div><div><br></div><div>It seems obvious to me why this is the ca=
se. the implementation of std::bitset clearly uses the heap for storage reg=
ardless of how many bits you are trying to store. Certainly, this is the si=
mplest implementation. But I think we can do better.</div><div><br></div><d=
iv>Now that &lt;cstdint&gt; is part of c++11. I would love to see the stand=
ard require the following:</div><div><br></div><div>If a given uintN_t type=
 is present, an object of type std::bitset&lt;N&gt; shall have a sizeof of =
precisely N bits and use no heap allocations for storage.</div><div><br></d=
iv><div>If any of those types are not present on the system, the implementa=
tion is free to use the heap as in current implementations.<br></div><div><=
br></div><div>To me this has multiple benefits:</div><div><br></div><div>1.=
 Meets the "efficiency while maintain abstraction" mentality of C++. Why sh=
ould I use std::bitset&lt;64&gt; when a uint64_t is more efficient? I would=
 *expect* them to be equally efficient.<br></div><div><br></div><div>2. Sma=
ller memory footprint if using many std::bitset&lt;&gt; instances. If I hav=
e an array of 100 std::bitset&lt;8&gt; objects. My proposal would occupy no=
 more than 100 bytes. The current version occupies at least: 900 bytes (100=
 pointers, and 100 bytes pointed too. Possibly more if they simply the impl=
ementation by always storing an array of unsigned longs and a bitmask, but =
900 is the minimum).</div><div><br></div><div>3. Makes the type more useful=
 for systems programming.</div><div><br></div><div>4. it's more efficient! =
No dereferences of memory, and less generally work to do the bit twiddling =
in std::bitset's implementation for the special cases where the underlying =
type is a native size.<br></div><div><br></div><div>I know that library wri=
ters have been free to do this for basically forever and obviously have cho=
sen not to. But it seems to be an obvious optimization. Perhaps they just o=
verlooked it? Or perhaps they just don't find it worth it. Either way, I th=
ink that would be nice to have the standard insist on an efficient implemen=
tation when it's possible to do. It's not a particularly hard specializatio=
n to do, I've made an experimental one myself in the past which worked beau=
tifully if an example is desired.<br></div><div><br></div><div>As a seconda=
ry improvement, I'd love to see std::bitset have first_set_bit() and last_s=
et_bit() members which a particularly clever implementation could implement=
 with O(1) compiler intrinsics when dealing with these "native sized types"=
</div><div><br></div><div>Thoughts?</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_709_3010481.1398283333403--

.

On Apr 23, 2014, at 4:02 PM, Evan Teran <evan.teran@gmail.com> wrote:

> Thoughts?

    std::bitset<65> b65;
    std::cout << sizeof(b65) << "\n";

Howard

--

---
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/.

.

Il giorno 23/apr/2014, alle ore 22:02, Evan Teran <evan.teran@gmail.com> ha scritto:

>
> I noticed the other day that regardless of the number of bits you specify std::bitset (at least GNU's libstdc++ implementation) the size of the type is always the size of a pointer. For example the following code:
>
> //----------------
>
> #include <bitset>
> #include <iostream>
>
> int main() {
>     std::bitset<8> b8;
>     std::bitset<16> b16;
>     std::bitset<32> b32;
>     std::bitset<64> b64;
>     std::cout << sizeof(b8) << "\n";
>     std::cout << sizeof(b16) << "\n";
>     std::cout << sizeof(b32) << "\n";
>     std::cout << sizeof(b64) << "\n";
> }
>
> //----------------
>
> prints:
>
> 8
> 8
> 8
> 8
>
> It seems obvious to me why this is the case. the implementation of std::bitset clearly uses the heap for storage regardless of how many bits you are trying to store. Certainly, this is the simplest implementation. But I think we can do better.
> <cut>
> Thoughts?

If you try sizes greater than 64 you'll see that sizeof() increase accordingly.
Actually, for N up to 64, sizeof(bitset<N>) is always 8 because the GNU implementation
(and LLVM one, too), uses an array of size_t as the storage, so at least 8 bytes are used
if size_t is 64bits (commonly it is).

No heap involved here, and yes, using a bitset<64> is as efficient as a size_t.
I don't know if it's mandated by the standard or not, though...

P.S. Just seen Howard reply, I couldn't be more succint :)

Bye,
Nicola

--

---
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_571_24719016.1398284563237
Content-Type: text/plain; charset=UTF-8

Howard,

I think you may have misunderstood (or I failed to clarify).

For that example, the library would be allowed to fall back on the current
heap based behavior. What I am suggesting is simply a specialization for
sizes that happen to match up with native integer types.

So for you b65, sizeof(b65) would be 8 on my system. because it would be
have a pointer to (at least) 9 bytes of memory. Occupying at a minimum 17
bytes total of RAM. But my proposed b64 specialization would occupy
*precisely* 8 bytes of RAM.

On Wednesday, April 23, 2014 4:15:08 PM UTC-4, Howard Hinnant wrote:
>
> On Apr 23, 2014, at 4:02 PM, Evan Teran <evan....@gmail.com <javascript:>>
> wrote:
>
> > Thoughts?
>
>     std::bitset<65> b65;
>     std::cout << sizeof(b65) << "\n";
>
> Howard
>
>

--

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

<div dir=3D"ltr">Howard,&nbsp;<div><br></div><div>I think you may have misu=
nderstood (or I failed to clarify).</div><div><br></div><div>For that examp=
le, the library would be allowed to fall back on the current heap based beh=
avior. What I am suggesting is simply a specialization for sizes that happe=
n to match up with native integer types.<div><br></div><div>So for you b65,=
 sizeof(b65) would be 8 on my system. because it would be have a pointer to=
 (at least) 9 bytes of memory. Occupying at a minimum 17 bytes total of RAM=
.. But my proposed b64 specialization would occupy *precisely* 8 bytes of RA=
M.<br><br>On Wednesday, April 23, 2014 4:15:08 PM UTC-4, Howard Hinnant wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Apr 23, 2014, at 4:02 PM=
, Evan Teran &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"6_oUubJQ1e0J" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">evan....@gmail.com</a=
>&gt; wrote:
<br>
<br>&gt; Thoughts?
<br>
<br>&nbsp; &nbsp; std::bitset&lt;65&gt; b65;
<br>&nbsp; &nbsp; std::cout &lt;&lt; sizeof(b65) &lt;&lt; "\n";
<br>
<br>Howard
<br>
<br></blockquote></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_571_24719016.1398284563237--

.

On 2014-04-23 16:02, Evan Teran wrote:
> I noticed the other day that regardless of the number of bits you specify
> std::bitset (at least GNU's libstdc++ implementation) the size of the type
> is always the size of a pointer. [...]
>
> It seems obvious to me why this is the case. the implementation of
> std::bitset clearly uses the heap for storage regardless of how many bits
> you are trying to store.

Are you sure? Did you inspect the code? (*My* knee-jerk guess would be
that an inline array of long of suitable size is used. It's
statically-sized after all.)

And in fact, on my machine (using gcc), sizeof(bitset<96>()) is indeed 16...

> Now that <cstdint> is part of c++11. I would love to see the standard
> require the following:
>
> If a given uintN_t type is present, an object of type std::bitset<N> shall
> have a sizeof of precisely N bits and use no heap allocations for storage.

....or uint_fastN_t. I wonder if the heap is really always used, or if
the compiler is just using an inline long because there is little reason
to use a smaller type (and possibly even reason *not* to).

That said, I don't object to the standard specifying inline storage
where possible. I'm much more leery of requiring *minimum adequate*
inline storage, however, as opposed to allowing the implementation to
use a larger-than-strictly-necessary type. (Even if that means you are
still out of luck in memory usage of large quantities - especially e.g.
when packed - of bitset's.)

--
Matthew

--

---
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_743_5975841.1398284972007
Content-Type: text/plain; charset=UTF-8

Good point, I have not inspected the code, but I will in just a moment to
be sure :-).

On Wednesday, April 23, 2014 4:23:43 PM UTC-4, Matthew Woehlke wrote:
>
> On 2014-04-23 16:02, Evan Teran wrote:
> > I noticed the other day that regardless of the number of bits you
> specify
> > std::bitset (at least GNU's libstdc++ implementation) the size of the
> type
> > is always the size of a pointer. [...]
> >
> > It seems obvious to me why this is the case. the implementation of
> > std::bitset clearly uses the heap for storage regardless of how many
> bits
> > you are trying to store.
>
> Are you sure? Did you inspect the code? (*My* knee-jerk guess would be
> that an inline array of long of suitable size is used. It's
> statically-sized after all.)
>
> And in fact, on my machine (using gcc), sizeof(bitset<96>()) is indeed
> 16...
>
> > Now that <cstdint> is part of c++11. I would love to see the standard
> > require the following:
> >
> > If a given uintN_t type is present, an object of type std::bitset<N>
> shall
> > have a sizeof of precisely N bits and use no heap allocations for
> storage.
>
> ...or uint_fastN_t. I wonder if the heap is really always used, or if
> the compiler is just using an inline long because there is little reason
> to use a smaller type (and possibly even reason *not* to).
>
> That said, I don't object to the standard specifying inline storage
> where possible. I'm much more leery of requiring *minimum adequate*
> inline storage, however, as opposed to allowing the implementation to
> use a larger-than-strictly-necessary type. (Even if that means you are
> still out of luck in memory usage of large quantities - especially e.g.
> when packed - of bitset's.)
>
> --
> Matthew
>
>

--

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

<div dir=3D"ltr">Good point, I have not inspected the code, but I will in j=
ust a moment to be sure :-).<br><br>On Wednesday, April 23, 2014 4:23:43 PM=
 UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On 2014-04-23 16:02, Evan Teran wrote:
<br>&gt; I noticed the other day that regardless of the number of bits you =
specify
<br>&gt; std::bitset (at least GNU's libstdc++ implementation) the size of =
the type
<br>&gt; is always the size of a pointer. [...]
<br>&gt;
<br>&gt; It seems obvious to me why this is the case. the implementation of
<br>&gt; std::bitset clearly uses the heap for storage regardless of how ma=
ny bits
<br>&gt; you are trying to store.
<br>
<br>Are you sure? Did you inspect the code? (*My* knee-jerk guess would be=
=20
<br>that an inline array of long of suitable size is used. It's=20
<br>statically-sized after all.)
<br>
<br>And in fact, on my machine (using gcc), sizeof(bitset&lt;96&gt;()) is i=
ndeed 16...
<br>
<br>&gt; Now that &lt;cstdint&gt; is part of c++11. I would love to see the=
 standard
<br>&gt; require the following:
<br>&gt;
<br>&gt; If a given uintN_t type is present, an object of type std::bitset&=
lt;N&gt; shall
<br>&gt; have a sizeof of precisely N bits and use no heap allocations for =
storage.
<br>
<br>...or uint_fastN_t. I wonder if the heap is really always used, or if=
=20
<br>the compiler is just using an inline long because there is little reaso=
n=20
<br>to use a smaller type (and possibly even reason *not* to).
<br>
<br>That said, I don't object to the standard specifying inline storage=20
<br>where possible. I'm much more leery of requiring *minimum adequate*=20
<br>inline storage, however, as opposed to allowing the implementation to=
=20
<br>use a larger-than-strictly-necessary type. (Even if that means you are=
=20
<br>still out of luck in memory usage of large quantities - especially e.g.=
=20
<br>when packed - of bitset's.)
<br>
<br>--=20
<br>Matthew
<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_743_5975841.1398284972007--

.

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

On 23 April 2014 15:02, Evan Teran <evan.teran@gmail.com> wrote:

> It seems obvious to me why this is the case. the implementation of
> std::bitset clearly uses the heap for storage regardless of how many bits
> you are trying to store.
>

Really?  I'm 100% sure that *isn't* the reason.  It would violate the
noexcept specifications on constructors, for a start.

There is usually an embedded array of "words" that holds the bits, and
usually no reason to make it smaller than a word due to alignment
considerations.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr">On 23 April 2014 15:02, Evan Teran <span dir=3D"ltr">&lt;<=
a href=3D"mailto:evan.teran@gmail.com" target=3D"_blank">evan.teran@gmail.c=
om</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 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">It seems obvious to me why this is the case. the implement=
ation of std::bitset clearly uses the heap for storage regardless of how ma=
ny bits you are trying to store. </div></blockquote><div><br></div><div>
Really? =C2=A0I&#39;m 100% sure that *isn&#39;t* the reason. =C2=A0It would=
 violate the noexcept specifications on constructors, for a start.</div>
<div><br></div><div>There is usually an embedded array of &quot;words&quot;=
 that holds the bits, and usually no reason to make it smaller than a word =
due to alignment considerations.</div></div>-- <br>=C2=A0Nevin &quot;:-)&qu=
ot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</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 />

--f46d043c7ffeebc84404f7bba11c--

.

------=_Part_515_8046299.1398285431219
Content-Type: text/plain; charset=UTF-8

My implementation appears to do the following for all cases:


      typedef unsigned long _WordT;
      _WordT _M_w[_Nw];

So I was wrong in my assumption of it being heap allocated. But it
definitely allocates in multiples of sizeof(unsigned long). I would still
argue that for native types, it would be possibly be more efficient to
special case them. Additionally, I would love to see that bitset<8> is just
as space efficient as uint8_t :-).

On Wednesday, April 23, 2014 4:29:31 PM UTC-4, Evan Teran wrote:
>
> Good point, I have not inspected the code, but I will in just a moment to
> be sure :-).
>
> On Wednesday, April 23, 2014 4:23:43 PM UTC-4, Matthew Woehlke wrote:
>>
>> On 2014-04-23 16:02, Evan Teran wrote:
>> > I noticed the other day that regardless of the number of bits you
>> specify
>> > std::bitset (at least GNU's libstdc++ implementation) the size of the
>> type
>> > is always the size of a pointer. [...]
>> >
>> > It seems obvious to me why this is the case. the implementation of
>> > std::bitset clearly uses the heap for storage regardless of how many
>> bits
>> > you are trying to store.
>>
>> Are you sure? Did you inspect the code? (*My* knee-jerk guess would be
>> that an inline array of long of suitable size is used. It's
>> statically-sized after all.)
>>
>> And in fact, on my machine (using gcc), sizeof(bitset<96>()) is indeed
>> 16...
>>
>> > Now that <cstdint> is part of c++11. I would love to see the standard
>> > require the following:
>> >
>> > If a given uintN_t type is present, an object of type std::bitset<N>
>> shall
>> > have a sizeof of precisely N bits and use no heap allocations for
>> storage.
>>
>> ...or uint_fastN_t. I wonder if the heap is really always used, or if
>> the compiler is just using an inline long because there is little reason
>> to use a smaller type (and possibly even reason *not* to).
>>
>> That said, I don't object to the standard specifying inline storage
>> where possible. I'm much more leery of requiring *minimum adequate*
>> inline storage, however, as opposed to allowing the implementation to
>> use a larger-than-strictly-necessary type. (Even if that means you are
>> still out of luck in memory usage of large quantities - especially e.g.
>> when packed - of bitset's.)
>>
>> --
>> Matthew
>>
>>

--

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

<div dir=3D"ltr">My implementation appears to do the following for all case=
s:<div><br></div><div><br></div><div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbs=
p; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
typedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">long</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> _WordT</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; _WordT _M_w</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">_Nw</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">];</span></div></code></div>=
<div><br>So I was wrong in my assumption of it being heap allocated. But it=
 definitely allocates in multiples of sizeof(unsigned long). I would still =
argue that for native types, it would be possibly be more efficient to spec=
ial case them. Additionally, I would love to see that bitset&lt;8&gt; is ju=
st as space efficient as uint8_t :-).</div><br>On Wednesday, April 23, 2014=
 4:29:31 PM UTC-4, Evan Teran wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">Good point, I have not inspected the code, but I wil=
l in just a moment to be sure :-).<br><br>On Wednesday, April 23, 2014 4:23=
:43 PM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On 2014-04-23 16:02, Evan Teran wrote:
<br>&gt; I noticed the other day that regardless of the number of bits you =
specify
<br>&gt; std::bitset (at least GNU's libstdc++ implementation) the size of =
the type
<br>&gt; is always the size of a pointer. [...]
<br>&gt;
<br>&gt; It seems obvious to me why this is the case. the implementation of
<br>&gt; std::bitset clearly uses the heap for storage regardless of how ma=
ny bits
<br>&gt; you are trying to store.
<br>
<br>Are you sure? Did you inspect the code? (*My* knee-jerk guess would be=
=20
<br>that an inline array of long of suitable size is used. It's=20
<br>statically-sized after all.)
<br>
<br>And in fact, on my machine (using gcc), sizeof(bitset&lt;96&gt;()) is i=
ndeed 16...
<br>
<br>&gt; Now that &lt;cstdint&gt; is part of c++11. I would love to see the=
 standard
<br>&gt; require the following:
<br>&gt;
<br>&gt; If a given uintN_t type is present, an object of type std::bitset&=
lt;N&gt; shall
<br>&gt; have a sizeof of precisely N bits and use no heap allocations for =
storage.
<br>
<br>...or uint_fastN_t. I wonder if the heap is really always used, or if=
=20
<br>the compiler is just using an inline long because there is little reaso=
n=20
<br>to use a smaller type (and possibly even reason *not* to).
<br>
<br>That said, I don't object to the standard specifying inline storage=20
<br>where possible. I'm much more leery of requiring *minimum adequate*=20
<br>inline storage, however, as opposed to allowing the implementation to=
=20
<br>use a larger-than-strictly-necessary type. (Even if that means you are=
=20
<br>still out of luck in memory usage of large quantities - especially e.g.=
=20
<br>when packed - of bitset's.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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_515_8046299.1398285431219--

.

------=_Part_1593_8433424.1398364728709
Content-Type: text/plain; charset=UTF-8

On Wednesday, April 23, 2014 10:31:54 PM UTC+2, Nevin ":-)" Liber wrote:
>
> On 23 April 2014 15:02, Evan Teran <evan....@gmail.com <javascript:>>wrote:
>
>> It seems obvious to me why this is the case. the implementation of
>> std::bitset clearly uses the heap for storage regardless of how many bits
>> you are trying to store.
>>
>
> Really?  I'm 100% sure that *isn't* the reason.  It would violate the
> noexcept specifications on constructors, for a start.
>
> There is usually an embedded array of "words" that holds the bits, and
> usually no reason to make it smaller than a word due to alignment
> considerations.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

What would be nice though are separate specializations for std::bitset<N>
if N is a multiple the number of bits in the word type. This would avoid
the needless bit-shaving that is done in the operator<< and operator>>.
 IIRC, both libstdc++ and libc++ only specialize for the case of a single
word, but not for multiple words.

--

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

<div dir=3D"ltr">On Wednesday, April 23, 2014 10:31:54 PM UTC+2, Nevin ":-)=
" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On 23 April 2014 15:02, Evan Teran <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WT4zyTHtjU0J" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">evan....@gmail.com</a>&gt;</span> wrote:<br><div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">It seems obvious to me why this is the case. the implement=
ation of std::bitset clearly uses the heap for storage regardless of how ma=
ny bits you are trying to store. </div></blockquote><div><br></div><div>
Really? &nbsp;I'm 100% sure that *isn't* the reason. &nbsp;It would violate=
 the noexcept specifications on constructors, for a start.</div>
<div><br></div><div>There is usually an embedded array of "words" that hold=
s the bits, and usually no reason to make it smaller than a word due to ali=
gnment considerations.</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;=
mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W=
T4zyTHtjU0J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a><wbr>=
&gt;&nbsp; (847) 691-1404</div></div></blockquote><div><br></div><div>What =
would be nice though are separate specializations for std::bitset&lt;N&gt; =
if N is a multiple the number of bits in the word type. This would avoid th=
e needless bit-shaving that is done in the operator&lt;&lt; and operator&gt=
;&gt;. &nbsp;IIRC, both libstdc++ and libc++ only specialize for the case o=
f a single word, but not for multiple words.&nbsp;</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_1593_8433424.1398364728709--

.

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

On Thu, Apr 24, 2014 at 11:38 AM, <rhalbersma@gmail.com> wrote:

> On Wednesday, April 23, 2014 10:31:54 PM UTC+2, Nevin ":-)" Liber wrote:
>>
>> On 23 April 2014 15:02, Evan Teran <evan....@gmail.com> wrote:
>>
>>> It seems obvious to me why this is the case. the implementation of
>>> std::bitset clearly uses the heap for storage regardless of how many bits
>>> you are trying to store.
>>>
>>
>> Really?  I'm 100% sure that *isn't* the reason.  It would violate the
>> noexcept specifications on constructors, for a start.
>>
>> There is usually an embedded array of "words" that holds the bits, and
>> usually no reason to make it smaller than a word due to alignment
>> considerations.
>> --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404
>>
>
> What would be nice though are separate specializations for std::bitset<N>
> if N is a multiple the number of bits in the word type. This would avoid
> the needless bit-shaving that is done in the operator<< and operator>>.
>  IIRC, both libstdc++ and libc++ only specialize for the case of a single
> word, but not for multiple words.
>

This seems like a quality-of-implementation issue; I don't see any need for
the standard to address it.

>  --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Apr 24, 2014 at 11:38 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:=
rhalbersma@gmail.com" target=3D"_blank">rhalbersma@gmail.com</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, April 23, 201=
4 10:31:54 PM UTC+2, Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"">On 23 April 2014 15:02, Evan Teran <span d=
ir=3D"ltr">&lt;<a>evan....@gmail.com</a>&gt;</span> wrote:<br></div><div><d=
iv class=3D""><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir=3D"ltr">It seems obvious to me why this is the case. the implement=
ation of std::bitset clearly uses the heap for storage regardless of how ma=
ny bits you are trying to store. </div></blockquote><div><br></div><div>

Really? =C2=A0I&#39;m 100% sure that *isn&#39;t* the reason. =C2=A0It would=
 violate the noexcept specifications on constructors, for a start.</div>
<div><br></div><div>There is usually an embedded array of &quot;words&quot;=
 that holds the bits, and usually no reason to make it smaller than a word =
due to alignment considerations.</div></div>-- <br></div>=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a>ne...@eviloverlord.com</a><u></u>&gt;=
=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a></div>
</div></blockquote><div><br></div><div>What would be nice though are separa=
te specializations for std::bitset&lt;N&gt; if N is a multiple the number o=
f bits in the word type. This would avoid the needless bit-shaving that is =
done in the operator&lt;&lt; and operator&gt;&gt;. =C2=A0IIRC, both libstdc=
++ and libc++ only specialize for the case of a single word, but not for mu=
ltiple words.=C2=A0</div>
</div></blockquote><div><br></div><div>This seems like a quality-of-impleme=
ntation issue; I don&#39;t see any need for the standard to address it.=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<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></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 />

--047d7bdc84c422ad9b04f7d0dcd2--

.

Em qua 23 abr 2014, =C3=A0s 13:37:11, Evan Teran escreveu:
> So I was wrong in my assumption of it being heap allocated. But it=20
> definitely allocates in multiples of sizeof(unsigned long). I would still=
=20
> argue that for native types, it would be possibly be more efficient to=20
> special case them. Additionally, I would love to see that bitset<8> is ju=
st=20
> as space efficient as uint8_t :-).

Who says it's more efficient?

If you qualify as "space efficient" like you did in the last sentence, then=
 yes,=20
it is. But a generic "efficient" isn't a necessity. There could be a platfo=
rm in=20
which the processor provides bit manipulation instructions but they operate=
 on=20
quantities larger than 1 byte.

Like, for example, x86. From the Intel Software Developers Manual about=20
instruction "BT - Bit Test"

  When accessing a bit in memory, the processor may access 4 bytes starting=
=20
  from the memory address for a 32-bit operand size, using by the following=
=20
  relationship:
        Effective Address + (4 =E2=88=97 (BitOffset DIV 32))

--=20
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

--=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_124_4567994.1398434059750
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


You make a fair point. So I can certainly agree that this is a quality of=
=20
implementation issue and not something that should be mandated by the=20
standard.

As a modification to the original concept, perhaps there could be a new=20
template parameter which would allow the user to specify favoring space=20
efficiency or not?=20

something like:

bitset<8, compact> bs8;

It would of course be optional and default to allowing the implementation=
=20
to decide.



On Thursday, April 24, 2014 6:16:32 PM UTC-4, Thiago Macieira wrote:
>
> =20
>
Who says it's more efficient?=20
>
> If you qualify as "space efficient" like you did in the last sentence,=20
> then yes,=20
> it is. But a generic "efficient" isn't a necessity. There could be a=20
> platform in=20
> which the processor provides bit manipulation instructions but they=20
> operate on=20
> quantities larger than 1 byte.=20
>
> Like, for example, x86. From the Intel Software Developers Manual about=
=20
> instruction "BT - Bit Test"=20
>
>   When accessing a bit in memory, the processor may access 4 bytes=20
> starting=20
>   from the memory address for a 32-bit operand size, using by the=20
> following=20
>   relationship:=20
>         Effective Address + (4 =E2=88=97 (BitOffset DIV 32))=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

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

<div dir=3D"ltr"><div><br></div>You make a fair point. So I can certainly a=
gree that this is a quality of implementation issue and not something that =
should be mandated by the standard.<div><br></div><div>As a modification to=
 the original concept, perhaps there could be a new template parameter whic=
h would allow the user to specify favoring space efficiency or not?&nbsp;</=
div><div><br></div><div>something like:</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px=
 solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">bitset</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">8</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> compact</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> bs8</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code></di=
v><br></div><div>It would of course be optional and default to allowing the=
 implementation to decide.<br></div><div><br></div><div><br></div><div><br>=
On Thursday, April 24, 2014 6:16:32 PM UTC-4, Thiago Macieira wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">&nbsp;<br></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">Who says it's more efficient?
<br>
<br>If you qualify as "space efficient" like you did in the last sentence, =
then yes,=20
<br>it is. But a generic "efficient" isn't a necessity. There could be a pl=
atform in=20
<br>which the processor provides bit manipulation instructions but they ope=
rate on=20
<br>quantities larger than 1 byte.
<br>
<br>Like, for example, x86. From the Intel Software Developers Manual about=
=20
<br>instruction "BT - Bit Test"
<br>
<br>&nbsp; When accessing a bit in memory, the processor may access 4 bytes=
 starting=20
<br>&nbsp; from the memory address for a 32-bit operand size, using by the =
following=20
<br>&nbsp; relationship:
<br>&nbsp; &nbsp; &nbsp; &nbsp; Effective Address + (4 =E2=88=97 (BitOffset=
 DIV 32))
<br>
<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_124_4567994.1398434059750--

.

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

On 25 April 2014 08:54, Evan Teran <evan.teran@gmail.com> wrote:

>
> As a modification to the original concept, perhaps there could be a new
> template parameter which would allow the user to specify favoring space
> efficiency or not?
>

Adding a template parameter to an existing template is a breaking change
and extremely unlikely to happen for such a minor use case.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr">On 25 April 2014 08:54, Evan Teran <span dir=3D"ltr">&lt;<=
a href=3D"mailto:evan.teran@gmail.com" target=3D"_blank">evan.teran@gmail.c=
om</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 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><br></div><div>As a modification to the original conc=
ept, perhaps there could be a new template parameter which would allow the =
user to specify favoring space efficiency or not?=C2=A0</div></div></blockq=
uote>

<div><br></div><div>Adding a template parameter to an existing template is =
a breaking change and extremely unlikely to happen for such a minor use cas=
e.</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;=C2=A0 (847) 691-1404
</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 />

--e89a8f3baa07191af904f7dead6d--

.

--Apple-Mail=_3AFE8F81-B871-43F6-9DAB-1793539F6B23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-04-25, at 9:54 PM, Evan Teran <evan.teran@gmail.com> wrote:

>=20
> bitset<8, compact> bs8;
>=20
> It would of course be optional and default to allowing the implementation=
 to decide.

Is there ever any reason not to "compact"? I think it's just implementation=
 effort.

Some libraries may resist or at least postpone such an improvement because =
any change to class layout is a change to the application ABI, causing DLLs=
 to be mutually incompatible. But, the best way forward is to contribute a =
patch to your library of choice.

--=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=_3AFE8F81-B871-43F6-9DAB-1793539F6B23
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"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2=
014&ndash;04&ndash;25, at 9:54 PM, Evan Teran &lt;<a href=3D"mailto:evan.te=
ran@gmail.com">evan.teran@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></=
div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word; positi=
on: static; z-index: auto;"><code class=3D"prettyprint">bitset<span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">8</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span> compact<span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span> bs8<span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span></code></div><br></div><div>It would o=
f course be optional and default to allowing the implementation to decide.<=
br></div></div></blockquote><div><br></div></div>Is there ever any reason n=
ot to &ldquo;compact&rdquo;? I think it&rsquo;s just implementation effort.=
<div><br></div><div>Some libraries may resist or at least postpone such an =
improvement because any change to class layout is a change to the applicati=
on ABI, causing DLLs to be mutually incompatible. But, the best way forward=
 is to contribute a patch to your library of choice.</div><div><br></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=_3AFE8F81-B871-43F6-9DAB-1793539F6B23--

.

On 2014-04-25 23:22, David Krauss wrote:
> On 2014-04-25, at 9:54 PM, Evan Teran wrote:
>> bitset<8, compact> bs8;
>>
>> It would of course be optional and default to allowing the implementation to decide.
>
> Is there ever any reason not to "compact"? I think it's just implementation effort.

If compacting does not reduce the alignment requirement, there is no
reason to compact. If it does, you're likely to see a performance impact
from your reads/writes being unaligned and smaller than word size.
(Especially on platforms that SIGBUS, where your implementation must now
explicitly use different instructions, or at worst implement alignment
adjusting itself.)

IOW, compacting (assuming it reduces alignment) is a space efficiency
versus performance trade-off.

--
Matthew

--

---
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/.

.

Em s=E1b 26 abr 2014, =E0s 11:22:59, David Krauss escreveu:
> > It would of course be optional and default to allowing the implementati=
on
> > to decide.
> Is there ever any reason not to "compact"? I think it's just implementati=
on
> effort.

See my email Evan replied to. The reason not to compact is performance=20
efficiency, like alignments and use of bit manipulation instructions that=
=20
operate on quantities larger than bytes.

--=20
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

--=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/.

.