Subject: Re: [boost] [log] Release candidate 1
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-03-10 14:56:19
Le 10/03/13 16:28, Andrey Semashev a écrit :
> I've finished the docs update and released the RC1 of Boost.Log v2. The code
> can be downloaded here:
> The code can also be checked out from SVN:
> svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log
> The updated docs are available online:
> Aside from the docs updates there were a few changes I made as a part of the
> reviewing process (some were pointed out by users):
> - The add_attr manipulator was renamed to add_value. The new name better
> follows the terminology of the library.
> - The attribute value visitation API no longer forwards the result of the
> visitor. This feature is rarely needed but it slows down compilation
> significantly. To acquire the result one can use the new save_result function
> object wrapper.
> - Formatter and sink factories for settings parsers are now classes rather
> than simple function objects. This follows the pattern set by filter
> factories, which were classes before.
> - Fixed a few bugs and compilation problems.
> Sadly, there was almost no discussion of the library in this list. I received
> a few private emails on the library, mostly concerning some problems here and
> there and porting issues from v1. While valuable, this feedback can hardly
> replace a good review of the Boost community. I encourage everyone interested
> to take a look at the library, however deep you like, and provide your
> I don't plan to make any significant changes to the code, except maybe some
> include optimization and fixing the problems. If everything's fine, I'm going
> to post a request for permission to merge to trunk in a week or two.
The review result requested to take in account some critical issues. I'm
sure that we could found some of the answers to these question on the
documentation, but it would be easier for the mini-review if you give
some explicit answers to these critical issues. Telling if you have
taken in account some of the non-critical points could help also.
These issues must be addressed, and be passed through informal mini-
before the library can be added to SVN.
- It appears that the 'trivial' logging is not sufficiently good to just
take and use. The library should provide an out-of-the-box mechanism
- supports channel/severity attributes, without creating new logger for
each severity. It also should be possible to filter out specific
channel by essentially poking at some "map", and without manually
composing a new filter that checks for a set of allowed channels
sequentally. I believe that at least Christian, Roland, Robert and
- has no observable effect on compile time. One second (or more) that
imposes is not acceptable.
- outputs to console by default, but permits changing that
- outputs only component/severity/message by default, but probably
- By default, the library should try hard to continue working no
matter what errors happen during processign a log record -- including
things like invalid attribute names or types, or other exceptions.
- The library should not reinvent wheels. In particular, custom
of TSS and RW mutex seems like a very bad idea. Use of a custom lambda
implementation was pointed by many as not great -- we already have a
so let's not add more to the mix.
- Library interface is too geared towards lambda. In particular,
formatters/filters as free-standing functions appears to require
more code. In particular, it should be possible to access an
attribute using a
single function call. Also, logging::extract taking a lambda for
complicates matters, it's desirable to have a more direct variant.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk