Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Paul Long (plong_at_[hidden])
Date: 2013-06-30 12:14:27

On 6/30/2013 6:25 AM, Rob Stewart wrote:
> ... explicitly reusing a text-based operator, via a customization 
> point, might work well. 

I don't understand. What's a "customization point?"

>> uint32_t u;
>> char networkByteOrder[sizeof u];
>>
>> ...this would not be portable:
>>
>> memcpy(networkByteOrder, &u, sizeof networkByteOrder);
>>
>> ...but this would:
>>
>> networkByteOrder[0] = u;
>> networkByteOrder[1] = u >> CHAR_BIT;
>> networkByteOrder[2] = u >> CHAR_BIT * 2;
>> networkByteOrder[3] = u >> CHAR_BIT * 3;

I realized, laying in bed this morning, that I made a mistake. _This_ would produce network byte order, or big endian:

networkByteOrder[3] = u;
networkByteOrder[2] = u >> CHAR_BIT;
networkByteOrder[1] = u >> CHAR_BIT * 2;
networkByteOrder[0] = u >> CHAR_BIT * 3;

>> ibitstream does not do this specific thing, but it shows how one can write portable code without regard to platform endianess. Therefore, ibitstream does not "translate," at least IMO.
> If you do the same thing on all platforms, then you have no portability. If you do that only on little endian platforms, then you've reinvented the network/host byte ordering mechanism. If something else, then I don't understand you.

Unless you're referring to my mistake, this should be portable because integrals are operated on as _values_, not according their representation in memory. It's only when one aliases them as a char array that their representation, e.g., endianess, becomes relevant.

Paul