Why not concatenate C source files before compilation? [duplicate]

Answer 1

While you can still write your program in a modular way and build it as a single translation unit, you will miss all the mechanisms C provides to enforce that modularity. With multiple translation units you have fine control on your modules' interfaces by using e.g. extern and static keywords.

By merging your code into a single translation unit, you will miss any modularity issues you might have because the compiler won't warn you about them. In a big project this will eventually result in unintended dependencies spreading around. In the end, you will have trouble changing any module without creating global side-effects in other modules.

Answer 2

Your approach of concatenating .c files is completely broken:

• Even though the command cat *.c > to_compile.c will put all functions into a single file, order matters: You must have each function declared before its first use.

  That is, you have dependencies between your .c files which force a certain order. If your concatenation command fails to honor this order, you won't be able to compile the result.

  Also, if you have two functions that recursively use each other, there is absolutely no way around writing a forward declaration for at least one of the two. You may as well put those forward declarations into a header file where people expect to find them.

• When you concatenate everything into a single file, you force a full rebuild whenever a single line in your project changes.

  With the classic .c/.h split compilation approach, a change in the implementation of a function necessitates recompilation of exactly one file, while a change in a header necessitates recompilation of the files that actually include this header. This can easily speed up the rebuild after a small change by a factor of 100 or more (depending on the count of .c files).

• You loose all the ability for parallel compilation when you concatenate everything into a single file.

  Have a big fat 12 core processor with hyper-threading enabled? Pity, your concatenated source file is compiled by a single thread. You just lost a speedup of a factor greater than 20... Ok, this is an extreme example, but I have build software with make -j16 already, and I tell you, it can make a huge difference.

• Compilation times are generally not linear.

  Usually compilers contain at least some algorithms that have a quadratic runtime behavior. Consequently, there is usually some threshold from which on aggregated compilation is actually slower than compilation of the independent parts.

  Obviously, the precise location of this threshold depends on the compiler and the optimization flags you pass to it, but I have seen a compiler take over half an hour on a single huge source file. You don't want to have such an obstacle in your change-compile-test loop.

Make no mistake: Even though it comes with all these problems, there are people who use .c file concatenation in practice, and some C++ programmers get pretty much to the same point by moving everything into templates (so that the implementation is found in the .hpp file and there is no associated .cpp file), letting the preprocessor do the concatenation. I fail to see how they can ignore these problems, but they do.

Also note, that many of these problems only become apparent with larger project sizes. If your project is less than 5000 lines of code, it's still relatively irrelevant how you compile it. But when you have more than 50000 lines of code, you definitely want a build system that supports incremental and parallel builds. Otherwise, you are wasting your working time.

Answer 3

You could do that, but we like to separate C programs into separate translation units, chiefly because:

1. It speeds up builds. You only need to rebuild the files that have changed, and those can be linked with other compiled files to form the final program.

2. The C standard library consists of pre-compiled components. Would you really want to have to recompile all that?

3. It's easier to collaborate with other programmers if the code base is split up into different files.

Answer 4

This means that I don't have to write a header file for each function I create (because they're already in the main source file) and it also means I don't have to include the standard libraries in each file I create. This seems like a great idea to me!

The pros you noticed are actually a reason why this is sometimes done in a smaller scale.

For large programs, it's impractical. Like other good answers mentioned, this can increase build times substantially.

However, it can be used to break up a translation unit into smaller bits, which share access to functions in a way reminiscent of Java's package accessibility.

The way the above is achieved involves some discipline and help from the preprocessor.

For example, you can break your translation unit into two files:

// a.c

static void utility() {
}

static void a_func() {
  utility();
}

// b.c

static void b_func() {
  utility();
}

Now you add a file for your translation unit:

// ab.c

static void utility();

#include "a.c"
#include "b.c"

And your build system doesn't build either a.c or b.c, but instead builds only ab.o out of ab.c.

What does ab.c accomplish?

It includes both files to generate a single translation unit, and provides a prototype for the utility. So that the code in both a.c and b.c could see it, regardless of the order in which they are included, and without requiring the function to be extern.