4

I understand and very much appreciate the practice of separating header (.h, .hpp) and source files (.cpp).

However, many simple classes can be expressed entirely in the header file itself. I could define some methods within the class and others (e.g. template methods, inline methods) below the class.

What advantage is there to creating a .cpp file when I could just declare and define the entire class in the header file? (Do I even need to?)

Rapptz
  • 20,807
  • 5
  • 72
  • 86
jvriesem
  • 1,859
  • 3
  • 18
  • 40
  • 5
    Potentially faster compilation. In their cpp file the implementations are compiled once, not every time the header is included. – user4581301 May 11 '20 at 16:09
  • 1
    For small classes there is no reason to seperate definitions into a .cpp file. I feel like C++ projects are hard to navigate through anyway without having to separate every tiny class into two files. It's all opinion-based anyway. – DeiDei May 11 '20 at 16:13
  • 1
    https://stackoverflow.com/questions/1305947/why-does-c-need-a-separate-header-file https://stackoverflow.com/questions/333889/why-have-header-files-and-cpp-files – Mat May 11 '20 at 16:18

4 Answers4

8

If you have the code in the header file, whenever the header changes, the client code that includes the header must also be recompiled. With a separate cpp file, only re-linking is needed. On large projects, the difference may be in hours.

Putting the code in the .cpp file hides it from the user, if you build a library and distribute only the header file. Sometimes this is necessary.

By having a header file, you can leave the client code unchanged and replace the library (say between debug and release, or regular and call-tracing versions). This is useful for debugging or investigating problems.

Leaving the header file aside makes for a smaller file that is easier to understand by the class user. You can hide complexity away in the .cpp file.

Jeffrey
  • 11,063
  • 1
  • 21
  • 42
1

As already mentioned compilation time is one reason for having separate translation units. Especially if you have many cores parallelization can dramatically decrease compile time. Another reason is that non-template classes and functions as well as variables in header files would lead to duplicate symbols when included in different translation units. As soon as you use virtual functions inlining is no viable option.

You could use templates to avoid the duplicate symbol issue but in addition to higher compilation times this also leads to higher linking time because the linker has to collapse the template-instances (see https://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html). Nevertheless STL and many other header-only libraries do exactly this.

Markus Lenger
  • 521
  • 5
  • 7
0

Nothing holds you back from having everything in header files. But doing otherwise can have various effects on the project itself, in certain cases improving readability and positively improving compilation speed due to not having compile everything that has a dependency on files you just made changes to.

Usually, for small classes or classes which change very rarely, it has almost no impact whatsoever.

I would note that with > c++20 and inclusion of modules things will slowly change and we will start seeing more code that is purely written in header files (if they will still be called like that).

Nonetheless, it is too opinion based question to have a good answer.

Quest
  • 2,764
  • 1
  • 22
  • 44
0

Compilation speed. Keeping implementation away from definition gives you flexibility of modifying small code without having to re-compile all sources which include that header. This is the way a makefile work, it detects changes in the prerequisites.

Tony Tannous
  • 14,154
  • 10
  • 50
  • 86