Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualCornstalks

Posted 14 June 2012 - 09:23 AM

I use singletons in my game. Not many, but I use them. DebugLogger is a singleton class I have. Every method is protected against multiple threads, and it CAN slow down my performance. Haven't seen it yet, but I know the chance is there. This is only available in debug and debug/release builds of the game. In release, it's not active and doesn't do anything.

It's scenarios like this (and I honestly can't think of another scenario) that are okay to be a singleton. EVERYTHING will need to log something, and you don't want to pass around a pointer/reference to the logger to everything.

Look at rip-off's post. There is *no* need for it to be a singleton. Go ahead, use a global variable. But don't use a singleton. Additionally, you can just use functions, and nothing will need to touch the logger.

// Thread safe function that logs to a global logger
logThis(const std::string& msg);

void someFunction()
{
    logThis("hello world");
}

void anotherFunction()
{
    logThis("like how I don't even need to touch a Logger instance?");
    logThis("logThis() is a threadsafe function that logs to a global Logger instance");
    logThis("but it's nice, because all that is abstracted away. I don't care how logThis() is implemented. I just have a message to log.");
}

void thisFunctionLogsToACustomLogger()
{
    Logger logger("customLog.txt"); // open a new log, don't use the global one (this can be useful in certain situations)
    logger.log("and look! I'm not abusively restricting myself to having only one logger! I can use"
               "another Logger instance if I need, or I can use the global log if I need. Yay!");
}

#1Cornstalks

Posted 14 June 2012 - 09:20 AM

I use singletons in my game. Not many, but I use them. DebugLogger is a singleton class I have. Every method is protected against multiple threads, and it CAN slow down my performance. Haven't seen it yet, but I know the chance is there. This is only available in debug and debug/release builds of the game. In release, it's not active and doesn't do anything.

It's scenarios like this (and I honestly can't think of another scenario) that are okay to be a singleton. EVERYTHING will need to log something, and you don't want to pass around a pointer/reference to the logger to everything.

Look at rip-off's post. There is *no* need for it to be a singleton. Go ahead, use a global variable. But don't use a singleton. Additionally, you can just use functions, and nothing will need to touch the logger.

// Thread safe function that logs to a global logger
logThis(const std::string& msg);

void someFunction()
{
    logThis("hello world");
}

void anotherFunction()
{
    logThis("like how I'm don't even need to touch a logger?");
}

void thisFunctionLogsToACustomLogger()
{
    Logger logger("customLog.txt"); // open a new log, don't use the global one (this can be useful in certain situations)
    logger.log("and look! I'm not abusively restricting myself to having only one logger! I can use"
               "another Logger instance if I need, or I can use the global log if I need.");
}

PARTNERS