From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-04-10 10:05:16
> Such code doesn't solve the problems I've pointed out. Although it
> solves the simple case, it won't provide things like flexible filtering
> and attributes.
Well, given the 5 minutes it took to write it, of course.
> You'll have problems with log initialization and
> multi-module applications. Thread safety is another issue. If you try to
> develop this solution to a product state, you'll end up with a
> full-fledged logging library, pretty similar to the many out there. :)
>From reading your previous points it seems I'll end up doing that
myself anyway? Or shouldn't boost log be a full-fledged logging
library? I'm now confused exactly which problems it should solve.
Log initialization - user responsibility
Thread safety - user responsibility
Multi-module issues - user responsbility
Log code generation config - user / library author responsibility
I still don't see why it's up to the end user to deal with all this..
> IMHO, whether boost uses its own library or not is irrelevant to the
> library usability for end users.
>From the review I remember statements like 'boost needs its own
logging library', maybe I misunderstood the intentions of that, but I
thought it meant to support logging from inside boost.
Anyways, if it's not possible to draw any general conclusions on how
library code/config for log support should look like, I'll to live
with that :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk