On 6/06/2014 09:21, quoth Andrzej Krzemienski:
[1] The main point in using pimpl idiom (at least my) is to avoid header inclusion, which may grow compilation time too much (at the expense of certain run-time cost). But in order to use Boost.Pimpl I do need to include a header file, which in turn includes more header files. This is arguably less headers that in normal non-pimpl implementation, but it is more than if I used a raw pointer. And this is what I finally did in my work: switched to raw pointers for implementing piml in order to get the build perform faster. (I didn't measure the improvement though.)
As I see it, the main benefit of pimpl comes from avoiding recompiles due to *mutable* header files -- ie. if I make a change in private implementation of a class, I don't want to have to recompile all consumers of that class (but that's needed if I change the public interface). Depending on (mostly) immutable header files (such as Boost.Pimpl itself) is usually not a problem; you can resolve compilation-time issues with these by using precompiled headers.
[2] Boost.Pimpl is good for everyone: people who like value semantics get the value semantic interface, and people who like shated_ptr's get shared_ptr semantics. Call me selfish or biased, but I believe using shared_ptr's should be banned (at least in 90% of the cases where it is currently being used), and the fact that you advertise it first in the docs makes me uneasy.
+1.
[4] This page: http://yet-another-user.github.io/boost.pimpl/the_boost_pimpl_library/pimpl_... says "The advantage of the 'built-in' *Book::null()* [...] is that it makes possible an implementation of strongly exception-safe constructors, the copy constructor" There seems to be something wrong with this statement. How can a strong (commit-or-rollback) guarantee apply to constructors? If an exception is thrown from constructor the object is never created or accessible, so no-one cares about its state (as long as it doesn't leak). Or did you mean the no-throw guarantee? But the latter looks like an anti pattern. What is the value in concealing the exception (and information it carries) and instead produce null objects, which cannot be used?
I presume this is related to the Null Object Pattern, which TBH I've never been entirely comfortable with -- while at first glance it might make the code tidier to avoid explicit null checks and instead provide a reasonable do-nothing-return-defaults immutable fake/"null" object, the reality is that you often want completely different behaviour for null vs. non-null cases and it's usually not sensible to pretend the action was successful while actually doing nothing, so you end up putting the null checks back in anyway. And instead of a simple "is this pointer null" check which the compiler can almost always optimise down to almost nothing, you now have an "is this object equal to the null object" check, which can get quite heavy depending on how things are internally implemented.