Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2011-05-28 02:55:53

Stewart, Robert <Robert.Stewart <at> sig.com> writes:
> Yes and no.  The Pimpl Idiom is *only* about separating the interface and
> implementation.  

... and hiding the implementation details. See, say,
http://www.gotw.ca/gotw/024.htm, http://www.gotw.ca/publications/mill05.htm. 

> What the Pimpl library does is modify the interface of the class with a
> hidden implementation.  

If that exposure is not desired, there is private inheritance.

> Helping to
> implement copying and assignment is useful, provided the class is supposed to
> support those operations. 

Pimpl does *not* provide copying and/or assignment. It delegates these
"requests" to the policy. For shared_ptr-based Pimpls copying and assignment are
done by shared_ptr. For value-semantics-based Pimpls copying and assignment are
only available if the underlying implementation supports that. No surprises.

> The rest seems questionable, as I've discussed variously in the Code
> Collaborator comments.

The rest are 

safebool, null, swap, reset. swap, reset again delegate to the policy classes.
safebool, null are IMO idiomatic to the Pimpl concept as it is idiomatic for raw
pointers.

> For me, the bottom line is that a UDT, with or without using Pimpl should
> look the same, in terms of interface, to the user of that type.  

It does. The implementer controls what is implemented/visible what what is not.

> Pimpl's presence should be just an implementation detail.  

Disagree. Pimpl is a programing concept and it brings relevant
features/behavior. Like if I decide to pass args by pointers, I get respective
pointer-related "features" (good or bad depends on one's view).

> That doesn't mean it
> cannot be a base class, just that its presence needs to be unobtrusive to the
> user of classes using the library.

I am certainly biased, but I've never found Pimpl involvement being obtrusive.

> Given no effect on the interface of a class using Pimpl, where Pimpl can
> offer real value is in providing
> predefined policies for how to manage the implementation object and its
> lifetime.  It could include
> policies to support things like SBO or cloning (as Artyom has noted).

Sure. If Pimpl accepted/sticks around, it's reasonable to expect other policies
(likely by other people) to emerge. I am not obviously planning on spending my
time adding some other policies of no value to me without any guarantees my
effort and time won't be wasted.

> The problem isn't so much that pimpl provide those features, but that it
> adds them to the interface class because of inheritance.  

It's up to the implementer to make use of those provided features or deny them. 

> One doesn't derive from shared_ptr, for example.

One does derive from boost::noncopyable, for example.

V.