From: Neal Becker
I'm wondering if I can selectively switch off bounds checking without overhead?
In theory, for such simple cases like ints and compile-time bounds, yes. In practice, of course, it depends on optimisation capabilities of compiler and compilation options used.
I added: /** Error policy for constrained that ignores bounds. */ struct ignore { [snip documentation comments] template <typename V, class L, class U, class C> void operator () (V & ov, const V & nv, const within_bounds < L, value_generator::integral<bool, true>, U, value_generator::integral<bool, true>, C> & c) const { }
};
I'm wondering if the this will eliminate all overhead allowing the speed of the underlying ValueType (e.g., int)?
In case of such policy the check would still be performed - if the value is valid, it is assigned, and if it's not, then the operation is ignored. What you really want is to assign the value no matter if it's valid or not, so the error policy should be: struct no_error_policy { template <typename V, class C> void operator () (V & old_val, const V & new_val, C &) { old_val = new_val; } }; Note, that this policy is quite unnatural and breaks the constrained class' invariant when invalid value is assigned. In debug code the constrained class will fire an assertion, but in release code no action will be performed (i.e., the invalid value will be assigned as any other). In this case there is a chance that a good compiler figures out how to optimise this. I've checked this with GCC 3.4.5. I've written the following code: int main(int argc, char * argv[]) { bounded_int<int, -10, 10, true, true, no_error_policy>::type b; b = argc; return b; } After compiling it with "-S -O3 -DNDEBUG" (using current library's code, which differs slightly from the older code available for download), the main function looked like this: _main: [snip irrelevant stack manipulation etc.] movl 8(%ebp), %eax leave ret Which means that for this simple case there is no difference between constrained and int. It doesn't mean, however, that the compiler will figure optimisation opportunities in more complex cases (actually it didn't for e.g. initialisation of b with argc). BTW, currently I'm working on examples section of the documentation and performing some code tuning, so there is a chance that the library will be _finally_ submitted for a review. ;-) Best regards, Robert