Re: [boost] [pimpl] No documentation for pointer semantics

Subject: Re: [boost] [pimpl] No documentation for pointer semantics
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-06-09 22:15:23

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.