When should a Logger flush?

Question

I want to know when, or how often should a Logging class flush its stream - and why? Should it flush after every log, or wait for the stream buffer to fill and then flush, or is it somewhere in between?

To further illustrate my question:

My logging class holds a reference to some std::ostream stream and uses operator<< for input. I am able to flush after every line of input, let's say by using std::endl; - but i don't, instead i use stream << "\n" to just force a newline. I let flush happen when the stream buffer is full or on stream /logger destruction.

Answer 1

As often as possible, so that no entries are lost upon a crash, and also to have better real-time information while the program is running.

As rarely as possible to avoid overhead of writing to a file.

These requirements conflict, so you need to find a balance that fits your needs.

You might want to consider that some log messages may be less important than others, and you may use this to affect your flushing policy.

You can use signal handlers (or similar OS specific techniques) to flush the buffer right before a crash. Note that flushing a std::stream is technically something you're not allowed to do in a signal handler (although that might depend in its implementation), but it might work and that's usually better than just crashing.

Answer 2

In C++ the iostreams library has 2 classes for logging. Both are bound to stderr.

cerr - flushes after each input is formatted, which means after every call.

clog - flushes when buffer is filled or called manually (example: endl or flush()).

The thinking is that, you want errors to be output ASAP. But logging can be output in batches.

Answer 3

It depends. Though logging is often narrowed down to denote some kinds of error-related messaging mechanism, it is not always tied with errors. In contrast, sometimes it is even explicitly separated with errors (e.g. clog vs. cerr). Another example is tracing in general. So it is up to you, the designer of the logging system, to decide which integrity level you want to achieve with specific logging.

Stream-based logging can be a simple way to report errors. It is not the feature of last sorts, but it is unwise to be depended as the only way to record fatal errors. Just better than nothing (particularly in cases where portability is emphasized)... when you have to rely on this way, flush it ASAP.