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

On Sat, Jan 24, 2015 at 11:13 AM, Olaf van der Spek wrote:

On Sat, Jan 24, 2015 at 5:04 PM, Peter Dimov wrote:

...

Olaf van der Spek wrote:

...

On Sat, Jan 24, 2015 at 3:54 PM, Beman Dawes 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