On 06/10/2014 11:12 AM, Gavin Lambert wrote:
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).
Gavin, Thank you for the explanations. I do understand them and it all sounds sensible. And your reasoning most likely would be my reasoning as well if I started looking at it from purely academic point of view. Namely, the Compiler Firewall (a.k.a. Pimpl) idiom hides the implementation and is only concerned with that. Full stop. Clean and simple concept. Then, everything you write follows. Like "other than recompiling, adding or removing a pimpl from a class should be invisible to consumers of that class". I am not arguing against that. All my rumblings were due to my immense surprise and not due to disagreement or inability to understand the value-semantics concept. In my case it's most likely because my interest in and development of my-pimpl has always been driven by the practical need. And it just happened that I never had a need to hide implementation of small, copyable, value-semantics classes. I would start hiding implementations of classes when they were getting big and/or outside of my control... and not easily or non copyable Say, database (in wide sense) records, GUI components. So that deployment pattern was firmly burnt in my brain... it might well be the specificity of the industry I am in as no-one in our dev. team asked for or deployed pimpl::value_semantics. :-) Nevertheless, thank you for your explanations all the same. V.