Re: [boost] Checked Integral Class

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-16 16:06:09

From: "Matt Doyle" <mdoyle_at_[hidden]>
> > From: "michael toksvig" <michaeltoksvig_at_[hidden]>

> > > add two numbers in the 1-10 range, and you invariably end=20
> > up with a number=20
> > > in the 2-20 range

> > Yep.  However, when considering constrained ranges, I find it
> > surprising that the result would be *permitted* to exceed the
> > constraints of the inputs.

> > IOW, I'd have expect the result to be constrained to be 2-10.
> > Yes, that means that combinations exist that violate that
> > constraint, but at least it wouldn't surprise me.
> >
> YES, that's exactly the point I was trying to make earlier - you just =
> did a much better job of explaining it :)

Thanks, if in fact I was addressing your concern.

> IMO, the constraints and/or policies set forth when the type was defined =
> must apply for the lifetime of the type.

To be certain we're talking about the same thing, Michael and I
have been discussing the result of a computation.  Built-in types
regularly undergo promotions when participating in such
expressions, so the question is whether something similar should
happen for a checked integral class and what form it should take.

Michael was positing that the result type should account for the
full range of values possible from the computation.  I argued
against that.

I should also point out that built-in types don't behave that
way; they can overflow silently, but they don't magically gain
range.  (The analogy isn't strong, but has some bearing, I
think.)

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;