Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

Is your Logger global?

This topic is 587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 : )

Edited by Angelic Ice

Share this post


Link to post
Share on other sites
Advertisement

"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...")

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Free function all the way. It should be the single authoritative point of entry for anything that wants to log, and all intricacies of getting logs formatted, on disk, over the network, etc. should hide behind it.

Share this post


Link to post
Share on other sites
Parts of the development environment itself make sense to be global - anything that has a 1:1 relationship with the program. e.g. a function to see if the developer is in a debug session, or to log some debug info.

Non-global logs also make sense if they're a feature of the app instead of a developer feature. E.g. A server may want to keep a log of all login attempts, a journal of changes to settings, and a transient log of chat room activity -- these are normal application features and should follow normal software engineering practice.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!