Thread: When to use a .cpp file

Say you declare your class in a header file. Some member functions are big, some medium, some small, and some with a single line (public accessor). My book suggests that professional code tend to have the smaller code within the header, and the bigger functions are defined within its equivalent .cpp file. Is that really common practice? I know some people who are religious with putting everything in a cpp file. Is this really the common way to do things? It would save space in the cpp file anyway.

Makes sense... I'm finding out that's the only way to inline small member functions. It would be a mistake to just throw small member functions in the .cpp file and claim professional code, unless he's building a word processor . How many lines are usually the safe limit for inline functions? I'm thinking 1-20.

Hmm, I guess macros were no different. Its rare to see a macro with over three lines. Zeroing memory from a structure, etc. Probably faster in a real-time loop with a macro/inline function than calling it every frame.

Good idea... thanks for the tips everyone. I'll keep it to one line and go from there.

Inlining is a way to make code run faster, but it's only meaningfull if the inlined code is quite short. And it really only makes sense in code that is run often - accessor methods are of course a typical case where inlining makes sense.

In an ideal case, the inlined code should be shorter than the "out of line" code.

Note also that adding inline to a function doesn't alway make it inlined:
1. functions that you take the address of can't be inlined.
2. Virtual methods can't be inlined.
3. Most compilers have a limit (can sometimes changed by compiler flags - but this is only really useful if you have a good reason to do so, benchmarks showing that it's faster that way would be a good way to determine that).
4. Code that the compiler "can't see" will never be inlined, so even if you add "inline" in a .cpp file that is compiled separately from another file, it won't inline the code.

There are several cases where aggressive inlining is NOT faster than the non-inlined code. One well-known case where "reducing the inlining makes better code" is in the Linux kernel, where they went from "maximum inlining" to "minimum inlining" and actually saw some benefits [I can't remember the exact difference, but system calls were generally faster after this change].

Also be aware that if you inline a function into a another inlined function, it can cause much bigger code, so it's GENERALLY not a good idea to inline functions that call other functions - exceptions do exist, but it's a good starting point to avoid this.

--
Mats

Originally Posted by philvaira

Say you declare your class in a header file. Some member functions are big, some medium, some small, and some with a single line (public accessor). My book suggests that professional code tend to have the smaller code within the header, and the bigger functions are defined within its equivalent .cpp file. Is that really common practice? I know some people who are religious with putting everything in a cpp file. Is this really the common way to do things? It would save space in the cpp file anyway.

Most intelligent modern C++ compilers make their own decisions whether to inline functions. Defining a function inside a class definition may result in an inline function, or maybe not. The compiler is generally better at determining what should be inlined than you are.

So, in theory, you could write every function of a class inline, and allow the compiler to decide which functions are simple enough to actually produce inline code. It's tempting, but there's a big down side -- header files are included by every .cpp file that uses the functionality exported by that header file. This means the code in that header file is recompiled over and over again, and this can be incredibly slow.

I wouldn't worry too much about accidentally hurting performance by declaring functions inline. The compiler won't inline it if it shouldn't be inlined.

Compilers do have their own ideas of what to inline and what not to inline. The keyword inline isn't necessarily observed by the compiler - many compilers do have a switch to say "inline when you think it's a good idea" as well as a switch for "inline things that have the inline keyword" (and of course a switch for "inline nothing" - which is a good idea for debugging - as inlined code often breaks the debuggers ability to understand where in the code you are at the mome).

My personal opinion is that unless you REALLY KNOW what you're doing, avoid worrying about inline at all.

A comment to anon: Is it possible that the compiler did exactly what you wanted it to do: inlined the big function. But because it was inlined, the code grew too large to fit in the L1 cache easily, and thus you got worse performance?

--
Mats

Sometimes the -Os (both MS VC (cl) and gcc's flag for "optimize for smallest codesize") gives the best performance, because smallest code is inlined when inline makes it smaller, and not inlined if the code is larger after inline than before. And smallest code fits best in cache, frequently used functions can remain in cache, rather than being a "different" copy of the function when it's being inlined, etc, etc. It's worth giving it a try, that's for sure.

I'm pretty sure gcc has various switches for the limits of how much code to inline/not inline, etc. MS VC (cl) doesn't seem to support changing the inline limits other than the three levels of "inline nothing", "inline only functions marked inline", "inline what the compiler thinks will work".

--
Mats

Yip, I know this stuff... could be great for someone else though if they are a little rusty. I do a lot of real-time applications so I'm trained to add performance even though it might make an application a little bigger in memory. Padding structures is another example so they are 32-bit aligned. A lot of time, there's clearing memory, getting user input, etc. These small functions are inlined because the function overhead is probably longer in milliseconds than the 1-2 lines of code!

Originally Posted by philvaira

Padding structures is another example so they are 32-bit aligned.

You are aware that the compiler pads the structures for you, right?