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-10 16:37:57

Gavin, I was planning on replying by Rob bit me to it pretty much 
expressing my view. My strong "attachment" to ref.-counted "Pimpl" is 
probably stems from the fact that I've always treated it as 
another/handier name for Handly/Body. Strangely, in all these years of 
deploying my-pimpl no one (including Sutter) "corrected" me on that... 
until now.

On 06/10/2014 06:15 PM, Gavin Lambert wrote:
> 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.
>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>