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.
If you needed a reminder that inlining functions isn't necessarily an optimisation, here is a fun little experiment.
Looking at several languages and their reflection features. What's coming with C++26 is really something of another class than anything else. I just have concerned about its readability though.
Looks like an interesting tool to follow availability of C++ features in compilers.
Nice introduction of the C++ ownership system. Nothing new under the sun obviously but since I still encounter developers struggling with this, such introductory material is nice to have handy for sharing.
This piece is (unsurprisingly) biased. Still there's some truth there. C++ is here to stay, like it or not. The safety issues are overblown and are getting addressed. Now where the article is lacking is that the language has other issues. Also, will profiles ever become a real thing?
Careful of undefined behaviours. They can be reached fairly quickly. Especially in C++ and its initialisation maze.
Another explanation for the rule of zero in C++. We should definitely stick to it.
Excellent resource for keeping an eye on performance issues in your codebase. It's very C++ oriented but most of the insights can be generalised to other ecosystems.
I definitely agree there. It looks like a missed opportunity to improve the API and nudge people in the right direction.
Definitely the right rule to follow to designing classes in C++ in my opinion.
It's indeed fairly underrated but very useful, especially if you're making libraries.
A reminder that small details at declaration can have large impacts on memory layouts.