Stephen Gross wrote:
Since the assignment check is done at runtime (as it has to be), why make the range restriction at compile time? Isn't it more useful to have a class that works more like this:
=== CODE === CheckedIntegralValue x; x.setLowerLimit(-5); x.setUpperLimit(1000); x = 10; x = 9000; // Fails at runtime ===========
Does this make sense?
Yes, it does, except: - it means that the limits are run-time properties of each object, which adds to their size (likely 3 times!) - it means that you cannot use the bounds for static deductions, which can actually ensure that if some operations are always safe, then no run-time checks are necessary (and therefore there is no overhead) or on the contrary, if the operation is always wrong then there is no sense to even allow it to compile. The only advantage of the run-time approach is that you can set the limits based on the information that is not yet available at compile-time (like bounds read from the database). In my opinion both approaches have their uses, just like std::vector and boost::array. -- Maciej Sobczak http://www.msobczak.com