Boost logo

Boost :

Subject: Re: [boost] safe integer library -- the scope
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-12-14 14:15:25


On December 14, 2015 11:39:50 AM EST, Robert Ramey <ramey_at_[hidden]> wrote:
> On 12/14/15 5:15 AM, Andrzej Krzemienski wrote:

Most of what you quoted/replied to was from me, not Andrzej.

> >>>> Then it can be known at compile time that y can never overflow so
> no
> >>>> runtime checking is required. Here we've achieved the holy
> grail:
> >>>>
> >>>> a) guaranteed correct arithmetic result
> >>>> b) no runtime overhead.
> >>>> c) no exception code emitted.
> >>>> d) no special code - we just write algebraic expressions
> >>>>
> >>>> This is the true motivation for safe_..._range
> >>
> >> Why isn't that the behavior of your safe type in the first place?
>
> it is

I'm confused. If that's the behavior of safe, why do you need safe_..._range?

> That is,
> >> what benefit does your safe type offer that it shouldn't just be
> supplanted
> >> by the range type?
>
> safe<T> can be used as a drop in replacement for T . safe...range
> cannot.

Why not?

> >> However, since min() and max() are now constexpr, that all can be
> >> collapsed into a single template with three parameterizing types:
> the
> >> underlying type, the minimum, and the maximum:
> >>
> >> template
> >> <
> >> class T
> >> , T Min = std::numeric_limits<T>::min()
> >> , T Max = std::numeric_limits<T>::max()
> >>>
> >> class safe;
>
> That's exactly what safe<T> is.

Why doesn't that suffice for all use cases?

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk