Sign in to follow this  

extern global variables vs singleton classes

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

which is better? faster? and why?

1. using a extern global variable like as:

extern CLogger* Logger;

Logger->Log;




or



class CLogger : public Singleton<CLogger>
{
/*...*/

static CLogger* getInstance(void){ return m_Instance;};
};

...

CLogger::getInstance->Log(...);

Share this post


Link to post
Share on other sites
A global variable is just a variable; a POD especially doesn't have any lifetime management or accessor crud around it, so it's going to be as fast as you can get. Whether or not the singleton object performs as well is up to compiler optimizations.

However that's besides the point, since you shouldn't be using singletons anyway. If you only want one of something, then only create one. Wrap it in a namespace. Done. There's nothing a singleton gives you but tighter coupling and unnecessary inflexibility.

Share this post


Link to post
Share on other sites
You should not be using global variables or singletons (which are just Satan's piss-ant excuse for global variables).

The only time you should be using state variables to represent mutual exclusion over a resource is when you actually need mutual exclusion over that resource, in which case you should be letting the operating system handle it for you, because it it will do a better job.



As for which is faster, let me tell you a story:


One day, a truck was driving down the highway. Suddenly, it was hit by a falling asteroid made out of manure.

Which was more purple?

Share this post


Link to post
Share on other sites
Speedwise, I imagine they are about identical, assuming a competent compiler.

Better? I think a global is slightly superior because it doesn't tie you down to a single logger. If you decide that your networking module or graphics module needs specialised log support, you'll find the fact that you aren't using a singleton really helpful. You can also point the global logger pointer at a regular stack allocated object inside main(), which alleviates the static initialisation order fiasco (if applied universally).

You can get away without globals with a bit of though. I don't bother for something like a logger. Arguably, it would be better not to write a fancy logger and just flush everything to stdout and/or stderr.

That way you can have an ultra-flexible log, because you can wire up your program to log to a file using redirection, pipe its output through tee or even end up pointing it at telnet or something for remote logging. If you are debugging a particular subsystem you can use grep to filter out every else. Best of all, you can change this dynamically without messing with the code.

The only thing you might want to support is "log levels" to avoid unnecessary output to the log file, which might be set via a command line parameters. This filtering could be done with a little grep magic too.

Share this post


Link to post
Share on other sites

This topic is 2569 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this