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:
> [...] 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.
> 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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk