Re: [boost] [safe_numerics] review

Subject: Re: [boost] [safe_numerics] review
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-03-12 05:51:03

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