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

Subject: Re: [boost] [pimpl] No documentation for pointer semantics
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-06-10 04:15:42

On 10/06/2014 14:15, quoth Vladimir Batov:
> 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. :-)

My use of Pimpl has also been driven by practical need -- the need to 
avoid recompiling 200+ source files when changing a tiny implementation 
detail of one class that happens to be used deep in the object graph. 
(Compiling can take quite a long time.)  Though normally I just do it 
manually rather than using any framework -- which isn't to say that a 
framework might not be useful if I had one readily available.

But the way you're phrasing things above still sounds to me like we're 
still coming at things from different perspectives.

To me, any given instance of a class (eg. Book) is *always* a value, and 
has value semantics.  This doesn't imply that it's small or copyable -- 
you can mark classes as movable only or non-copyable/movable.

If something wants to have a reference to that instance (pointer 
semantics), then it declares a pointer, reference, or smart pointer 
instance that refers to the other object.  (Note that a smart pointer is 
itself a value-semantics instance that happens to have pointer-semantics 
referring to another object as well.)  It's left up to the consumer to 
decide what kind of pointer to use, based on how they plan to use it.

On occasion I've made a class that mandates specific pointer-semantics 
only (usually because it uses shared_from_this()), but it does this by 
having a private constructor, deleted copy constructor, and a public 
factory method that returns a shared_ptr<X>, such that it's not possible 
to get a non-shared instance from outside.  Internally it's still a 
value object.

But the concept of referencing/pointing is separated from the class 
itself, which is where our perspectives differ, I think.