Re: [boost] [endian] Refresh based on comments received

From: me22 (me22.ca_at_[hidden])
Date: 2006-06-05 16:37:33

On 6/5/06, Yuval Ronen <ronen_yuval_at_[hidden]> 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.

> - 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.

> - 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.

~ Scott McMurray