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]