On 3/10/17 11:25 AM, John Maddock via Boost wrote:
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.
I use test_z as place to put temporary code used to track down specific errors. Doing it this way means that I don't have to constantly re-cake my ide project (which always ends up a minor project. sorry CMake fan - CMake doesn't really work - it has to be made to work). Some times these mini-projects get promoted into their own test. Other times I just comment them out so I don't run them - but I'm loath to just throw them a way.
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.
My interest has been peeked by my current efforts to fixup automatic type promotion. Currently it seems that many compilers support 128 bit integer operations - but std::uintmax_t tops out at 64. maybe multiprecision specializes the 128 bit integers to use the compiler built-ins. Once I pull on that thread - it's hard to avoid just permitting all the operations 256, 512 bits etc. Even if they are used only a compile time to figure out when value checking can be skipped. Of course this pre-supposes that multi-precision is implemented in a constexpr way. ... I'm not in a hurry about this though. Things are already complicated enough considering the libraries separately.
Build it and they will come ;)
LOL - that's not the way I see the world. My view is the one has to flog the hell out of even the simplest obvious ideas to make them happen. Robert Ramey