From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-04-24 12:30:11
Sebastian Redl wrote:
> Jens Seidel wrote:
>> On Thu, Apr 24, 2008 at 12:37:09PM +0200, Sebastian Redl wrote:
>>> Any application that uses a precompiled
>>> Boost component probably uses other Boost components, too. As such, the
>>> likelihood is high that upgrading Boost means recompiling the
>> Please explain this! Probably you mean that beside Boost libraries
>> also parts of Boost are used which are provided in headers only?
>> Now you assume that one has to recompile to gain from the header only
>> parts? This is right but you forgot (if my assumptions are true)
>> that there is a much more likely case:
>> Every Linux or *BSD distribution (and probably also Cygwin and Fink)
>> contains Boost and applications linked against it.
>> Now assume the Boost maintainer in this distribution wants to
>> update Boost. With a stable ABI the maintainer just uploads a new
>> version of Boost and that's all. Without a stable ABI the maintainer
>> either has to keep the old Boost library (or better librar*ies* in this
>> case) and provide just another version or the upload of a new Boost
>> version requires a coordinated upload with all recompiled programs and
>> libraries which depend on Boost. This is a very big mess!!!!
> What I'm saying is that I believe it to be very dangerous to have your
> own application use Boost header-only libraries of one version and
> precompiled libraries that link against other versions of the
> header-only libraries. If components from the header-only version (say,
> a shared_ptr or an any) are somehow transferred between the main
> executable and the library, you're in great danger of crashing.
This is not anything specific to header-only libraries. Classes that
are in the public API, regardless of whether the actual implementation
is defined inline, or compiled in a separate object file, should not
change their layout in point releases, in my opinion.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk