Re: What sense do h files make in c/cpp?

xz wrote:


1) You often want to create functions, types and constants which
are local to one compilation unit and which you don't want
interfering with the rest of the program. For example, you might
want to have something like this in a cpp file:

namespace { const int LOOPS = 42; }

and you want that to be local to the current cpp file and not seen
anywhere else. You don't need to worry if some other cpp also uses
the name "LOOPS" for something completely different.

2) Related to 1, but more generally: By exposing the entire cpp file
to other cpp files, you are breaking the principle of minimal public
interfaces. A header file should contain as little code as possible:
That is, the public interface of that module and the bare minimum
implementation details enforced by technical reasons of the compiler.
All the implementation details which are not necessary in the header
file for technical reasons should be "hidden" in the cpp file. This
increases abstraction and modularity, which is good in the long run.

3) For technical reasons, if you are going to include a cpp file in
more than one other cpp file, all the functions in that cpp file must
be 'inline' or else you will get linker errors because of duplicate
implementations.

4) Related to that: If you have a static member variable or a static
variable local to that cpp file (usually inside a nameless namespace
or such), you *will* get a linker error if you include the cpp file in
more than one other cpp file. That's because the linker will see two
instances of that static variable and has no way of knowing which one
it should use. You can't "inline" static variables as you can do with
functions.

5) Compiling each cpp file separately (and keeping all headers as
minimal as possible and with as few #includes as possible) will
greatly speed compilation times in large projects. Usually if you
just modify one cpp file then the compiler just has to recompile
that cpp file and then it can link everything into the final binary.
If, however, that cpp file was included in dozens of other cpp files,
which in turn are included in dozens of others and so on, modifying
one cpp file may suddenly require for the compiler to recompile most
of the others too, for no good reason. With very large projects that
could take hours instead of a few seconds.

6) Likewise, compiling one cpp file would take much longer if it
includes dozens of other cpp files (which themselves include dozens
of others and so on).

7) If module A references module B, and module B references module A,
you have a problem. With minimal headers this problem can usually
be solved (as long at least one of A or B uses only references/pointers
to the other). However, if you always included the cpp files, you would
have no solution to this problem.

8) Header/source file pairs is not the only possible way of compiling.
Bunch-of-headers/big-precompiled-library is another very common
situation (which is actually almost always the case with the standard
libraries of the compiler). There's no reason why you would want to
have the entire source code of the library when just the headers are
enough to use it.