A reminder that small details at declaration can have large impacts on memory layouts.

It's all written oriented toward C++ use. That said I think most of it equally applies whatever the language.

An old one now, but still a very good overview of what C++ ranges brought to the table.

Good list of hardening options indeed. That's a lot to deal with of course, let's hope this spreads and some defaults are changed to make it easier.

The type inference in C++ can indeed lead to this kind of traps. Need to be careful as usual.

Interesting work from Apple and Google to have better hardening in libc++. It's nice to see it ripples through the upcoming C++26 standard as well.

Another nice use of the upcoming C++ reflection feature.

Indeed, the C++ syntax for closure captures is way superior to the Rust one. Interesting musing on a potential path forward for Rust.

Maybe we have a path forward for performance stackful coroutine? More pieces need to fall in place but this looks promising.

A long paper which explains what can be expressed with concepts in C++.

This is an interesting pattern that I still seldomly meet in C++ codebases. Of course don't go overboard with it, but don't be scared of using it for wrong reasons.

It's kind of an unusual design choice... This is subtle, I think I'm still a bit on the fence regarding this one.

An illustration of why C++ can still be a relevant choice in new code. It all depends on the contraints you have for a given problem.

Reminder that there are a few cases where you might not want your variables declared as const.

As usual, you need to measure before you jump to conclusion...

OK the coming compile time reflection features coming with C++26 are definitely mind blowing. It really opens the door toward a very different evolutionary path for C++. Many things can be done from libraries now and producing bindings to other languages shall become much simpler to.

Now it's once again about adding more to the language... This makes the question of how to extract a safer and leaner subset even more important. It's also asking for more tooling to support it, like the constexpr debugger mentioned during the questions.

For as much as we collectively like to complain about C++ it's important to also give credit where its due. Now I don't necessarily agree with everything in this one even though it provides a few good arguments.

C++26 really looks like a step in the right direction in term of safety. Undefined behaviours are too often neglected in that conversation.

We got this nice feature a while ago now. It deserved to be used more, and it keeps improving.

Yes, this one feature in the standard doesn't seem to reap much benefits... It's sad that it got there.