Hi Yuval, Yuval Ronen <ronen_yuval@yahoo.com> wrote:
I see that enum endianness have a 'native' option. This looks a bit weird to me. If I want to use native endianness, why should I use a class named 'endian'?
You might be writing code that cares about endianness, and need to use native endianness in some places, and big- or little-endian integers in others. One example is receiver makes right protocols, where the message is always transmitted using the sender's endianness. When a message is received it could be either big- or little-endian.
- Is aligned more common than unaligned, or vice-versa? It sounds logical to me, that since the POD integers types (int and friends) are aligned, it should also be the 'default' behavior of any class mimicking them, including of course, the endian class. The conclusion is that instead of prefixing 'a' or 'aligned_' to the aligned types, the unaligned types should get a prefix ('unaligned_'?).
I had a think about this too, and came to the opposite conclusion that unaligned is the sensible default. The purpose of these classes is manipulating records for I/O, not mimicking in memory structures. IMHO defining a structure that uses the aligned endian types (slightly) increases code fragility due to the effect of compiler alignment options on the layout, and so should not be given equal billing. Since the stated motivation for supporting aligned types is performance, you'd have specific reasons for choosing them and be more likely to be careful about using them correctly. Cheers, Chris