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

From: bjorn_at_[hidden]
Date: 2005-09-23 14:41:14

On Friday 23 September 2005 16:54, John Maddock wrote:

>
> >> 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.

Yes it seams to be a reasonable assumption that it would work fine.  However, 
I would not like to be the one that have introduced the idea of using 

#define BOOST_NAMESPACE boost

simply because

namespace boost { 

is much more pleasing to the eye than 

namespace  BOOST_NAMESPACE {   // ushhhjjj

It does however open up for some interresting possibilities, by the way I 
think you came up with it ;-)  kidding aside, see what I write below about 
your comments on side-by-side header support.

>
> >> 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/.  

in addition, a macro based solution will not work well in a side-by-side 
header setting.  The macros would expand to the same string when used in 
application.  Hence different definitions of types would be used internally 
in the library from those in the API in context of the application.

My main concern in my original post was support for side-by-side binaries.  
However if a relatively drastic solution is needed, we should consider 
side-by-side header support as well.  To me it does not look like the macro 
solution support that. 

> >> 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.
>

Ok, I see.  

I think as you point out that this would work fine.  In my experimental 
extention to bcp I add a file header informing that the file is an 
autogenerated derivat of the original Boost file.  Then I replace text based 
on a replacement namespace given as parameter. e.g. --namespace=MyLib::boost
where the idea is to replace :: with / for paths and _ in macros.  

boost.org --> boost.org
boost/      -->  MyLib/boost/
boost       -->  Mylib::boost         ( not implemented for nested ns yet )
BOOST    -->  MYLIB_BOOST

This actually seemed to work surprisingly well.  I have not done extencive 
testing on resulting code except for trying to compile some resulting 
mylib_boost libraries.  That worked fine. There are possible traps, and the 
solution does not feel robust at all.  I belive this solution need to be 
supported by a tool with much better inherent capabilities for C++ syntax 
than plain regexp replace, so what I have is nore like a prototype.  I would 
not like boost developers to have to be careful not to break features in such 
a tool.

> >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.

For side-by-side binaries that is fine, but not for side-by-side headers.  But 
again, I could live with that.  Side-by-side headers would however be nice to 
many, I think.  If they really had different symbols in headers while 
compiling code using MyLib boost types could safely be used in API.  How to 
deal with possible need for type convertion for types used in API, e.g. 
between Mylib::boost::filesystem::path and boost::filesystem::path, would 
then be a problem that the user of MyLib could handle in a variety of ways.  

An interresting thing I come to realize now is that my choice to look at a 
search replace strategy partly come from an interrest in not excluding 
posibility of using boost types in API.  I think my preference would be not 
to use them to avoid symbol incompatibillities.  But if they are in a 
different namespace they are no longer the boost types, or are they?

------
Bjørn