Boost logo

Boost :

Subject: Re: [boost] [safe_numerics] review
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-11 22:56:25

Robert Ramey wrote:

> BTW - when are we going to a comments form Peter Dimov?

I read the documentation, and here are some comments on that:

- there is an example that explains that safe<long> is not implicitly
convertible to int, even though long is. I think that it should be, subject
to the usual constraint that the value can be represented in an int.

- that safe_signed_range and safe_unsigned_range have a default policy of
native seems wrong to me. The point of these classes is to represent, well,
ranges, and arithmetic by default (if not always) should produce the
appropriate range of the result, that is, the equivalent of 'automatic'. In
fact, as the ranges have no template parameter for the underlying type, I'm
not entirely sure what 'native' is supposed to do here.

- it's not clear why safe_signed_literal and safe_unsigned_literal need
policies at all, as all the arithmetic there happens at compile time.
There's never a need to promote or throw.

I've misplaced the announcement e-mail, is the right place for the code?
Because if it is, it doesn't follow the Boost convention for the include
directory - the headers aren't in include/boost/safe_numerics but in
include. There's also no Jamfile in the test directory, which is of minor
importance compared to the include issue. The library just doesn't fit into
the Boost structure in its present state.

Boost list run by bdawes at, gregod at, cpdaniel at, john at