Subject: Re: [boost] [log] v2 Initialisation, default sink behaviour and filtering documentation
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2013-01-25 03:44:01
> -----Opprinnelig melding-----
> Fra: Boost [mailto:boost-bounces_at_[hidden]] På vegne av Andrey
> Sendt: 24. januar 2013 04:30
> Til: boost_at_[hidden]
> Emne: Re: [boost] [log] v2 Initialisation, default sink behaviour and filtering
> On January 23, 2013 6:38:45 PM Mats Taraldsvik
> <mats.taraldsvik_at_[hidden]> wrote:
> > Hi,
> > I am in the process of moving beyond the default sink now, and had
> > some issues. I tried to add the sinks after my logger object had been
> > default initialized, and this caused some problems (partial
> > streams/corruption, mostly). Currently I'm calling
> > core->remove_all_sinks() to remove the default sink. Are there any
> > "best practices" here? Perhaps it would be a good idea to add these
> > "requirements" to the documentation, if they are not there already and
> > I missed them? :)
> The default sink cannot be removed, not even with remove_all_sinks. It is
> used implicitly when no other sinks are added to the core. When you add
> your sink to the core you automatically suppress the use of the default sink.
> As for your problem, could you describe it in more details? A minimal code
> sample would be useful.
I believe that the corruption was just about flushing buffers correctly, but I can't reproduce it, unfortunately -- I have no problems currently.
I found the reason for having to call remove_all_sinks repeatedly : I was initializing multiple logger objects repeatedly, thus adding the sinks to the core multiple times. Unfortunately, I can't avoid this. Is there a better workaround than creating a custom core attribute telling me whether the core has been initialized?
> > --
> > I also noticed that the severity filter examples are :
> > logging::core::get()->set_filter
> > (
> > logging::trivial::severity >= logging::trivial::info
> > );
> > From "Setting up sinks", and
> > sink->set_filter(expr::attr< int >("Severity") >= 2);
> > (i.e. comparing the Severity with an int) when moving to the more
> > advanced section in "Sink frontends".
> > Could you adjust one of the examples in "Sink frontends" to use the
> > severity_level type (that the documentation introduces in the tutorial
> > "Adding more information to log: Attributes") directly? For example:
> > sink->set_filter(expr::attr< severity_level >("Severity") >=
> > sink->warning);
> > Or explaining this in "Log record formatting".
> > I had trouble understanding this at first, but I might be the only one
> > :). Thought I'd mention it anyway.
> The type of severity level is not mandated by the library, and each section of
> the documentation is intended to have minimal dependencies on other parts
> of the library. That's why trivial severity levels are not used in sinks
> description. I'll think about how to clear this confusion better.
Ok. I understood that the severity_level is allowed to be a custom object. What I did not understand in this context was how to filter the object representing the severity (for trivial::severity it was the object e.g. trivial::fatal, but the advanced documentation compared against an int (I am aware that enums are implicitly casted to ints, but still)).
I can't get this (or BOOST_LOG_SCOPED_THREAD_ATTR) to compile:
BOOST_LOG_SCOPED_LOGGER_ATTR(_logger, "FID", boost::log::attributes::constant<int>(id));
_logger is a private member reference to a severity_logger
Compile errors (more or less equal for BOOST_LOG_SCOPED_THREAD_ATTR):
1>Object.cpp(945): error C2248: 'boost::log::v2s_mt_nt5::aux::scoped_logger_attribute<LoggerT>::scoped_logger_attribute' : cannot access private member declared in class 'boost::log::v2s_mt_nt5::aux::scoped_logger_attribute<LoggerT>'
1> boost/log/attributes/scoped_attribute.hpp(58) : see declaration of 'boost::log::v2s_mt_nt5::aux::scoped_logger_attribute<LoggerT>::scoped_logger_attribute'
> Unsubscribe & other changes: