Hello forum : )

Using C++ but topic probably affects similar languages as well.

I will talk about a class/object called "logger", my definition of a logger: A class that can be used by every class to print significant code-happenings to a file. E.g. new state of a state-machine has been reached.

I know globals can be very unhealthy to use and should be avoided. This is what I do, I have not a single global within my own code (what libraries provide does not count).

Nonetheless, I want to implement a logger - easy way to track bugs happening while my software is running without some debugger-console.

Users will have an easy way to help me fixing bugs, too.

So I was wondering whether global loggers are common practice or if the senior programmers would hunt and burn me if they find out :' )
Literally every component within my software could and will use the logger, so why bother passing around a logger?

Especially because nobody relies on a logger, it is a simple "write-only"-class.

Thanks a lot for your time, have a nice day : )

I tend not to bother logging things; I mostly think it's a waste of time for most applications.

When I do, it's typically transient: that is, I'll log a bunch of stuff related to a some problem I am working on now, but remove all of that one I fix the problem.

I just call a logging function, which itself is just wrapping whatever the most-natural logging mechanism is for the platform I am on. I don't really see the need to turn the concept of a log into an object with it's inherent complexities about lifetime and management and all that.

"Don't use globals" I think is one of those general guidelines that makes sense to break IF you know why you're doing it (and it's a good reason). Like whenever you hear "don't use pointers!" - it's not because they should never be used, but more that you should know exactly *why* you're using them and be comfortable with the implications.

Maybe your particular logger makes sense to be accessed as a global.

Maybe an object in your game should be taking ownership of the logger anyway.

Maybe make your logger a singleton, Logger::Get()->Log("My debug message...")

Maybe put your log functions in a namespace instead of a class, Logging::Log("My debug message...")

It really depends on your logging needs.

On one end of the spectrum you have a set of simple logging functions that write to standard output/error and maybe a few files. This is pretty straightforward to write yourself and doesn't require any complex object modeling. On the other end you have libraries like log4cxx which make heavy use of objects and statics/globals and allow you to create all sorts of complex logging behaviors and configurations.

So I would start by asking yourself the extent to which your code needs logging, and what kind of functionality you need. Then decide whether that's best handled with a simple functional interface, or if you need to start using objects (and whether or not you want to write this yourself or use an existing library).

Depends on the project as well.

We generally use a well-known instance. That is a global pointer to an instance that has established semantics of when it is created and destroyed.

Subsystems can (and sometimes do) create their own sub-loggers. Also the primary logger is an event listener, so code can either call the logger directly or pass messages indirectly.

Just be careful with it. The three are globally accessible objects, not singletons.

As for the standard streams being near-universally useful, note that a good logging system can have an any number of logging listeners. That includes adding a listener that directs to stdout and stderr depending on severity or logging level.