From: Jeff Garland (jeff_at_[hidden])
Date: 2007-11-12 21:19:24
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