Boost logo

Boost :

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
> (, 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

> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at