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 https://github.com/robertramey/safe_numerics/ 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.