----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Yuval Ronen Sent: 23 March 2007 11:43 To: boost@lists.boost.org 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: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com