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