
*Online docs:*
* What is your evaluation of the design? The requirements and goals are not entirely clear. Is this a library for building strings at the point of logging and delivering that sequence of strings to one or more storage+viewing mechanisms? If so then its a sufficiently good design. To raise the bar you might include requirements such as gleaning maximum information from the point of logging, with minimum developer fuss and delivering that information to a storage+viewing mechanism for convenient post-processing and analysis, e.g.; - the library doesnt appear to use the __LINE__ facillity - how do I log the value of a variable and then search for that variable by name? - how do I search for the next reference with any assurance that the same name is used? - where is the default mode that just works "out of the box" * What is your evaluation of the implementation? Didnt look. * What is your evaluation of the documentation? Reasonable. Some strong concepts though a little disjointed. * What is your evaluation of the potential usefulness of the library? Useful. This looks after most of the needs relating to developers debug output and also more permanent support output. It does not appear to consider what often occurs with such output - it may be the best or only record of system activity and will become the focus of more complex post-processing and analysis. The library does not specifically cater to such activity. * Did you try to use the library? With what compiler? Did you have any problems? No . * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Somewhere between a quick reading and an in-depth study. A few hours of reading and analysis. * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. No. As an example of a developers debug logging facillity this is one of the better ones. A Boost logging facillity should be targeted slightly differently. Solving the requirements of developers debugging should be a side benefit of solving the wider issue of recording system activity for any of the system stakeholders. Cheers, Scott