Re: [boost] [safe_numerics] Last three days

Subject: Re: [boost] [safe_numerics] Last three days
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-03-10 20:15:01

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