Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Paul Long (plong_at_[hidden])
Date: 2013-06-29 22:49:02

On 6/29/2013 10:12 AM, Rob Stewart wrote:
> I suspect that Mathias is assuming ibitstream derives from istream, so 
> there would be issues selecting the right extraction overload for a UDT. 

ibitstream does not derive from istream. I wanted to but found that 
istream is not sufficiently abstract--it is intentionally and 
specifically a character-streaming class. I just couldn't make it work 
for bit streaming. I could have another look at it, though.

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

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

Paul