Is it a good practice to always create a .cpp for each .h in a C++ project?

Some classes, like exceptions or templates, only need the header file (.h), often there is no .cpp related to them.

I have seen some projects were (for some classes) there aren't any .cpp files associated to the headers files, perhaps because the implementation is so short that it is done directly in the .h, or maybe for other reasons, such as template classes, where it is mandatory to include the implementation in the header.

What is your opinion, if a class is too short, sould I avoid creating a .cpp file and writing the code directly on the header file ? If the code is written in the he开发者_运维问答ader file, should I include an empty .cpp so the files in the project remains consistent ?

I wouldn't add unnecessary .cpp files. Each .cpp file you add must be compiled, which just slows down the build process.

In general, using your class will only require the header file anyways - I see no advantage to an "empty" .cpp file for consistency in the project.

Nope. If there's nothing that needs to be in the .cpp, you don't need one.

There is one advantage to always creates a .cpp for each .h, even when the former would be empty: it enforces at compile time that header files are self-contained. This is related with the guideline of including foo.h first in foo.cpp:

With the preferred ordering, if dir2/foo2.h omits any necessary includes, the build of dir/foo.cpp will break. Thus, this rule ensures that build breaks show up first for the people working on these files, not for innocent people in other packages.

Its really horses for courses:

• Header only classes: eg template classes
• Header and cpp: separates declaration from implementation.
• cpp only: your main() can live in one of these.

Header file only source code is sometimes the only way of writing re-useable templates. See boost for plenty of examples of this.

Header and cpp is more 'normal'. Its separates the declaration from the implementation and can speed up compilation when the compiler doesn't have to read implementations loads of times. You might want to start here and then see how the implementation goes and if the cpp file become empty you can delete it.
Another point here is that you will have your #include "foo.h" at the top of foo.cpp to prove that anyone else can do this and not have compiler errors.

Cpp only files. main() can live here, and I've put cppUnit test classes in files like this.

Rule of thumb, keep related class together in the same file. Majorly different Classes need to put into their own .hpp and .cpp files. The reason for this is in large projects you have up to 10,000 classes and to put that number of files infront of the user and IDE normally make things break.

There are very useful and successful libraries, like many in boost, that are header-only.

If some classes are short and seem to be inlineable, I tend to put them all together in types.h -- the only header which I don't consider to deserve a .cpp file.

However most classes outgrow both the chance to go into header only, and the chance to go into types.h.

Some examples from what I do. I consider class for implementation of three-dimensional vector Vector3 to deserve its .h and .cpp, despite being simple. But Position does not really deserve that; after all, it would even be a P.O.D. structure, if it weren't for that pesky getDistance() that I like implemented there.

So no -- not all classes deserve their .cpp and .h files. But most do, and those that don't definitely don't get to stand in a lone header. If they're so short to fit in header alone, either they cuddle together with other short classes, or go into the header of the class they're closely related to.

My rule of thumb is that any method I need more than one line of code to express goes into a .cpp file.

For a further discussion of this issue, you may want to check out this old question of mine: C++ code in header files. I don't think your question is an exact duplicate, but its close enough that you should read it.

Please also see this question - the header files should only be for declarations.

If you have compilable code included in multiple places (from your comment: "sould I avoid creating a .cpp file and writing the code directly on the header file ?"), it will be compiled each time (although you might have pre-compiled headers) and the linker will resolve (or not) the bloated object code.

Just because the class definition is small does not mean it should be in the header file unless the definition is also the same as the declaration - e.g. a pure virtual class or a simple type as mentioned in the other answer.