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
But the concept of referencing/pointing is separated from the class
itself, which is where our perspectives differ, I think.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk