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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-06-06 02:00:11

me22 wrote:
> 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.

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