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@sig.com 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.