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