Boost logo

Boost :

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-05-15 23:51:22

Piyo wrote:
> Felipe Magno de Almeida wrote:
>> Sorry answering to myself.
>> On 5/15/07, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> 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 {
> ---------------------------------
> example: boost_foo.h
> ---------------------------------
> #include "user-config.h"
> namespace boost
> {
> // do you regular stuff here
> }
> ---------------------------------
> 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.

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.

> _______________________________________________
> Unsubscribe & other changes:

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