It's still there, but the compiler can still refuse to inline even with the keyword. It will issue a warning instead.
Yes, of course. There are some types of functions that are "unsuitable" to inline - for example very large ones. I can't really think of any other scenarion where an ordinary function can't be inlined. Of course, virtual calls through the vtable won't ever be inlined, since the compiler don't know what is going on.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Any case where a pointer to the function is used can't be inlined.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I've tested this fairly extensively with GCC 4.x. You can almost guarantee inlining by passing -finline-limit=9999999. The number refers to some unspecified "inline heuristic value", in other words, some goodness score the compiler computes when deciding whether to inline. By setting the value huge you can make it do it all the time.
The definition of the heuristic value is not specified -- the man page describes it as an abstract measure of "function size," but I don't think it's quite that simple. It also seems to mix in certain complexity measures independently of function size. And the exact method probably changes from version to version of GCC.
Of course, there are certain cases where the function simply can't be inlined no matter what you do.
1. It's called through a pointer. In certain circumstances, the compiler can still optimize it away (if it's static, and the pointer call is stupidly trivial).
2. It's recursive.
3. It calls a function in some other module. The other module could potentially make a call back to the function itself, making it indirectly recursive and thus not inlineable.
Potentially excessive size of the object file?Why does indirect recursion cause a problem?
Why would the object file be bigger?
As long as the other function isn't inline too, I don't see the problem. If the other function is in another module, then it can't be inline.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I think the compiler CAN inline a function that calls another (external) function, but it will need to keep the original function too, so if the function is also large, it's likely to NOT inline it.
For recursion, I'm pretty sure it will inline constant level recursion (where at compile-time the compiler can decide the number of recursions), but it's obviously necessary to keep the original type of function around for the "don't know how many levels of recursion".
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Whether to inline a function is decided in each compilation unit independently. I don't see why a compilation unit would ever inline and also keep the original definition. It may mark in some way the inline expansion of a function, in case it needs to change it to non inline. But the definition would be used from a compilation unit that did not inline.
But it's indirect recursion. The number of recursions is determined by the non-inline function. For example:For recursion, I'm pretty sure it will inline constant level recursion (where at compile-time the compiler can decide the number of recursions), but it's obviously necessary to keep the original type of function around for the "don't know how many levels of recursion".
--
Mats
There should be no problem inlining func1, even though the number of recursions is unknown (as long as func2 is not inline too). A call to func1 would in this case simply be a call to func2. Func2 becomes directly recursive after inlining, but it's not inline itself, so that's not a problem.Code:inline int func1(int eg){ return func2(eg); } int func2(eg){ return eg?eg*func1(eg-1):1; }
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.