Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-06-30 07:25:35

On Jun 29, 2013, at 10:49 PM, Paul Long <plong_at_[hidden]> wrote:

> On 6/29/2013 10:12 AM, Rob Stewart wrote:
> 
>> If you derive from the standard library types, then the text based operators can also apply. In that case, any bitstream overload not provided for a UDT will imply use of the text based operator instead. That would mean silently getting text based encoding.
> 
> Yeah, I understand. That would be nice.

Maybe. Text-based encodings are not necessarily reversible and the are inefficient. I was actually thinking that the silent fallback was a problem. OTOH, explicitly reusing a text-based operator, via a customization point, might work well.

>> Surely you're doing host to network swaps. That means you assume input and output in host order, and transmission in network order. That fits "translation" well enough I think.
> 
> No, ibistream does not do that. As an example, given the definitions,
> 
> 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;
> 
> 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.

___
Rob

(Sent from my portable computation engine)