Subject: Re: [boost] [log] Review-ready version in the Vault
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-11 14:04:06
Vladimir Batov wrote:
>>> 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
> 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.
That's ok, I'm not trying to persuade you either. I'm just sharing my
view on these things, as well as answering questions. :)
> 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.
I'd say I can both agree and disagree with your point, depending on the
situation. For classes that play active role in an application, such as
the aforementioned network connection class, I think it is perfectly
reasonable to store a logger in it as a member. It doesn't violate the
design because writing logs is actually a part of functionality of such
classes. I can say more, I had cases when such approach was essentially
mandated by the requirements on the project management level, because
such practice proved to be useful.
If your classes play passive role in the application, for instance,
classes that represent dictionary entries, I totally agree with you.
Such classes do tend to have many instances and size overhead can be
significant, while there is no obvious benefit from having a logger
inside each of them.
> 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 agree, there is no point of having a static member logger. Unless you
want to restrict access to it in such way.
> 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 =
Sorry, I don't see much difference between
logger& lg = name::get();
The latter looks more descriptive to me. If you like your syntax more,
you can write a trivial wrapper around "get()" or use flyweight.
However, after getting a quick look at flyweight docs, it doesn't seem
to provide inter-module facilities.
> 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".
Yet again, you can create loggers at your will, so your case is covered
by the library. The only thing you have to do besides creating a logger
is to provide a sink, where to store logs. For instance, to put logs
into a file you have to call
somewhere in the beginning of your main(). I think you'll have to do it
with any approach, be that my library or a different one.
> 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.
I fact, the Tutorial in the docs was written with respect to increasing
complexity. The first two steps (about sinks and loggers) describe the
basics to get things started. The rest of the steps go deeper and
introduce filtering and formatting.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk