|
Boost : |
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
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk