Need a logger...

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

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 on other sites
std::clog stream, appropriately redirected?

Share on other sites
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 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 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 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 on other sites
Quote:
 Original post by TelastynThe 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 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 TelastynThe 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 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 on other sites
There's some working code in this thread. Basic, simple logger. No frills. Just works.

--smw

Share on other sites
I really have to agree with Telastyn here, go with the KISS principle until you need more. Loggers are easy to scale up when you need too but it's a PAIN when you're using something way too complex like log4j/log4cpp.

Share on other sites
Quote:
 Original post by Mike2343I really have to agree with Telastyn here, go with the KISS principle until you need more. Loggers are easy to scale up when you need too but it's a PAIN when you're using something way too complex like log4j/log4cpp.

I'm curious why you guys think Log4J is too complex. The most complex it ever gets is when you need to implement your own output target, and that's a rare thing since it comes with several useful implementations out of the box. During development, you can configure all output from all loggers to go stdout with a single method call.

// during init, configure the root logger to send output to stdout,// in a simple format, at the default log levelBasicConfigurator.configure();// in each module, grab a logger refstatic final Logger logger = Logger.getLogger("my.class.name");// now loglogger.info("blah blah");try { ...} catch(Exception e) {   logger.error(e);}

Nothing complex or painful about it from my perspective. Most applications will never need to use anything more complex than creating a logging config file for the final distributable, or to turn debug output on/off. And it would take very little effort to expand the usage of the system if you decide you want to later on down the road.

Sure, for simple hobby work or cast of releases, it might not be a priority. But if you're going to release anything that you intend to actually support, it can be a huge boon to add something like this in from the beginning.