What is the point of clog?

I've been wondering, what is the point of clog? As near as I can tell, clog is the same as cerr but with buffering so it is more efficient. Usually stderr is the same as stdout, so clog is the same as cout. This seems pretty lame to me, so I figure I must be misunderstanding it. If I have log messages going out to the same place I have error messages going out to (perhaps something in /var/log/messages), then I probably am not writing too much out (so there isn't much lost by using non-buffered cerr). In my experience, I want my log messages up to date (not buffered) so I can help find a crash (so I don't want to be using the buffered clog). Apparently I should always be using cerr.

I'd like to be able to redirect clog inside my program. It would be useful to redirect cerr so that when I call a library routine I can control where cerr and clog go to. Can some compilers support this? I just checked DJGPP and stdout is defined as the address of a FILE struct, so it is illegal to do something like "stdout = freopen(...)".

• Is it possible to redirect clog, cerr, cout, stdin, stdout, and/or stderr?
• Is the only difference between clog and cerr the buffering?
• How should I implement (or find) a more robust logging facility (links please)?

Is it possible to redirect clog, cerr, cout, stdin, stdout, and/or stderr?

Yes. You want the rdbuf function.

ofstream ofs("logfile");
cout.rdbuf(ofs.rdbuf());
cout << "Goes to file." << endl;

Is the only difference between clog and cerr the buffering?

As far as I know, yes.

If you're in a posix shell environment (I'm really thinking of bash), you can redirect any file descriptor to any other file descriptor, so to redirect, you can just:

$ myprogram 2>&5 

to redirect stderr to the file represented by fd=5.

Edit: on second thought, I like @Konrad Rudolph's answer about redirection better. rdbuf() is a more coherent and portable way to do it.

As for logging, well...I start with the Boost library for all things C++ that isn't in the std library. Behold: Boost Logging v2

Edit: Boost Logging is not part of the Boost Libraries; it has been reviewed, but not accepted.

Edit: 2 years later, back in May 2010, Boost did accept a logging library, now called Boost.Log.

Of course, there are alternatives:

• Log4Cpp (a log4j-style API for C++)
• Log4Cxx (Apache-sponsored log4j-style API)
• Pantheios (defunct? last time I tried I couldn't get it to build on a recent compiler)
• Google's GLog (hat-tip @SuperElectric)

There's also the Windows Event logger.

And a couple of articles that may be of use:

• Logging in C++ (Dr. Dobbs)
• Logging and Tracing Simplified (Sun)

Since there are several answers here about redirection, I will add this nice gem I stumbled across recently about redirection:

#include <fstream>
#include <iostream>

class redirecter
{
public:
    redirecter(std::ostream & dst, std::ostream & src)
        : src(src), sbuf(src.rdbuf(dst.rdbuf())) {}
    ~redirecter() { src.rdbuf(sbuf); }
private:
    std::ostream & src;
    std::streambuf * const sbuf;
};

void hello_world()
{
    std::cout << "Hello, world!\n";
}

int main()
{
    std::ofstream log("hello-world.log");
    redirecter redirect(log, std::cout);
    hello_world();
    return 0;
}

It's basically a redirection class that allows you to redirect any two streams, and restore it when you're finished.

Redirections

Konrad Rudolph answer is good in regard to how to redirect the std::clog (std::wclog).

Other answers tell you about various possibilities such as using a command line redirect such as 2>output.log. With Unix you can also create a file and add another output to your commands with something like 3>output.log. In your program you then have to use fd number 3 to print the logs. You can continue to print to stdout and stderr normally. The Visual Studio IDE has a similar feature with their CDebug command, which sends its output to the IDE output window.

stderr is the same as stdout?

This is generally true, but under Unix you can setup the stderr to /dev/console which means that it goes to another tty (a.k.a. terminal). It's rarely used these days. I had it that way on IRIX. I would open a separate X-Window and see errors in it.

Also many people send error messages to /dev/null. On the command line you write:

command ...args... 2>/dev/null

syslog

One thing not mentioned, under Unix, you also have syslog().

The newest versions under Linux (and probably Mac OS/X) does a lot more than it used to. Especially, it can use the identity and some other parameters to redirect the logs to a specific file (i.e. mail.log). The syslog mechanism can be used between computers, so logs from computer A can be sent to computer B. And of course you can filter logs in various ways, especially by severity.

The syslog() is also very simple to use:

syslog(LOG_ERR, "message #%d", count++);

It offers 8 levels (or severity), a format a la printf(), and a list of arguments for the format.

Programmatically, you may tweak a few things if you first call the openlog() function. You must call it before your first call to syslog().

As mentioned by unixman83, you may want to use a macro instead. That way you can include some parameters to your messages without having to repeat them over and over again. Maybe something like this (see Variadic Macro):

// (not tested... requires msg to be a string literal)
#define LOG(lvl, msg, ...) \
     syslog(lvl, msg " (in " __FILE__ ":%d)", __VA_ARGS__, __LINE__)

You may also find __func__ useful.

The redirection, filtering, etc. is done by creating configuration files. Here is an example from my snapwebsites project:

mail.err /var/log/mail/mail.err
mail.* /var/log/mail/mail.log
& stop

I install the file under /etc/rsyslog.d/ and run:

invoke-rc.d rsyslog restart

so the syslog server handles that change and saves any mail related logs to those folders.

Note: I also have to create the /var/log/mail folder and the files inside the folder to make sure it all works right (because otherwise the mail daemon may not have enough permissions.)

snaplogger (a little plug)

I've used log4cplus, which, since version 1.2.x, is quite good. I have three cons about it, though:

1. it requires me to completely clear everything if I want to call fork(); somehow it does not survive a fork(); call properly... (at least in the version I had it used a thread)
2. the configuration files (.properties) are not easy to manage in my environment where I like the administrators to make changes without modifying the original
3. it uses C++03 and we are now in 2019... I'd like to have at least C++11

Because of that, and especially because of point (1), I wrote my own version called snaplogger. This is not exactly a standalone project, though. I use many other projects from the snapcpp environment (it's much easier to just get snapcpp and run the bin/build-snap script or just get the binaries from launchpad.)

The advantage of using a logger such as snaplogger or log4cplus is that you generally can define any number of destinations and many other parameters (such as the severity level as offered by syslog()). The log4cplus is capable of sending its output to many different places: files, syslog, MS-Windows log system, console, a server, etc. Check out the appenders in those two projects to have an idea of the list of possibilities. The interesting factor here is that any log can be sent to all the destinations. This is useful to have a file named all.log where all your services send their logs. This allows to understand certain bugs which would not be as easy with separate log files when running many services in parallel.

Here is a simple example in a snaplogger configuration file:

[all]
type=file
lock=true
filename=/var/log/snapwebsites/all.log

[file]
lock=false
filename=/var/log/snapwebsites/firewall.log

Notice that for the all.log file I require a lock so multiple writers do not mangle the logs between each others. It's not necessary for the [file] section because I only have one process (no threads) for that one.

Both offer you a way to add your own appenders. So for example if you have a Qt application with an output window, you could write an appender to send the output of the SNAP_LOG_ERROR() calls to that window.

snaplogger also offers you a way to extend the variable support in messages (also called the format.) For example, I can insert the date using the ${date} variable. Then I can tweak it with a parameter. To only output the year, I use ${date:year}. This variable parameter support is also extensible.

snaplogger can filter the output by severity (like syslog), by a regex, and by component. We have a normal and a secure component, the default is normal. I want logs sent to the secure component to be written to secure files. This means in a sub-directory which is way more protected than the normal logs that most admins can review. When I run my HTTP services, some times I send information such as the last 3 digits of a credit card. I prefer to have those in a secure log. It could also be password related errors. Anything I deem to be a security risk in a log, really. Again, components are extensible so you can have your own.

One little point about the redirecter class. It needs to be destroyed properly, and only once. The destructor will ensure this will happen if the function it is declared in actually returns, and the object itself is never copied.

To ensure it can't be copied, provide private copy and assignment operators:

class redirecter
{
public:
    redirecter(std::ostream & src, std::ostream & dst)
        : src_(src), sbuf(src.rdbuf(dst.rdbuf())) {}
    ~redirecter() { src.rdbuf(sbuf); }
private:
    std::ostream & src_;
    std::streambuf * const sbuf_;
    // Prevent copying.                        
    redirecter( const redirecter& );
    redirecter& operator=( const redirecter& );
};

I'm using this technique by redirecting std::clog to a log file in my main(). To ensure that main() actually returns, I place the guts of main() in a try/catch block. Then elsewhere in my program, where I might call exit(), I throw an exception instead. This returns control to main() which can then execute a return statement.