Hi Amit Hi John,
Thanks for accepting my review in the constructive spirit. I am sure this library is potentally useful enough that it has to get into boost soon. Now to answer your questions:
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?
I think that if the library provides a high-level interface (i.e. provide a file name as a log destination), then it should either provide a way to let the user control the destination state, or explicitly state what can be assumed about the destination. As we have discussed previously, this is specially important for this lib since logs can be dumped asynchronously. Also, I would think that it would be useful to have a section in the docs where limitations, error conditions, fallback strategies are explicitly listed. E.g., if the destination file can't be written to due to a network failure, disk full etc - how does the library deal with such cases? Is it an error condition to close the destination while logging is in progress? What is the overhead of logging using various strategies? And so on. A suggestion is that the lib could optionally set unexpected()/terminate(), so unhandled exception conditions can be logged. Just knowing what exception occurred would be useful. Also, exception adapters that log automatically would be useful. I am thinking something like: logging_exception<E> : public E where E is a specialization of std::exception. I see that there has been a lot of discussion about macros. My point was that macros provide a shorthand for some instantiations/function calls. So OK to provide macros as a convenience, but the architecture should be such that lib can be easily understood/extended without macros as well. And doc should list examples without macros, but mention at the end that a macro can be used instead for brevity. This lets the reader understand what the library is doing. Now, if only people would think about the phrase 'learning curve' and realize steep implies good... :) Best Amit