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