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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-08 14:17:22

Yuval Ronen wrote:
> 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
> 
>... 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).

What I'm missing is the motivation. Other than for endian I/O, I'm not 
able to visualize any need for integers of various sizes/alignments 
beyond those already provided by <cstdint>.

In any case, such types would seem to fit better into an integer library 
than a library providing endian byte-holders.

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

I need motivating use cases or applications rather than just hearing 
that "there should be [such types]".

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

<cstdint> is about integers, where the number of bits is critical, even 
if not exactly a certain number of bytes.

<boost/endian.hpp> is about endian byte-holders, where the number of 
bytes is critical, even if not exactly matching the architecture's 
integer number of bits.

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

CHAR_BITS is fixed at 8. It never varies.

It really sounds like your concern is applications involving integers, 
and an endian class is the wrong tool to solve your problem. Is that 
possibly the case?

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

Unaligned (including the very common sub-cases of aligned by 
happenstance, careful placement, or padding) covers the vast majority of 
the uses in my experience. Forced alignment is a (somewhat dangerous) 
optimization that I would not recommend except to endian experts who 
understand the risks involved.

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

My initial implementation did have an additional template argument, 
taking an enum:

   enum alignment { unaligned, aligned };

But having an additional argument meant that defaulting didn't work 
well. It is nice to be able to default the lengths for 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.

Not at all. The whole point of posting preliminary versions is to get 
feedback.

Thanks,

--Beman