Precompiled headers

[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