Vladimir.Batov@wrsa.com.au wrote:
The code is in the Boost Vault called Pimpl.zip It compiles with GCC 4.1.2 (I use it on Ubuntu 7.04) and MS Visual Studio 2005. Documentation is at DDJ site: http://www.ddj.com/cpp/205918714 Any questions/suggestions/critique - vladimir.batov@wrsa.com.au
I have only quickly gone through your documentation on DDJ, so my comments may be off. Feel free to correct me if I misunderstood something. Personally, I fail to see the advantage over a shared_ptr member. The only differences I could notice are - implementation class is not user-declared but rather is a specialization of a template. - the null pointer is called null (by the way, I think we shouldn't allow a null value, the private implementation should always be initialized somehow, if lazily) There doesn't seem to be any useful help for allocating the private implementation. Such potentially interesting allocation schemes, like stack allocation, seem also to be impossible. Being able to replace the private implementation of a base with the private implementation of a derived class certainly is a necessity. I have to admit, though, I do not understand your solution. You're passing a null<Widget>() to the Widget constructor, but the constructor wasn't written to take any kind of special argument. I'm not really sure of the point (and validity) of having pointer semantics. Do you really want your implementation details to be shared by some of your different instances? (maybe there is a point in sharing implementation details with all instances or all equivalent instances, but some?) It seems more logical to me to have the same semantics for the object and its private implementation. If the object itself has pointer semantics, then you won't copy it. Using one or the other for the implementation makes no difference, then. You might as well use the value semantics, which would even be more lightweight in that case.