Re: [boost] [Review] Boost.Endian mini-review

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-26 07:24:19

On Sat, Jan 24, 2015 at 3:03 PM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 24 January 2015 at 12:00, Beman Dawes <bdawes_at_[hidden]> wrote:
>
>> In practice, the enhanced efficiency of aligned types is usually more
>> important than worry about someday encountering an odd-ball
>> architecture or use in an unaligned location.
>>
>
> I disagree with that for endian.  Most of those uses are in wire and file
> protocols, and they are either densely packed or based on the alignment of
> the original architecture that the protocol was developed on.

I agree with you that a lot of uses are for legacy formats, but my
experience has been that most of those observe 16 and 32-bit alignment
rules that are the same as we need today. 64-bit values may be a
different story - I have virtually no experience with legacy formats
that use 64-bit data.

But regardless, the endian library must support both aligned and
unaligned. I'm warming to Jeremy Maitin-Shepard's suggestion in a
later post that we use explicit names for both aligned and unaligned
types.

>  Unless one
> is transferring data between machines with different architectures, why
> would one use endian at all?

Most of us write programs for little-endian architectures that deal
with big endian wire and file formats.

Thanks,

--Beman