On June 5, 2014 9:51:18 PM EDT, Vladimir Batov
...
[1] The main point in using pimpl idiom (at least my) is to avoid
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
On 06/06/2014 07:21 AM, Andrzej Krzemienski wrote: header 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)