Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Matthias Schabel (boost_at_[hidden])
Date: 2008-12-03 17:40:19

>>> 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.

I think that the only change that would need to be made in most end- 
user code
is a namespace alias:

using namespace boost = boost_1_38_0;

The advantage of this is that upgrading to a newer boost library will  
trigger a
compile-time error. You also have self-documentation on the version of  
boost
that was used to develop the code.

> 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).

Right, it was not my intent to say anything about the idea of flagging  
libraries new/stable
(which I also agree seems like a good idea).

> I also have to say I can't quite see how it
> would have solved my original problem with Boost.Range.

My understanding of your issue may be incomplete, but I imagined that  
you would just
include the boost_1_32_0 headers in files relying on the old  
iterator_range behavior.
This would allow you to continue to use that version of the code,  
while simultaneously
using more recent versions of other boost libraries (as Dave pointed  
out). In fact, I was
even thinking that previous releases of the libraries could be  
retrospectively altered with
the new boost namespace policy and re-released to provide some  
backward continuity.

> 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 may be true, but it may be the case that you inherit some code  
that uses an older
version of boost, and you would like to modify or extend part of that  
code with newer
boost library facilities without having to mess with the older, tested  
code that already
exists. By having unique namespaces, you can accomplish this  
relatively easily. The main
issue I see is naming of header files : should the directory structure  
also be altered so that
the headers are, e.g., #include <boost_1_38_0/units/quantity.hpp>?  
This seems safest,
but imposes some additional overhead.

> 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.

I actually think that this is fairly probable, since larger projects/ 
vendor supplied libraries
generally are (for good reasons) slow adopters, if you want to use one  
of the shiny new
boost libraries without breaking the vendor code, having the namespace  
separation would
be nice.

> 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.

The real issue is how can this be done in a way that minimizes the  
impact on both developers
and end-users. It seems like some clever preprocessing could help ease  
the transition...

Matthias