18
votes

For years I've been coding C++ in the standard way, with class declarations in header files .hpp and the function definitions in source .cpp files. Recently I moved to a new company where the code (seemingly influenced by boost coding styles) is entirely coded in .hpp files with one short .cpp file to include the header files and create the object/program binary.

It got me thinking - what are the strengths/weaknesses of writing your code in header files as opposed to writing a .hpp & .cpp file for each object? This assumes our project doesn't create common libraries that are then linked into the program binaries, but instead each program binary is built from the sum of the header files (and one source .cpp file). Is this a new trend in C++?

E.g. Template objects need to be header only, but it could seem a good idea to put non-template classes into header files and then simply include these common project classes in your binary(s). Assuming you're creating a new codebase from scratch, would it mean less linking, which might mean less linking errors and possibly faster builds. Would pre-compiled headers facilities also mean using header files speeds up build time? Or are build times longer because we now need to compile all code when creating a binary rather than linking common shared library objects?

Also note we're not writing an API here (in which case something like the pimpl idiom would give us more flexibility by hiding implementation), we're writing programs to run on a customer site.

Thanks in advance,

3
Faster full builds? I don't know. But with this scheme you always get full builds.R. Martinho Fernandes
Yea full builds are the only option given the fact that the only source file creates the final binaryGary Robinson

3 Answers

11
votes

Off the top of my head:

Strengths:

  • implementation visible (more of a weakness, but depends on the case)
  • no need to export to a library
  • better chance for the compiler to optimize some of the code

Weaknesses:

  • implementation visible
  • slower build time
  • bloated header files
  • a change in implementation would require a full rebuild, having the implementation in an implementation file does not (only compile that specific file or library)
  • In case of circular dependencies, you use forward-declarations and only include the full type in the implementation file. If all you have is a header, this is no longer possible.

I'm sure there are others, I'll edit if I can think of any more.

1
votes

Header only libraries tend to make the build system easier, and generally you need to care less about dependencies.

On the other hand moving code to implementation files make it easier to control module boundaries and create exchangeable binary modules, which can improve incremental builds. The cost is more "housekeeping". My hunch is to prefer implementation files, and there are some data points that back me up, like this blog post from the Author of the proposed Boost Networking Library.

0
votes

Common libraries are one thing, general reusability of code is another. If you want to use some of the code you've written in another project, you may have to copy'n'paste huge chunks of code and then maintain the separate codebases. The compile time will get longer, because the program will be a one big compile unit as opposed to many cpp/h files, where only these, who include modified header file will be recompiled. For instance, full build of application I'm currently working on takes 7 minutes. A recompilation takes ~ fifteen seconds, if the changes are not severe. Finally, the code may tend to be less readable. Header file gives you quick glance of what the class is created for and how to use it. If classes are written inplace, you'll have to unnecessarily dig through the source code.