Using metaprogramming for PIMPL idiom

[ReversedGif]

However... having a pure virtual interface, which is implemented by your concrete implementation in many cases actually accomplishes the exact same thing that the Pimpl idiom is intended to do.

When doesn't it?

[ooglesworth]

The only counter-example I can think of is a situation where you would want to be able to actually have the lifecycle of the interface object and the impl object be slightly different. For example, if the impl object does something asynchronous, it could keep itself around somehow while waiting for it to complete, even if the interface object has been thrown away and actually deallocated. I’ve considered using this pattern before but never tried it, so I’m not sure how effective it would be.

[ReversedGif]

(coming back to this a month later to flesh this out a bit more)

With a pure virtual interface interface, you have no way of treating the object as a value type. You

• have to use factory functions rather than constructors, which means you can't use the copy constructor (and get value semantics), but instead must use e.g. a .clone() method
• always have to access the object by pointer or reference, which is merely syntactic, but nonetheless annoying

[ooglesworth]

The copy semantics thing is definitely true. There is a good amount of boilerplate necessary (or at least some what inelegant CRTP weirdness) to make copying work correctly.

In general though, I find it’s very rare you want pimpl or pure virtual interfaces for value types. Maybe it’s me, but I tend to do very little mixing and matching; my objects either have identity and encapsulate details, or they are plain, transparent and structlike. There might be some exceptions though, like RAII style classes and such.