Boost logo

Boost :

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

Sent from my Verizon Wireless BlackBerry

Boost list run by bdawes at, gregod at, cpdaniel at, john at