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.+31 (0)6 2411 0061 Fax.+31 (0)15 285 1984 thijs@sitmo.com <mailto:thijs@sitmo.com> - www.sitmo.com <http://www.sitmo.com>