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

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-02-09 08:40:29

On Tue, Feb 3, 2015 at 6:25 PM, Rob Stewart <rob.stewart_at_[hidden]> wrote:
> One thing that is not clear is why both the buffer and arithmetic types exist. The one, of course, derives from the other, so the only benefit would be the omission of what the derivate adds. What does one gain by using the buffer class rather than just always using the arithmetic type? IOW, why not just collapse the hierarchy?

I've added these two entries to the overall FAQ:

Why do both the buffer and arithmetic types exist?

Conversions in the buffer types are explicit. Conversions in the
arithmetic types are implicit. This fundamental difference is a
deliberate design feature that would be lost if the inheritance
hierarchy were collapsed.

The original design provided only arithmetic types. Buffer types were
requested during formal review by those wishing total control over
when conversion occurs. They also felt that buffer types would be less
likely to be misused by maintenance programmers not familiar with the
implications of performing a lot of arithmetic operations on the
endian arithmetic types.

What is gained by using the buffer types rather than always just using
the arithmetic types?

Assurance than hidden conversions are not performed. This is of
overriding importance to users concerned about achieving the ultimate
in terms of speed.

"Always just using the arithmetic types" is fine for other users. When
the ultimate in speed needs to be ensured, the arithmetic types can be
used in the same design patterns or idioms that would be used for
buffer types, resulting in the same code being generated for either
types.

Thanks,

--Beman