Re: [boost] Checked Integral Class

From: Dan McLeran (dan.mcleran_at_[hidden])
Date: 2005-09-15 17:13:02

I also disagree with this suggestion. I would rather leave it up to the 
developer to specify the type of any variable. If someone gets it wrong, 
then the policy class that deals with over/under flow will handle it.

"Matt Doyle" <mdoyle_at_[hidden]> wrote in message 
news:12F38DF504DEFB4FA6BBF26668FE96DA02A62C_at_python.a-m-c.com...
I think I want to disagree with this suggestion. Citing your example a=b 
should work just fine provided that the value of b will fit within the 
constraints of a.

I think in most situations (but not all) the limits are determined by how 
the type will ultimately be used and not necessarily on the result of the 
operation that's taking place. If it doesn't fit, so be it, it's an error.

On another note; I liked that earlier suggestion of user definable error 
handling, I can see where heavy handedness is not always desirable.

> also, the type of a binary operator's return value should combine the
> intervals of the operands
>
> e.g. given:
>     CheckedIntegralValue<int, -10, 100> a;
>     CheckedIntegralValue<int, -100, 20> b;
>
> then the type of a+b should be CheckedIntegralValue<int, -110, 120>
>
> and given:
>     CheckedIntegralValue<int, -110, 120> sum;
>
> then sum = a+b, sum = a, and sum = b should all compile just fine
>
> conversely, a = sum, b = sum, and a = b should not
>
> this may have been implied, just wanted to make sure
>
> regards,
>
> /michael toksvig
>
<snip>

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

> Scanned by Fortigate {X3BTB534}
>

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

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