Re: [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2008-12-03 08:40:06

Edward Diener wrote:

> Mathias Gaunard wrote:
>> Jeff Garland wrote:
>> 
>>>       bounded_int<int, 0, 23>::type hour;
>>>       hour = 20; // OK
>>>       hour = 26; // exception!
>>>
>>> Behavior in case of assignment of an invalid value can be customized.
>> 
>> I think this is wrong.
>> Providing an invalid value should be a non-recoverable programming error.
>> Non-recoverable means it should abort the program, and programming error
>> means it should only be enabled in debug mode.
>> i.e. an assert is the best choice to assert the preconditions are met.
> 
> I disagree with your analysis. The '26' value could be a run-time
> calculation and not just a compile-time constant. In which case you are
> saying that the assignment of a run-time calculation should assert only
> when run in debug mode and otherwise should be ignored. I can not agree
> with that idea.
> 
>> 
>> Apart from that, wouldn't it be more interestin, when multiplying a
>> bounded_int<int, 0, 23> by 2, to yield a bounded_int<int, 0, 46> instead
>> of attempting to keep the object with the same constraint?
>> Of course, that only works with bounded_int and not constraints in
>> general.
> 
> I disagree with this also. The entire idea of a constraint in this
> library is that the underlying value meets the criteria of the
> constraint and not that the constraint changes to accomodate a new
> underlying value.
I also disagree.  There is no universal design here that would satisfy all needs.  The only universal approach I see is that an operation on 2 operands of the same bi type should return the same bi type.  If you want the result in a different type, cast the operands to that type first.