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://listarchives.boost.org/mailman/listinfo.cgi/boost
>