Pros & Cons of putting all code in Header files in C++?

Question

You can structure a C++ program so that (almost) all the code resides in Header files. It essentially looks like a C# or Java program. However, you do need at least one

Answer 1

Well, as many have pointed out there is a lot of cons to this idea, but to balance out a bit and provide a pro, I would say that having some library code entirely in headers makes sense, since it will make it independent of other settings in the project it is used in.

For example, if one is trying to make use of different Open Source libraries they can be set to use different approaches for linking to your program - some may use the operating system's dynamically loaded library code, others is set to be statically linked; some may be set to use multithreading, while others is not. And it may very well be an overwhelming task for a programmer - especially with a time constraint - to try to sort these incompatible approches out.

All of that is however not an issue when using libraries that are contained entirely in headers. "It just works" for a reasonable well-written library.

Answer 2

You misunderstand how the language was intended to be used. .cpp files are really (or should be with the exception of inline and template code) the only modules of executable code you have in your system. .cpp files are compiled into object files that are then linked together. .h files exist solely for forward declaration of the code implemented in .cpp files.

This results in quicker compile time and smaller executable. It also looks considerably cleaner because you can get a quick overview of your class by looking at its .h declaration.

As for inline and template code - because both of these are used to generate code by the compiler and not the linker - they must always be available to the compiler per .cpp file. Therefore the only solution is to include it in your .h file.

However, I have developed a solution where I have my class declaration in a .h file, all template and inline code in a .inl file and all implementation of non template/inline code in my .cpp file. The .inl file is #included at the bottom of my .h file. This keeps things clean and consistent.

Answer 3

static-or-global-variable kludges even less transparent, perhaps un-debuggable.

for example counting the total number of iterations for analysis.

In MY kludged files putting such items at the top of the cpp file makes them easy to find.

By "perhaps un-debuggable", I mean that routinely I will put such a global into the WATCH window. Since it's always-in-scope the WATCH window can always get to it no matter where the program counter happens to be right now. By putting such variables outside a {} at the top of a header file you would let all downstream code "see" them. By putting them INSIDE a {}, offhand I would think the debugger will no longer consider them "in-scope" if your program-counter is outside the {}. Whereas with the kludge-global-at-Cpp-top, even though it might be global to the extent of showing up in your link-map-pdb-etc, without an extern-statement the other Cpp files can't get to it, avoiding accidental coupling.

Answer 4

One problem with code in headers is that it must be inlined, otherwise you will have multiple-definition problems when linking multiple translation units that include that same header.

The original question specified that there was only ever a single cpp in the project, but that is not the case if you're creating a component destined for a reusable library.

Therefore, in the interests of creating the most reusable and maintainable code as possible, only put inlined and inlinable code in header files.

Answer 5

If you are using template classes, you have to put the whole implementation in the header anyways...

Compiling the whole project in one go (through a single base .cpp file) should allow something like "Whole Program Optimisation" or "Cross-Module Optimisation", which is only available in a few advanced compilers. This is not really possible with a standard compiler if you are precompiling all your .cpp files into object files, then linking.

Answer 6

I disagree with point 1.

Yes, there is only one .cpp and the built time from scratch is faster. But, you rarely build from scratch. You make small changes, and it would need to recompile the whole project each time.

I prefer doing it the other way around:

• keep shared declarations in .h files
• keep definition for classes that are only used in one place in .cpp files

So, some of my .cpp files start looking like Java or C# code ;)

But, 'keeping stuff in .h' approach is good while designing the system, because of point 2. you made. I usually do that while I'm building the class hierarchy and later when code architecture becomes stable, I move code to .cpp files.