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