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

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-25 11:53:28

On Sat, Jan 24, 2015 at 11:13 AM, Olaf van der Spek <ml_at_[hidden]> wrote:
> On Sat, Jan 24, 2015 at 5:04 PM, Peter Dimov <lists_at_[hidden]> wrote:
>> Olaf van der Spek wrote:
>>>
>>> On Sat, Jan 24, 2015 at 3:54 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
>>> >    struct
>>> >    {
>>> >        big_int32_buf_t code;
>>> >        big_uint32_buf_t length;
>>> >        little_int16_buf_t version;
>>> >        big_int32_buf_ut shape_type;
>>> >    } data;
>>>
>>> You're mixing aligned and unaligned types. Shouldn't all be unaligned? See
>>> the docs: "Warning: Code that uses aligned types is possibly non-portable
>>> because alignment requirements vary between hardware architectures and
>>> because alignment may be affected by compiler switches or pragmas. For
>>> example, alignment of an 64-bit integer may be to a 32-bit boundary on a
>>> 32-bit machine. Furthermore, aligned types are only available on
>>> architectures with 16, 32, and 64-bit integer types."
>>
>>
>> Yes, a good argument against having aligned buffers at all, even though the
>> docs do provide rationale for them. If you want aligned, use the non-buffer
>> types.
>
> I think the default / shortest name types should be unaligned, with
> aligned access being explicit.

I thought that at one time, too, and the names were as you suggest.

There were several problems with defaulting to unaligned and thus
having longer names for aligned types.

1) Real-world applications use aligned data layouts far more often
than unaligned. Users prefer that defaults meet the most common needs.

 2) If the default is unaligned, unaligned types will get used
inadvertently where aligned types could be used, and that can cause
performance problems. Remember that the familiar <cstdint> types (e.g.
int16_t, int32_t) are aligned types. It is natural to assume
big_int32_t is an aligned type.

Thanks,

--Beman