Ah ok that clarifies somewhat; I thought it was the formatter that I was
having trouble with. I tried setting one, and then saw that the text was
added to the console to test. But I'm doing
boost::log::add_common_attributes(), and I print the string to std out just
to make sure that I will get what I expect. As it turns out, I think that
the backend is supposed to visit the record_view, and the record view has
the default attributes and any others added.
I'm trying to get those extra attributes; if I do BOOST_LOG(lg) << " blah"
<< endl; I get "blah" on my screen which I swap out the backend from the
default. My backend just prints to the console.
How do I had the record_view items to the string to be sent?
On Mon, Oct 27, 2014 at 2:56 PM, Andrey Semashev
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...
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost