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
Not just version number, but fold in relevant build options as well. A good example is _SECURE_SCL on MSVC, and _DEBUG on stlport build -- both affect ABI. On SunWS, this would include which std lib was used. And so forth. Not only does this allow multiple versions to a certain degree (IO libraries are suspect, since they often like to attach themselves to a single non shareable resource) but configuration problems get noted in a dramatic way at link time, esp if you have a very descriptive namespace. Drawback -- added size of executables to hold the names, difficulty reopening the namespace, and "namespace as configuration metadata" is a battleground when many heterogenous libraries want to put data in there for their own purpose. Another way I have seen this solved in the past is to do something like <toolset-msvc:version>8.0:<define>boost=boost_1_35_0__SCL_SECURE_NO_DEPR ECATE__MT And the users build tool would do an analagous define i.e. using -D This works fine when all the various lib contributors are aware of the technique, and play along. Then it is up to the user to add as much or as little as they need. Advantage, "follows the the 'Don't pay for what you don't use rule'", and very simple to implement. Disadvantage= wreaks havoc with anything else called "boost" ,users have to know what is important in versioning, cannot use multiple versions The model follwed by Xerces works very well, which is close to Rene Rivera described. The change would be that this namespace boost_1_35_0 { // boost libraries declared here }; namespace boost = boost_1_35_0; becomes namespace BOOST_NAMESPACE { // boost libraries declared here } namespace boost = BOOST_NAMESPACE; Where "BOOST_NAMESPACE" is something like #ifndef BOOST_NAMESPACE_OVERRIDE #define BOOST_NAMESPACE boost #else #define BOOST_NAMESPACE BOOST_NAMESPACE_OVERRIDE #endif //BOOST_NAMESPACE_OVERRIDE BOOST_NAMESPACE_OVERRIDE is something defined by the build. Then a person using multiple versions has a way to accomplish this, but the typical user does not have to worry about it. The user in now responsible for the version ing metadata, according to their own policies. Lance -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Sunday, April 27, 2008 5:42 PM To: boost@lists.boost.org Subject: Re: [boost] Idea for discussion: Putting version number in boost namespace? Jonathan Biggar wrote: 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.