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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk