Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-06-01 14:28:39

Sean Chittenden wrote:
>
> This is less rhetorical than I'd like, but what's the right
> amount of baggage that a Pimpl implementation can bring along
> with it? On one side of the spectrum you have an austere
> implementation that is literally an opaque pointer with its
> relevant compilation glue ("the one true/pure pimpl").

There's good reason to provide support for copying, assignment, and swapping, of course.  After that, it gets iffy.

> On the other side of the spectrum you've got something that
> overloads functions and operators and makes a pimpl
> implementation easier to use, ala the Pimpl library.

There are two interfaces to discuss.  There's the public interface, which is given to the derivate (Book).  It is possible to derive privately or "protectedly" to reduce the public interface, but that's not the normal use case.  There's also the implementation interface, which is accessible to the derivate for accessing and manipulating the implementation object.

My concern is mostly for the public interface, but I have thoughts on what's included in and how to improve the implementation interface, too.  It's important to discuss each interface separately.  I know I've also convoluted what functionality is part of which interface, adding to the confusion I'm sure.

> For example:
>
> https://github.com/sean-
> /Boost.Examples/blob/master/pimpl/boost/pimpl/pimpl.hpp#L134
>
> Not strictly necessary, but I understand why it's there and why
> it would be wanted in a Pimpl implementation. I also understand
> the puritanical argument for why you wouldn't want it.

That link points to the middle of a comment, so I don't know what you're referring to.

> In fact, my search for Boost.Pimpl began because I missed
> adding a non-const* ->() to my implementation. After wading
> through pages of gcc error messages (naturally this happened in
> the middle of a asio/bind/wrap call) I started looking for a
> reference implementation that had some of this spelled out
> since I didn't think I should be spending my time
> reimplementing the wheel. I don't have an answer for what's
> "right" on the spectrum of austere vs "featureful", but the
> featureful side of Pimpl has clear merit.

I've suggested these instead of the member selection and dereferencing operators:

   implementation &
   impl();

   implementation const &
   impl() const;

Those are easy to call -- no need for (*this)->, etc.  The diagnostics would probably be a bit easier to read, too.

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