Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk