views:

202

answers:

6

I have a method like the one shown below. Will the for loop always make the compiler for go the "inline request" ?

inline void getImsiGsmMapFrmImsi
  (
    const string& imsiForUEDir, 
    struct ImsiGsmMap& imsiGsmMap
  )
{
    for (int i = 0 ; (unsigned)i < imsiForUEDir.length() - 1 ; i++)
    {
         imsiGsmMap.value[i] = imsiForUEDir[i] - '0' ;
    }
    imsiGsmMap.length = imsiForUEDir.length() - 1 ;
}
+3  A: 

Simply, no.

"inline" is just a hint to the compiler.

There are ways to force a compiler to inline something, but these ways are compiler-specific. Your code looks mobile to me, so here's some ways on some C++ compilers used on various mobile phone platforms:

Windows CE/ Windows Mobile VC++ ARM compiler uses the __forceinline keyword instead of the hint 'inline'.

A better compiler (i.e. makes faster output) for Windows CE/ Windows Mobile is cegcc, which uses the very latest GCC 4.4. In GCC, you write __attribute__((always_inline)) after the function name and before the body.

The bigger thing is if it's a good idea to inline this loop. I program mobile phones for a living, and they don't have much CPU budget generally. But I'd be really surprised if this loop is a bottleneck. Strip your program of all the 'inline' decorations and when you're approaching shipping, if the program is slow, profile it!

Some compilers allow 'profile guided optimisation' where they can make an instrumented binary that you run in a realistic way, and then they use the data so gathered to make a production binary where they make informed decisions about code speed vs code size in the various parts of your program to give the very best mix of both.

Will
No? I would interpret the answer as "yes". You can _say_ inline pretty much where ever you want. The compiler has the right to ignore you. :-)
asveikau
He was answering "No" to "Will the for loop always make the compiler for go the "inline request" ?"
Chris Lutz
Note that even with `__forceinline` the compiler can still ignore the 'request': "There is no guarantee that functions will be inlined. You cannot force the compiler to inline a particular function, even with the `__forceinline` keyword" (http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx). I imagine the same is true with GCC's `always_inline (the docs seem to imply that the only thing this attribute does is cause inlining to occur when optimization is off). At a certain point, the compiler's going to say 'nope!'. It would be a pretty neat trick to inline any given recursive function.
Michael Burr
+5  A: 

You can specify "inline" and the compiler can ignore it if it feels like that.

sharptooth
A: 

I wonder if the inline keyword is even necessary anymore. Don't modern compilers mostly just ignore it and do whatever they think is best, anyway?

Jeremy Friesner
It is necessary if the header with a function implementation is included into multiple translation units.
sharptooth
Some compilers have settings that force them to treat `inline` as a strict order, not as a hint. Some compilers offer alternative non-standard forms of `inline` keyword that force the inlining.
AndreyT
abhijeet
No, it isn't. The C++ language requires that inline function be *defined* (and defined *identically*) in all translation units where it is used. If you expect to use this function in several translation units, and want to have it as `inline`, you better move the definition to the header file.
AndreyT
+2  A: 

"No inlining for functions with loops" is probably a bit of some inline heuristic from some particular compiler. It doesn't apply universally.

Every compiler uses some heuristics to determine whether the function should be inlined or not, but normally every compiler uses its own ones. So, to say that a loop will have some universal effect on inlining is not correct. It won't. There's absolutely nothing in your function that would somehow fundamentally preclude inlining. Most modern compilers can easily inline this function, if they deem it reasonable or if you force them to do it.

Yes, some compilers offer non-standard declaration specifiers (or compiler options) that will actually force the inlining, i.e. override the heuristic analysis, except for a number of situation when the inlining is truly beyond the capabilities of the compiler. For example, many modern C/C++ compilers normally can't inline functions with variable number of parameters (variadic functions).

It also commonly believed that recursive function can't be inlined. In reality, in many compilers recursive functions can be inlined to certain fixed recursion depth, thus "compressing" the recursion.

AndreyT
A: 

Most likely compilers will not inline a function with a loop, since what would be the point? If the code is looping, generally the cost of a function call will be unmeasurable noise compared to the looping.

But if a compiler wants to inline it (maybe the compiler is sophisticated enough to determine the loop bounds and can even unroll the loop), it's certainly allowed to.

But I wouldn't bet on it.

Michael Burr
A: 

To summarize a previous answer I gave to this, the things you should watch out for when choosing a function for inlining are:

* local static variables
* loop constructs
* switch statements
* try/catch
* goto
* recursion
* and of course too much complexity (whatever that means)

Having said that as the other answers here point out, it's basically unspecified if the compiler inlines the function or not. 7.1.2/2 has:

A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected.

An interesting detail on this, is that the compiler would normally label the kind of behaviour that's involved here. For example: "it is unspecified" or "the behaviour is undefined" etc.

Richard Corden