Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-26 07:59:15

Thomas Klimpel wrote:
> Artyom Beilis wrote:
> > Should The library be accepted in Boost:
> > ========================================
> >
> > No it should not. It is "a fancy" library that was written
> > without a knowledge of the problem domain. It tries
> > to solve problem in smart way making it overcomplicated.
> >
> > IMHO old std::auto_ptr is much more suitable
> > for writing pimpl-objects then Boost.Pimple.
> >
> > For easy pimpl-ideom you do not need a fancy class
> > but rather a set of pimpl-suitable smart pointers.
>
> I haven't reviewed the Pimpl library, but this comparison to
> "old std::auto_ptr" looks very strange to me. If I understood
> correctly, one of the reasons why "old std::auto_ptr" is
> deprecated in favor of "std::unique_ptr" is that "old
> std::auto_ptr" will silently break the default generated copy-
> constructor and assignment operator of a class containing an
> "old std::auto_ptr" as member. "std::unique_ptr" on the other
> hand will disable default generated copy-constructor and
> assignment operator and only default generate the "move"
> versions of these, so the user will at least realize that he
> has to manually provide correct versions of copy-constructor
> and assignment operator.

It is these issues and the several manual steps required to implement the Pimpl Idiom that this library tries to address and simplify.

It is totally clear that one can use shared_ptr, unique_ptr, etc., or even a raw pointer to implement the Pimpl Idiom.  However, each such choice requires different member functions to effect proper copy and equality semantics, for example.  Remembering to do everything and doing it correctly every time, for each case, is the problem.

It may be that Artyom has used Pimpl so often that he never makes mistakes in its implementation for each use case.  He may understand the issues completely and may always do the right thing.  That doesn't mean that others will do as well.  Libraries exist to capture design and implementation details so others can build upon that effort, even without fully understanding the issues.

It may be that this library needs to be extended to support cloning, holding, and other use cases the author hadn't identified.  That hardly justifies saying that the author does not have "knowledge of the problem domain."

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