[Boost-users] [Log] record_ostream too restrictive due to non-copyability, non-assignability?

Subject: [Boost-users] [Log] record_ostream too restrictive due to non-copyability, non-assignability?
From: Latimerius (pvl_at_[hidden])
Date: 2014-10-23 15:30:06

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