Re: [boost] [threads] rework notes

From: Dylan Trotter (trotterdylan_at_[hidden])
Date: 2005-09-06 10:17:49

> I am really surprised to see everyone agreeing that a header-only
> implementation is preferable.

I completely agree with that sentiment.

> In my day job we have strict rules about
> what is allowed to appear in header files, the principal reason being to
> reduce dependencies between header files in order to keep compile times
> and code bloat manageable. For example, we prefer forward declaring classes over #includes
> when possible, we use the pimpl idiom on occasion, we use abstract interfaces
> in as much code as possible, etc. All of which help to make for a more
> loosely coupled design which has the benefit of minimising the amount
> of code that is transitively included in each compilation unit.
> 
> I think that boost is an excellent set of C++ libraries, but I have always been
> dissapointed by the apparent philosophy of putting
> most or all code into header files. I can't remember the details, but
> we had one occasion about a year ago where our application's build times increased
> fairly dramatically when we upgraded boost versions. We tracked the problem down to a
> boost header that we were including having been changed to include another boost header
> which ended up transitively bringing in hundreds of header files.
> 
> Now I know that making the most of C++'s template mechanisms does imply that more code
> will end up in headers than traditional C/C++ code, but to me that is all the more reason to
> look extra hard for opportunites to place at least some of the code into .cpp files.
> 
> As a user of boost, linking in a few libraries is a minor pain that I am willing to take,
> compared to the pain of long build times.
> 
> cheers,
> mick

I think that many of the libraries are well suited to header only 
implementations. In particular, where most classes are templates. In 
something like threads however, the opposite is true. The implementation 
of threads is completely platform dependent and those platform details 
ought to be invisible (i.e. buried in .cpp files) to a library user.

Building and linking in a library is a very small price to pay 
considering how good Boost.Build has become in recent releases. If there 
is to be any effort devoted to getting novices running Boost.Threads it 
should be directed at improving the "Getting Started" documentation 
(although I personally find it quite sufficient) or by providing 
pre-built libraries for the popular compilers.

Glad to hear Boost.Threads is getting a re-work though. I thought it was 
a shame that it wasn't getting any attention lately, considering how 
important it is for cross-platform development.

Thanks,

Dylan Trotter