Piyo wrote:
Felipe Magno de Almeida wrote:
Sorry answering to myself.
On 5/15/07, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
[snip]
Which is desirable for a library developer.
Sure I meant *un*desirable.
Best regards,
I agree with Ulrich that the problem is not specific to Boost but the solutions that we use impact the library in question. What I guess I am saying is that if Boost were to adopt user- definable versioned namespaces, it would help a lot. Here is what we have been doing for other open source libraries:
example: user-config.h --------------------------------- #define SITE_SPECIFIC_NAMESPACE_BEGIN namespace v1_33_1 { #define SITE_SPECIFIC_NAMESPACE_END } ---------------------------------
example: boost_foo.h --------------------------------- #include "user-config.h"
namespace boost { SITE_SPECIFIC_NAMESPACE_BEGIN // do you regular stuff here
SITE_SPECIFIC_NAMESPACE_END } ---------------------------------
For people who do not care, SITE_SPECIFIC_NAMESPACE is simply nothing and it reverts to your unversioned boost. Otherwise, if we do care and put our versioning in it, we can now distinguish different interfaces and plus have the compiler warn us of such mixing.
This helps, but it is ugly and in my opinion far from bullet proof. You have to consider other aspects as soon as you expose 2 versions of the same header files. E.g. are all macro/precompiler definitions compatible?
Thoughts? concerns? Any other alternatives?
You could read this thread. http://lists.boost.org/Archives/boost/2005/09/93902.php If there is any interest I can dig out the modified bcp code. As I remember it worked well for replacing namespace boost and all references to it with whatever you like, e.g. boost with boost_1_32. It would also replace any boost macro BOOST_XX with BOOST_1_32_XX. This worked nicely with running the boost tests in the boost/status directory. I was down to a few errors which seemed related to Jamfiles. One effect of this approach is that the code using boost would have to use the new namespace and macros. It would be annoying to use versioned names, hence I would use mylib_boost, boost_mylib, or boost::mylib. Then you have to hope your clients are not using more than one version of mylib in the same app ;-). In a situation where you have a lot of plug-in components, using versioned names would allow them to share boost .dll/.so file dependencies. The latest version of the bcp code I worked on attempted to do nested namespaces like boost::mylib. This was only partly completed using boost::xpressive with encouraging results. -- Bjørn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost