Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-06-09 17:25:10
On 06/10/2016 04:59 AM, Emil Dotchevski wrote:
> On Thu, Jun 9, 2016 at 5:19 AM, Rainer Deyke <rainerd_at_[hidden]> wrote:
>> On 08.06.2016 23:57, Emil Dotchevski wrote:
>>> On Wed, Jun 8, 2016 at 2:29 PM Rainer Deyke <rainerd_at_[hidden]> wrote:
>>> 3. I want a class to have value semantics, but use a copy-on-write
>>>> implementation behind the scenes.
>>> Pimpl is not about semantics, it's about reducing physical coupling. It's
>>> not about the pointer pointing at the private implementation object
>>> being private, is an implementation detail anyway), it's about the private
>>> implementation *type* being left incomplete.
>> Pimpl is a technique where the implementation of a class is moved to a
>> separate implementation class (the "impl"), to which the interface class
>> maintains a pointer (the "p").
> The "p" stands for "private" not for pointer. The defining property of the
> pimpl idiom is that the private implementation type is left incomplete in
> the interface: the pointer is opaque. For example, if you implement
> copy-on-write using a pointer to a type that is defined in the interface,
> you're not using pimpl. So, logical design (semantics), including copy
> semantics, is orthogonal to pimpl.
Emil, as Sutter described in his early articles the pimpl name was
introduced by one of his colleagues where the "p" stood for "pointer"
due to Hungarian notation as the type was actually a pointer to "impl".
That said, I agree with you stressing the "private implementation"
property. However, IMO that property only comes after the "separation of
interface and implementation". So, one might argue that a class
implementing the "separation" property already qualifies as a pimpl (or
Handle or Proxy)... and formally I personally agree that it does. The
first (and one might argue the only) pimpl property is the "separation",
the introduction of a level of indirection, the introduction of a proxy.
Many use it to then hide the implementation. Rainer uses it for
write-on-copy. I personally find Rainer's application of Pimpl
interesting (and I am considering adding such a policy to the proposed
Then, when you say that "Pimpl is *not* about semantics", I want to
agree with you... but in reality I have to disagree. :-) The reason for
that is that (for me) the idiom is about indirection -- through handle
to body, through proxy to data, i.e. the idiom defines *two* objects...
Even your version has two objects -- opaque data and shared_ptr<data>.
And, as soon as we introduce 2 objects, we face the important dilemma of
defining the relationship between those two objects. The semantics
describes that relationship -- be that the pointer semantics, the value
semantics or, as Rainer mentioned, the copy-on-write semantics. One
might argue that that's outside the idiom. However, I feel that's
splitting a hear as on the practical level the proxy-data relationship
is part-n-parcel of the whole package. Don't you agree?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk