Boost logo

Boost :

Subject: Re: [boost] [safe_numerics] One more review
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-03-11 18:43:33

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<Char, Trait> instead of ostream)

I want to replace ostream with basic_stream<CharT, CharTraits> 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
> . Also looks like this class is not covered well with tests, because
> line
> shall not compile
I'm going to remove it.
> There's a bunch of implicit conversions in the library
> (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.

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
> Try using <iosfwd> and making all the function below to use
> `basic_ostream<Char, Trait>&`.
> No need to define those in `namespace std`
> . 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:

will look into it.

Robert Ramey

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