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