Re: [boost] [dynamic_bitset] Endianess and Adaption Vs Copying

Subject: Re: [boost] [dynamic_bitset] Endianess and Adaption Vs Copying
From: Joel (jdy_at_[hidden])
Date: 2012-05-03 19:46:56

Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:

> Perhaps you could post a short example of some code that you think 
> would fail?

If a C library created an internal bit vector  where the bits were packed
tightly and in order from left-to-right (low memory to high memory),
dynamic_bitset would be able to correctly map the vector on a big-endian machine
but would mess it up on a little-endian machine.

The order that the bits are packed is completely arbitrary.  This library
has chosen to pack the bits from least-significant to most-significant within
blocks and left-to-right across blocks.

> I was a bit surprised to find that it has this:
> 
> template <typename Block>
> class dynamic_bitset {
>    template <typename BlockInputIter>
>    dynamic_bitset(BlockInputIter first, BlockInputIter last) { ...
 
That didn't surprise me, other than I wish it had a comment giving the 
expected bit-ordering.

> So you can do this:
> 
> const char* data = ......;  // From a "platform independent" binary file.
> dynamic_bitset<unsigned int>  b(data,data+size);

Should be 
  const uint32_t data = .....; in that case!

> 
> Joel say:
> > At minimum, the bit-ordering imposed by dynamic-bitset should be 
> > explicitly documented.
> 
> The BIT ordering?  No, bit ordering is always the same.  You never need 
> to re-order the bits within a byte.
> 
> (What am I missing?)

Bit ordering is completely arbitrary.  If the constructor for reference in
dynamic_bitset.hpp is changed from:

        // the one and only non-copy ctor
        reference(block_type & b, block_type pos)
            :m_block(b),
             m_mask( (assert(pos < bits_per_block),
                      block_type(1) << pos )
                   )
        { }

to:

        // the one and only non-copy ctor
        reference(block_type & b, block_type pos)
            :m_block(b),
             m_mask( (assert(pos < bits_per_block),
                      ((block_type(1) << (bits_per_block-1)) >> pos ))
                   )
        { }

and the ordering would be reversed.  Now on little-endian machines, the ordering
nicely goes always left-to-right.

Joel