C++ Modules Are Here to Stay

Summary

C++ Modules are here to stay January 24th, 2026 Within C++, there is a much smaller and cleaner language struggling to get out. C++ enthusiasts will often bash you for using the C preprocessor instead of the latest great metaprogramming feature of the language but until recently, any meaningful use of C++ meant that you had to use at least one preprocessor directive (#include) and that is no longer true. C++20 modules provide a way to encapsulate a library (or a namespace) such as Qt, cv, or std1. Know your modules Using modules is as easy as import std; auto main() -> int { std::println("Hello world!"); } and creating your own module is no harder, but we ought to have some terminology laid down first: Translation unit: Think of this as any .cpp file. Module unit: This is one or more translation units that declares a module. You can declare everything in one file (that we call the interface unit) or separate your interface and implementation (like a .h file with a corresponding set of .cpp files). Export declarations: Inside of your module unit, you can export declarations (classes, functions, etc.) that are importable by the users of your modules. Exports are explicit. With those definitions out of the way, we can begin by declaring our first module, a data structures and algorithms module: export module dsa; namespace dsa { export int pow(int a, int b) { ... } } Well, that was easy. How about we add Red-Black Tree as a submodule? export module dsa.rbtree; export namespace dsa { enum class AllowDuplicates : bool { No, Yes, }; template<typename T, AllowDuplicates AllowDuplicates, typename Compare = std::less<T>> class RedBlackTree { ... } } It’s the same thing. In fact, from the compiler’s perspective submodules are not a thing; dsa.rbtree is to dsa what “openai” is to “open”. Since there’s no such thing as “submodules”, there’s no way for modules to interact except by their public interfaces and that is by design. But this also means that you’ll have one gigantic m...