Hi Amit, Thanks for the review.
* 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.
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.
Got that - will make it much simpler in the next version.
* What is your evaluation of the implementation?
Unwieldy & too reliant on preprocessor macros. Namespaces are over-used. Some
The idea about namespace = concept was a very easy way to look for possible implementations of a concept once you know it. Perhaps I did abuse it, though.
important considerations have been overlooked (e.g. output encoding, state of the log destination, automatically logging exception conditions).
About state of log destination : basically I'll ask people to vote for the features they'd like. Because I've got quite a few conflicting ones :) About logging exception conditions : what do you mean?
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).
Thanks, keep me posted ;)
* What is your evaluation of the documentation?
Comprehensive, but too informal. Ultimately insufficient to aid in understanding
About informal - got it, will formalize it.
* 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, this would be a very useful library for almost all C++ developers.
Yup, will do.
* 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.
About logger & filter in one - will be there. About code conversion - will talk privately.
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.
About irrelevant object - you're right, won't be there in the next version.
I look forward to the outcome of the review, and offer my services for testing any revised implementations.
I'm pretty sure of the outcome of the review :) But I'll ask for another review to take place in about 3.5 months. As for testing - I'll take you up on that offer ;) Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right