Reasons for denial of inline function suggestions in C++

Inline functions are functions whose code syntax is preceded by inline keyword. They suggest to the compiler to replace their call with their code. This is done to reduce the call overheads like call stack operations which significantly save on time. However, inlining a function is a suggestion and not a guarantee that the compiler will always comply. The good news is that the compiler refusal is based on clear rules. Some of the rules are:

Example of inlined function

        const string name = "jack";
                    

Inlined function contain loops

Loops are usually expensive to execute and slows down the execution by some margins. Inline functions are expected to be short and inexpensive. Therefore, function containing loops are definitely left for normal function call.

Switch/goto statements

Switch statements have a lot of constants, comparisons and stack access. Goto on the other hand is culpable for code bloat (large entangled code) and optimization complexities because goto creates runtime complexities which are hard to resolve at compile time.

Function body too large

It is only logical to inline small functions since small duplicates are copied to the call point. Functions with many lines of code will bring huge copies to the code hence larger programs will be loaded on RAM. Furthermore, large code will lead to CPU cache misses because an instruction comprising of the inlined function is too big. All this beats the original purpose of inlining functions i.e efficiency.

Non-void functions without return statements

It is generally flagged when one writes a non-void function with no return statement provided the function is not main function. It would have been messier if the faulty function would have been integrated into the mainstream code.

Static variables

There are two instances here why the compiler refuses to accept the inline suggestion for a function containing a static variables. The first one is the One Definition Rule which entails that a definition of static variable at namespace level means each translation unit (.cpp file) will have its own static variable instance. The other reason is due to static variables persistence between calls. This means the compiler must employ specific mechanisms to ensure ODR compliance.

We have clarified on some common reason for compiler ‘stubbornness’ , we have to entice you back to raring to use inline functions again. These are the advantages of inline function you will miss by embracing ‘fear of rejection’:

• Elimination of the variable push/pop overheads.
• Elimination of function calling overhead.
• Increase of locality of reference by utilizing instruction cache.
• Enabling of the compiler to perform more aggressive optimizations which may not have been possible with function call boundaries.

In conclusion, inline functions presents very many reasonable advantages in large programs and is encouraged. However, it will be a waste of your time thinking you inlined a function only for your ‘suggestion’ to be rejected at compile time. As a rule of the thumb, ensure all inline functions are small enough to be duplicated without significant code size increase and opt for inline functions over macros.