Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-31 12:07:13

Vladimir Batov wrote:
> 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.

Separating the implementation from the interface is for the purpose of hiding the implementation.  I think I covered it just fine.

> > Helping to implement copying and assignment is useful,
> > provided the class is supposed to support those operations.
>
> shared_ptr-based Pimpls copying and assignment are done by
> shared_ptr.

That tells me that Pimpl provides copying and assignment for the derivate.

> For value-semantics-based Pimpls copying and assignment are
> only available if the underlying implementation supports that.

That is good.

> > The rest seems questionable, as I've discussed variously in
> > the Code Collaborator comments.
>
> The rest are
>
> safebool, null, swap, reset.

Don't forget dereferencing and member selection.

> swap, reset again delegate to the policy classes.

reset(), as I've noted, exposes the need to allocate memory using new to code that otherwise doesn't need it.  The overload taking a deleter is a helpful addition, however.

> safebool, null are IMO idiomatic to the Pimpl concept as it is
> idiomatic for raw pointers.

Those are idiomatic only to the implementation of the derivate (Book), not to clients of the derivate.

> > 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.

As you've noted, this is only by virtue of using private inheritance.  I still don't think it is correct behavior for a library implementing the Pimpl Idiom to modify the interface class' (Book's) interface.  Consider a raw pointer Pimpl design:

class Book
{
   // state
};

becomes:

class Book
{
   struct impl;
   impl pimpl_;
};

struct Book::impl
{
   // state
};

Adding a pimpl did nothing to Book's interface.  Why then should Book's interface chance when using your library?  That seems to be an extension of the idiom into the territory of the Bridge Pattern or something else entirely.

> > 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).

Where has this been incorporated into "The Pimpl Idiom" in the literature (besides your article)?  Have I missed something?

> > 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.

Modifying the interface is the part I was referring to.

You've said that copying and assignment are only supported (for value semantics, anyway) if the derivate provides them.  That's a good approach.  If everything is of that sort, then all's well, but that's not what I see.

> > One doesn't derive from shared_ptr, for example.
>
> One does derive from boost::noncopyable, for example.

You were suggesting that shared_ptr provides pointer semantics, so it was reasonable that pimpl do so.  My point was that one doesn't derive from shared_ptr, so the pointer semantics were relegated to shared_ptr data members rather than to the class itself.  Therefore, you couldn't justify adding pointer semantics using shared_ptr as an exemplar.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.