From: John Maddock (john_at_[hidden])
Date: 2005-09-06 12:28:31
> I am really surprised to see everyone agreeing that a header-only
> implementation is preferable. 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
> 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.
> 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.
Violent agreement, Boost.Threads is an excellent candidate to keep
implementation and interfaces separate.
However, there is a need for a small (possibly *very* small) subset which is
header only so that other Boost libs which otherwise need no external
linkage can become thread safe without constantly rolling their own solution
(something that is a "bad thing" with a capital "B" !). I would guess that
one mutex type would do it at a pinch, but call_once and various atomic
operations would be a help as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk