So no, modules aren't even here, let alone to stay.
Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them seriously, or otherwise I simply do not understand what weed they are smoking. I would very much appreciate to stand corrected, however.
The version of modules that got standardized is anything but that. It's an incredibly convoluted mess that requires an enormous amount of effort for little benefit.
You are spoiled by the explosive growth of open source and the ease of accessing source code. Lots of closed source commercial libraries provide some .h files and a .so file. And even when open source, when you install a library from a package from a distribution or just a tarball, it usually installs some .h files and a .so file.
The separation between interface and implementation into separate files was a good idea. The idea seemed to be going out of vogue but it’s still a good idea.
(Buy my book)
https://devblogs.microsoft.com/cppblog/integrating-c-header-...
That is not the same as using modules, which they have not done.
Program
- Module
- Module Partition
Program
- Private Module
- Private Module
- Private Module
- Public Module
- Public Module
Rust, Modula-2 and Ada are probably the only ones with module nesting.
"Just one more level bro, I swear. One more".
I fully expect to sooner or later see a retcon on why really, two is the right number.
Yeah, I'm salty about this. "Submodules encourage dependency messes" is just trying to fix substandard engineering across many teams via enforcement of somewhat arbitrary rules. That has never worked in the history of programming. "The determined Real Programmer can write FORTRAN programs in any language" is still true.
There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transition to a legacy language
when people say this do they have like any perspective? there are probably more cpp projects started in one week (in big tech) than rust projects in a whole year. case in point: at my FAANG we have probably like O(10) rust projects and hundreds of cpp projects.
as they say "citation needed"
Log scale: Less than 3% done, but it looks like over 50%.
Estimated completion date: 10 March 2195
It would be less funny if they used an exponential model for the completion date to match the log scale.
Chuanqi says "The data I have obtained from practice ranges from 25% to 45%, excluding the build time of third-party libraries, including the standard library."[1]
[1]: https://chuanqixu9.github.io/c++/2025/08/14/C++20-Modules.en...
It seems likely I’ll have to move away from C++, or perhaps more accurately it’s moving away from me.
Just like Python was to blame for the horrible 2-to-3 switch, C++ is to blame for the poor handling of modules. They shouldn't have pushed through a significant backwards-incompatible change if the wide variety of vendor toolchains wasn't willing to adopt it.
It kinda is. The C++ committee has been getting into a bad habit of dumping lots of not-entirely-working features into the standard and ignoring implementer feedback along the way. See https://wg21.link/p3962r0 for the incipient implementer revolt going on.
How well does this usually work, by the way?
But you might not be able to use libraries that insist upon modules. There won't be many until modules are widespread.
- Single translation unit (main.cpp)
- Include all other cpp files in main
- Include files in dependency order (no forward declarations)
- No circular dependencies between files
- Each file has its own namespace (e.g. namespace draw in draw.cpp)
This works well for small to medium sized projects (on the order of 10k lines). I suspect it will scale to 100k-1M line projects as long as there is minimal use of features that kill compile times (e.g. templates).
If these aren't compelling, there's no real reason.
I don't see many "fair" benchmarks about this, but I guess it is probably difficult to properly benchmarks module compilation as it can depend on cases.
If modules can reach that sort of speedup consistently, it's obviously great news.
The current solution chosen by compilers is to basically have a copy of your code for every dependency that wants to specialize something.
For template heavy code, this is a combinatorial explosion.
It’s regrettable that the question of whether a type meets the requirements to call some overload or to branch in a particular if constexpr expression, etc, can depend on what else is in scope.
In Haskell, you can't ever check that a type doesn't implement a type class.
In Golang, a type can only implement an interface if the implementation is defined in the same module as the type.
In C++, in typical C++ style, it's the wild west and the compiler doesn't put guard rails on, and does what you would expect it to do if you think about how the compiler works, which probably isn't what you want.
I don't know what Rust does.
It does not work very well at all if your goal is to port your current large codebase to incrementally use modules to save on compile time and intermediate code size.
Dude…
auto main(argc, argv) -> int
int argc;
char **argv;
they never were in C++.
> auto main() -> int
Isn't that declaring the return type twice, once as auto and the other as int?