On 7/06/2014 12:54, quoth Vladimir Batov:
Indeed, in my mind having two sides of that "coin" is quite natural... and I feel Rob agrees with us on that... he is just "vehemently" against calling it "pimpl".
If it helps (I'm not sure that it will), to me "pimpl" implies value semantics (typically very thin and implemented via a bare pointer internally). If you wanted to share such an object then you would wrap a shared_ptr around the "outside" of the class; it wouldn't be part of the internals (and consumers of the class wouldn't need to care whether it was implemented with a pimpl or not). A "handle" is different; it implies pointer semantics and can either be directly shared or cheaply copied (where the copied handle points to the same underlying object as the original). Mutability is orthogonal, but I suspect it's a factor in the confusion of idioms -- from the sounds of it both Rob and myself are used to value-semantics mutable pimpls, while Pete and yourself are used to pointer-semantics immutable "handles". Where an object is immutable the differences between value and pointer semantics are very slight (from a behavioural perspective, ignoring performance). To put it another way: other than recompiling, adding or removing a pimpl from a class should be invisible to consumers of that class (just like any other change to private fields of a class). I can envisage this easily for value semantics; I have a harder time doing so for pointer semantics (as this seems like it would require changing consumer code more extensively, unless the original class was *already* using some kind of handle/body pattern).