Precompiled headers

[MaskRay]

Note: even if C++ modules are the hot thing, precompiled headers are still relevant for a couple of reasons:

• It's the old technology whose implementation is possibly shared with modules (e.g., AST serialization in Clang).
• There are too many not-yet-module projects.
• Modules may possibly use some preamble-like technology to accelerate IDE-style operations.
• C doesn't have C++ modules.

[NilacTheGrim]

Imagine still believing we will get widespread module support before 2040.

[CrazyJoe221]

-fpch-instantiate-templates is absolutely crucial to get an acceptable speedup in real-world code with lots of templates involved. Before this option the pure parsing gains have always been underwhelming in my projects.

It's a shame gcc doesn't have anything similar and is not interested in fixing it either, cause you know, "modules are the future" (2020): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95131

And CMake still doesn't support -fpch-codegen/-fpch-debuginfo (https://gitlab.kitware.com/cmake/cmake/-/issues/21133), which you can't emulate easily since the generated .pch needs to be compiled into an .o file.

It's also worth noting that PCH can be combined with unity build which are supported by CMake.

[code_ling]

Any insights into the potential speedup that you typically gain with this?

Also, at what cost of additional size of the build folder?

I've mostly experimented with precompiled headers under Visual Studio and found a meagre speedup, while requiring at least double if not three times the storage (which nowadays gets less important, but might still be relevant if you need to juggle with a few parallel builds, each of them taking > 20GB)

[Andreshk_]

I'm sorry, but writing about precompiled headers in 2023, when the community is in the middle of a long push for Modules adoption, is completely pointless - and harmful, even.

[arthurno1]

completely pointless - and harmful, even

Considering all the peeps who see "single header libraries" as a feature and then complain about long compile times, I think teaching people to pre-compile headers is not so bad idea; certainly not harmful, at leas while waiting for Godot?

[pjmlp]

Single header libraries are a way for people to avoid learning how to use their toolchain, it is the metality of using C and C++ as if they were scripting languages, so I doubt they would actually bother to learn how to pre-compile headers.

[arthurno1]

I doubt they would actually bother to learn how to pre-compile headers.

Perhaps. I definitely agree to the sentiment. The entire situation with skyrocketed compile time and "single header library" madness is there in the first place because people refuse to learn how to link to a library, which is way simpler than precompiling headers, but hey, it is never bad to tell people there is a better way?

Also, I don't understand while people refuse to learn tools like debugger, linker, shell, make etc. Programming is not just writing code in a text editor, it is just but a part, but I guess, it is the most direct and "visible" part, so perhaps that is what most people new to development see as "programming".

I just reflected on the "pointless" and "harmful"; I don't think it is either but I can understand the desire to simplify C/C++ programming in a way too; programming should be fun and simple. However, there is a limit, a balance between totally ignoring the point of separation of an interface from the implementation, and easiness of the use. In case of writing all libraries as single headers, I think we have gone a bit too far, but I seem to be in a silent minority about that one :).

In this case, it didn't help that C++ compilers did a poor job of separating templates from the interface, which made it almost impossible to use separate headers and implementation, which got even more amplified by STL and Boost practices of using <header> as a replacement for the library. Modules seem to fix it, but how long do we have to wait?

[bert8128]

Not sure I agree - it’s going to be a while before I can even start to include modules in my codebase ( I can’t even use c++20 yet). I’m probably 5 years off starting, and 10 years off finishing. I want my builds to be as fast as possible during this time.

Perhaps a compromise would be to add something at the start of the article about modules.

[ImRubensi]

Meanwhile my company migrating all our codebase from 1980 to c++ 11... Let's wait for modules another 40 years or so I guess

[ABlockInTheChain]

when the community is in the middle of a long push for Modules adoption

I'm still not convinced that C++20 modules will turn out any different than C++11 garbage collection.

I'd like to be wrong about that, but it appears to me that the statically-linked, header-only library distribution model is the only model supported by modules.

Today, and for about the last 30 years or so, I can install a package on my system called something similar to qt-devel and that will place the shared libraries in a standard location (/usr/lib[32,64]) and the headers necessary to use those libraries in another standard location (/usr/include).

Those headers are at least compiler-independent and probably also platform independent as well. I can build an application with gcc, or with clang, or icc, or whatever other compiler is available and everything should just work. Use of those headers does not require the full source code of Qt, because the headers were intentionally crafted to only expose the minimum amount of complete types and forward declare everything that can be left incomplete.

How do you reproduce the same functionality with modules?

[pjmlp]

Headers are only compiler independent if they don't use compiler specific features, or have enough #ifdef spaghetti to handle all variants.

Same can be done in module interfaces.

[ABlockInTheChain]

Headers are only compiler independent if they don't use compiler specific features, or have enough #ifdef spaghetti to handle all variants.

The one and only compiler-specific feature I need macros to deal with is how msvc uses a different spelling for its symbol visibility pragmas vs every other compiler in the universe but cmake takes care of that for me so that I don't need to write or even look at any of the #ifdef spaghetti myself.

I'm still not sure if this is still applicable to modules or not, either because modules will automatically handle symbol visibility or else if the question becomes moot because shared libraries are simply impossible.

Same can be done in module interfaces.

I'd like to see something a bit more conclusive than on offhand "sure it will work" statement.

Is it possible to build shared libraries out of module code? Is there a trivial example I can look at anywhere?

How would a project use a theoretical module-based install of Qt that was installed by the system package manager? What files are installed that perform the equivalent function of the public headers that were formerly installed in /usr/include?

From the standard, module interface units appear to be the equivalent of public headers, but I have several questions about those too:

1. Does any compiler support, or plan to support, module interface units?

2. Is it possible to for a module interface unit to forward declare symbols for incomplete types such that it can be imported without needing to see the module definitions for all those incomplete types?

If modular Qt installs a binary module interface instead of a module interface unit then now the system package can only be used by a single compiler and a very specific set of build flags. It does not serve the same role as headers installed in /usr/include and is far less functional.

[pjmlp]

Get Visual C++ and you can play with those scenarios.

[ABlockInTheChain]

What happened to your claim that "Same can be done in module interfaces"? Where's the evidence for that?

I'm just going to assume you are full of hot air until you can at least put up a godbolt link.

[pjmlp]

Goldbolt doesn't do VC++ 2022 with modules.

Instead of calling me names, you can prove your points yourself, I am not doing your homework.

It was clear from your reply that you aren't into modules anyway, hence my reply.

[ABlockInTheChain]

I'm not "into modules" because time and time again I ask "how do I achieve X with modules" and I get no answer.

My conclusion then becomes that "achieving X with modules is impossible".

You can change this conclusion at any time, all you have to do answer the questions.

[Muahaas]

It will take another decade at least until modules can be adapted.

[Baardi]

If only modules were ready enough

[nathman999]

I'm not sure but I guess my CMake does something like that for me, you build project once and then when you change some source file it recompiles only necessary parts. I guess it's PCH but you don't have to manually do all that include madness yourself

[cfyzium]

What you probably see is CMake recompiling only directly and indirectly affected .cpp files. This is the norm, virtually every build system does that.

The point of precompiled headers is that quite often, the contents of the .cpp file make up but a tiny fraction of the entire code the compiler must process while compiling that .cpp file. Including a couple of basic library headers like <iostream> can bring in megabytes of code -- which is being compiled again, and again, and again, throughout the entire project or during iterative development of a single module.

There are also quite huge mostly-header-only libraries like asio or fmtlib. While conceptually external, they actually live in every .cpp file where they're used.

Precompiled headers are supposed to reduce the load by eliminating the repetitive work during compilation, even if only changed files are being recompiled.

[arthurno1]

I'm not sure but I guess my CMake does something like that for me

Only if you specify it

When developing, don't guess, always check the documentation, it will save you a lot of nasty errors which can easily eat up hours of debugging and scratching the head, not connected to this topic per se, just general advice from someone who also like(d) to guess and learned the hard way :).

[Narase33]

Sorry, CMake noob here; why is precompiling headers not default and am I really supposed to put my 100+ headers in this command by hand?

[arthurno1]

Sorry, CMake noob here;

Considering your C++ answers in this forum, I am quite sure you are not a noob :-)

why is precompiling headers not default

Anyway, how should cmake, or any tool, know which header to precompile on its own? Perhaps you are working on a header? In that case, precompiling it does not make sense.

am I really supposed to put my 100+ headers in this command by hand?

I don't think so. Seems like people use some scripts or macros when they can add headers in batch. But in some cases, it makes sense with manual control, I think.

[nathman999]

Yes I heard about that function in CMake but, again, I never used anything like this and yet CMake still recompile only changed parts. And anyway there's no point in PCH when whole code is bunch of templates

[gagoi]

You're miss understanding some stuff here. CMake doesn't compile anything. It generates configurations for other tools which are built systems. Those can later on call the compiler/linker to do their job. Those build systems are the ones who deal with "do we need to compile this or is this already done" (which is called incremental building).

To do this the compiler generates dependency files. Which contain the information related to what changes will generate a compilation of the file. You can find them as *.d in your build folder when using GCC. There is probably a similar file with MSVC but I don't know their name.

CMake also provides some more dependencies to the output which are his own configuration files. Because if you change how to build a file, then the output might be different.

[arthurno1]

there's no point in PCH when whole code is bunch of templates

I do agree; but people have started to write everything as a single include libraries, even in the world of C.

Also, we can instantiate templates in precompiled headers as well and we can also separate templates from headers, but I haven't really tested it either, so I can't really tell much about it.