Boost logo

Boost :

From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2007-03-23 08:37:21

----Original Message----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Yuval Ronen Sent:
23 March 2007 11:43 To: boost_at_[hidden]
Subject: Re: [boost] Boost.Threads, N2178, N2184, et al

> Peter Dimov wrote:
>> Case A, call_once implemented in the header. You ship an improved
>> call_once.hpp. User program needs recompilation to take advantage of
>> the improvement.
>> Case B, call_once a thin wrapper over a C API, as in N2178. You ship
>> an improved .lib/.dll. User program doesn't need recompilation (lib)
>> or relink (dll).

That strikes me as an ADVANTAGE of a header only implementation. As an
application author, I don't want somebody changing a library I'm using
under my feet. (My favourite example is: Library documents that it
returns a collection in a random order. Actual implementation returns
sorted data. Application starts using std::lower_bound (which is a bug
in the application, but works). Application ships. Library is improved
and returns collection in unsorted order. Application crashes.)
> Has anyone ever encountered a scenario where a new version of a
> library is published, and applications using it consider re-compiling
> a major (or even minor) drawback?
Well, I've often encountered the case that I consider changing to a new
library has associated disadvantages (I need to go round retesting
everything). But the recompilation is certainly not an issue.

> And if so, why does Boost push so hard for a
> header-only implementation of its libraries? Isn't it a contradiction?
There is a difference between Boost (which is hard to install - though
getting easier), and a C++ implementation (which usually is pretty
straightforward to install on it's target platforms).

Martin Bonner
Project Leader
Telephone: +44 1223 441434 / 203894 (direct)
Fax: +44 1223 203999
Email: martin.bonner_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at