Re: [boost] Should Boost adopt pimpl/d-pointer as much as it can?

Subject: Re: [boost] Should Boost adopt pimpl/d-pointer as much as it can?
From: Josh Faust (jfaust_at_[hidden])
Date: 2010-03-22 18:22:08

>
> i strongly diagree with you
> i think one should strive to make his library open to as many users as
> it is possible, not only pro developers
> that is the scourge of modern software engineering (as i understand it)
> modern tools are so complicated that only very experienced programmers
> can handle it
> please don't make things worse than they are!
>
>
A lot of professional developers (and corporations) refuse to use boost
because of the increased compile times in client code.  Focusing on people
who are not comfortable linking against other libraries (a pretty
fundamental part of C/C++ development) to me focuses on the entirely wrong
set of developers.

Boost.Thread is a great example where there's no reason for it to be header
only.  Compare:

#include <boost/thread/mutex.hpp>

int main(int argc, char** argv)
{
}

time /usr/bin/g++ -O3 test_thread_compile_time.cpp -o
test_thread_compile_time

real    0m0.492s
user    0m0.420s
sys    0m0.020s

to the pthread equivalent (whose header includes far more than just
mutices):

#include <pthread.h>

int main(int argc, char** argv)
{
}

time /usr/bin/g++ -O3 test_pthread_compile_time.cpp -o
test_pthread_compile_time

real    0m0.091s
user    0m0.020s
sys    0m0.020s

This is without even *using* anything from Boost.Thread, just including that
one header -- it pulls in 227 other boost headers, 322 total.  Changing that
header to boost/thread/thread.hpp increases that time to ~0.9 seconds.

The actual method of separation (pimpl, implementation in a library, etc.)
doesn't matter, and in some cases it doesn't make sense, but it would be
nice if there were a policy to try and keep compilation times for clients as
low as is reasonably possible.

Josh