|
Boost : |
From: michael toksvig (michaeltoksvig_at_[hidden])
Date: 2005-09-15 18:40:59
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_at_[hidden]> wrote in message
news:dgcrlf$8ev$1_at_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_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
>
>
>
> _______________________________________________
> 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