
Hi Paul, Thanks for the positive review! (just now, when I so got used to the negative ones :))
Appears to meet many of the almost infinitely widely varying requirements.
Many of the reviewers seem to be unwilling to vary their 'essential' requirements, but considering the possible permutations and combinations, I am unconvinced that their rejections should as absolute as they suggest.
Thanks :)
* What is your evaluation of the implementation?
Seems more complicated than I suspect it really is.
Appears to permit use where efficiency is important.
Oh yes!
So I recommend presenting examples of how to use this package with 'pure' C++, as well as more slickly using macros. This will also help quiet the noisy Macrophobes ;-)
As said, I will remove most of them. And one or two remaining - I'll make them optional.
This is especially when example macros have inscrutable systemish names like L_.
The only reason for the ending _ was that I wanted a very short name, and one letter seemed too short :)
Surely it is worth suggesting use of three letters like LOG in an example?
Will do.
And the #define cries out for a comment line saying "you might like to define a macro that does ...)
'g_l' is not self-explanatory to me.
Got it, will use better naming.
Could add_formatter be easier to write and read if add_formatter chained?
(and this namespace information
using boost::logging::formatter::idx; // index - please!
Yup, will change :)
using boost::logging::formatter::append_newline; ... provided in an .hpp)
so it might read more like:
g_l()->writer() .add_formatter(index() ) .add_formatter(append_newline() ) .add_formatter(tag::file_line() ) .add_formatter(tag::level() );
Sure, not a problem!
* What is your evaluation of the documentation?
Confusing. Shows every sign of being written by someone who knows too much about it ;-)
Much too chatty in places.
Yup, got that - will update.
The 1st examples are too difficult.
(The later ones may be too easy - but I haven't got there yet ;-) )
Will make them easier.
Levels are not mentioned in the 'The Basics'.
Will do.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library?
Yes. This is a difficult task and this is good enough.
And I think that we should try to get it into much wider real-life use before embarking on too much re-re-review. The reviewers usage so far is far too thin, and probably unpresentative, to make detailed judgements. I favor accepting this pretty much 'as is' but expecting some quite major revisions of documentation, and perhaps implementation.
Thanks, will happen! Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right