Subject: Re: [boost] [log] Review-ready version in the Vault
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-11 01:27:35
>> Hmm, I honestly think that having "loggers as class members" is a bad
>> idea.
>
> 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.
Yes, I understand and I am not trying to convert you or anything. Just
expressing my view which you might or might not take into account.
Design-wise I do not believe a logger should be part of a class. That
inclusion of convenience that you describe is unlikely to happen in a more
structured development environment (where design is evaluated and approved
separately and might be even done by different people). I feel that
inclusion certainly goes against the design trend of making classes as
clean/small as possible. Implementation-wise, you do not mention if you
"make logger a member of this class" as a static member. If it is not
static, then the associated overhead is not acceptable (I have about 30,000
objects). As a static member it is not greatly different from a file-scope
static.
>> 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.
I have not got that impression that your
BOOST_LOG_DECLARE_GLOBAL_LOGGER-based "example above does just that". To
start with, I (I'll use "I", "you" for convenience. nothing personal) simply
create a logger instance on the spot when I need it. You insist I *declare*
first with some hairy :-) macro "in some common header". Then, to actually
get the logger, I need "src::severity_logger_mt< >& lg = my_logger::get();".
I do not mind you do it the way you do it. However, I insist that "my" way
is very incremental. I can start the most basic:
boost::log() << "Hello";
and then incorporate streams, filters, formatters, etc. when the need
arises. I do not have the feeling you do "just that". IMHO the incremental
deployment nature is extremely important for a logging library. Probably
your library can do all that. What I feel is that the user's exposure to the
library complexity might be looked at.
V.