Jump to content
  • Advertisement
Sign in to follow this  
ZealousEngine

Need a logger...

This topic is 3863 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

I kinda want to implement a simple logger in my app, but before I roll my own, I wanted to see if anyone has any suggestions? All I really want to do is record simple messages to a text file like LOG->write("Current time - this function is being called!");. Doesnt stl have some kind of basic logger? Couldnt see it anywhere.. Thanks

Share this post


Link to post
Share on other sites
Advertisement
Was kinda hoping for something that would auto record the time of the log, and also have some options to record to different files based on flags (ie all the boring stuff goes into a common log, but critical errors are recorded in another file, ect...).

Should I just roll my own or is there some good ones out there?

Share this post


Link to post
Share on other sites
I didn't see any when I searched (albeit briefly) so I rolled my own logger (which, admittedly, isn't that great). For c/c++ I just haven't seen any that are all that useful (unlike Java). I'm sure if one exists someone will pipe up in this thread to let us know.

Share this post


Link to post
Share on other sites
Paul Nettle has a nice little logger, look in the code section on his site www.PaulNettle.com
(sorry can't find direct link because its a flash site...)
and while you are at it, check out his cool memory manager (for easy finding of memory bugs).

Iftah.

Share this post


Link to post
Share on other sites
If that's all you need, throw something together. A stream sink, a few decorators... piece of cake. It'd take less time and effort than asking.

The loggers I've seen as packages are (imo) totally overkill. The main design requirements for them (log rotation, catching config file updates without restarting, wildly configurable log levels) are (imo) things of minimal value to a game.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
The loggers I've seen as packages are (imo) totally overkill. The main design requirements for them (log rotation, catching config file updates without restarting, wildly configurable log levels) are (imo) things of minimal value to a game.


Yep, I totally agree. The logger I'm using right now is contained in about 300 lines of code and its most complex feature is a map of void* to strings to allow it to log the subsystem sending a message without requiring an identifier.

Figure out what you need your logger to do it and just write it up. It'll probably even take you less time than learning how to use someone else's.

Share this post


Link to post
Share on other sites
There's an Apache project called Log4cxx, which is a C++ port of Log4J. I've not used it yet, though I've used Log4J extensively and can't live without it now. If I were in need of a C++ logger, I'd definitely give it a try.


Quote:
Original post by Telastyn
The loggers I've seen as packages are (imo) totally overkill. The main design requirements for them (log rotation, catching config file updates without restarting, wildly configurable log levels) are (imo) things of minimal value to a game.


I used to feel the same way. In my old C projects, I was quite happy using a very simple logging system that put out a timestamp and marked error messages with a special prefix. Certain messages could be compiled away with a define. Very basic, common, setup. And exactly the sort of inflexible, prehistoric system that modern logging packages are meant to correct.

A logging system that only supports a couple of compile time configurations is not something I would ever want to use again. Being able to control the level of output, the format, and the output target is a huge plus, even for games.

For example on the client side (or even in just single player games) you can compile in as many log calls as you need to report a wide variety of metrics, but have it all turned off, only logging initialization and error messages by default. When a player has an issue, you can have them enter a command in-game that would turn on some, or all, of the metric output and redirect it from the local file system to a TCP connection which streams it to a remote report server, where you can store it in a file and look at it later or watch it in real time. Alternatively, the client could bundle all of the output into an email and fire it off to you automatically, or upload the log file to your ftp server.

If you maintain a game server, you can have a rotating file target set up so that you get a new log each day. When the server acts wonky you can login remotely, turn on more detailed logging for specific systems or for the whole app, and completely redirect the output to your client or have it sent there in addition to the files.

The flexibility of runtime configurable logging packages, like Log4J, is not overkill by a longshot, even for games. Being able to turn it off when you don't need it so that you don't pay for more than a simple boolean check and then to switch on as much or as little as is necessary when you need it, while sending it to as many targets as it needs to go to.... You get benefits both in customer support on the client side and in day-to-day maintenance on the server side.

Share this post


Link to post
Share on other sites
log4j/log4cpp was exactly the over-engineered, user unfriendly sort of package I had in mind when I wrote my original post. Do some games benefit from such things? Sure. MMO servers or similar uptime valuable, long running sort of processes similar to Apache benefit quite a bit. These though are not the majority of games, and not the vast majority of hobbyist games.

But yes, these are the fairly standard packages if you're going to go with one. Try it for yourself. Perhaps my experiences spending more time debugging others' logging configs than the errors themselves are atypical.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!