Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-07-01 05:16:22

On Jun 30, 2013, at 12:14 PM, Paul Long <plong_at_[hidden]> wrote:

> 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?"

A CP is a template your code uses, to effect some desired behavior, that users specialize to control your code. Thus, you could call a static member function of a class template to determine how to convert a type. The primary specialization, for supported types, invokes your bitstream functionality, and is not implemented for unsupported/unknown types. Thus, there is no support for such types built into the library. Users can specialize the CP for their type to use, say, insertion into an ostringstream and then use your string support for insertion into a bitstream.

>>> 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.

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, then 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 code.

___
Rob

(Sent from my portable computation engine)