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
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
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk