Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
Date: 2008-12-03 23:10:50
Another example: 6 represents june. 6 + 3 is then 3 months after june, otherwise september. 6 + 12 is the next june.
From: Edward Diener
Sent: Dec 3, 2008 8:03 PM
Subject: Re: [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
Deane Yang wrote:
> Edward Diener wrote:
>> Deane Yang wrote:
>>> I have an even more extreme view on this. I don't believe any
>>> arithmetic operations should be permitted for constrained numbers.
>>> They just don't make sense (would you ever want to add two different
>>> days of a month?).
>> You have chosen a particular type for which arithmetic operations
>> sometimes make little sense. In many other situations this is not the
> Could you give an example?
An example of what ? Of a constraint where arithmetic operations make
If we take a constraint representing a percentage between 0 and 100, I
think it is perfectly valid to add a percent to what is already there.
That is just one of innumerable cases where arithmetic operations of
contraints seem perfectly valid to me. Why would you even want to
consider limiting constraints by removing arithmetic operations if the
underlying type supports such operations ?
Boost-users mailing list
Sent from my Verizon Wireless BlackBerry
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk