[Boost-bugs] [Boost C++ Libraries] #12178: Log record stream state persists between log statements

Subject: [Boost-bugs] [Boost C++ Libraries] #12178: Log record stream state persists between log statements
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2016-05-05 14:25:26

#12178: Log record stream state persists between log statements
--------------------------------+---------------------
 Reporter:  oe@…                |      Owner:  andysem
     Type:  Patches             |     Status:  new
Milestone:  To Be Determined    |  Component:  log
  Version:  Boost 1.60.0        |   Severity:  Problem
 Keywords:  log, stream, state  |
--------------------------------+---------------------
 Hello,

 the issue is best illustrated with the following example:

 {{{#!C++
 #include <ios>
 #include <boost/log/trivial.hpp>

 int
 main()
    {
    BOOST_LOG_TRIVIAL(trace) << "dec: " << 16;
    BOOST_LOG_TRIVIAL(trace) << "hex: " << std::hex << 16;
    BOOST_LOG_TRIVIAL(trace) << "dec: " << 16;
    }
 }}}

 which prints something like:

 {{{
 ... [trace]   dec: 16
 ... [trace]   hex: 10
 ... [trace]   dec: 10
 }}}

 Obviously, the state of the log stream persists between the individual log
 statements.  To me this was quite surprising, as the documentation and
 also the code itself conveys the notion of independent log records being
 created and processed; attributes for example use the same manipulator
 syntax (add_value()/add_value_manip<>), but then only apply to the current
 log record under construction.  And if log records are created manually
 via open_record() asf., one also creates a new log stream for each record.

 The reason for the observed behaviour is that log streams are pooled by
 the implementation, and thus the same instance gets used in all three log
 statements in the example above.  To alleviate the effects of this
 implementation detail(?), I'd suggest that (a common subset of) the stream
 state is reset to its default values when a stream is retrieved from the
 pool to be handed out to a log statement.  Does this sound reasonable?
 I've prepared a patch along these lines that at least in my case solves
 the problem (see attachment)...

 Thanks and regards[[BR]]
 Oliver Ebert

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/12178>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.