Boost logo

Boost :

Subject: Re: [boost] [pimpl] Mini Review
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-05-26 23:33:30


On 5/26/11 8:06 PM, Vladimir Batov wrote:
>> 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). On the smaller
> scale it tries to do *two* things -- 1) the separation of interface and
> implementation and 2) implementation hiding. It is because that is how I
> understand the properties/qualities/characteristics of the Pimpl idiom. 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. Is it the support for the Bridge pattern and Non-Virtual Interface Idiom
> that get you worried? Then, ignore that -- that's not a stone in your shoe, is
> it?
>

Vladimir, your frustration is entirely understandably (and indeed, I
would feel the same way if I were in your position), but I would like to
respectfully suggest that right after criticizing the tone of others for
being harsh it is generally a good idea to be extra careful to police
your own tone.

Having said that, I do agree with your thesis but would restate in the
following way: even if it also made sense to have the parts of pimpl
available as separate tools, it is nonetheless would be a great boon to
ordinary users to have a "one stop shop" where they could just get
everything that they need and not have to worry about it, which is
exactly what pimpl attempts to provide. So even if all the parts were
available separately, I think that we would want something like pimpl to
combine them all for the common case.

>> Many of the features addressed by Pimpl can be provided by separate tools,
>> instead of packing all of them to Pimpl.
> Yeah, and next time you go to buy, say, a car, please to not accept a car as a
> whole but insist on wheels, radio, etc. separately. I am sure you'll enjoy the
> ride.
>

How about the following compromise?

Why not break pimpl up into a number of subclasses that share a common
base virtual class; then the user only wants some of the features, they
select whatever custom features that they want by choosing those
particular base classes. Or, if the user isn't experienced enough to
know what they want, they can just inherit from the a default choice
will be provided that contains everything. Furthermore, this provides
an infrastructure basis that can be further extended with other features
both by the pimpl library and also by users in the future.

I would implement this by having all of the "feature" classes have
trivial constructors. As I understand it, virtual constructors are
called immediately from the most derived class so the user will just
need call the pimpl base class from their own code to initialize the
member data and all of the other calls to this virtual base constructor
will be ignored. All of the extra checks to see whether the virtual
base class had been constructed would add some overhead to the
construction cost, but hopefully not too much.

Personally I think that this provides a solution that addresses both
concerns and provides additional potential for the library to be useful
now and in the future.

Thoughts?

Cheers,
Greg


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk