That still raises the obvious question: why is your logger an object/class to begin with?

• Using globals is always wrong. They create a mess with initialization ordering, threading and dependencies.
  
• A free function would open the door for dozens of globals. Enable/Disable logging to OutputDebugString() - you need a global flag. Write log to a file? You need another global flag and a global variable storing the file handle.
  
• Singletons, global variables in disguise, rob you of all flexibility (like logging networking related stuff in file 1 and graphics related stuff in file 2) and gets in the way of unit testing.
  
• Passing some semi-global application class around is just hugely increasing dependencies since now you don't know which objects a class will look up through the application class (the service locator anti-pattern).
  

• Equip your classes with a SetLogger() method. By default, the logger is NULL, therefore no logging is performed. If you want to log something, you simply assign the logger to the class post construction.
  
• Do not add logging to your classes directly, wrap them in a logging wrapper (eg. a LoggedRenderer around your Renderer). Obviously can only log calls and results and with some effort exceptions leaving the renderer.
  
• Add a Log event (as in signals/slots) to your class. This is just another variant of the SetLogger() idea, of course.
  
• Forfeit logging altogether. I've done this in my code. I'm going all-out with assertions for pedantically checking internal states and exceptions for any usage error. Since the point of logging is to help you find the cause of errors quickly, by not letting any inconsistency, bad return code or missing capability slip under the carpet you remove the need for logging.
  

The main logging object handles adding file, line, function info, process and thread IDs, timestamps, possibly even call stacks when logging exceptions/errors, etc, to the message object

I prefer a single logging object with multiple logging channels, where each channel can be of a different type. i.e. a FileLoggingChannel for writing to file, a ConsoleLoggingChannel for writing to the console, a SocketLoggingChannel for sending the logs over the network to an external logging application/server. Each channel type just implements a simple interface[/quote]I'd prefer to avoid the uneccesary inheritance here and keep your different log back-ends decoupled:class SocketLoggingChannel : NonCopyable
{
public:
SocketLoggingChannel(...);
~SocketLoggingChannel();
void log( const char* msg );
};

class ConsoleLoggingChannel: NonCopyable
{
public:
ConsoleLoggingChannel(...);
~ConsoleLoggingChannel();
void log( const char* msg );
};

cosnt char* FormatLogMessage(const char* fmt, ...);
typedef std::vector<std::function<void(const char*)>> ChannelVec;

#define Log(channels, fmt, ...) do { \
cosnt char* msg = FormatLogMessage(fmt, __VA_ARGS__); \
for (auto &c : channels){ \
c(msg); \
} \
} while(0) //