From: Jeff Garland Robert Kawulak wrote:
constraints can all be inline and fixed at compile time. I'd rather have 2 types if need be to allow maximum efficiency for the static cases.
I wouldn't consider this a great issue. My experiments with compilation to assembly code show that compilers are able to optimise-away all (or at least much of) the abstraction easily (e.g. see http://article.gmane.org/gmane.comp.lib.boost.devel/164478).
Hmm, I'm dubious that this testcase is representative. Because you have a fixed const there is apparently no checking required...unlikely to work in most cases. Also, you still have the function call overhead...so I'm still leary that instead of 2 compares you get 2 compares plus the overhead in your example.
I'm not sure I understand - why you think there's a function call and 2 comparisons in that example? The function's code simply returns the literal value of 5 and that's it. Anyway, I've tried with more representative example - the value is not known at compile time: extern int i; void test() { bounded_int<int, 3, 5>::type b(i); } With #define NDEBUG and -O2 switch, gcc 4.0.1 gave the following code: __Z4testv: [...] irrelevant stack-manipulation code movl _i, %eax movl %eax, -32(%ebp) cmpl $2, %eax <== lower bound jle L8 cmpl $5, %eax <== upper bound jle L46 L8: [...] irrelevant error-handling code L46: [...] irrelevant stack-manipulation code ret With the same options, Borland C++ 5.6.4 gave: @@test$qv proc near [...] lots of seemingly irrelevant code mov eax,3 <== lower bound [...] cmp eax,edx setg al and eax,1 test al,al jne short @19 mov eax,5 <== upper bound cmp edx,eax setg cl and ecx,1 test cl,cl je @17 @19: [...] irrelevant error-handling code @17: [...] ret @@test$qv endp In both cases the compilers were able to optimise-away the abstraction of bounds generators, using the literal values of bounds in the comparisons. I'm not sure this is what you were worrying about, but if so, then I think there's no problem at all. ;-) Best regards, Robert