Re: [boost] Bounded types

From: Neal Becker (ndbecker2_at_[hidden])
Date: 2005-10-20 19:11:08

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>.