[snip]
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 :)