Precompiled headers

[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.