Subject: Re: [boost] [log] Review-ready version in the Vault
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-10 11:53:54
Vladimir Batov wrote:
>> ... You can either create a logger and use it as an independent
>> object, or you can declare a global logger and use it everywhere you
>> need it. The first approach is good to store loggers as class members.
>> The second is convenient if you tend to use functional code or don't
>> need any context-specific attributes in it. It can be done like this:
>> BOOST_LOG_DECLARE_GLOBAL_LOGGER(my_logger, src::severity_logger_mt< >)
>> void foo()
>> src::severity_logger_mt< >& lg = my_logger::get();
>> // go ahead logging
> Hmm, I honestly think that having "loggers as class members" is a bad
And I find it extremely useful. In fact, I tend to avoid making loggers
irrelevant to some sensible entity in the program. For example, if I
have a class that implements a network connection, I would most likely
make logger a member of this class. This allows to seemlessly embed
information related to this connection into log records. In consequence,
this allows to apply filtering based on this information.
> I do not usually like global objects either (static initialization
> issues, too much visibility). However, what I definitely use a lot is
> retrieving the same log by name in different compilation modules (that
> takes the visibility down). Like
> boost::log log1(name);
> boost::log log2(name); // The same as log1
The example above does just that. All you need is to have the
BOOST_LOG_DECLARE_GLOBAL_LOGGER in some common header, and include it
whenever you need the my_logger logger. The my_logger is a singleton
that is accessible from different translation units and even different
modules (dlls, sos). It does have static initialization problems solved.
This is the key difference from declaring a namespace-scope logger variable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk