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
>> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk