On 3/11/17 2:56 PM, Peter Dimov via Boost wrote:
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 the documentation is wrong - I'll double check. It's worked well for me to build the documentation in parallel with code. But sometimes things don't get clarified until later and the documentation has to be revised. So this can happen.
I think that it should be, subject to the usual constraint that the value can be represented in an int.
Right.
- 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.
hmmm - very astute observation. in effect it seems I've intertwined "automatic" with native. It's more ineresting in a compound expression where the intermediate results returned are ranges. The idea here is to keep the type from growing beyond what holding the result requires. This will diminish the need for runtime checking and the conversion to larger types which presumable would be slower. Then there is the question that assigning "automatic" to the result of a binary expression would conflict with the operand of the next higher binary expression. This conflict then stops the process. I'll really have to think about this a like arrive at some sort of compromise (sigh).
- 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.
default is void. So that when they are combined with some other safe type, the policy of the other operand is used. The prevents two safe literals from being added though.
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.
I'm aware of this. Boost doesn't require final form for a review. I used a form which easier for people to use without adding it to their boost tree, running b2, etc. Also b2 is a big obstacle for most people so I supported CMake which is easier for me as well. If it gets accepted into boost, it will have to be updated to fit the boost conventations. Robert Ramey