David Abrahams wrote:
on Fri Sep 12 2008, Sohail Somani <sohail-AT-taggedtype.net> wrote:
#undef BOOST_NAMESPACE_boost Indeed, you are right. Clever too :-)
There is one obvious problem I see with the -DBOOST_NAMESPACE=foo approach: there is no way to include two versions of Boost within the same translation unit. Unfortunately, I don't think there would be any acceptable way to do this. Though I'm sure you will come back with a way to do it!
I think you do that by sticking each version of boost in its own namespace, turning off the global namespace alias, and using explicit qualification to select the version in question...
This still has the problem that all the Boost source code needs to be changed to use version-specific macros and version specific includes. So a version 1.34 header might look like: #ifndef INCLUDED_BOOST_FUNCTION_HPP_134 ... #include <boost_134/function/detail/base.hpp> // or whatever I think you can guess what the 1.35 header would look like. I personally think that two versions of Boost in the same TU can /only/ be solved in an acceptable way by bcp.
If you want to be ambitious, there's also the issue that some libraries (or parts thereof) might want to maintain binary compatibility across releases. Suppose that nothing in Boost.Signals changes between 1.37 and 1.38. Should that generate two sets of symbols with non-interchangeable types?
Without a totally comprehensive policy for ABI compatibility (good luck with that one, I'm told!), I have to say yes. Ideally, no, but practically yes. -- Sohail Somani http://uint32t.blogspot.com