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
> 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
>> * 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!
It seems the only one is
>> * 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 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk