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
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
* 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