From: Sean Hunt (rideau3_at_[hidden])
Date: 2008-02-18 02:19:46
Well, I just thought that I'd pitch in with my first ever boost library
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk