Re: [boost] [pimpl] Some comments

Subject: Re: [boost] [pimpl] Some comments
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-06-05 23:13:14

On June 5, 2014 9:51:18 PM EDT, Vladimir Batov <Vladimir.Batov_at_[hidden]> wrote:
>
>On 06/06/2014 07:21 AM, Andrzej Krzemienski wrote:
>> ...
>>
>> [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.)
>
>Well, I feel you mix up two things here: pre-build analysis and the 
>build as such. The number of included headers has impact on the first 
>phase -- pre-build analysis -- as 'make' has to check those 
>included-files timestamps. I do not believe it's such an issue as I do 
>not expect to notice much/any performance differences from checking 1
>of 
>10 timestamps. So, if you have pimpl.hpp included with a few other
>Boost 
>headers thrown into the mix, then 'yes' it does increase the time of 
>pre-build analysis... which is negligible compared with the time of the
>actual build. Given those mentioned Boost headers do not change, they
>do 
>not trigger re-build. That said, when re-build is triggered by other 
>code, those headers to need to be compiled and that takes time.

You've glossed over the overhead of compiling your headers when the implementation details change. I doubt that adds a lot of time, but it isn't zero either.

>> [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.
>
>We might be developing for different industries. I've been working for 
>rail and air for the last 15 years and there shared data are
>everywhere. 
>Rail network topology is only one, aircraft data, airline schedules are
>all shared by many threads. So, my focus on shared_ptr-based 
>pimpl::pointer_semantics is clearly biased.

I took a quick look at the docs. First, like Edward, I was frustrated by how much I had to read to understand what the library offered and how. Second, you've extended the Pimpl Idiom. It has always been about moving the implementation details out of the header, not sharing those details. Thus, your value semantics implement the idiom and your pointer semantics provide something different.

If you don't try to shoehorn both into "Pimpl", you'll get better traction. I suggest "shared_impl" and "pimpl" as the names of the two class templates.

___
Rob

(Sent from my portable computation engine)