Boost logo

Boost :

Subject: Re: [boost] Custom logging backend difficulty
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-10-27 14:56:16


On Monday 27 October 2014 14:40:22 Kenneth Adam Miller wrote:
> So, I need malleable logging facilities, and so far I've identified boost's
> logging facilities as useful. I've read the docs on logging, and right now
> I'm having difficulty achieving what I want-basically, I have a custom
> backend, in order that when logging is done, it gets routed to an
> alternative destination - over the network namely.
>
> I extended from text_ostream_backend, and basically I'm having the
> following trouble:
>
> I don't understand the record_view visitation API. I'd like the ability to
> set formatters and what not to remain untouched, but have the final
> formatted result sent off else where. I can change this by sending the
> string received in the consume function that has to be overrode, but the
> values are lost in the record_view.
>
> void consume (const record_view & rec, std::string s);
>
> where I do { send(s); } for the body.
>
>
> What I think is necessary is just to retain the default behavior of
> accepting whatever formatter was specified...
>
> What is the best way to go about achieving what I want?

I'm sorry, I don't understand what you mean.

The first argument of consume() is the record view, which contains all
attribute values that were passed to the library when the log record was
created. This includes the message text. Whether or not you apply a formatter
to it, the view remains intact and can be used in your sink backend if needed.
Accessing attribute values is summarized here:

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/detailed.html#log.detailed.core.record

The second argument is the result of formatting, i.e. the format of the string
is defined by the formatter. If you send log records as strings over the
network then this string is probably what you need, provided that you set the
appropriate formatter.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk