Using C++ Log class from within other non-related classes

Question

I have a C++ Log class (implementation is long and probably not important) where I've overloaded the << operator so I can use statements like log << "Error" << endl; to make it more intuitive (and to allow me to bifurcate the output to screen and log, if need be). The class works fine; I instantiate it in Main() and can use it without issue. I'd like to be able to use it in other, non-related classes without actually passing it into them (via class constructor or similar) because if I pass by copy, I end up running certain housekeeping log class methods twice and if I pass by reference, I have to dereference the pointer in the external classes to use it (*log << "Error" << endl;). Is this possible? What is the best way to do it?

Answer 1

Create a global function with the following declaration:

Log& log();

Its implementation can look like this:

Log& log()
{
    static Log log;
    return log;
}

Or like this, avoiding order-of-destruction issues (which might happen when the destructor of another object with static storage duration writes something to the log):

Log& log()
{
    static Log* log = new Log; // never deleted
    return *log;
}

You can then use your logger with almost the same syntax as before:

#include "log.h"

// ...

void f()
{
    log() << "Error\n";
}

This has two advantages over the Singleton approach:

• It's simpler.
• It keeps the actual concern of the log class (writing log messages) separated from a particular allocation strategy.

By the way...

because if I pass by copy, I end up running certain housekeeping log class methods twice

Not sure what you mean, but if you pass by copy, then the class needs to be copyable, and it usually does not make sense to copy a logger which encapsulates or accesses external resources. That's why standard stream classes (std::ostream et al) are not copyable.

and if I pass by reference, I have to dereference the pointer in the external classes to use it

No. You mix up pointers and references. They are quite different language features. Dereferencing is for pointers, not for references.

Answer 2

I know all the reasons object oriented purists object to the following idea, but it has worked well for me for logging and similar activities in a variety of large projects. It avoids a number of practical problems in other designs:

Make a base class with pure virtual methods for the thing your logging class can do. Make a static member of the base class, which will be a pointer to the singleton instantiation of that class, with that pointer filled in by the constructor, and available by a static accessor method. So you typically use it as:

 base_logger::singleton() << whatever...

The actual logger class is constructed once (wherever convenient before first use) which implicitly calls that base_logger constructor locking in the pointer to itself, which will be returned as a reference by that singleton() function.

Likely you'll want different names for base_logger and singleton. I'm just describing how it fits together for convenient use, not suggesting those names.

Answer 3

One thing that you can do is make the logger class using the static singleton design pattern.

This means that there is only ever one instance of it created (usually at static storage duration in the logger.cpp compilation unit), and there is a globally visible, static method of class logger that returns a reference to this. Then, you don't need to pass the object around into constructors or functions or anywhere else -- wherever you want to use it, you can simply grab the singleton.

This pattern is indeed usually considered harmful if overused. However, for a logger utility it seems very appropriate -- a logger can quite reasonably be considered an application-level resources which can be appropriately tied to the lifetime of the program. The singleton pattern can make it painful to create proper unit tests, but usually you aren't terribly concerned with unit testing the logger framework either -- if your log messages aren't working correctly usually you'd spot that right away.

Answer 4

I would make it as simple as possible, and instanciate a single global Log object (not a singleton actually):

Log log;

and declare it extern in a common header file:

extern Log log;

With this, you can use your existing syntax everywhere.