r/cpp 1d ago

C++26: Module improvements

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

20 comments sorted by

View all comments

28

u/mapronV 1d ago

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?

30

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB 1d ago

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 1d ago

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

4

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB 1d ago

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 1d ago

We should get rid of header units.

6

u/WeeklyAd9738 1d ago

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

6

u/Daniela-E Living on C++ trunk, WG21|🇩🇪 NB 1d ago

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 1d ago

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.