Re: [boost] Checked Integral Class

From: Matt Doyle (mdoyle_at_[hidden])
Date: 2005-09-16 16:36:26

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Rob Stewart
> Sent: Friday, September 16, 2005 2:06 PM
> To: boost_at_[hidden]
> Cc: boost_at_[hidden]
> Subject: Re: [boost] Checked Integral Class
> 
> 
> 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.)

I think we are talking about the same thing but from different angles, consider this simple case;

typedef constrained_value<0, 10, policy> MyCV;
MyCV a = 6;
MyCv b = 8;
MyCv c = a + b;	// Should fail

If the user wants "c" to be able to hold the result of "a + b" he should define a new type that would accommodate it.

We are on the same page aren't we?

> 
> -- 
> 
> Rob Stewart                           stewart_at_[hidden]
> Software Engineer                     http://www.sig.com
> Susquehanna International Group, LLP  using std::disclaimer;
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 

Scanned by Fortigate {X3BTB534}