Thanks Jonathan for this interesting point. I did a little research and experimentation to be able to provide an answer.

It turns out that defining a unique_ptr member doesn’t require in itself the definition of the class. The definition is needed for instantiating the destructor of unique_ptr. The rationale behind this is that deleting a pointer to an incomplete type (declared only) leads to undefined behaviour, so the unique_ptr prevents this from compiling altogether.

Pushing a unique_ptr on the stack, like on the example you provided, calls the destructor of unique_ptr, so needs the definition. However, using it in a pimpl doesn’t need the definition visible from the pimpl declaration, as long as the pimpl destructor is not implemented along with the declaration in the header.

Very interesting point! 🙂

I first came across the pimpl pattern in 1988. My boss, the late John Carolan, called it the cheshire cat pattern, because the pointer was like the smile of the Lewis Carroll’s cat in Alice in Wonderland. We used the pattern extensively for a GUI framework, called CommonView. I don’t know if he invented it, but I suspect it was already known.

Recently, I have wondered if this technique works with std::unique_ptr, but I believe the implementation of std::unique_ptr prevents a user creating an instance of unique_ptr without knowing the full structure of Foo.

I got errors compiling the following: https://godbolt.org/g/WM8xqs

Cheers Robin, glad that you appreciate it.
This is a very good question. In fact, I keep doubles for the members because the member themselves already have names, contrary to parameters passed to an interface at call site. But I recognize this is subject to debate! 🙂

Good point Michal. Well here the purpose was to avoid dynamic polymorphism in order to manipulate objects with value semantics, and also because there aren’t several possible classes hiding behind one interface in the case here. But your point is totally valid, maybe I should have mentioned it in the exploration of possibilities.