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