Jonathan Biggar wrote:
I noticed some discussion in threads about the worries that some people have with linking their application against boost and then needing a third party library that also links to a potentially different version of boost that might not be available to the in source form.
Has any thought been given to changing the boost namespace declaration to include the version number, like this:
namespace boost_1_35_0 { // boost libraries declared here };
#ifndef BOOST_NAMESPACE_ALIAS_DECLARED #define BOOST_NAMESPACE_ALIAS_DECLARED
namespace boost = boost_1_35_0;
#endif // BOOST_NAMESPACE_ALIAS_DECLARED
This allows an application linked to boost 1.X+1.0 to also link to a third party library that privately uses boost 1.X.0 without causing ODR problems. Of course it doesn't help if the third party library exposes boost types in its interface. [...]
I was just discussing such a trick in the IRC channel in relation to the library building, and dealing with variants. The idea would be that instead of generating a bunch of different library files, we mangle the boost namespace name to include the variant one is using (which would include the version as you suggest). Using this would allow to build many variants, but still have the simple linking use pattern of "-lboost_foobar". Unfortunately it might not be possible to remove all separate library build, as many aspects of compiling affect ODR at the std level. As the discussions of the MSVC runtime options have illustrated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail