From: John Torjo (john.groups_at_[hidden])
Date: 2008-02-11 16:09:09
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
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
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
> 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 ;)
-- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk