Headers - Cpp And H/hpp #include: "why" Question

Your question indicates that you don't understand the compilation process (most of this will apply to c as well as c++.)

The fundamental unit of compilation is a source file; for C++ the convention is to use the .cpp file extension. The extension could be anything, but most compilers use the extension to determine how to process the file, ex. .cpp means c++, .o means object, .c means straight c, etc. Source files are complied into object (nominally .obj or .o) files. Object files are linked together to create executable files.

The compiler doesn't know anything about header files. There is a pre-processor that replaces the #include directives with the content of the header file, and processes other pre-processor directives, the resulting output is what the compiler sees as input; this is the reason why headers are included in source files and not vice versa.

Header files aren't strictly necessary to compile source to object; they are a tool to manage complexity, organize and modularize your source files. As the other answers have explained, when foo.cpp needs to reference something in bar.cpp, say baz(), foo.cpp needs to have some descriptive information about baz() so it can generate a reference that the linker can resolve.

One could simply put this information in foo.cpp, but this would duplicate the information in bar.cpp. The solution to this duplication is to put all the descriptive information in another file, which we call a header file (nominally .h or .hpp.) With bar.h the information that needs to be included in foo.cpp and bar.cpp is only in one file, which is inserted into the file when the pre-processor finds the #include directive. This becomes invaluable as the complexity of the project increases.

Much of the compilation process is hidden behind an IDE or a makefile. Compiling a small project by hand will be very instructive in learning how the compilation process actually works. The first time I had to write a .makefile from scratch in school all mystery about the compilation process vanished; I had to learn all the details to accomplish the task.

Compiling and linking your example would be 3 operations, in two stages:

• Compile the source files:
  • Compile foo.cpp into foo.o (ex. gcc -c -o foo.o foo.cpp)
  • Compile bar.cpp into bar.o (ex. gcc -c -o bar.o bar.cpp)
• Link the object files:
  • link foo.o and bar.o into program (ex. gcc -o program foo.o bar.o)

During the compilation stage each file is processed individually. The resulting object files contain machine code and external references (things not in the source file, but located some other source file.)

The final step is to link the objects, this is when the references are resolved, if you forget to include the object file in the link command, it will fail with unresolved external references; this is the step where all the information is needed. Modern compilers can handle all those steps with a single command, but that hides the process.