Bjørn Roald wrote:
Even if you solve this for the namespace, you can not safely have side-by-side headers from two boost versions in the same translation unit. You still have the issues of include paths and all the other BOOST_ preprocessor symbol definitions. There are probably other issues as well that is off my radar screen. Namespace variations only solve part of the issues, but if you don't mix boost versions in the same translation units you may be Ok. However, if you need to use boost types in interfaces used across boost versions -- then you need a different solution. The types need adapters, or they need to be aliased and binary compatible.
I am of the opinion that the best and most portable C++ ABI is C. So I hope the number of occurrences of Boost types in a C++ binary-only interface is close to 0! But yeah, two versions of Boost in one TU is asking for it.
By the way, I've received a message on IRC telling me that Xalan and Xerces do something very similar so it wouldn't be totally unprecedented
I was never pleased with the limitation of the Xerces method. So, some years ago I did some testing with a different approach to solve this. I used a patched version of the bcp tool to manipulate names of preprocessor symbol names, include paths, and namespace names in a copy boost (or of selected boost libriaries) copied with bcp. I did some promising tests and posted a patch to the list. I think Eric Niebler reported some success in using this approach.
I think your bcp patch is overkill just for compiling with a different namespace. However, it is the best solution for multiple versions in a single TU. I don't envy that guy's job though... -- Sohail Somani http://uint32t.blogspot.com