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

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Olaf van der Spek (ml_at_[hidden])
Date: 2015-01-27 03:41:20

On Mon, Jan 26, 2015 at 11:14 PM, Peter Dimov <lists_at_[hidden]> wrote:
> Olaf van der Spek wrote:
>
>> Isn't overflow more like a logic error than a runtime error? An assert
>> might make more sense.
>
>
> It typically happens in a portion of the code that can already throw because
> it deals with output to file. And if it were an assert, what would you do to
> avoid it?

On input ensure the destination (type) is large enough to hold all
values and on output ensure the value to be written isn't too large.

> The same the library would do, check the value and throw if it
> doesn't fit. So the library just does for you what you'd have done anyway,
> as a convenience.
>
> As a more practical matter, users don't tend to like asserts when saving,
> even if this would have been the theoretically sound thing to do. :-)

Users don't like bugs in general.

> (For the reverse operation, where the bits are more than the value type can
> represent, assert doesn't seem to make sense either because we don't control
> the bits, which typically come from an external source.)

But we do control the destination type.

> In all this I'm assuming the buffer types, BTW. I'm not sure if the same
> logic would apply to the arithmetic types, because they have very different
> use cases. Buffers are relatively straightforward - the bits are read from
> file and the value is extracted, or the value is stored and the bits are
> written - so it's easier to reason about the context in which they are used.
> Arithmetics should probably just do on overflow whatever the underlying type
> does.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
Olaf