源代码构建混乱（预处理和链接）

Question

Why is it that during the preprocessing step, the #includes in a main file are only replaced with the contents of the relevant header files (and not the function definitions as well (.cpp files))?

I would think that during this step it should first go into the header files and replace the #includes there with the contents of their associated .cpp files and then and only then go back to replace the #includes in the main file with everything, thus negating the need for any linking (one giant file with everything). Why does it not happen this way?

Answer 1

Why is it that during the preprocessing step, the #includes in a main file are only replaced with the contents of the relevant header files (and not the function definitions as well (.cpp files))?

Simply put, the header files are the only files you've told the preprocessor about. It can't assume the names of the source files, because there could be many source files for any given header. You may be thinking "Hey, why don't I just include the source files?" and I'm here to tell you No! Bad! Besides, who's to say that you have access to the source files in the first place?

The only way for the compiler to know about and compile all of your source files is for you to pass the compiler each source file, have it compile them into objects, and link together those objects into a library or executable.

Answer 2

There's a great difference between compiling and linking :

Pre-processor, Pre-compile-time and Compile-time:

The pre-processor check for # symbol and replaces it with the relevant content eg:

#include <iostream> // the content will be replaced here and this line will be removed

So the content of iostream will be added above.

eg2:

#define PI 3.14 // wherever PI is used in your source file the macro will be expanded replacing each PI with the constant value 3.14 

The compiler only checks for syntax errors, functions prototypes ... and doesn't care about the body of functions, resulting in an .obj file`.

Link-time:

The linker links these obj files with the relevant libraries, and in this very time functions called must have a definition; without a definition will issue in a link-time error.

Answer 3

Why does it not happen this way?

History and the expectations of experienced programmers, and their experience with bigger programs (see last statements, below)

---

I would think that during this step it should first go into the header files and replace the #includes there with the contents of their associated .cpp files ...

If you accept a job coding in C++, your company will provide to you a coding standard detailing guide lines or rules which you will want to follow, or face defending your choices when you deviate from them.

You might take some time now to look at available coding standards. For example, try studying the Google C++ Style Guide (I don't particularly like or dislike this one, its just easy to remember). A simple google search can also find several coding standards. Adding a 'why conform to coding standard?' to your search might provide some info.

---

negating the need for any linking (one giant file with everything).

Note: this approach can not eliminate linking with compiler tools or 3rd party provided libraries. I often use -lrt, and -pthread, and some times -lncurses, -lgmp, -lgmpxx, etc.

For now, as an experiment, you can manually achieve the giant file approach (which I often do for my smaller trial and development of private tools).

Consider:

if main.cc has:

#include "./Foo.hh" // << note .hh file

int main(int argc, char* argv[])
{
   Foo  foo(argc, argv);

   foo.show();   
...

and Foo.cc has

#include "./Foo.hh"  // << note .hh file

// Foo implementation

This is the common pattern (no, not the pattern book pattern), and will require you link together Foo.o and main, which is trivial enough for small builds, but still something more to do.

The 'small'-ness allows you to use #include to create your 'one giant file with everything' easily:

change main to

#include "./Foo.cc"   // << note .cc also pulls in  .hh
                      // (prepare for blow back on this idea)    

int main(int argc, char* argv[])
{
   Foo  foo(argc, argv);

   foo.show();   
...

The compiler sees all the code in one compilation unit. No linking of local .o's needed (but still library linking).

---

Note, I do not recommend this. Why?

Probably the primary reason is that many of my tools have 100's of objects (ie. 100's of .cc files). That single 'giant' file can be quite giant.

For most development churn (ie early bug fixes), ONLY one or TWO of the .cc files gets changes. Recompiling all of the source code can be a big waste of your time, and your compiler's time.

The alternative is what the experience developers have already learned:

A) Compiling the much smaller number of .cc's that have changed (perhaps one or two?),

B) then linking them with the 100's of other .o's that have not changed is much quicker build.

A major key to your productivity is to minimize your edit-compile-debug duration. A and B and a good editor are important to this development iteration.