In 30 years of using C++ this is the first time I've ever come across "translation unit" being abbreviated to TU and it took a bit of effort to figure out what the author was trying to say. Not sure why they felt the need to abbreviate this when they explain PCH for instance, which is a far more commonly used term.
Thought I'd add the context here to help anyone else out.
<meta> is another question, it depends on string_view, vector, and possibly other parts. Maybe it's possible to make it leaner with more selective internal deps.
I was somewhat horrified to discover that the STL ended up with a special role in the language spec. (IIRC, one of the tie-ins is initializer lists.)
IMHO it's far wiser to leave the standard library as something that isn't needed by the core language, and where users can (at least in principle) provide their own alternative implementation without needing compiler hacks.
I.e., those details are inherent in the definition of "library" in the C/C++ world.
Compilation speed is a huge part of productivity and enjoying writing C++
I first created the module via:
g++ -std=c++26 -fmodules -freflection -fsearch-include-path -fmodule-only -c bits/std.cc
And then benchmarked with: hyperfine "g++ -std=c++26 -fmodules -freflection ./main.cpp"
The only "include" was import std;, nothing else.These are the results:
- Basic struct reflection: 352.8 ms
- Barry's AoS -> SoA example: 1.077 s
Compare that with PCH:
- Basic struct reflection: 208.7 ms
- Barry's AoS -> SoA example: 1.261 s
So PCH actually wins for just <meta>, and modules are not that much better than PCH for the larger example. Very disappointing.
C++ is the opposite of simplicity and clarity in code.