Robert Kawulak wrote:
Hi,
From: Neal Becker <...> I'm more interested in bound specified at runtime. I believe (without proof) that for many applications there will be little performance difference. I say this because I'm expecting in many (most?) cases the actual integral values will be known to the compiler.
Has any thought been given to adding this? Or, perhaps even making this the default bounded_int, (wrapping_int, etc.) type?
Yes, I'm still thinking about this. The difference between static and run-time bounds is that in the latter case a bounded object needs to store the bounds which makes its size at least 3 times bigger. Another one is that with static bounds many checking operations may be optimised-away or at least inlined. Therefore I'd rather not make run-time bounds the default. I'm working on this as an optional feature, but this is a little bit harder than it seems to unite the two concepts.
Yes, the advantage of integral template parameter bounds is primarily that it could be optimized or inlined - but I think the same is true if the bound checking function is inline and the bounds are known at compile time. IIUC, integral template parameter has the advantage that it might be optimized, but the disadvantage is less flexibility. A static bounds checking function could also be inlined and optimized away in case the bounds are known at compile time - this same condition is the only time the template parameter could be used at all. Therefore, I expect there is no performance advantage to the integral template parameter approach, but less flexibility. I'm thinking something like this: template<typename checker_t> class bounded {... bounded (checker_t check) ... assign () { check (value); } checker_t is a functor which could store the bounds. I'm guessing it could allow checking to be inlined. I guessing the size of a bounded object would not necessarily be increased. For example, suppose we _did_ know the bounds at compile time. Then checker_t could be wrap<0,10>.