On 07/09/05, Mick Hollins <mick@hollins.id.au> wrote: Anthony Williams wrote:
Matt Hurd <matt.hurd@gmail.com> 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.