Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Isidor Zeuner (boost_at_[hidden])
Date: 2010-05-16 21:36:37

> > 
> > I haven't tried if a -Dboost=boost_1_43 preprocessor flag
> > (applied
> > to both the boost build and the application build) is
> > sufficient,
> > though.
> 
> There is my small python script that renames boost [1]. It renames
> all includes and defines so you can simultaneously use several 
> boost version in same code.
> 

Thanks for the pointers. This already sounds very useful for bundling
boost. Actually, I'd think it would also solve your problem: you
could bundle a renamed boost and control yourself what updates you
allow. Thereby you allow a binary stable build. Yet it would be still
possible to provide a compile time flag to use the system boost
instead. So people comfortable with a changing ABI can avoid having
two boosts, and people uncomfortable with it don't need to have
that issue.

But what I would like even more to see would be boost solving the
renaming problem without copying, by just using the
preprocessor. Think replacing all the namespace boost { ... } with
something like:

BOOST_NS_START
..
BOOST_NS_END

..and boost::foo with BOOST_NS::foo. Then the BOOST_NS* macros could
allow to have preprocessor-controlled namespace naming.

> Also latest BCP version allow you to do similar job, but it does not
> rename includes and macros so you can't include two boost version in
> same C++ code.
> 

I do not see a point in using two boost versions in the same
compilation unit. This would just increase code size.

> Note: my script was written before BCP provided such option.
> 
> **BUT!!!!** It does not solves all problems:
> 
> 1. There is a code placed in tr1 namespace - it would collide if you use
>    it.
> 2. Some libraries that provide extern "C" functions do bad job and pollute
>    global namespace with these symbols. They collide as well.
> 
>    Examples: 
>    - Boost.Thread: https://svn.boost.org/trac/boost/ticket/3812
>    - Boost.Test: https://svn.boost.org/trac/boost/ticket/3811
>    - LW Thread: https://svn.boost.org/trac/boost/ticket/3810
> 
>    But in some libraries this behavior is actually design. For example
>    boost.regex provides POSIX regex API regcomp(A|W), regexec(A|W) that
>    go directly to global namespace. 

Thanks for the pointers. I think it would be a great benefit for boost
to make all these global names preprocessor-configurable.

> P.S.: as you can see it is quite non-trivial issue.
> 

I already feared it was that way :). But I think this is the way to
go. Maybe we can have multiple-parallel-boost-versions regression
tests some day. But this would call for a distributed SCM system like
git for boost development, so an automated test could pull an older
(incompatible) version to compile against without bothering the svn
server all the time.

Best regards,

Isidor