Update: I now have a version which builds and runs all the tests with VC2017, the fixes required are here: https://github.com/robertramey/safe_numerics/pull/33 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 territory.
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 ;) Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com