Re: [boost] [log] Release candidate 1

Subject: Re: [boost] [log] Release candidate 1
From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2013-03-10 22:24:44

Hi Andrey,

It's good to see this library steaming steadily towards trunk. I've been
looking forward to this happening.

I'm glad you've added the trivial logger. As big as that warning is in the
documentation, it would be more reassuring to see that this logger supports
lazy evaluation of the logging expression if the example demonstrated it.
eg.

// Note: some_very_expensive_operation() won't be called unless debug
logging is enabled.
BOOST_LOG_TRIVIAL(debug) << "A debug severity message" <<
some_very_expensive_operation();

I don't see a way to compile out certain levels of log messages using
compile-time flags with the syntax Boost.Log uses. Many other logging
libraries choose to put the logging expression as part of the macro, which
makes it easy to support this usage pattern. Have you considered supporting
this?

I'm going to try this out properly tomorrow.

Cheers,

Darren

On 10 March 2013 15:28, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> 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/download
>
> 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.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>