# The importance of using implementation .cpp files over .h

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

## Recommended Posts

You can successfully compile source files with classes fully defined in a .h file. I know header files are used as the definition of classes and the source file (.cpp) is the implementation of the class.

In my code, classes that are used as 3rd party support are generally fully defined in a .h file. However, other code that are project-specific are defined in a .h and then implemented in a .cpp.

As someone with slight OCD, this doesn't feel consistent. So what how important is it to HAVE implementation (.cpp) files? They feel redundant!

##### Share on other sites
Incremental build times can suffer badly if too much is put in headers.

Why did you decide to fully define (which I assume means inline all member functions) in headers for stuff that isn't project-specific?

##### Share on other sites
Basically it's the concept that I type it all up in one sitting and I'm done because it's not the primary focus for my project. I didn't know .h functions were auto-inline. This is interesting news.

##### Share on other sites
Careful; it's not that all functions in a header file are implicitly inline. Member functions (including static member functions) are implicitly inline only if their declaration is also their definition. Template functions are also implicitly inline.

It might be worth spending a little time at becoming more familiar with internal and external linkage.

##### Share on other sites

It might be worth spending a little time at becoming more familiar with internal and external linkage.

See, never before has this sort of concept occurred to me. Looks like I should!

What about variables though? Is that ever a problem? Or is that where the keyword extern comes into use?

##### Share on other sites
Firstly note that implicit inlining needs a bit more discussion. Declaring and defining functions/methods at the same time is not generally good form. You should define inlined methods in the header file but outside (below) the class. While defining methods inside the class body implicitly means inlining, defining them below is still inlined, even if not implicit (it requires you to add the inline/__inline/whatever keyword, thus changing from implicit to explicit).

Variables? What kind? Class members?
Globals shouldn’t be an issue since you shouldn’t be using them.
But if for some reason you are, the easiest way is to add them as members of a class (static members) and define them in .CPP files. Without doing this, you have to muck about having it declared as extern to all but one translation unit (a .CPP file) and it is really just a mess.

L. Spiro

##### Share on other sites
Again, it depends how the variable is declared and if that declaration is also a definition, and the linkage of that definition.

For example, putting this in a header is not a good idea:

 int x = 4; 

This is because x has external linkage, and if the header is #included multiple times (across more than one translation unit), you will have violated the One Definition Rule. If you declare/define x as const, it will have internal linkage and everything will be fine. This will produce multiple 'x' objects, one per translation unit, but because they're const, this duplicity typically doesn't matter.

If you really only want one mutable 'x', you'll have to declare it extern and define it in a single translation unit:

 // header file // ... extern int x; 
 // implementation file // ... int x; 

1. 1
2. 2
frob
16
3. 3
4. 4
5. 5
JoeJ
10

• 20
• 13
• 14
• 76
• 22
• ### Forum Statistics

• Total Topics
632139
• Total Posts
3004369

×