I've been doing a little work on a new branch called code-cleanup. You can check it out like this:
Code:
svn co http://svn.vdrift.net/repos/vdrift/branches/code-cleanup vdrift-code-cleanup
At the moment this will nearly compile but throws tons of linker errors. Essentially what I've done is moved all the global variables and functions from main.cpp into a class called VGAME.
Now, all the functions in all the other classes that used to use those globals are unable to find the functions they need...so something will have to replace them. I suspect I will make some of the functions and variables in VGAME public so that the functions can be called and the variables can be used as they used to by just following a reference to the VGAME object. But I guess that means it has to be global....sigh. I guess I could code data return paths into the various places that need them like I did with the Gui class. Hmmm...I think I'll sleep on it. If anyone has any ideas about how I should make the globals not-global as gracefully as possible, speak up.
can you make the functions in VGAME static (maybe it is not static but somethiing else)?
so you could use VGAME::functionName ();
What does moving all of the globals into a VGAME class get you?
As private members of the VGAME class, the former globals are totally inaccessible. I could make them public, or provide a public function to return a reference or something along those lines. However it seems to me that will make it harder to update all those references to the globals.
Public data members might work, but I was hoping for some more elegant solution...public data members are little better than globals in my eyes.
thelusiv Wrote:As private members of the VGAME class, the former globals are totally inaccessible. I could make them public, or provide a public function to return a reference or something along those lines. However it seems to me that will make it harder to update all those references to the globals.
i haven't looked at the code yet, but you can always make the data protected and make the classes that need to update the data friends of the VGAME class. this way you can control how the global data is being accessed. i'll try to take a look at the code soon.
--alex--
I don't like singletons because they use static data and make the code look very ugly (and slow you down). Instead of doing utility.LoadTexture("blah"); you have to do something like UTILITY::GetInstance()->LoadTexture("blah"); which seems less readable. Plus, burying your data in static members of a class somewhere doesn't make it very straightforward to see where global data is (or where it gets instantiated).
Isn't this how Vamos solves this problem? I'm not all that familiar with the code, but it seems like I've seen a lot of that kind of thing. What do you think the best way to solve this is? I'm open to lots of things...
Isn't this how Vamos solves this problem? I'm not all that familiar with the code, but it seems like I've seen a lot of that kind of thing. What do you think the best way to solve this is? I'm open to lots of things...
You don't always have to do the GetInstance() thing. You can make GetInstance return a reference then use that:
my_type& t = my_type::instance()
t.stuff()
Then it works very much like a global. The thing I like about singletons is they are created on first use *after* main() has started executing. You don't have to initilize them twice like globals. Also they encapsulate data better than globals do, for example, you don't generally access one singleton from another singleton.
Functionally, both globals and singletons serve pretty much the same purpose, but I think singletons are a better, more complete, and more robust solution.
You don't always have to do the GetInstance() thing. You can make GetInstance return a reference then use that:
my_type& t = my_type::instance()
t.stuff()
Then it works very much like a global. The thing I like about singletons is they are created on first use *after* main() has started executing. You don't have to initilize them twice like globals. Also they encapsulate data better than globals do, for example, you don't generally access one singleton from another singleton.
Functionally, both globals and singletons serve pretty much the same purpose, but I think singletons are a better, more complete, and more robust solution.
So we will need a variable such as "t" in each of our classes that uses a given class through the singleton interface. For instance we use the UTILITY class a lot. does this mean we will end up with every single class having its own singleton reference to UTILITY?
So we will need a variable such as "t" in each of our classes that uses a given class through the singleton interface. For instance we use the UTILITY class a lot. does this mean we will end up with every single class having its own singleton reference to UTILITY?
No, I don't really recommend having a reference as a memeber for the class, although you could do it that way. I think it would be better to have a reference for each function that uses the singleton rather than one per class. It would work fine both ways though...
No, I don't really recommend having a reference as a memeber for the class, although you could do it that way. I think it would be better to have a reference for each function that uses the singleton rather than one per class. It would work fine both ways though...