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.

It is usually a good idea to put implementations in a separate file. However, it is reasonable to have the small functions inlined, therefore they need to be in the header anyway.

Note that inlining large functions usually reduces performance (as far as I've seen).

Compilers also mostly don't support putting templated code in a separate cpp file.

Edit: One more thing. You can put the code that needs to be in the header (for inlining or templates) in a separate file and include that at the end of the header file. That's for organizational purposes only: the preprocessor will just paste that file into the header. It may also have a different extension, for example "*.tpp" for template code implementations.

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.

Maybe 1?

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.

Apart from 1-line set/get type functions, put everything in the .cpp file until you've got a working and debugged program.

Then you can work out whether there is any impact of performance / code bloat by careful measurement of a known working and stable system.

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

Quote:

---

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.

Quote:

---

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.

---

Wouldn't that depend on the compiler? And would it even be possible to inline stuff if you haven't written the code in a particular way (having method implementation inside the class declaration for example)?

I'm working on a largish program where certain parts need to be as fast as possible. As an idea I tried inlining a fairly large function that gets called very often, by moving the definition inside the class declaration. If I'm not wrong compiler optimizations were on and obviously the compiler did something different as there was a large speed ... decrease.

(Fortunately I stumbled upon an higher-level implementation idea that will give it a big boost :) )

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

Yes, that's what I would guess.

I brought this up as an example where the compiler didn't know better than me. Of course, I usually don't bother about this kind of optimisations, so I don't know if there are some additional compiler switches to -O2 or -O3.

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! :)

Quote:

---

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?

Quote:

---

Originally Posted by brewbuck

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

---

It depends on the compiler and its default settings. In fact, Visual C++ 2003 and Visual C++ 2005 do not do what you just assumed.

Code:

---

#include <iostream>
#include <string>
 
struct Actor
{
        unsigned short int a;
};

int main()
{
        std::cout << sizeof(Actor) << std::endl;

        system("pause");
        return 0;
}

---

Returns 2 bytes bud :)

I would suggest that you read the docs a little more carefully. It will become your best friend.

In most cases, just go to Project - Properties - C/C++ - Code Generation - Struct Member Alignment

In code, you can do this...

Code:

---

#define ALIGN32 __declspec(align(32))

ALIGN32 struct Actor
{
        unsigned short int a;
};

---

During runtime, sizeof(Actor) returns 32.

Of course, you would want each field to be 4-bytes if possible so the Pentium doesn't scream in tongues due to the wreaking havoc in memory addressing. But the unsigned short int data type clearly suggests that the struct is not aligned 32-bytes by default by the compiler.

Quote:

---

Originally Posted by philvaira

It depends on the compiler and its default settings. In fact, Visual C++ 2003 and Visual C++ 2005 do not do what you just assumed.

---

I spend approximately 0% of my time programming on Windows platforms. I had no idea the defaults were quite so stupid.

I wouldn't say they're stupid. I would say they are smart... not wasting any memory than having to. If you were writing a real-time application, it would be important to turn on 32-bit alignment (or more). If you're writing a word processor, this extra memory would have been a waste. It a smart move, if you ask me. Not everyone benefits from it. You will see compilers that have it on by default, but the bigger/bloated your word processor will be too for no particular reason. It just depends on the problem trying to be solved, and default settings will not always be the right way to go, regardless of what OS taste you have.

Not a good example of padding... In most cases padding is put between members, not after the last member

what about

Code:

---

#include <stdio.h>

struct test
{
        char a;
        int b;
};
int main(void)
{
        printf("&#37;d\n", sizeof(struct test));
        return 0;
}

---

The struct would be 5 bytes then. A better idea so its accessed in a DWORD boundary would be this...

Code:

---

struct test
{
        int ch;
        int n;
};

---

It wastes space since it's now 8 bytes, but it may be better for the Pentium if you're doing any high performance stuff. Theres less addressing havoc. I'm not sure what you mean with padding between members.

In all worst cases, given you have a compiler that doesn't help, you can give the struct dummy variables so it is 32-bit. The point is it doesn't matter how you do it, but as long as you do it when it comes to critical-performance applications. Never assume the compiler is doing it for you.

Quote:

---

The struct would be 5 bytes then

---

Have you tested it on VS2005? Because this compiler - that you claim does not do padding, shows the sizeof struct as 8

Yes. My point on that example was if you aren't padding for some odd reason, keep each member 32-bit if possible. 8 bytes is slightly better than the 5-byte example. Pentiums like 32-bit! Better yet, you can pad it with dummy variables if the compiler doesn't have alignment options. But that's getting pretty rare but I have seen them.

Anyway, this thread is getting a little off topic caused by me and others (it was about cpp files initially somewhere :)). Thanks for the conversation in text-mode.

I don't see why you want to make each var int if you do not need it.
Keep your types as you need. Leave compiler worry about padding.
When you come to size or speed issues - solve them.
The unconditional optimization - is evil ;)

That's the problem... people think the compiler knows what they are trying to do but it just ends up making horrible products.

You use two ints because you do need it in performance-critical applications.

int + char = (4 + 1) = 5 bytes.

The pentium is 32-bit. Do the math. You're going to wreck havoc in memory addressing. I come from a real-time programming background. I don't think it matters if you're doing event-driven software. There's no gain from keeping everything 32-bit as possible when building a word processor, so you can use as much horrible solutions as you want and let the compiler do all the default settings for you... no one will notice. That's the majority of the general software industry for you :)

I'm doing RT programming - and I know what I'm talking about... You think you smarter than the compiler... Take a profiler - and prove it... Otherwise - all your talking is just a blah-blah

Quote:

---

I'm not sure what you mean with padding between members.

---

An example would be:

Code:

---

struct test
{
    char a;
    int b;
    char c;
};

---

versus:

Code:

---

struct test
{
    int b;
    char a;
    char c;
};

---

On my machine both the MinGW port of g++ 3.4.2 and VS2005 pad such that the former takes 12 bytes and the latter 8 bytes.

I think that even without profiling this kind of rearrangement of members is reasonable. Unless you are crazy about listing members in alphabetical order or grouping them in specific ways, their order usually does not matter too much, so you might as well potentially save some space.

Quote:

---

Never assume the compiler is doing it for you.

---

I think that you should assume the compiler is doing for you, but check on it if it is critical.

Hmm, that is interesting. I'm getting 12 and 8 as well. Each structure has the same variables and data type, but its arrangement is adjusting the structure's size. I'm not understanding what it's doing internally. That will be worth looking into.

Vart, fit the problem you are trying to solve. If you're happy with the default settings, more power to you.

Quote:

---

I'm not understanding what it's doing internally

---

It adds padding to save the member alignment

Code:

---

struct test
{
    int b;
    char a;
    char c;
};

---

b ends on the WORD boundary that is as well the byte boundary, so a and c are located here without padding...

Code:

---

struct test
{
    char a;
    int b;
    char c;
};

---

a ends on the BYTE boundary but it is NOT a WORD boundary, so 3 bytes padding is added before b...

Quote:

---

I think that even without profiling this kind of rearrangement of members is reasonable.

---

I didn't say you need profiling to arrange struct members from bigger sizes to smalles to get to decrease the size of the struct for free...

But changing chars to ints just because you think it will work faster - you should prove it before applying such a change... You gain on the memory access speed - you loose in the cache utilization...

So you are smart :) That is quite interesting. Thanks for sharing about that.

Quote:

---

Originally Posted by philvaira

Hmm, that is interesting. I'm getting 12 and 8 as well. Each structure has the same variables and data type, but its arrangement is adjusting the structure's size. I'm not understanding what it's doing internally. That will be worth looking into.

---

Some of us may look dumb but we actually have half a clue.

The compiler cares about speed. The compiler also cares about memory usage. It pads structures based on both factors. In most cases the result is what you would also have wanted.

On quite a few platforms (most, actually), padding isn't even optional, because unaligned access isn't just slow, it's NOT POSSIBLE. x86 is one of the only chips I can think of that can read an unaligned 32-bit quantity.

EDIT: Also, messing with the padding automatically makes your code non-ABI-compliant. ALL code has to be compiled with the same padding options. For operating system traps and system calls which involve structures, this completely breaks. You have to match the padding the kernel is using.