Le 10/03/13 16:28, Andrey Semashev a écrit :
Hi,
I've finished the docs update and released the RC1 of Boost.Log v2. The code can be downloaded here:
http://sourceforge.net/projects/boost-log/files/boost-log-2.0-RC1-r847.zip/d...
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:
http://boost-log.sourceforge.net/libs/log/doc/html/index.html
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 feedback.
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.
Hi, 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. Thanks, Vicente Critical issues =============== These issues must be addressed, and be passed through informal mini- review, 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 that: - 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 myself requested this. - has no observable effect on compile time. One second (or more) that trivial.hpp imposes is not acceptable. - outputs to console by default, but permits changing that - outputs only component/severity/message by default, but probably permits changing that. - 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 implementations 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 couple, so let's not add more to the mix. - Library interface is too geared towards lambda. In particular, implementing formatters/filters as free-standing functions appears to require considerably more code. In particular, it should be possible to access an attribute using a single function call. Also, logging::extract taking a lambda for callback complicates matters, it's desirable to have a more direct variant.