Re: [boost] [safe_numerics] One more review

On 3/11/17 1:00 AM, Antony Polukhin via Boost wrote:

Nitpicks:

More generic streaming operators could be profitable (better to use basic_ostream instead of ostream) https://github.com/robertramey/safe_numerics/blob/master/include/interval.hp...

I want to replace ostream with basic_stream but I couldn't figure out the template definition syntax for using two separate sets of template parameters. Someone knows the answer off hand. Please save me some time and post here - after you're sure it compiles.

Many operations may be decorated with noexcept

right - I'd be curious to know what happens if one uses noexcept and also uses -fno_exceptions in the command line of some compileers.

This macro seems broken https://github.com/robertramey/safe_numerics/blob/master/include/safe_litera... . Also looks like this class is not covered well with tests, because line https://github.com/robertramey/safe_numerics/blob/master/include/safe_litera... shall not compile

I'm going to remove it.

There's a bunch of implicit conversions in the library https://github.com/robertramey/safe_numerics/blob/master/include/safe_base.h... (BTW, have not found a body of this one). Would it be better to make them explicit?

Ahhh - no a very sore point. Implicit conversions between numeric type are supported by the library - just as they are for builtin integer types. This is to support the "drop-in" replacability goal. The difference is that these conversions are checked at compile time or execution time. tl;dr; This is actually a very subtle and difficult issue brought up by vicente. I'm going to paraphrase. Aren't we promoting bad practice by encouraging implicit conversions? Or Isn't the way to program correctness paved with strong types? I've a big promoter of this later view. But I confess that making the library has led me to conclude that the future of correct programming needs a more nuanced view. In order to promote correct code, we need to be able to express our ideas directly in code in a way that matches the way we use the ideas in real life. In real life we say x+y with no ambiguity. We can't express real numbers in computer hardware so x+y doesn't really capture what we want to say. requiring explicit conversions every where is going to make it harder to verify that our program matches our expectation. So (checked) implicit conversions are the correct approach. It maintains our ability to visually compare/verify that our code matches our intention - but it traps the times when our expectation can't be actually realized inside the computer hardware. I've become convinced that this is the way things have to be.

Those headers are very heavy https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f93331769... Try using <iosfwd> and making all the function below to use `basic_ostream&`. right

No need to define those in `namespace std` https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f93331769... . Defining those in `boost::numeric` namespace works fine (thanks to ADL!). Hmmm - I didn't know that.

I'd really like to see tests coverage for the library. This is pretty simple to add, just follow the instructions from here: https://svn.boost.org/trac/boost/wiki/TravisCoverals

will look into it.

Robert Ramey