Subject: Re: [boost] [safe_numerics] Last three days
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-03-10 19:25:33
Update: I now have a version which builds and runs all the tests with
VC2017, the fixes required are here:
Hopefully this will encourage a few other people to give this a try.
The one exception is test_cast.cpp which triggers the MSVC runtime
checks due to the use of an unitialized variable in the test suite,
which should obviously be fixed.
I also noticed that test_z.cpp has no content: it's all #if'ed out.
> Perhaps you might take a different tack. I've spent a little time
> looking at the boost multi-precision library with the eye of
> incorporating it into the safe numerics testing. In the course of
> doing this a couple of interesting things occurred to me.
> a) would safe numeric types inter-operate with safe numerics types?
> They should - but I haven't actually tested this. Whenever I fail to
> test something - there's almost always a bug in it.
> b) would safe<T> work if T is one of the types defined by boost
> multi-precision? This is unclear to me. safe numerics presumes that
> the largest types available are std::uintmax_t and std::intmax_t .
> It's easy to imagine altering this presumption to use types defined by
> the user to be types like boost::uint512_t or... . I think this would
> work with minor changes - such a combination would open up whole new
There is overlap between the two libraries here: class cpp_int already
has built-in overflow checking that allows it to operate as a checked
integer type already. The issue here, is that a generic test for
possible overflow is likely to be ruinously expensive compared to
built-in support - in fact built in support has basically zero cost
since the presence of overflow is already right there in the
multiprecision-algorithm, as in "we have more bits in the result but no
where left to put them". One thing I want to at least try and do, is
figure out whether your extension-API's are suitable for hooking into
this along with assembly code overflow checks for native types.
> Maybe if you confined the scope of your review to issues such as the
> above you could save a lot of time and bring up issues that others are
> not in a position to do.
> Finally, my biggest disappointment in all this has been my inability
> to get people to take this whole effort seriously. That is, to even
> admit that there is even a problem. It's inexplicable and
> disheartening to me that one can write something like x + y and not be
> confident that the result actually equals x + y. Especially in light
> of the fact that we're using C++ to make flying cars - not just
> websites. I feel that for the first time in 60 years we're in the
> position of making demonstrably correct software - and no one cares.
> It's very frustrating.
> I so much appreciate the interaction I have with my Boost soulmates.
> I'm not sure what I would do with this.
Build it and they will come ;)
--- This email has been checked for viruses by AVG. http://www.avg.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk