Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Static or singleton

Sign in to follow this  


I'm struggling to find the advantage of the singleton pattern. The way I see it, most people use it to make a class globally accessible and only once instanced. Why not just use static functions and variables?

I used to do things like this for my managers:

class settingsManager : singleton {

extern settingsManager* settingsMGR;

I hate always having to do settingsManager::getInstance()->function(). So in the application setup I point settingsMGR to the single instance, and this pointer can simply be used everywhere. Is this bad?

Anyway, it seems easier just to use static functions. Instead of calling settingsManager.getSetting("width") I would call settingsMGR::getSetting("width"). What are the implications of this?

Come to think of it, what exactly does the "static" keyword do? I feel like I know what happens because of it, but not exactly what it does. I know the official definition is that it makes a variable/function stay alive for the lifetime of the program. It doesn't matter which function call or class instance we are dealing with, if a function or variable is static it will always be the same variable.

But I've noticed some things. If you declare a static variable in a header file, it seems to make a new "instance" of this variable wherever it's included. I guess it would be a global static variable, which must have some weird implications. For example:

static int staticVar = 5;

(source1.cpp, includes header)
staticVar = 0;

(source2.cpp, includes header)
staticVar = 1;

Now, without the "static" keyword, you get a linker error because of multiple definitions of same name. Put the static in there, and it compiles fine. Why is that? What exactly happens at the linker stage? Because in source1.cpp, it sees a variable called "staticVar" that equals 0, while in source2.cpp, it sees a variable called "staticVar" that equals 1. I've confirmed this with code and printf's.

If you want it to be the "same" variable across multiple files, use "extern" and then declare it in an implementation file.

Anyway, I like understanding the things that I use. Just my ramblings..

PS. oh, and thanks for the replies on the previous post. I understand it now [grin]
Sign in to follow this  


Recommended Comments

In C++ the static keyword is deprecated on non class members. It is basically the same thing as using a nameless namespace.

namespace {
int var;

That is, you are not sharing a single variable across multiple files, but instead are declaring multiple variables that are local to the current compilation unit only (source file).

As far as static and classes go. This ensures that you have only a single instance of a variable shared between all instances of the class. There are advantages and disadvantages to this. Typically you try and avoid static member data unless it's state is fixed (such as a configuration files data would be).

Share this comment

Link to comment
In C++ the static keyword is deprecated on non class members. It is basically the same thing as using a nameless namespace.

Ah, good to know. Thanks a lot Washu.

And yeah... I think I'm not gonna use the static method, because of the fact that you mentioned. I can't guarantee that a manager's state will be fixed. You could have a class with static functions that accesses static attributes, making its state dynamic, couldn't you? I guess that's just bad practice though.

I think I'll stick with my first method. I like the singleton pattern that I use; I still have control over construction and destruction order, and all it does it make sure not more than 1 is created.

Share this comment

Link to comment

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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!