Re: [boost] Idea for discussion: Putting version number in boost namespace?

From: Lance.Diduck_at_[hidden]
Date: 2008-04-28 09:50:23

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_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Rene Rivera
Sent: Sunday, April 27, 2008 5:42 PM
To: boost_at_[hidden]
Subject: Re: [boost] Idea for discussion: Putting version number in
boost namespace?

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
_______________________________________________
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.