Re: [boost] Boost.Threads, N2178, N2184, et al

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
PI SHURLOK LTD
Telephone: [phone] / 203894 (direct)
Fax: [phone]
Email: martin.bonner_at_[hidden]
www.pi-shurlok.com