id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc 12178,Log record stream state persists between log statements,oe@…,Andrey Semashev,"Hello, the issue is best illustrated with the following example: {{{#!C++ #include #include 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 ",Patches,closed,To Be Determined,log,Boost 1.60.0,Problem,fixed,"log, stream, state",