Re: [boost] Checked Integral Class
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}
From: "Matt Doyle" <mdoyle@a-m-c.com>
also, the type of a binary operator's return value should combine the=20 intervals of the operands
I think I want to disagree with this suggestion. Citing your example = a=3Db should work just fine provided that the value of b will fit within = the constraints of a.=20
That's why I suggested the converting constructor. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
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
i agree that allowing a policy to decide whether it compiles or not is a superior solution as long as the type of the addition reflects the expanded range: (a+b).min==a.min+b.min && (a+b).max==a.max+b.max /michael toksvig "Dan McLeran" <dan.mcleran@seagate.com> wrote in message news:dgcrlf$8ev$1@sea.gmane.org...
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Dan McLeran -
Matt Doyle -
michael toksvig -
Rob Stewart