C++ and Inlining Functions

[n2ize]

In C it is common to define small functions as macros...

#define ADD(x,y) (x) + (y)

The advantage being that the macro is expanded in place resulting in less overhead than placing values on the stack and using CALL.

In C++ macros get tricky due to side effects and the fact that macros can't access private class data members. Thus defining ADD as above then calling it on private class members would cause an error.

Fortunately C++ has "inline functions". They are very easy to implement either by including the "inline" keyword OR by including the function definition along with the function declaration inside the class.

Thus

class Foo {

int bar(int a, int b)
{ return a + b; }
};

would automatically be created as an inline function. The advantage is that the function is expanded in place resulting in less overhead than a standard function call. The downside is that the header file containing the definition needs to be included in every file that uses the function.

The advantage of eliminating function call overhead is not unlimited optimization. Since the inline funtion is expanded in place everywhere the function is used inlining large functions that are called frequently can start to result in bloated code which ultimately diminishes the effect of any optimizations obtained via inlining.

However, one thing that is not made very clear (at least in most C++ texts) is how large is large ? At what point is it best to refrain from inlining functions and instead make standard function callsvia external function definition ?

Wonder if any of you C++ coders out there have done any benchmark tests on code optimized with inline functions versus non-inline function calls ? If so what have you discovered. At what point (how big a function) is it no longer warranted to use inline functions in a C++ program ?

[KD8COO]

The usefulness of inlining varies by the number of times you call the function and the processing time involved more than the size. Generally speaking, do not inline unless you have a VERY good reason to do so (such as saving a decent percentage of execution time).

[ab1ga]

That depends on a million things, including hardware specific items like code page size. Plus, inlining is only a suggestion to the compiler, not a command, so your fate is in the hands of the compiler writers.

In the scientific code I've worked on and with, I've never seen inlining of functions more than a few lines long. Bigger than that and they may trigger page faults, which wipe out all the time saved by eliminating stack pushes and pops, and code bloat may actually slow down the code.

You can get more info than you want on inlining from the Web; I'd try Googling "c++ inlining", and maybe visiting a couple of compiler vendor sites.

[n2ize]

Thanks for the help.I've been looking at Paul Eckel's online book titled "Thinking in C++" (among other sources) to learn how to write more efficient code in C++, I do have the ability to examine the assembly listings and get an idea what is going on with respect to how my code is being translated. But overall efficiency is tricky and dependent on lots of variables which is why I suppose the books cannot give a concise answer regarding exactly when and where to inline.

Most of my C code rarely uses much innthe way of preprocessor macros and practically none of my C++ code uses inlines. Nonetheless I'd like to experiment with them to see if I can generate any improvements in efficiency via inlining.

I guess inlining is somewhat like operator overloading. Too much of a good thing can make things worst rather than better. I can see where op overloading has it's benefits but I've also seen it done to overkill. Sort of like me with pointers, I tend to overuse them.