Logging library review extension is at it final day

Welcome everyone to the last day of the official review of proposed Logging library. I would like to encourage anyone interested in this very important and complex problem domain to invest some time and give this submission a shot. Whether you are novice developer looking to use logging facility or experienced designer developed it once or twice already, your opinion is valuable. Here is the links to the online docs http://torjo.com/log2/doc/html and package for download http://torjo.com/code/log2.zip. This is the point when you shouldn't leave it for later. If you care to be heard, we need to hear your voice now. Gennadiy Rozental - Review Manager -

Well, I just thought that I'd pitch in with my first ever boost library review! The biggest issue I see right out is that the tutorial is incredibly dense... most tutorials start out with a simple working example, and expand from there. This tutorial seems to introduce the concepts rather sharply - it takes a long time to even understand how the library works. Also, some of the links are broken, because Doxygen implicitly adds links to classes based on it's best guess - the repeat of certain names like "level" can confuse it a lot. And the diagrams are missing. Some documentation is very inadequate, such as boost::logging::destination::stream_t (perhaps you should turn on the extraction of undocumented members). The next is that there's a lot of macros (and namespaces, but that's not as important. Good code separation is a good thing, in my opinion)! The documentation recommends defining a "L_" macro to do your logging. This violates many levels of coding philosophy... in my opinion, an approach similar to Boost.Lambda should be taken, but I shouldn't be judging the library because it doesn't meet my ideal - there's plenty of other good implementations, and I'd be happy with any of those.. That said, I think that using macros to hide ugly code is not a good idea - a better approach would be to hide the ugly code, and provide a friendly interface. I support the idea of a built-in profiler, and I'll say it out loud so that I don't look like I'm trying to attack this library from every angle without remorse (I'm not). I do like the amount of customization that this library offers. It seems very impressive, but I think that the approach is a little too generic and forces the user to jump through hoops. There needs to be a better interface. Right now, the library looks like something that's too complex and difficult to be chosen over writing a small class to address the user's direct needs. I really like the idea of a logging library, but logging, like documentation, is one of those things that developers don't want to go to great extents to do. I'm going to have to vote no for this library. But because I haven't actually used it, I only want it counted as a half vote. Sean Hunt
participants (2)
-
Gennadiy Rozental
-
Sean Hunt