As far as I know, .cpp usually contains far more codes than .h, mainly because .cpp contain implementation details of functions instead of just one line of class member/method definition.

Here comes to my mind is a quite weird idea: is it good practice to write or migrate some contents or codes from .cpp to .h, in order to reduce the amount of codes in .cpp?

I know we should not write everything in header in order to:

  1. Prevent extra compile time when recompiling codes after content is changed in the header

  2. Prevent include one header from another header which is not necessary for every compile unit (i.e.:prevent header spaghetti)

but I think some contents can be moved to header "safely", such as function documentation and functions that fulfilling all conditions below:

  1. Rarely changed functions

  2. Simple or trivial functions (e.g.:setters and getters)

  3. Functions that does not lead to extra include statements in cpp

and the bonus advantage of moving functions to headers is we can declare those functions as inline which gains extra performance improvements.

Is it a good practice to narrow the line number difference between header and corresponding .cpp files?

  • 2
    You enumerated some conditions where your reasons for not putting code in headers don't apply as much. But as far as I can see, you don't name any reasons why code should be in headers.
    – user7043
    Commented Mar 29, 2016 at 7:08
  • 2
    The "bonus" is actually mandatory and not an advantage. The One Definition Rule requires that functions are defined once, unless defined inline. As headers are usually included more than once, any definition there would violate the ODR if not inline. As for actual inlining, that doesn't require they keyword inline.
    – MSalters
    Commented Mar 29, 2016 at 11:18
  • John Lakos' well known book "Large-scale C++ Software Design" is the canonical source on how to distribute C++ code on different source files, what to put in .h and what in .cpp. I recommend heavily to get a copy.
    – Doc Brown
    Commented Jun 6, 2017 at 6:06

2 Answers 2


There is no advantage in putting code in the headers just to balance the amount of code in headers and cpp files. Unless you find that aesthetically pleasing, I guess?

There are, however, a number of reasons for stuff to be in header files, mostly related to actually using said stuff in multiple compilation units. For example, if you want to allow the compiler to inline a function, or when you want to be able to use a template in multiple compilation units.

There are also very good reasons to avoid putting stuff in header files. Chief among those is that a change to a cpp file should only mean the recompilation of that cpp file (unless the interface has changed, but then you aren't changing only that file), while a change to a header file means the recompilation of all the files that directly or indirectly include it.


First, C++ (I mean at least C++11) is practically speaking slow to be compiled, in particular because the standard container library is mostly header-only code, and standard headers pull a lot of code (e.g. <vector> is pulling 10K lines on a recent Linux GCC 5!), and you'll better use standard containers quite often. A possible trick might be precompiled headers, but these have also disadvantages, and you practically need to have a single header (which is #include-ing a lot of system or library headers) to make that work well.

(if you have time -and you'll need a lot of it-, you might help the C++ standard committee -they do welcome constructive feedback- and contribute to C++ free software compilers like GCC or Clang/LLVM)

Then (unless you systematically enable link-time optimizations -which slows down compilation time a lot, e.g. by at least a factor of two-, e.g compile and link with g++ -flto -O2 on a recent GCC), a header needs to contain those functions which you want to be inlined, and practically speaking in genuine C++11 code you have a lot of inlined functions.

Some people (including some standard C++ library implementors) are physically separating some "implementation" part of the header in a separate file (but #include-d by some public header file), mostly for readability reasons. For example, on my GCC 5 Linux, /usr/include/c++/5/bits/deque.tcc is indirectly included from <deque> (and other) header.

Future C++ standards might define some module mechanism (but not in C++17!)

Is it a good practice to narrow the line number difference between header and corresponding cpp files?

I am not a native English speaker, so I have hard time understanding what you really mean, but I guess that you are referring to have quite large header files (perhaps #include-ing some "implementation detail" headers). That is ok. In particular, templates practically need to be mostly implemented in header files.

  • extremely disappointed the C++ committee doesn't want to look at the toolchain over obscure language features.
    – gbjbaanb
    Commented Mar 29, 2016 at 7:37
  • 2
    @gbjbaanb: What are you referring to? BTW, you might consider helping the C++ committee (and perhaps becoming part of it), but that takes a lot of your time. Are you willing to spend it? I won't dare criticizing the C++ standard committee. It is a difficult job and they have a lot of legacy constraints. Commented Mar 29, 2016 at 7:39
  • The committee doesn't meet anywhere near me. I was referring to modules support. I don't think standardising things like that would affect much legacy code at all, but easier compilation and "packaging" would make a huge difference. I did once try to explain why an ABI would be a good thing to Bjarne but he simply dismissed it as difficult to get the compiler makers to co-operate.
    – gbjbaanb
    Commented Mar 29, 2016 at 7:48
  • 2
    Yes, that are the issues. Contributing to standardization or to compiler implementation practically requires at least a half-time job. Do you have the time & resources for that? If you don't, perhaps try to respect the work of those who do... And I don't understand why an ABI would be a good thing... Commented Mar 29, 2016 at 7:49
  • 2
    @gbjbaanb: It's the ISO C++ committee, literally a global organization. It is onl;y to be expected that their meetings are on average thousands of kilometers away. If you want to campaign for an ABI, don't start with Bjarne but with Microsoft. But note that your argument is a bit weak. There is no fundamental reason why vector has to be 10K lines. it could be one line, __magic vector, and still be conformant.
    – MSalters
    Commented Mar 29, 2016 at 11:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.