Logging library review This is my first boost review, so could be it lacks a lot of things.. * What is your evaluation of the design? IIUC, the library provides a flexible solution to compile-time definitions of different loggers. IMO, this is rarerly the case. What should be configured at compile time are the tags (or simplier, the message type). All the rest, destinations, formats, interval, caching, etc is not the responsibility of the programmer defining the log, this is the responsibility of some other programmer using the first programmers library, or the customer using the first programmers application. Destinations will be added at runtime (such when opening a telnet console, typing 'enable-log debug' or similar), configured at runtime, removed at runtime. These scenarious are not even discussed, which make me doubt the library. It seems that formatters are attached to the top level writer object, is this the only way? The formatted message may need to vary for different destinations. I would typically have the file logs to include more data (tags, if you will) then the console destination, making it easier to read the console for human eyes(no timestamps, codelines, etc). If there are some data missing while I look at the console, I would at runtime change the formatter to include some more. * What is your evaluation of the implementation? Didn't look much, but I'm strongly against configuration macros and small utility macros for things that could be written without them. * What is your evaluation of the documentation? I share the same opinion about the documentation as others have already said. It's confusing to read, and sometimes I think that the library is more useful than the documentation makes it, but I'm not convinced. * What is your evaluation of the potential usefulness of the library? A logging library is indeed very useful, I am not sure about this one though. I don't agree with other reviewers that boost must have a logging library for its own sake. With spirit, for instance, I can enable logging to std::cout perfectly for debugging my grammar, no need for very large frameworks for that. Talking about which, how would that work with the proposed library? * Did you try to use the library? With what compiler? Did you have any problems? Tried some of the samples with vc8, no problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Read the documentation a couple of hours and looked at the examples. * Are you knowledgeable about the problem domain? Yes. I've written and maintained a log library that's been running for many years. * Do you think the library should be accepted as a Boost library? No, sorry. Could be that the flexibility and customization I am looking for is in there already, but the documentation is written with other scenarios in mind than I have. It should be addressed how the logging library will be configured when used in: * an external header only library (ex, spirit). * an external compiled static library (ex, serialization.lib). * an external compiled dynamic library (ex, serialization.dll/so). * an application, that is shipped/sold to third party. * an application, where destinations are added/removed at runtime from multiple threads. To me a logging library plays a very important role in large software projects since it becomes a part of the interface of an application, note merely being a building block for the programmers behind the application (like std::vector<> for instance =). What is goal of the library? Regards, Christian