Robert Kawulak wrote:
From: Jeff Garland
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
That 'irrelevant stack manipulation code' isn't irrelevant at all...it's the function call overhead cost and would likely *not exist* in a fully static version. Same with the stuff right before the return. <snip>...good details...
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. ;-)
Nope...it's the stack code which can't be optimized out because you have to have a function pointer and call a different location instead of fully inlining. If you take out the dynamic function part I bet you'll cut the generated code down to just the compares and the error handling... Jeff