Miscellaneous There are a few miscellaneous topics that deserve mention. As mentioned in the original review announcement, there are a few known problems: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) If the library is accepted, I will work on these (and other issues that are being brought to my attention during this review). Another issue has been that the library is "too huge" to grok at once; hopefully these messages will help people grok different parts of the library independently. Along those lines, I can imagine some people arguing during the review that some portions of the library be accepted and others rejected. If that's what ends up happening, then it's ok, but as practical matters, keep in mind that - there are a number of non-obvious implementation dependencies among the library components, so some parts of the library may not be able to be "excised" easily - I "have users", and if (part of) FC++ gets accepted into Boost, I would like to provide my current users a smooth transitional path As an example, I can imagine people not being enamored by "indirect functoids". If so, I'd like it if they could be included/accepted, but also deprecated, and then when result_of gets into Boost and experience shows that boost::function and FC++ interoperate ok, then indirect functoids could be removed (and possible some of their extra features "absorbed" into boost::function). The overall point being, I think given the overlap of parts of FC++ and Boost, it might be practical to judge the review with an eye towards "transitional path" rather than just "immediate yes/no". But let me know what you-all think of that. -- -Brian McNamara (lorgon@cc.gatech.edu)