Boost logo

Boost :

From: John C. Femiani (john.femiani_at_[hidden])
Date: 2008-08-09 10:18:46

Isaac Dupree wrote:
> (more generally/irrelevantly, I'm surprised how often Boost libraries
> share techniques that ought to be libraries in themselves. And how
> poorly commented some of Boost code is... but there I'm getting way
> off topic :-P)
I agree, and I notice a number of submissions (e.g. fusion, proto) say
they were previously a part of Spirit or something.

It looks to me as if some of the libraries should be re-reviewed
sometimes, because I think the suite of tools available in boost changes
and the libraries need to be kept consistent. For instance, as a user,
I don't immediately see why there is a need for Boost.Bind _and_
Boost.Lambda. I don't know why a GIL image does not use the concepts
from MultiArray (same with uBLAS), and I don't know if 'Tuples' will
become irrelevant now that we have Fusion cons/lists (and more powerful
algorithms etc.) Also it seems like the 'operators' and the 'iterators'
libraries overlap IIRC. I also don't know why we need three different
sets of placeholders in mpl, bind, and lambda (perhaps 'cause I don't
know implementation details).

Frankly, recently I have been experiencing some anxiety over which boost
tool to choose because of the almost-but-not-quite repeated stuff.


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