
Mathias Gaunard wrote:
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 couldn't disagree more: that would negate the whole point of the library. I'm not saying that the design choices you want may not be valid in some situations, just that you're asking for a different library. Indeed if it's absolutely essential to the proper functioning of the software that a value fall within certain constraints, turning off assertions in release mode, or indeed aborting, may not be viable options (think embedded program control software). Would you really want your software to crash if it detected a negative velocity for your car? (or your car to crash if the software fell over?). This library lets you choose what actions happen on constraint-failure, including assert or no-op actions if that's what you really want. But I suspect most users of the library will be looking for something that will allow them to write fault-tolerant code.
Apart from that, wouldn't it be more interestin, when multiplying a bounded_int
by 2, to yield a bounded_int instead of attempting to keep the object with the same constraint?
Interesting, as in "may you live in interesting times"? ;-) John.