Subject: Re: [boost] Any interest in bitstream class?
From: Paul Long (plong_at_[hidden])
Date: 2013-07-01 12:16:02
On Mon, 1 Jul 2013 05:16:22 -0400, Rob Stewart wrote:
> On Jun 30, 2013, at 12:14 PM, Paul Long <plong_at_[hidden]> wrote:
>>>> uint32_t u;
>>>> char networkByteOrder[sizeof u];
>> 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.
> You are aliasing a value as a char array, so you are relying on the
> endianness, and if you do that for every value on every platform,
> the bitstream's order depends upon the endianness of the host that
> creates it and isn't portable.
> If you only do such things on little endian hosts, and not on big
> endian hosts, then you're doing the normal host->network->host order
> swaps of network communications, albeit with your own reordering
I'm still not sure what you mean. I wrote encode and decode functions
on http://codepad.org/nml6RjX5 which apparently runs on a big-endian
platform. Maybe that'll help our understanding.
I'm saying that, using this technique, one can write portable
code--without the hton family of functions--that makes no assumptions
about the underlying endianess of the platform. Of course, one will have
to choose an endianess of the encoding. In this example, I have chosen
big endian. Is that what you're concerned about--that any decoder will
have to know the endianess of the encoded value and therefore it must
"translate?" I agree that a decoder will have to know the endianess of
the encoded value, but it does not need to know the endianess of the
platform on which it is running; see my decode function on
As an aside, I bet there is a dichotomy of developers. Some, like me,
mostly write code that supports a standardized encoding or protocol, in
which the endianess is prescribed. Others are just interested in
communicating data between proprietary entities and don't much care what
endian is used, so it might as well be the endian of one and hopefully
all of the platforms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk