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?
Individual use cases might want those, not care about them, or specifically not want them.
So, if I follow your line of reasoning correctly, then I should discard boost::regex as it provides support for Perl Regular Expression Syntax POSIX Extended Regular Expression Syntax POSIX Basic Regular Expression Syntax when I only "want/care for" the Perl syntax? Do you pay for that additional functionality? Is it heavy to carry? Is it getting in your way somehow? Does it result in unexpected behavior? Have you noticed that *any* library actually provides *more* than *you* usually need because such library might be written with wider audience in mind? Jeez, I do not believe we are even discussing it!
... And Pimpl providing the following: safebool operator; pimpl::null; can be an unwanted side-effect, and may therefore lead to a decision not to use the proposed Pimpl in this case.
Are you just pondering or have something concrete in mind? If that is the latter, then bring it on. We'll look at it and fix it... or I'll say, shit, you are right, bad-bad design... and fix it again. Otherwise, all these "can" and "may" are just noise.
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.
... To conclude, I agree, that the problems addressed by the proposed Pimpl need solutions, but I suggest providing separate tools addressing the problems instead of Pimpl addressing all of these.
So, would you please come forward and suggest something tangible addressing those problems. I am sure you are prepared that that features that you care about might not be so dear to somebody else's heart. V.