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@a-m-c.com> wrote in message news:12F38DF504DEFB4FA6BBF26668FE96DA02A62C@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