Re: [boost] version conflicts: is there a solution?

Subject: Re: [boost] version conflicts: is there a solution?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2009-06-24 01:50:53

On Wednesday 24 June 2009 02:49:12 am Lewis Hyatt wrote:
> Hi Everyone-
>
> This has been discussed before
> (http://thread.gmane.org/gmane.comp.lib.boost.devel/180008), but I think my
> question is along a slightly different line so I thought I would ask about
> it. Let's say I want to compile and distribute a library (without the
> source), and I happen to use some boost header-only libraries as an
> implementation detail in some of my functions. None of the headers
> associated with my library include boost headers; it's purely an internal
> detail.

That makes it a lot simpler.  I would go for a solution where you rename the 
boost namespace in the source you include to something "private" for your lib.  
Eg namespace  mylib_boost { ..

But if you include a lot of source you probably want to have a tool for this.   

Armed with such a tool, updating to new version of boost for your internal use 
is simply a mater of re-running the tool.  Now I am ignoring all other 
possible issues unrelated to this thread.  

I have a patch for tools/bcp which does exactly what I think you need
as a part of the process bcp is intended for.  Bcp is used to copy part of 
boost with all its dependencies.  If you are interested in this approach I 
will brush some dust off the patch and sync it with trunk for you.

> Now, it seems to me that users of my library will still have to be aware of
> the fact that I used boost in my implementation -- specifically, if they
> happen to use different versions of the same boost libraries in their code,
> then the ODR is violated and the behavior is undefined.

Yes - and that is very bad.  Much better if you as a lib provider do some 
extra work to prevent this.  Put all your references to boost is in different 
namespace.

> I realize this isn't a boost-specific problem (it would affect any library
> of template functions), but I am wondering if there is a boost-specific
> solution already worked out? Has anyone thought about this? It seems to me
> that in this case, what would be ideal would be if I could do:
>
> #define BOOST_NAMESPACE some_unique_namespace_for_boost
> #include "boost/algorithm/string.hpp"
> BOOST_NAMESPACE::shared_ptr<void> x; //or whatever
> Then I can insure there are no ODR violations and I don't need to bother
> users of my library with the fact that I used boost at all.
>
> Other than the sheer annoyance of having to go through all the boost code
> to use this macro, is there a strong downside to this approach?
>
> Alternatively, I could try:
>
> namespace {
>     #include "boost/..."
> }

Hmm... I have no idea if this is defined how this will work.  But it may be 
worth figuring it out.

> But I don't know, could this work? Or are there boost headers that rely on
> fully qualified references like ::boost::algorithm::whatever?
>
> I'd appreciate anyone's thoughts on this issue, thanks!

Many approaches to a general solutions for these issues would require changes 
to a lot of boost, code and they do not support all use-cases.  One difficult 
issue which you have avoided is side-by-side headers from multiple boost 
versions in same translation unit.  My bcp patch is an attempt to get around 
these issues in a general way.  As my need back then faded away, I am unsure 
of how field tested the patch is by others on this list.  Some people tried it 
out.  Artyom's script may be a simpler solution for you, but I have not tested 
it.

-- 
Bjørn