Re: [boost] safe integer library -- the scope

Subject: Re: [boost] safe integer library -- the scope
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-12-11 11:21:38

On 12/11/15 7:07 AM, Andrzej Krzemienski wrote:
> Hi Robert,
>
> It is great to see this library getting into Boost. It fills an important
> gap, but it is only after a long while that I realized that, because the
> introductory part of the documentation does not stress it enough, and in
> fact it misled me a bit.

I'm not sure if you're referring to the documentation as it was when you 
posted your review or the documentation in it's current state.  When I 
read you're review I realized that I hadn't clearly isolated the concept 
of undefined behavior from that if incorrect arithmetic behavior.  I 
reworked a lot of the documentation based on your review.

Also as I worked on the package it became clear to me that I had to be 
more ambitious to make the impact I wanted.

>
> My understanding is that safe<int> represents a high level abstraction of
> an integral number from mathematics: unlike raw type int, which represents
> a set of allowed operations on the underlying processor.

Very well put.  I'll work that in somewhere.

> You could say that raw type 'int' is only needed to efficiently implement
> higher level abstractions, like BigInt or safe<int> -- the two only differ
> in trade-offs between efficiency and the range of values they can represent.

Again correct.  The key concept is that our machines don't implement 
arithmetic.  It's up to us to find a way to make them do it.  Until we 
do, we'll be in a continuous battle to reconcile the differences between 
the arithmetic we think about and the bit manipulation that our machines do.

> I was missing this in the introduction. Instead I got a somewhat negative
> impression that the goal of the library is to turn any UB into throwing
> exceptions (and thereby prevent any UB-based static analysis from detecting programmer
> errors).

That wasn't all that in accurate.  When I started the library, I was 
just thinking I needed a hack to reduce my bug count.  I figured I could 
make a small class which would do the job and that it take a couple of 
days to make a cool little class.

That was three years ago.

As I started to patch up corner cases, I came to understand that one had 
to grab the stick from the other end.  That is, instead of trying to 
patch up C/C++ arithmetic to make it less error prone, start with 
arithmetic and "re-implement" it in terms of the operations that 
computer hardware actually implements.  Add to this two key requirements:

a) do not ignore cases where the underlying hardware cannot produce a 
correct result.

b) implementation must be as fast as possible

> I would like to see the library in Boost, although I must admit the other
> parts do not sound that compelling as safe<int>.

what other parts?

>
> Regards,
> &rzej
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>