wro.cpp wro.cpp
short

C++ modules in 2026: import std works, import boost is coming, your IDE still can't

· english · audience: working-cpp

C++20 modules shipped six years ago. The compilers support them. The ecosystem does not. Here is what actually works in May 2026, what does not, and what this means if you are using C++26 reflection.

Compiler support: import std; works

All three major compilers can compile import std;:

CompilerStatusFlags
GCC 16.1Works-fmodules -std=c++26 + --compile-std-module
Clang 18+Works (libc++ or libstdc++)-std=c++23 or later
MSVC (VS 2026)WorksDefault for new C++20 projects

GCC 16.1 added --compile-std-module, which auto-builds the std and std.compat BMIs before compilation — no separate pre-build step needed. MSVC has had import std; since VS 2022 17.5. The compilers are ready. Everything else is not.

Boost: the per-library prototype

Ruben Perez Hidalgo (Boost.MySQL author) has been the primary driver of bringing modules to Boost. His three-part blog series documents the effort:

  • Per-library modules: import boost.mp11;, import boost.charconv; — not one monolithic import boost;.
  • Dual-mode via compatibility headers: a BOOST_USE_MODULES macro toggles between #include <boost/mp11.hpp> and import boost.mp11. Same source code, both modes.
  • Measured results: an Asio-based server shows a consistent ~45% build-time reduction with modules vs headers. Some test suites see up to 3x speedup.

The prototype covers Mp11, Charconv, and a few core libraries. It is not merged into mainline Boost. Perez paused the work, waiting for CMake import std to stabilize and MSVC bugs to be fixed.

The tooling gap

This is where modules stall.

CMake (latest: 4.3): Named modules work with Ninja generators since CMake 3.28. But import std is still gated behind CMAKE_EXPERIMENTAL_CXX_IMPORT_STD with a version-specific GUID that breaks between CMake releases. Header units (import <header.hpp>) are not supported at all. Visual Studio generators cannot build BMIs for imported targets.

clangd: Experimental modules support exists, but editing a module interface does not update the BMI — you must rebuild the project. The clangd version must match your Clang version exactly.

VS 2026 IntelliSense: “C++ IntelliSense support for C++20 Modules is currently experimental.” This label has been unchanged for seven years.

CLion 2026.1: Partial support — syntax highlighting and code assistance via clangd work, but only for .ixx/.cppm/.mxx extensions. Refactoring across module boundaries is limited.

VS Code: The cpptools extension flags import std; as errors with GCC 15+. Using clangd with compile_commands.json works better.

Library ecosystem: almost empty

Mathieu Ropert and Whole Tomato both surveyed the library landscape in April 2026. The finding: “despite C++20 being 6 years old, barely any C++ libraries come with a module definition.”

LibraryModule support
{fmt}WIP (module branch, no official release)
BoostPrototype only (not merged)
AbseilNo
FollyNo
ranges-v3No
Catch2No

Until libraries ship module definitions, import std; is the only module you can reliably use.

Compile-time reality check

The headline numbers are real but context-dependent:

  • Best case: Alibaba measured import std vs #include <iostream> at 40x faster for a hello-world (0.03s vs 1.2s, debug mode).
  • Realistic case: Boost’s Asio server sees ~45% improvement.
  • Reflection case: Romeo’s benchmarks from the compile-time cost post show modules are 2.2x slower than plain includes on GCC 16.1 for <meta> (397ms vs 181ms). PCH beats both at 74ms.

The module performance gap on GCC 16.1 is an implementation artifact, not a fundamental limitation. GCC’s BMI format is not yet optimized for the scale of <meta>. Expect this to improve in GCC 17+.

What this means for reflection users

If you are building the wro.cpp reflection examples or shipping reflection-heavy code:

  1. Today: use PCH. Three lines of CMake, 2.3x speedup, works everywhere. See the compile-time cost post.
  2. Don’t: switch to import std; for reflection on GCC 16.1 — it is currently slower.
  3. Watch: GCC module performance, CMake import std stabilization, and the Boost prototype merge.
  4. Long-term: import std.meta; (or import std;) will eventually replace the PCH. We are not there yet.

The honest assessment: modules are a solved problem in the compiler frontend and an unsolved problem everywhere else. The standard landed in C++20. The ecosystem will catch up — but in May 2026, PCH remains the pragmatic choice for reflection projects.

Sources: Ruben Perez Hidalgo’s Boost modules prototype (Jan 2025), deep dive benchmarks, isocpp.org talk (May 20, 2026). Mathieu Ropert’s “Can we finally use C++ Modules in 2026?” (April 2026). Vittorio Romeo’s reflection compile-time benchmarks (March 2026).