Why would I compile 2 C/++ source files instead of using a header file?

Question

I've recently started learning about makefiles, and the video I'm watching includes a compilation if two source files and a header file. A class was defined in the header file, which was included in both source files. A method for the class was defined in one source file and was called in the second (main.cpp). Why would I ever need to have 2 source files (.c/.cpp)?

Answer 1

Every time you make any change to a header file every file that includes it must be recompiled, but if you change a source file only that source file needs to be recompiled.

When working on a project of non-trivial size this can dramatically reduce compilation times. Since most of your work is typically done on the implementation side, where modifications to header files are less frequent than to source files, most recompilation will be localized.

You'll also want to split up your source into separate files for reasons of navigability. Working through a 2000+ line source file is a lot more hassle than 10 files around 200 lines each. This is even more important when version control kicks in and you're working on a team, as then merge conflicts are reduced.

Imagine if Chrome was just a singular .cpp file. Making even the most trivial of changes to it would require recompiling the whole thing, which even on a well-equipped machine is going to take 6-12 hours. Compiling a single source file and re-linking is, by comparison, on the order of minutes.

In practice you'll often have one class per source file with a corresponding header file. Functions are grouped together logically into sets, each in their own pair of header/source files.

Answer 2

The human mind can't hold very much information at a time, so we chop things up into smaller, logical and coherent pieces.

OK. So one main.cpp that includes the dozens or hundreds or thousands files in the program, all implemented in header files of a reasonable size, each covering one concept or aggregating more headers files should that one concept be too broad to be easily be described¹ in a single header. Problem solved, right? Yup. But that's only one problem.

What about resource consumption?

It's helpful to read How does the compilation/linking process work? before continuing.

During preprocessing every include statement is replaced with the contents of the included file. The result is one mammoth file that's fed into the compiler. That takes up a lot of memory. Further, if one file includes everything as headers, then every time you make a change, no matter how small, this one file will need to be be built. It will include the project's worth of headers and that one change causes ALL of the files to be recompiled. This gets very time consuming.

Memory keeps getting cheaper, so constraining the first resource isn't as important as it was in the 1970s when all of this was being invented². Still rears it's ugly head from time to time. That's why I cross compile on a big, fat PC rather than building code directly on a Raspberry Pi.

Time doesn't get cheaper. Never has, never will.

But if you follow the best practices and headers contain an interface (what it does) rather than an implementation (how it does it) you'll find that the header doesn't change much. What changes most of the time is the how-to details in the implementation files. A small change is confined to the one implementation file that provides that changed behaviour. Likely this is the only file that needs to be recompiled. This is a huge improvement from every file every time to one or two files every time.

On the rare occasions where the interface changes, well, you suck it up.

¹ Because that's what code is: A description of behaviour. It's not a list of instructions for the computer to execute--that's the compiler output--it's a description of the behaviour of the program. The compiler's job is to turn your description onto the instructions.

² This also explains why building in more recently created languages is much less complicated³. They don't have baggage left over from having to make things work in the glorious days of 1/2 K ram and a CPUs clocked in the kilohertz. They also learned from a lot of mistakes.

³ For the end user, anyway. The back end of a modern build system is some crazy code, man.