Re: [boost] [tools][bcp] using boost internally in other libraries

From: John Maddock (john_at_[hidden])
Date: 2005-09-23 09:54:31

>I know -- in a post some time back I mentioned that a sort of index of how
>stable the maintainer and boost developers considered the various accepted
>library APIs to be might be helpfull.  I would have an easier time getting
>accept for using a library considered more stable by the developers.  This
>information is not available to me now.

Good point.

>> - maintainability of Boost source code
>>
>> That's a genuine concern, we have some code that can probably only be
>> maintained by the folks who wrote it, and that's not good at all.
>>
>
>This is closely linked with commercial support.  If a product is
>commercially supported by somebody I trust, then I might not care. But if
>it is not, I will have to consider the possibility of having to fix
>problems myself.  If I have no reasonable way of understanding the code,
>it spells TROUBLE.

Understood.

>> 1) Side by side binaries: requires that symbol names in binaries are
>> unique
>> to the Boost version being used, or even the library being compiled.
>> Requires that the Boost namespace be customisable to something other than
>> "boost".  I guess we could do what STLport does and make the namespace a
>> macro throughout Boost,
>
>This would give one source, better than mingling with source code.
>However I am not aware if a macro is a good solution for this, does that
>work well for STLport?

Well I must admit I've never tried to change STLports namespace away from 
the default, but the intention is clearly there.  In theory it's just a 
question of setting a #define somewhere and away you go.

>> 2) Side by side headers: only needed if the library exposes it's Boost
>> dependency in it's public API's.  Requires that the #include's get fixed
>> up
>> to include via a path other than boost/.  This is not as easy as it
>> sounds,
>> because there are some #include's in Boost that proceed via macros.
>
>I do not understand exactly what you mean with "proceed via macros".
>Could you point me at an example please?

Sorry, I mean things like:

#define MYHEADER <boost/whatever.hpp>

// then much later, different source file maybe:

#include MYHEADER

Boost.Config does things like that, as does MPL I believe.  However thinking 
about some more a global search and replace for "boost/" would probably be 
good enough.

>Yes,  I think I would just use "mylib_boost" since the version would be
>implicit through my configuration management.  Hopefully my customers are
>only using one version of MyLib ;-) .   But thats really their problem,
>not mine.
>
>Nesting would however be nice since we internally could write
>
>#using namespace MyLib;
>
>and then write boost code as everybody else.

How about a namespace alias:

namespace acme_computing_boost_1_33_0 {}

namespace boost = acme_computing_boost_1_33_0;

Is that an acceptable alternative?  It could be boilerplated inside the 
Boost.Config system if necessary.

John.