# Inline functions C++

This topic is 4163 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I read that in some cases inline functions use to be faster the normal functions, but are there any restriction in their use? Can I implement polymorphic (virtual) functions as inline? Thanks!

##### Share on other sites
There are a great deal of restrictions on what can be inlined. Also note that "inline" is just a "reccomendation", that the compiler often ignores. The pragma _forceinline will make the compiler inline more often, but if the code is not inlinable this will be ignored too. Look at your disassembly window in release mode to see if a function is actually getting inlined.

Generally the obvious rules are:

- Inline functions must be in .h file (edit - if they have global scope, functions that are local to a single CPP file can be inlined in that c file, but if they are used in multiple files they must be in the header). For C++ members they can be inside the class definition or outside.
- Inline function cannot be virtual or used as callbacks.

One way of having alot inlined functions without having a nightmare of .h dependencies is to use .inl files. These are C files that are included in header in release mode, but compiled as c files in debug mode (that way in debug mode you can edit them without recompiling your whole source tree).

##### Share on other sites
Quote:
 Original post by pisraelI read that in some cases inline functions use to be faster the normal functions, but are there any restriction in their use? Can I implement polymorphic (virtual) functions as inline?

Use a little logic :
inline means that the code is expanded in the caller code at compilation time. If the function is polymorphic with virtual keyword, that means that the actual code of the function is only known when the function is called, that means at runtime and that it could change from run to run depending on what object it is called on. So, No, you cannot expand the function at compile time based on this.

(Of course there are some corner cases where the type of the function is known at compile time so that is a possible optimization but shouldn't be considered the typical use of a virtual function)

LeGreg

##### Share on other sites
Quote:
 Original post by griffin2000- Inline function cannot be virtual...

Sure they can. They just can't be called virtually.

So long as the compiler is able to tell exactly what code is going to be executed, that function call is a candidate for inlining.

CM

##### Share on other sites
every good compiler does inlining on its own, so who gives a damn?

[Edited by - maximAL on July 21, 2006 3:01:39 PM]

##### Share on other sites
Quote:
 Original post by maximALevery good compiling does inlining on its own, so who gives a damn?

There are plenty of cases where it won't (I've had to use _forceinline on many occasions). But even if you do trust your compiler, the rules still apply, if it can't work out at compile time how to inline (beacause its in the CPP file or its being called virtually) then it won't get inlined.

##### Share on other sites
Quote:
 Original post by griffin2000There are plenty of cases where it won't (I've had to use _forceinline on many occasions).

there are also occasions, where inlining is contra-productive. probably your compiler realized that.
did forcing inlining give you a noticable speedup?

[Edited by - maximAL on July 21, 2006 3:12:29 PM]

##### Share on other sites
Quote:
 did forcing inlining give you a noticable speedup?

Yeah a massive one...

##### Share on other sites
I´m having the following problem:

In class GUI_Rectangle.h:

class GUI_Rectangle{			public: //methods		bool intercepts(TScreenCoord p_x, TScreenCoord p_y);};

in the class GUI_Rectangle.cpp:

inline bool GUI_Rectangle::intercepts(TScreenCoord p_x, TScreenCoord p_y){	return true;}

In class GUI_Component.cpp, i have:

bool GUI_Component::intercepts(TScreenCoord p_x, TScreenCoord p_y){	bool v_intercepts = m_rectangle.intercepts(p_x, p_y);		return v_intercepts;}

The compiler return me the error:

undefined reference to GUI_Rectangle::intercepts(unsigned short, unsigned short)' GUI_Component.cpp

If I remove the inline keyword from GUI_Rectangle::intercepts it compiles ok. Any ideia in how to solve it?

Thanks all!

##### Share on other sites
Quote:
 Original post by pisraelI´m having the following problem:The compiler return me the error:undefined reference to GUI_Rectangle::intercepts(unsigned short, unsigned short)' GUI_Component.cppIf I remove the inline keyword from GUI_Rectangle::intercepts it compiles ok. Any ideia in how to solve it?Thanks all!

The code for an inline function needs to be visible at the point where the function is called. When compiling a .cpp file, the only things that are visible are things in the .cpp file itself, as well as any files that have been #included, which usually just consists of .h files. The code for your inline function is in another .cpp file, which is not visible at the time of the function call. How can the compiler know what machine code to inline into the rest of the program at that point if it doesn't know the source code? That's the dilemma.

Two solutions:

1) Create an additional file, "GUI_Rectangle.inl", write the source code for your inline functions there, and at the bottom of "GUI_Rectangle.h", #include "GUI_Rectangle.inl". This will basically make everything in the .inl file a part of your .h file, so when "GUI_Component.cpp" #includes "GUI_Rectangle.h", it also grabs the code for your inline functions.

2) Just write the function definition write their in the class itself.

In class GUI_Rectangle.h:
class GUI_Rectangle{			public: //methods		bool intercepts(TScreenCoord p_x, TScreenCoord p_y)		{			return true;		}};

##### Share on other sites
also note, that inlining is a whole other story if your compiler supports whole program optimization. the newer vc++ compilers and intel do. in particular the requirement of code visibility on call is gone when compiling with WPO.
furthermore some compilers will restructure the layout of your exe based on profiling information (profile guided optimization, PGO). this process sometimes influences inlining and binary layout to an extreme degree. for instance, it may be possible for a PGO enabled compiler to detect the percentage of which class a virtual call of a method is statistically referring to and restructure the emitted binary accordingly to guarantee near-linear "hot paths". this is close to inlining in a way, maximizing binary code locality.

just wanted to mention these so you don't think the inlining story really ends with inline or __forceinline. there's a lot more you can do (or your compiler can do).

cheers,
simon

##### Share on other sites

This topic is 4163 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.