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