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