Jump to content
  • Advertisement
Sign in to follow this  
Skute

Good Log Design

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

Hi, i want to build a basic logging utility throughout my engine. i wondered which design method is best to go with? I thought about the following: a) Having a global g_pLog variable which has logging functions on it b) Having all classes inherit from a base class which has several generic functions in which are useful throughout the codebase (not just logging), that way all classes will have access to the log (the log pointer can be passed through as a constructor param) c) Having global log functions d) Having static functions on the main application / engine class (i.e. CEngine::WriteToLog()) e) Some other way... My main requirements are that almost every class can write what they like to the log. The log might not necessarily be a physical file, it could be to a console, to a dialog, to the visual studio output window or all of the above. What are you suggestions?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Personally, I use a singleton type setup like this:

in Log.h or whatever:

class ILog
{
public:
ILog(){};
virtual ~ILog(){};

virtual void Log(const char *Format, ...) = 0;
};


ILog *Log(void);

and in Log.cpp or whatever:

class CLog : public ILog
{
... implementation...
};

ILog *Log(void)
{
static CLog L;
return &L;
};


Only the interface is exposed to the outside world...
oh, and i'm sure somebody will point out the error of my ways using '...', but whatever... i don't care.

i'm not saying this is the 'best' way, just my way. for now.

Share this post


Link to post
Share on other sites
Don't waste time trying to get the perfect design for your log system. It just isn't that important.
Personally, I just have a global std::ostream that I can log to from anywhere. In the highly unlikely event that you find yourself severely limited by this system, then you can think about a more complex way of doing it - but I think this is a fairly safe case of You Aint Gonna Need It.

Don't worry - there will be plenty of other impossible code design decisions to make later.

Edit: Having said all that, there is one important point to mention - whatever system you end up with, make sure you either turn off buffering, or flush the log whenever you write a message (iirc, outputting std::endl has the effect of flushing the stream, but I could be wrong). Otherwise, you may find yourself hunting bugs in the wrong place because your code has got further than the log indicates.

John B

Share this post


Link to post
Share on other sites
I just made a simple logging class and made it a singleton. It has the advantage of being available globally and allows a little more complexity than just putting some text to a file (like nicer formatting, prefixing each line with the time and splitting up the log into individual subsystems). Like others said though, you don't need to spend alot of time on the log, just make sure it's usable and gets the job done.

EDIT: You may want to check out superpig's Enginuity article where he covers error logging.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBSmall
Don't waste time trying to get the perfect design for your log system. It just isn't that important.
Personally, I just have a global std::ostream that I can log to from anywhere. In the highly unlikely event that you find yourself severely limited by this system, then you can think about a more complex way of doing it - but I think this is a fairly safe case of You Aint Gonna Need It.

Don't worry - there will be plenty of other impossible code design decisions to make later.

Edit: Having said all that, there is one important point to mention - whatever system you end up with, make sure you either turn off buffering, or flush the log whenever you write a message (iirc, outputting std::endl has the effect of flushing the stream, but I could be wrong). Otherwise, you may find yourself hunting bugs in the wrong place because your code has got further than the log indicates.

John B


I strongly disagree.

To make your log a useful tool it needs to be very extensive - you need to log many thousands of lines for a typical game run.

Obviously, sifting through 1000's of lines of logs is too time consuming so your log system needs to be smarter than a simple text file.

Yuo will need the ability to write to multiple logs (you can safely ignore any log entries made by your renderer when you are debugging an input problem).

You will need the ability to search your logs (colour coding is also a must). XML is a good tool for this.

You may also need the ability to have your logs rendered in game somehow (it's difficult to debug AI unless you know what the AI is 'thinking' in real-time).


The only time that You Aint Gonna Need It applies to logging is when you plan on writing 100% perfect code which we all know never happens.

Share this post


Link to post
Share on other sites
Frankly, the main feature a logging class should have is that it works, no if's and's or but's. Integrating an XML framework, dealing with color coding... seems like more work [and risk] than the benefits. IMO, simple use of grep is a better alternative. YMMV.

Though I do concur, the abilty to log multiple places, even to some sort of in-game console is quite advantageous.

Personally, currently, I use a simple interface [a virtual function that takes a string] which has about 4 implimentations [file, screen, gui console, functor]. For certain things, I create a local instance of that interface, usually though it just goes to a global instance.

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!