Re: [boost] [pimpl] Mini Review

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