Re: [boost] a safe integer library

Subject: Re: [boost] a safe integer library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-12-11 14:19:17

Le 11/12/2015 00:48, Robert Ramey a écrit :
>> these links are broken
>
> <snip>
>
> I'm still working on these sections - I'll tweak things so that's clear.
There are other links that are broken, native, ExceptionPolicy.
>
>>
>> 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 ???.
I will add numeric in the name. std::safe<T> don't says this is a 
numeric type.
>
>> * 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!

It seems the only one is

6.1.6 Header
#include<boost/safe_numerics/safe_integer.hpp>
>
>> * 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.
>
You have almost convinced me.

Hmm, but why the simple approach that is valid for the standard is not 
good enough for Boost?

I believe the good thing to do is to provide in boost both safe<T> and 
basic_safe<T,P,E>.  safe<T> can be an alias of basic_safe<T>. This 
ensure to have a simple interface also in Boost.

Vicente