from Hacker News

The C++ Build Process Explained

by green7ea on 11/14/18, 9:27 PM with 126 comments

• by wahern on 11/15/18, 5:38 AM

  > You could put a function's definition in every source file that needs it but that's a terrible idea since the definition has to be the same everywhere if you want anything to work. Instead of having the same definition everywhere, we put the definition in a common file and include it where it is necessary. This common file is what we known as a header.

  In C and C++ parlance "definition" should be "declaration" and "implementation" should be "definition".[1] The terminology is important if you don't want to get confused when learning more about C and C++. This is compounded by the fact that some languages describe these roles in the author's original terms. (Perhaps the author's terminology reflects his own confusion in this regard?)

  [1] This is indisputable given the surrounding context, but I didn't want to paste 3-4 whole paragraphs.

• by aidenn0 on 11/15/18, 12:03 AM

  If anybody is curious about how templates work, there are many ways, but the two most historically popular are:

  Prelinker:

  1. Compile each file, noting which templates are needed in a section in the object file

  2. Have a special program called the "prelinker" run before the linker that reads each .o file, and then somehow instantiates each template (which usually, but not always requires reparsing the C++ file)

  Weak Symbols:

  1. When compiling instantiate every needed template, but mark it somehow in the object file as being weak, so that the linker only pulls in one instantiation for each definition.

  The prelinker used to be more popular, as if you e.g. instantiate the same template in every single file, your compiler does tons more work with the weak symbols approach, but now weak symbols are popular both because they are much simpler to implement and the fact that compilation is usually parallel, while linker is typically not means that walk clock times may even be faster.

• by tiagoma on 11/15/18, 12:55 AM

  Watch this: https://www.youtube.com/watch?v=dOfucXtyEsU

• by amelius on 11/14/18, 10:14 PM

  Aside, C++ would have been so much nicer without the need for header files ...

• by crumbshot on 11/15/18, 1:04 PM

  The section describing how a function call is made appears to be slightly incorrect.

  The return value of the `add` function, in most ABI definitions, would be stored in a register. After that, the `main` function may then copy that value to its own space it has reserved on the stack.

  This is at odds with the description in the article, which seems to describe `add` passing its return value to `main` via the stack.

  (This is assuming no optimizations - all this would most likely be inlined anyway, with no function call.)

• by joker3 on 11/14/18, 11:17 PM

  I've been looking for something like this to send to some C++ newbies. This is almost what I need but not exactly. Is there something similar that explains how libraries work?

• by roel_v on 11/15/18, 8:34 AM

  "Basically, the compiler has a state which can be modified by these directives. Since every .c file is treated independently, every .c file that is being compiled has its own state. The headers that are included modify that file's state. The pre-processor works at a string level and replaces the tags in the source file by the result of basic functions based on the state of the compiler."

  I almost sort of get what the author means here but then I don't really. I mean, there is no 'state' for the compiler that is modified by precompiler directives, so this is probably an analogy or simplification he's making here, but I don't really understand how he gets to the mental image of 'compiler state'. Why not just say it like it is: the preprocessor generates long-assed .i (or whatever) 'files' in memory before the actual compiler compiles them, the content of which can be different between compilation units, because preprocessor preconditions might vary between compilation units?

• by marco_craveiro on 11/15/18, 9:51 AM

  Bit of a side-question, but somewhat related. Is anyone working on "whole program compilation"? I don't mean whole program optimisation, I mean an attempt to read all files for a given target in memory at the same time and then generate all translation units in one go (all in memory? and maybe linking them in memory too?). Clearly, there would be caveats (strange header inclusion techniques relying on macros to modify text of include files would break, gigantic use of memory and so forth), but for those willing to take the risk, presumably this should result in faster builds right?

  In fact, ideally you'd even generate all binaries for a project in one go but that may be taking it a step too far :-)

  At any rate, I searched google scholar for any experience reports on this and found nothing. It must have a more technical name I guess...

• by Const-me on 11/15/18, 11:32 AM

  I don’t think that article’s accurate. At least not anymore. Modern C++ compilers do less while compiling, and much more while linking. This allows them to inline more stuff and apply some other optimizations.

  VC++ calls that thing “Link-time Code Generation”: https://docs.microsoft.com/en-us/cpp/build/reference/ltcg-li...

  LLVM calls it “Link Time Optimization”, pretty similar: http://llvm.org/docs/LinkTimeOptimization.html

• by leni536 on 11/15/18, 10:00 AM

  I just watched Matt Godbolt's recent talk about the linking process[1]. It's a pretty good talk.

  [1] https://www.youtube.com/watch?v=dOfucXtyEsU

• by IloveHN84 on 11/15/18, 12:03 PM

  I hope someday the build and linking process could be standardized, but I don't believe it will happen, because many members of the committee come from Microsoft, Google and other tech giant who want to sell their compiler (or give it for free, but still).

  There are too much Interests and the standardization would kill many of them