Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-27 09:40:48

Krzysztof Czainski wrote:
> 2011/5/27 Vladimir Batov <vb.mail.247_at_[hidden]>
> > Krzysztof Czainski <1czajnik <at> gmail.com> writes:
>
> > > Personally I think the proposed Pimpl library tries to
> > > solve too many things at once.
> >
> > On the bigger scale it tries just *one* thing -- to implement
> > the Pimpl idiom as it is understood by me (which might well be
> > misunderstanding).

Yes and no.  The Pimpl Idiom is *only* about separating the interface and implementation.  How that's done is the issue.  The effect it has on the interface is also an issue.

What the Pimpl library does is modify the interface of the class with a hidden implementation.  Helping to implement copying and assignment is useful, provided the class is supposed to support those operations.  The rest seems questionable, as I've discussed variously in the Code Collaborator comments.

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.  Pimpl's presence should be just an implementation detail.  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.

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

> > What exactly more does it do? Is it the relational ops you do
> > not like? Then, say, shared_ptr has them and one needs them if
> > a Pimpl-based class is to be used, say, in std::containers. Is
> > it null() that keeps you awake at night? Then, many classes
> > (like shared_ptr again) have it... maybe not in as explicit
> > form but still.

The problem isn't so much that pimpl provide those features, but that it adds them to the interface class because of inheritance.  One doesn't derive from shared_ptr, for example.

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