When explaining someone the rules behind the special member functions and when you need to write which one, there is this diagram that is always brought up. I don’t think the diagram is particularly useful for that, however.

It covers way more combinations than actually make sense. So let’s talk about what you actually need to know about the special member functions and when you should write which combination.

Andrzej wrote about problems with CTAD and nested optionals, then Barry wrote about problems with comparison and nested optionals.

What do both problems have in common?

Nested optionals.

So let’s talk about them: What do they actually mean?

Almost three years ago — wow, how time flies — I blogged about namespace aliases and called them one of C++ most underrated features (which probably was a bit of a click bait).

Let’s talk about some other namespace feature, that is, well, not quite underrated, but relatively obscure: inline namespace. They are namespaces that don’t really introduce a scope, except when they do.

So what can you do with them?

Warnings are important, especially in C++.

C++ compilers are forced to accept a lot of stupid code, like functions without return, use of uninitialized warnings, etc. But they can at least issue a warning if you do such things.

But how do you manage the very compiler-specific flags in CMake?

How do you prevent your header files from leaking warnings into other projects?

I did a series about comparisons recently where I gave some guidelines about using the upcoming spaceship operator for three-way comparison. In particular, I pointed out a couple of flaws with the design as it is currently.

Well, now the proposals for the next C++ standardization meeting are here — almost 300 of them. And I’ve counted eleven of them that deal with the spaceship operator.

So let’s take a look and them and see whether they’ll fix any of the issues I’ve pointed out.