Re: [boost] Checked Integral Class

From: michael toksvig (michaeltoksvig_at_[hidden])
Date: 2005-09-16 17:45:14

matt, i don't think your code example disambiguates what rob and i are 
disagreeing on

when you say:
> MyCv c = a + b; // Should fail

you don't say why you think it should fail. there are (at least) 3 
possibilities:
a) at compile time (because it is an error to try to assign a 0-20 number to 
a 0-10 number)
b) at runtime, during the assignment (because it is an error to assign a 
0-20 number to a 0-10 number if it is outside the 0-10 range)
c) at runtime, during the addition (because it is an error to add two 0-10 
numbers if they add up to more than 10)

i think a) and b) are both useful, and i think rob is advocating c)

regards,

/michael toksvig

"Matt Doyle" <mdoyle_at_[hidden]> wrote in message 
news:12F38DF504DEFB4FA6BBF26668FE96DA02A633_at_python.a-m-c.com...

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

--------------------------------------------------------------------------------

> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost