Re: [boost] What is boost: was New libraries implementing C++11 features in C++03

Subject: Re: [boost] What is boost: was New libraries implementing C++11 features in C++03
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-12-01 19:58:39

Nevin Liber wrote:
> On 1 December 2011 14:29, Robert Ramey <ramey_at_[hidden]> wrote:
>
>> a) libraries are modular.
>> c) Libraries would be updated/versioned on their own schedule.
>
> So how do you solve the versioning problem?
>
> If Boost.Thread.90 requires Boost.SmartPtr.76 and Boost.Filesystem.90
> requires Boost.Smartptr.77, you've got a usability nightmare on your
> hands.  I don't see any way around Boost libraries having to work
> together in all baseline releases (which is what we have now).

I did consider this some time ago.  I proposed something on this
list.  I forget the details right now but basically it would be along the
lines of each library being able to report it's version at compile time
and execution time.  Libraries which use other libraries would be
able to check that their requirements are met  by inquiring this API.
I believe that something similar - though likely more elaborate is
ipmlemented as part of COM on windows to address the "DLL hell"
issue.  When I proposed this before, the consensus was that such
as system wasn't necessary.  I didn't really buy this but I other stuff
to do so I just dropped it.

> And this is a practical problem, as I have yet to work anywhere that
> doesn't have this problem when they integrate libraries from more than
> one source.

Hmmm - I have to address this all the time.  If I make even a relatively
simple Ap it might use the msvc C++ library, some version of the STL
library, some version of SQL server and some version of windows.
Then there might be some DLLS for special controls or whatever.
All of these components have their own versioning.  We don't
demand that all these be deployed as a monolithic group.  If
we have to deploy a group of components together, we're really
saying that the compoents are coupled together in their implementation
which is basically an error.

And this has already occured with parts of boost.  ASIO, spirit, GIL
and who knows what else were deployed separately before becoming
part of boost.  A requirement to deploy/version them concurrently isn't
necessary nor is it convenient.  And it's not pratical in the long run
as it can't scale.

Robert Ramey