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 = u;
>> networkByteOrder = u >> CHAR_BIT;
>> networkByteOrder = u >> CHAR_BIT * 2;
>> networkByteOrder = 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 = u;
networkByteOrder = u >> CHAR_BIT;
networkByteOrder = u >> CHAR_BIT * 2;
networkByteOrder = 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk