"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:<fsptpe$peo$1@ger.gmane.org>...

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.

Well, the pimpl idiom is certainly not a shared_ptr.as pimpl's main purpose is separation of interface and implementation and imlemetation hiding. shared_ptr does not provide the latter. I was hoping I covered all that in the article.

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

The private implementation is always initialized by default. Nowever, null() is certainly needed for many things. And Foo::null() is certainly not a pointer but a proper (but invalid :-)) Foo instance.

There doesn't seem to be any useful help for allocating the private implementation.

What exactly are your expectations? If you'd like private implementation to be allocated for you, then it's simply not possible as ity is called private for a reason.

Such potentially interesting allocation schemes, like stack allocation, seem also to be impossible.

I have not seen one single implementation of pimpl allocating private implementation on the stack and I do not believe it is possible as in order to allocate on the stack we/compiler have to know the size of the class (private implementation class) which is again private.

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.

null<Widget>() is an instance of Widget. Therefore, the copy constructor is called.

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?)

I am not sure about your usage patterns but my usage of pimpl::pointer_semantics vs. pimpl::value_semantics is 100:1. What is the point (and validity) of having shared_ptr<Foo>? Same is applicable to pimpl::pointer_semantics.

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.

I personally do not see logic the same semantics for the object and its private implementation because the object is the interface and its private implementation is implementation detail (which is private as well). They serve different purpose, have different visibilities et al. What is the advantage of them having the same semantics? Thanks, Vladimir.