Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-12-03 16:58:41

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:874p1lvvbr.fsf_at_mcbain.luannocracy.com...
>> which might sidestep some of the recent iterator_range anarchy, and 
>> simplify other
>> major transitions. N.B. I
>> haven't really thought about the ramifications of doing this, so the idea 
>> might be
>> completely unworkable in
>> practice.
>
> It also allows multiple versions of boost to exist in the same
> executable without ODR violations.  The ability to configure boost that
> way would be most welcome.

While the above seems like it may be useful, I can also see some potential 
difficulties.  We would probably need to try and come up with a set of 
guidelines for users and developers on how to best take advantage of such a 
system.  Here are a few things that come to mind:

1)  From the discussion here, it is clear that a lot of users are very 
flexible when it comes to upgrading to a new version of boost.  As such, 
they would want to just keep writing boost::foo, so that when they upgrade, 
their code continues working without having to go through and change 
boost_X::foo to boost_Y::foo.  This and a few other points I will mention 
below make me think that having versioned namespaces is not an alternative 
to the new/stable release cycle (I don't think the original poster 
necessarily intended it to be).  I also have to say I can't quite see how it 
would have solved my original problem with Boost.Range.
2)  While having different boost versions in different namespaces will allow 
different versions to exist in the same executable, because they are not 
interchangable, there cannot be any interoperability.  That doesn't mean I 
don't think it's useful - in fact, I've been faced with similar problems 
before and versioned boost namespaces would have been fantastic to have. 
But given the above, I think the utility is limited to the following two 
cases:
 a)  The different parts of the executable (e.g. your code and the vendor 
library) use a disjoint subset of boost.  Possible, but seems unlikely.
 b)  The different parts of the executable only use boost as an 
implementation detail (i.e. it's not exposed in the interfaces), so 
interoperability is not an issue.  A vendor library is a good example. 
Another one is an application that supports external modules/plug ins.

I think the plug-in case may be important enough to make this change.  I've 
had some other middle-of-the road ideas but I think we are already talking 
about introducing a big burden on the developers here.  I would also like to 
re-iterate that I don't think this replaces the need for the stable/new 
release cycle, which, to some degree, would be able to ameliorate the 
"different versions of boost in an executable" problem, too.

Tom