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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-06-05 15:59:26

Beman Dawes wrote:
> A refresh of the .zip file for the Endian library, based on comments 
> received so far, is available at 
> http://mysite.verizon.net/~beman/endian-0.2.zip
> 
> The docs are online at 
> http://mysite.verizon.net/~beman/endian-0.2/libs/endian/index.html

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.

Maybe this time I did a better job of convincing...

Other stuff:

- I think that using bits numbering is better than bytes, because a) 
uniformity with the types in <cstdint> is *very* important, IMO and b) 
as some noted, the size of a char is not necessarily 8 bits (so help me 
God if I understand why this is more useful than harmful), so bits 
numbering is less ambiguous than bytes (and maybe this is the reason why 
it was chosen to be used in <cstdint>). Actually, it just occurred to me 
that if portability between different platforms (with different 
CHAR_BITS) is our main concern here, then it *must* be bits, isn't it?

- 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_'?).

- 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 hope this post didn't sound too criticizing. That's not what I meant. 
I only wanted to thank you a lot for putting the effort of writing it, 
and present my humble comments.

Yuval