Hello, I'm trying to migrate from an existing solution to Boost.Log. So far I've been able to emulate all important features of the existing library - except one. The existing library supported submitting a log message in multiple statements. This is useful when the message being composed has conditional parts, when a part of it is composed in a loop or even a different function, something like this: auto logmsg = log (Channel::CORE, Severity::DEBUG); logmsg << "unconditional part"; if (condition) logmsg << " conditional part"; for (auto element : container) logmsg << element; logging_subroutine (logmsg); logmsg << endmsg; To that end I extracted a structure from the manual_logging() function from the Boost.Log documentation to hold the state of the message being composed: struct log_msg_state { my_logger & logger; logging::record rec; logging::record_ostream strm; ... <constructor & destructor definition> ... }; Having done this, I can emulate most of the above example fairly easily by defining a bunch of operator<<() overloads for the log_msg_state. However, I've been struggling with record_ostream. It was a bit of a challenge even to initialise it in the constructor - we can't use the initialiser list as we have to make sure first that our logging::record is valid. On the other hand, in the ctor body when the check can be performed, it's too late as record_ostream has already been constructed already and as it turns out, you can't do much with a constructed instance - no usual stuff like if (rec) strm = logging::record_ostream (rec); works! Fortunately, I've been able to hack around it like this: if (rec) new (&strm) logging::record_ostream (rec); Not pretty but has been working well so far! However, I've failed to find a solution for returning my log_msg_state (and thus record_ostream) from a function. The non-copyability, non-assignability, non-moveability are always getting in the way. (Note also that I do NOT want to hold a pointer to record_ostream in my log_msg_state and allocate it dynamically - that would certainly make things easier but I don't want to penalise each and every log message with a dynamic allocation for no good reason.) Could someone please advise me how to get the functionality I need, a solution or a work-around at least? Thanks in advance pvl