Those improvements are welcome. I wish we'd see more std::format uses.
Looks like a good book. This review definitely tempts me.
Interesting take on why CVEs are reported differently for C/C++ and Rust libraries. The responsibility for API misuse is treated differently because the abilities to express contracts is treated differently.
This is really interesting stuff that C++26 brings.
The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public
Cold and harsh look at how the C++ standard library evolves. There's indeed a problem in the fact that nothing gets removed ever.
Wondering about the memory layout emitted by the compiler when a virtual table exists for a type? This is a good summary.
Time to retire std::function in new code.
It's about time such a thing gets standardised in C++!
C++ too can have its own supply chain disasters with enough effort!
Looks like a small syntax adjustment, but that indeed open the door to nice improvements.
Probably not... This is really taking a long time to be adopted. It's not an incremental thing at all, this doesn't help.
This is indeed a nice pattern for dependency injection in C++ for global functions.
A good reminder of why destructors shouldn't throw. It really has to be a last resort measure and only carefully considered. There's a reason why they are nothrow by default since C++11.
Indeed be careful at how you use strings when interacting with C APIs. String views are likely not what you want in that context. There is a reason why they don't have c_str().
Vendor toolchains should see only a limited trust. Like in this case they're often partial or old.
The new standard is upon us and it'll be massive. It indeed looks like another C++11. If used it'll feel like a very different language.
A very good talk which walks you through how to move from object-oriented design to data-oriented design. Shows quite well how you must shift your thinking and the difficulties you might encounter with data-oriented designs. I appreciate a lot that it's not just throwing object-oriented design out of the window, indeed you have to pick and choose depending on the problem space. Also it's interesting to see how C++26 reflection might make some of this easier.
Nice little quality of life improvements coming to std::span in C++26.
Interestingly the issue for the compile time is not so much the feature itself but the STL headers required. It makes PCH pretty much mandatory.
A small change in the standard, but it opens the door to interesting uses.