Re: [boost] a safe integer library

Subject: Re: [boost] a safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-12-10 18:48:03

> these links are broken

<snip>

I'm still working on these sections - I'll tweak things so that's clear.

>
> minor comments:

> *  I believe the name safe<T> is too broad for the kind of types this
> class can wrap.

Hmmmm - The documentation of the library, the concepts etc. are 
themselves pretty general.  Take the concept Integer.  If someone comes 
up with a modular integer type or a money type, and these types fullfill 
the stated concepts in the documentation, I would expect the "safe" 
functionality to work.  Most of the library is implemented not in terms 
of particular types - but rather the "numeric traits" as specified in 
std::numeric_limits. So, although right now it's only implemented for 
integer like types - but that's an implementation feature not a design 
choice.

We're thinking big here!  To me, the implications of a safe<money> type 
are huge and I'm willing to be at least one wall street institution 
might have gone bust for lack of this data type.

Another consideration is that there are other libraries aimed at the 
same problem which are called "safe.." or SafeInt or ???.

> * Remove any adherence to boost in the standard proposal (include
> <boost/...)

Hmmm - I'm not seeing this.  The only reference to boost I find in the 
standard proposal is my affiliation - which I'm a very proud of!

> * I see that boost::numeric::safe and std::safe differ on the template
> parameters. I see why the standard version is not configurable and just
> throws.

 > However, I don't see why this doesn't applies to the proposal
> for Boost. What is not good for the standard can be good for Boost?

The short answer is:

The standard proposal is for wimpy programmers who don't use Boost.
The boost proposal is for programmers with huevos.

The longer answer is:

The current standard libraries don't use policies.  They all throw
standard exceptions so I thought it best to follow this example.

The policies - particularly "automatic" add a large amount of complexity 
to the library.  This makes it more complex to learn how to use, much 
more effort for vendors to implement.  I want to see a library in the 
standard which is a no-brainer to use so that everyone will use it to 
trap stupid bugs which occur all the time.  I expect to see some 
programmers who want to tweak the operation using the policies to get 
the absolute best performance or compile time guarantee of no errors 
(like life critical software).  So I see two different "markets".

And then there is the trying to please everyone issue.  If I choose one 
path above - I'll get a howl from the other camp.  Better than trying to 
please everyone by concocting a mishmash - I'll just define two 
different "levels" the standard one being a simple to use subset of the 
boost one.

Robert Ramey