hckrnws

"I can recompile the entire thing from scratch in ~4.3s. That’s around ~900 TUs, including external dependencies, tests, and examples"

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.

It is quite common when being around WG21 stuff, just as info.

> Not sure why they felt the need to abbreviate this

It's super common terminology for people around those spaces; they probably didn't even think about whether they should abbreviate it.

libstdc++'s <print> is very heavy, reflection or not. AFAIK there is no inherent reason for it to be that heavy, fmtlib compiles faster.

<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 don't know the exact details, but I have heard (on C++ Weekly, I believe) that it offers some advantages when linking code compiled with different compiler versions. That said, I normally avoid it and use fmtlib to avoid the extra compile time. So it isn't clear if it is a win to me. Header-only libraries are great on small projects, but on large codebases with 1000's of files, it really hits you.

It also bloats binary size if you statically link libc++ because of localization, regardless if you care for it. This wasn't true for fmtlib because it doesn't support localization. stringstream has this same problem, but it's one of many reasons embedded has stuck with printf.

I am very worried by feature creep in libc++ and libstdc++ and the harm that this inflicts on the wider C++ ecosystem. Transitive inclusion of large parts of the STL, and entangling of STL with core language features are both extremely bad. This should IMO be topic #1 of the committee but is barely even noticed. The mantra "It's okay, modules will save us" is naive and will not work.

I'm pretty late to this discussion, but...

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.

Which languages have a standard library that contains nothing requiring intimate integration with the language implementation itself? I'm not aware of any, even limited-standard-library C included.

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

std::type_info? std::is_trivially_...?

Parts of the language being in the std namespace isn't really a problem. An implementation is free to treat initializer lists as a built-in type.

Is there an implementation that does that?

With std::nullptr_t on MSVC, it's always there without any includes.

The language specification is already larger than several classical tomes of fiction. A reader could choose to tuck in with the C++ spec, or with War and Peace.

And given how much of the language's spec is "The behavior is undefined when combining these two features," it's not really a tome that is safely ignored.

At this point, I cannot recommend C++ on any new project that some external factor such as safety certification (which "solves" the problem by adding yet more pages of stuff a developer must not do that the language syntactically supports and compiles but generates garbage output) isn't forcing my hand on.

As of 2026 C has eclipsed C++ in popularity on the TIOBE index; anecdotally, roboticists I've chatted with have told me they prefer to write core functionality as C modules and then weld them together into high-level behavior with a terser scripting DSL over trying to write the whole thing in C++ and hoping there's no undefined behavior hidden in the cracks that multiple layers of linters, sanitizers, and auto-certifiers have missed.

Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.

I ran some more measurements using import std; with a properly built module that includes reflection.

I first created the module via:

  g++ -std=c++26 -fmodules -freflection -fsearch-include-path -fmodule-only -c bits/std.cc 

  hyperfine "g++ -std=c++26 -fmodules -freflection ./main.cpp"

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.

There are no zero cost abstractions: https://youtu.be/rHIkrotSwcc?si=oSBlKG9M_Ey8sVIU

There is plenty of zero cost abstractions in C++ (and Rust to some extend).

This talk just point that unique_ptr is not one of them due to the side effect of C++ move semantics being non destructive.

People that do not understand that should honestly stop to use it as an argument in favor of "there is no zero cost abstractions".

This is a pretty flippant response to a rather insightful point by someone who isn't exactly a newbie to the language. They understand very well the implications of move being nondestructive and the point they're making stands nevertheless.

Let me clarify something here (And my apologies if this looked a bit aggressive).

There is always a cost to abstraction, and that can take different form. In C++, it is often build time (and/or complexity). And Chandler, in his talk, is perfectly right about that.

But that does not change the validity of the C++ concept 'zero cost abstraction at *runtime*'. It is possible to get proper language abstractions while not sacrificing runtime performances.

I did get sharp on his comment because this talk is constantly posted by a specific C crowd that profoundly hate any form of abstraction and use it as a totem to justify terrible development practices.

If your language support zero cost abstraction and genericity, by the sake of god, use it... most of the time the impact in term compilation time is worth the benefits.

unique_ptr is a beautiful example of that btw.

You're not only undeservedly dismissing very salient high-level points but also just completely missing the low-level ones. Even ignoring build times and looking only at execution times (and btw it's not just time that matters here), even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others.

Nobody is concluding you shouldn't write functions either.

Then we disagree.

> (and btw it's not just time that matters here)

My remark is still valid. Even considering memory space and cognitive complexity.

> even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others

Divergence about the support of inlining in compiler implementation have nothing to do with the debate here. Some idiosyncrasy about C++ argument passing and lifetime might causes a cost in some specific scenario, still that is specific to C++.

It still does invalid the concept of zero runtime cost for abstraction.

As much as people like to dismiss it, Stepanov was right all along.

> Nobody is concluding you shouldn't write functions either.

Then, you will be surprised to learn that some 'devs' actually recommend exactly this and write guideline that minimize the number of function written. They tend to be from the same crowd that the one was describing before.

Nice to learn about hyperfine

Compilation speed is a huge part of productivity and enjoying writing C++

The hidden compile-time cost of <insert almost any C++ feature>

Nah, many great features are extremely cheap. E.g. constexpr, templates, fold expressions, equality operator defaulting, concepts...

Until you try to add / modify a feature of the software and run into confusing template or operator or other C++ specific errors and need to deconstruct a larger part of the code to find (if possible) out where it comes from and spend even more time trying to correct it.

C++ is the opposite of simplicity and clarity in code.

Yes, but they are still all hidden.

constexpr means running code at compile time. template means duplicating lots of code lots of times. these are not cheap.

Yeah this is the very first time I am hearing that templates are "extremely cheap". Template instantiation is pretty much where my project spends all of its compilation time.

How is it hidden if you can measure it?

just another piece to this jenga tower called c++. if you want reflection maybe just use a language that was designed with reflection support since the beginning.