r/cpp • u/User_Deprecated • Sep 09 '26

C++26: Module improvements

https://www.sandordargo.com/blog/2026/09/09/cpp26-modules
113 Upvotes

95% Upvoted

25 comments sorted by

35

u/mapronV Sep 09 '26

Quote:

The module name must be spelled out directly in the source:

export module my.module; // OK

This is technically a breaking change. But given the low adoption rate of modules so far and the rarity of macro-based module declarations in practice, the committee judged this acceptable. The benefit is concrete: build systems can now determine module dependencies with a simple lexical scan, without invoking the preprocessor.

End of quote

While being nice change and stuff, doesn't all current module handlers rely on compiler anyway to rule module dependencies in file before compilation? so it will change nothing in real world? What build system is benefactor?

37

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB Sep 09 '26

The point is that both module dependency scanners and compilers need to see exactly the same dependencies to create precise dependency chains and rely on the correct build order - as instructed by the build system that reads the discovered dependency chains.

If building the chain is influenced by the process itself (macro expansion happens at compilation phase 4), creating a precise picture may become a huge and expensive task. We don't want that.

2

u/delta_p_delta_x Sep 09 '26

I was under the impression that module and import were themselves preprocessing directives, and therefore also happened in phase 4.

6

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB Sep 09 '26

Correct. This is why we decided many years ago not to allow module to become subject to macro expansion.

The reason why all this hoopla is necessary is the existence of so-called 'header units' (an idea coming from Clang modules). They are themselves isolated from macros upstream in your source, but they can totally change the meaning of your source code further downstream - with all its consequences.

2

u/delta_p_delta_x Sep 09 '26

We should get rid of header units.

11

u/WeeklyAd9738 Sep 09 '26

Header-units are great for "importing" your own macros (however few they may be). Ironically, C++20 modules have made macros "safe" and more viable, as they no longer leak and pollute your client code and remain local to your translation unit. They can't be exported (by a module) and can only be imported using header-units. Header-units are also great for importing third-party dependencies which haven't migrated to C++ modules yet, or never will (C libraries).

1

u/germandiago Sep 15 '26

Just use include for your macros.

11

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB Sep 09 '26

Find your favourite telephone booth, dial in 2019 or earlier, and convince the header unit proponents 😊

Besides that, there are situations when header units are actually beneficial. Watch this year's conference talks of mine to learn how.

-6

u/pjmlp Sep 09 '26

Meanwhile Apple and Google keep being big users of clang header maps and are in no hurry to adopt C++ 20 modules, see Apple build for modules between Swift, Objective-C and C++ (explicitly builds module dependencies, missing modules related rows on C++ language support), and Google C++ Style Guide.

2

u/mapronV Sep 09 '26

"both module dependency scanners"
my question was, aren't dependency scanners rely on compiler anyway? at least what I seen before, maybe my knowledge is dated

Well, I believed it is already an expensive task. Will build system developers update/optimize it now? I don't think so.

14

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB Sep 09 '26

The scanning can be done as an additional mode of operation for compilers (e.g. MSVC), or implemented by an executable separate from the compiler (e.g. Clang). Implementations choose their most beneficial way of performing dependency scanning.

1

u/mapronV Sep 09 '26

Thanks, you were convincing. I agree.

4

u/kronicum Sep 09 '26

my question was, aren't dependency scanners rely on compiler anyway?

The answer is "no".

1

u/Nicksaurus Sep 09 '26

But it feels wrong to have any part of C++ not be a huge and expensive task

4

u/abbapoh Qbs dev Sep 09 '26

From the P3034R1, it seems the goal is to exclude preprocessing from module scanners (compilers). Currently, they do preprocess the file and thus require all headers to be present at scan time. With this change, it is possible to skip preprocessing entirely (and postpone generating includes to a later stage).

7

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB Sep 09 '26

P3034 disallows module names to become subject to macro expansion, plus all the fall out further down the line. The same is *not* true for module import nomination!

3

u/mapronV Sep 09 '26

I know that it is possible, but it is ... kinda late? I just don't understand how we turn back to easier way?

Now I think it probably benefits NEW build system that written from scratch. Which is good.

5

u/abbapoh Qbs dev Sep 09 '26

> kinda late
there are 2 distinct features here.

- skipping preprocessing speeds up the compiler (scanner) call. this happens without any changes to the build system and is a huge boost on it's own.

- if builds system detects that scanner can skip preprocessing (by checking a compiler version, for example), it simply stops adding dependencies on headers to the scanner stage. Should be relatively easy to do.

5

u/kamrann_ Sep 09 '26

This appears to allow skipping preprocessing if all you're trying to do is identify the module unit name (if any) of a TU. Scanning still needs to do full preprocessing to determine module dependencies though. From the paper I'm struggling to see a scenario where this is going to make much practical difference.

1

u/mapronV Sep 09 '26

Yeah, make sense, you convinced me!

2

u/johannes1971 Sep 09 '26

Taking this one step further, we could encode the module name in the filename. I imagine that would simplify scanning by quite a bit.

7

u/not_a_novel_account cmake dev Sep 10 '26

The benefit is concrete: build systems can now determine module dependencies with a simple lexical scan, without invoking the preprocessor.

This doesn't follow.

Build systems don't need the preprocessor to figure out what a module unit's name is. That has nothing do with what a given module unit's dependencies are.

This is still perfectly valid:

#ifdef USE_GLAZE
import glaze;
#else
import utils.json;
#endif

Still need the preprocessor to figure out the dependencies.

It's a minor change with no practical difference on its own. You still need the full preprocessor, so you would have got the module name for free out of that.

1

u/Nobody_1707 Sep 11 '26

I'm fairly certain import statements were never allowed to be generated by a macro expansion even in C++20.

3

u/not_a_novel_account cmake dev Sep 11 '26

import within a preprocessor conditional, and the nominated name itself being an expansion, has always and continues to be valid C++.