Re: [boost] [threads] rework notes

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-09-06 12:42:10

> On 07/09/05, Mick Hollins <mick_at_[hidden]> wrote:
> Anthony Williams wrote:
> > Matt Hurd <matt.hurd_at_[hidden]> writes:

<snip>

> > I think we should try and make it a header-only library akin to most of the
> > rest of boost, if we can; having to link in a separate library is a source of
> > pain for users, especially if it has to be linked as a separate DLL. I
> > appreciate that there are some areas which might require this, but if we can
> > avoid the requirement when these areas are not used, that would be good (don't
> > pay for what you don't use).
> >
> > Anthony
> 

<snip> good arguments for better quality via minimised dependencies
and Lakos-esque "large scale" compiler firewalls and the like from
Mick </snip>

I guess the widespread adoption of the inclusion model for template
based code has resulted in the wider adoption of the header only
model.  You could blame the lack of practical export facilities for
that mainly I think.  For many template based libs, especially heavy
type computation libs like boost.mpl, you don't have much choice. 
That's just the downside of modern C++ until the compiler and linker
technology catches up.

I agree that all things being equal faster compile times and hidden
platform dependencies are preferable.  Auto-linking would take out
most of the pain from linking.

The big negative is for other library writers wishing to rely on basic
synchronization primitives without forcing link dependencies where
their current libs don't have such a requirement.  For example,
boost.spirit follows the header only approach but conditionally
requires a basic synchronization primitive.  It seems to cope OK with
boost.thread as it is now, so perhaps it is not important.  Any
library writers have a comment on what they would prefer?

Q: Library approach instead of header only

Pros:
  - Faster compile times (I wonder how much faster in this case)
  - Minimises introduction of platform headers (more important IMO)
and other dependencies

Cons
  - May introduce link dependencies to libs that don't have them
(autolinking should take care of this)
  - Perceived barrier to entry for use by library authors (needs more
input from authors)
  - shared library linkage adornments detract from the code (pretty petty)
  - May not even be possible due to the nature of the statics required
(make the argument moot, expect perhaps for the 2nd alternative
approach below)
  - Easier support for header only.  Witness the FAQs w.r.t.
serialization, thread and regex linking issues.
  - Header only "encourages" synchronized versions of classes that may
optionally have synch policy parametrisation.  I dream that such
policies would be as pervasive as allocators in STL so I can stop
writing them myself.  I have a dream...

There are two other alternatives:

  1.  enable both by configuration macro (cpp becomes is used as an
ipp) - unusual

  2.  decide on which should be header only to suit lib authors as I
suspect simple synch primitives such as mutexes and their locks are
needed by most authors.

On balance the volume of the voices seems to indicate a preference for
library approach rather than a header only attempt.

Votes?  Further pros or cons?

matt.