Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today

Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
From: raindog_at_[hidden]
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.


------Original Message------
From: Edward Diener
Sender: boost-users-bounces_at_[hidden]
To: boost-users_at_[hidden]
Cc: boost_at_[hidden]
ReplyTo: boost-users_at_[hidden]
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 
>> case.
> 
> 
> Could you give an example?

An example of what ? Of a constraint where arithmetic operations make 
sense ?

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
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users





Sent from my Verizon Wireless BlackBerry