Re: [boost] [pimpl] Some comments

Subject: Re: [boost] [pimpl] Some comments
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-06-05 21:35:43

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__null___and_strongly_exception_safe_constructors.html
> 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.