Re: [boost] [log] Review-ready version in the Vault

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.