Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2008-12-03 18:08:11

Matthias Schabel wrote:
>>>> 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.
>
I thinks its much better to have a users alter the list of include 
directories that are searched,
instead of introducing all these changes.
When searching for a header file, the compiler will search directories 
in the specified order.
If you put a 'patch' directory tree in first (which is a thing *we* do), 
the compiler will search
that one first the include, and otherwise search the laterst boost 
directory tree.

If that doesn't cover the needs, then a user can just copy-paste old 
boost code with old
interfaces into your private code.

Remember, these issues are exceptions, when users are not willing to 
upgrade,
..which is ok, there is no obligation. User should either be flexible in 
that 1% of the time and
adopt, or branch if it's too problematic. There are already enough 
solutions in place
when you are flexible and pragmatic.

The solution where *everybody* has to change their
code in retrospect by inserting using namespace boost = boost_1_38_0;
sound like the minority hurting the majority.

-- 
SITMO Quantitative Financial Consultancy - Software Development
M.A. (Thijs) van den Berg
Tel.[phone]
Fax.[phone]
thijs_at_[hidden] <mailto:thijs_at_[hidden]> - www.sitmo.com 
<http://www.sitmo.com>