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