|
Boost : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-04 10:09:50
On 5/4/05, Roman Yakovenko <roman.yakovenko_at_[hidden]> wrote:
> > Would you actually prefer:
> >
> > a.cpp:14: result of f()
> > [100 lines of other logged messages]
> > a.cpp:14: 1234
> >
> > To:
> >
> > [100 lines of other logged messages]
> > a.cpp:14: result of f(): 1234
> >
>
> I'd like to add use case. I think that log messages should be written as soon as possible.
> Use case: program crash only on specific machine that you can't debug on. If logs messages will not
> be written immediately they will be lost. In this case this logger is pretty useless.
If one uses the supplied write_to_file appender, the messages will be
written to the output file as soon as they are complete. So for
example,
BOOST_LOG(debug) << "Wrote " << len << " bytes to socket fd " << fd;
would write a single message like "Wrote 56 bytes to socket 3" or
nothing at all (e.g. if the application crashed sometime in the middle
of formatting the message). I think this is eminently reasonable and
hardly "useless".
If you instead choose to use the ts_appender, messages will be
collected over some configurable time interval (default 100
milliseconds) and written to the output file all at once. In this
case you face the possibility of losing any messages which were logged
during that interval. The choice of which method to use is entirely
up to the user.
Aside: write_to_file opens the target file for appending on *every*
write call. I think this implementation should be changed. Perhaps
by using a shared_ptr<ostream>?
FWIW, I have seen a number of posts regarding the proposed Logging
library from folks that don't seem to have actually tried out John's
implementation. I'd suggest that you actually read the docs and try
out the code before suggesting features that are already implemented.
> I think that if someone prefer to see
>
> > a.cpp:14: result of f()
> > [100 lines of other logged messages]
> > a.cpp:14: 1234
>
> he should wrote "log viewer" that will handle this.
I don't see how implementing this would even be possible.
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk