From: "Phil Endecott" <spam_from_boost_dev@chezphil.org>
Artyom wrote: 2) Any non-template based class should have opaque/d/pimpl pointer in its body.
I think that what you have done is the right solution - you, the end user, can wrap things in pimpls where you believe it is beneficial.
I am far from convinced that it is always the right solution to leave that descion to the end-user.
It's fairly easy to convert a non-pimpl interface into a pimpl one, espcially if you need only a subset of it;
I personally spent quite a bit of time looking at the idom and I am under strong impression that converting to the pimpl interface *correctly* is not *that* straightforward. More so, I am not convinced that giving that *option* (or leaving that burden) to the user is such a good idea.
on the other hand, it's impossible to convert a pimpl'd interface back into a non-pimpled one.
In my experience non-pimpled implementations do make sense. Say, for classes of limited complexity (like struct { int a, b; }) where passing by value is more efficient. Due to growing complexity of s/w the overhead of pimpl is often negligible and, therefore, an intelligent decision can be make by the implementer. However, pimpl's benefits are substantial, more importantly for *both* the end-user *and* the library developer. Pimpl's important properties are the separation of the interface and the implementation *and* implementation hiding. The implementation hiding is crucial for industrial-grade s/w (which Boost has become) as it frees implementer's hands. The user benefits as well, as he/she might not even need to recompile to deploy a new shared/dynamic library. I've been deploying Pimpl for a while -- eliminated a lot of hassle as far as implementer-user is concerned. Best, V.