me22 wrote:
On 6/5/06, 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'? Very unintuitive... What I'm suggesting is exactly what I suggested before (and obviously failed to convince): There should be a set of Integer types for various sizes/alignments, which could be used without any relation to endianness (which probably means native endianness, just as using a simple 'int' or 'uint32_t' means native endianness). These types could then be wrapped in a big_endian or little_endian class, if the arbitrary native endianness is not desired.
I like that approach as well.
Unaligned native-endian arbitrary-sized integer types is what my exact.hpp header from the previous thread implemented. I'll try and implement the big_endian and little_endian wrappers for comparison purposes.
If this approach is accepted, then it means that we can debate about the arbitrary-sized/arbitrary-aligned types without any relation to the endianness, as the xxx_endian are just wrappers that are relevant only when they are relevant. Boost.Integer then needs to be extended to support unaligned types (it already has aligned types). I'm repeating all this (without saying anything new) because it's relevant to my answer to the next paragraph...
- 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 think it could be common to have many of these types in a header one after another and not wanting any padding between the members, so unaligned should remain the default.
Additionally, aligned can only be provided when there are fundamental integral types of the requested size, so having them be special in some way is probably good.
... so Boost.Integer's int32_t is aligned, period. If we want to create a new unaligned 32-bit type, it must be named something else. The non-prefixed names are already taken by the aligned types in <cstdint>... Of course we can come up with a whole new system of naming, just to bypass the names already taken, but I think that (according to the previous paragraph) the right way to go is extending Boost.Integer with unaligned types, because that's where it should go...
- Having an enum with values such as 'big', 'aligned_big', 'little', 'aligned_little', etc, just cries for separation. The enum should have only 'big' and 'little', and the endian template can accept one more template argument - 'bool aligned'.
I'm unsure whether or not the separation would be advantageous, but for readability I'd much prefer an aligned/unaligned enum over true/false.
No problem for me with an aligned/unaligned enum. Yuval