Re: [Boost-users] boost::graph issues.

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-08-18 06:29:24

David Abrahams <dave <at> boostpro.com> writes:

> In any case, if you want to be effective with Boost libraries I strongly
> suggest you don't use reading their implementation code as the primary
> way of understanding how to use them.  Most Boost libraries are very
> carefully constructed so that they are usable just by reading the
> documentation.

[...]

> How it works is not important if you're just trying to use the library.

I agree. The docs in general are high quality and sufficient
(except python and debugging w/o static linkage ;-)).

OTOH I believe that the development of boost has brought some techniques 
to life that are useful in general, so some meta-docs, some kind of 
extended rationale or some "The Design and Evolution of Boost" would
boost the development of boost itself. The developer ML shows messages
saying "This has been more elegantly solved in boost::x, check the source 
code there." And poor progranmmers then look at 
BOOST_MACRO_MAKES_ME_PORTABLE stuff mixed with the original technique.

"Take it, don't ask" is OK for users, since boost is well-thought,
well-done and well-documented, but this is only half of the truth.
We all not only are users, but also writers of code.
The value of boost not only lies in its interface and abstraction level,
but also in the knowledge behind it.

My favourite example of how things should be is Eric Niebler's
slow motion explanation in his splendid article about abusing 
ternary operator ?: to achieve a no-overhead-BOOST_FOREACH.
(http://www.artima.com/cppsource/foreach.html)
I have learned that one by heart. I have it in my head. 
It will help me one day.

Another issue I think is the fact that it is not transparent to the world, 
whether there is some development or not going on in some portion of boost.
 
E.g. boost::graph: Since years and years there is a Delaunay Triangulation 
anounced in the future plans of boost::graph 
(http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/challenge.html), but
I do not believe that oneanymore, especially since CGAL (http://www.cgal.org/)
went open source. So I considered boost::graph as DeadProject(TM).

OTOH I found by chance (digging into the wiki) that someone is working
on the named parameter scheme and some Summer of Code projects on
graph algos. So what's its state? 

Same thing with bind: 
It is a big boost FAQ which version of bind (original, ll::bind, tr1::bind,
fusion::bind, phoenix::bind, spirit2::bind, ...) to be used and the
answer depends on which month you ask and whether it is Joel or someone 
else answering (I like Joel's answer ;-)).
I think we could tag BLL as "not recommended" in future boost versions.

... and regular expressions:
I feel not able to find best choice among boost::regexp, tr1::regexp, xpressive 
and spirit semantic actions and happened to give a try to all of those 
(except tr1) in the same project. 

One could argue that this is normal for a fast evolving project to have 
concurrent engineering everywhere, but from user's point of view you sometimes 
cannot know your mass from a black hole anymore due to the number of choices
(which again is good, but makes it hard for first time users).

In short: I would like to propose some finer grained tagging of boost libraries.
It is no longer "The Boost Library", but "The Boost Libraries".
See sf.net as reference, from which I'd lend at least

- activity ranking + history
- maturity level (peer-reviewed is *not* mature)
- detailed and frequently reworked future plans
- alternative boost libraries with similar or superior functionality and/or
  "deprecated" tag, like for BLL

Markus