Why are function bodies in C/C++ placed in separate source code files instead of headers?

Question

For instance, when I define a class file in C++ I've always put the function bodies in the class header files (.h) along with the class definition. The source code file (.cpp) is the one with the main() function. Now is this commonly done among pro c++ programmers or do they follow the convention of separate header/source code files.

As for native C, I do notice then done in GCC (and of course for the headers in Visual Studio for Windows).

So is this just a convention? Or is there a reason for this?

Fula

This is just convention. – Cabalistic

@JakeFreeman: Conventions often have reasons. In this case, there's absolutely really good reasons – Tropaeolin

See: #875979 – Anasarca

Think about it. If you put everything in your header files, this must mean that you only have only one .cpp with your main() that must include, directly, indirectly the entire code. That may work for small programs, but good luck compiling the Linux kernel, this way. – Cutty

It is not "just a convention". Both do different things so the programmer makes the appropriate choice. See AnT's answer. – Pendergrass

Answer 1

Function bodies are placed into .cpp files to achieve the following:

1. To make the compiler parse and compile them only once, as opposed to forcing it to compile them again, again and again everywhere the header file is included. Additionally, in case of header implementation linker will later have to detect and eliminate identical external-linkage functions arriving in different object files.

   Header pre-compilation facilities implemented by many modern compilers might significantly reduce the wasted effort required for repetitive recompilation of the same header file, but they don't entirely eliminate the issue.

2. To hide the implementations of these functions from the future users of the module or library. Implementation hiding techniques help to enforce certain programming discipline, which reduces parasitic inter-dependencies between modules and thus leads to cleaner code and faster compilation times.

   I'd even say that even if users have access to full source code of the library (i.e. nothing is really "hidden" from them), clean separation between what is supposed to be visible through header files and what is not supposed to be visible is beneficial to library's self-documenting properties (although such separation is achievable in header-only libraries as well).

3. To make some functions "invisible" to the outside world (i.e. internal linkage, not immediately relevant to your example with class methods).

4. Non-inline functions residing in a specific translation unit can be subjected to certain context-dependent optimizations. For example, two different functions with identical tail portions can end up "sharing" the machine code implementing these identical tails.

   Functions declared as inline in header files are compiled multiple times in different translation units (i.e. in different contexts) and have to be eliminated by the linker later, which makes it more difficult (if at all possible) to take advantage of such optimization opportunities.

5. Other reasons I might have missed.

Jemmy

Also so that libraries can be distributed with their corresponding headers so that others may use them in their code. – Bivalve

Excellent answer. Thanks for explaining the actual reasoning behind it as it isn't just convention but computational efficiency. – Fula

Summary is excellent as is the username to avoid the old Novichok in the underwear problem ... :) – Birr

Answer 2

It is a convention but it also depends on the specific needs. For example if you are writing a library that you want the functionality to be fast (inline) and you are designing the library for others to use to be a simple header only library, then you can write all of your code within the header file(s) itself.

On the other hand; if you are writing a library that will be linked either statically or dynamically and you are trying to encapsulate internal object data from the user. Your functions - class member functions etc. would be written in a manner that they do what they are supposed to do so as to where the user of your library code shouldn't have to worry about the actual implementation details for that part is hidden. All they would need to know about your functions and classes are their interfaces. It would be in this manner that you would have both header files and implementation files.

If you place your function definitions in the header files along with their declarations, they will be inline and should run faster however your executable will be larger and they will have to be compiled every time. The implementation details are also exposed to the user.

If you place your function definitions in the header's related code file they will not be inline, your code will be smaller, it may run a little slower, but you should only have to compile them once. The implementation details are hidden and abstracted away from the user.

Washboard

Answer 3

There is absolutely no reason to put function bodies in header files in 'c'. If the header file is included in multiple 'c' files, this would force the compiler to define the function multiple times. If the function is 'static', there will be multiple copies of it in the program, if it is global, the linker will complain.

Similar reasoning is for c++. The exception is for 'inline' members of the class and some template implementations.

If you define a temporary class in your 'cpp' file, it is perfectly ok to define it there and have function bodies defined inside the class.

Listed

Very concise answer. Tahnks. – Fula