Subject: Re: [boost] a safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-12-10 18:48:03
> these links are broken
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
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
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
> 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