Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2011-05-27 00:32:32

> Gregory Crosswhite <gcross <at> phys.washington.edu> writes:
> ...
> 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.

Yes, I know. Apologies. Truly. Turning into an angry old man. Not pretty.

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

My first reaction is "I do not know" -- in its true meaning. I am somewhat slow,
so I have to sleep of that idea to better understand what it brings and what the
price/benefits might be. I am probably Pimpl-indoctrinated and I am certainly
this implementation-biased, so to me OTOH it does not offer really that much to
dwell on or to try to split into smaller parts -- the code is only about 100
lines (comments excluded). I guess, we are talking beyond taking safebool and
value_semantics_ptr out. To understand better I'll have to see concrete
examples/use-cases and how splitting Pimpl (or re-doing it) would help help to
solve some concrete issues and/or how the existing pimpl fails to address those.
Maybe, Krzysztof and Artyom would kindly provide some code snippets for an old
man like me to chew on.

Again, my sincere apologies, I hope no hard feelings. 
V.