* What is your evaluation of the design? I think the library is overdesigned, learning curve is too shallow & very difficult to comprehend for a casual user. Author has persevered with the notion of employing namespaces to encapsulate concepts - this leads to a profusion of unrelated names & types, apart from the arguable soundness of this approach.
* What is your evaluation of the implementation? Unwieldy & too reliant on preprocessor macros. Namespaces are over-used. Some important considerations have been overlooked (e.g. output encoding, state of
* What is your evaluation of the documentation? Comprehensive, but too informal. Ultimately insufficient to aid in understanding
* What is your evaluation of the potential usefulness of the library? I think that with a simplified design, discarding of maybe 25 out of the 30+ namespaces used, automatic defaults for typical tasks, no reliance on macros,
I reckon that the problem is that the author has designed the library to make complex tasks easy - e.g. if you wanted to use multiple filters controlling logging to mutiple destinations, this is probably the only library that would help you. But the cost of that power is that typical usage has become too complicated. the log destination, automatically logging exception conditions). But I am using code from the library just for the ability to log on a dedicated thread (with some changes). This alone is worth persevering with the library. I am satisfied that the code itself is stable and largely error-free - it has been running on a live web-server for a week now, without any issues (fingers-crossed). the implementation/usage details of the library. But my point is that the implementation is so scattered that any amount of documentation might be insufficient. this would be a very useful library for almost all C++ developers.
* Did you try to use the library? With what compiler? Did you have any problems? I did & do use it. ICL 10.1 on XP. I have interacted with the author to get some issues solved. I had to change the stream class to accept a flag that flushes on every write, when logging on a dedicated thread. Also, logging to file, cout etc are not possible with this library if the required code conversion is not supported by the locale. I attempted to create an object encapsulating the logger and the filter (since the library does not intend to provide one) but could not since the return type of the overloaded destination::<< is implicit - author did try to help but his suggestion did not work.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? All of the above, + 1 week integrating the library into my application.
* Are you knowledgeable about the problem domain? I am now :-)
And finally, every review should answer this question:
* 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.
Not in its current form. Withsupport for output encoding, provision for objects so user can just include the library and start dumping messages with having to create irrelevant objects (like optimized string - optimized for what? how?), the lib would have my unqualified support. I look forward to the outcome of the review, and offer my services for testing any revised implementations. Best Amit