The Mana World Forums

While working on an idea, I ran across the global variable "homeDir", defined in "main.cpp" and referenced in "gui/updatewindow.cpp". Is this the "approved" way to creating a global variable?

I had assumed otherwise - for the "updatesdir..." patches, I chose to add a public variable to the Configuration class to accomplish basically the same thing. And I'm wondering if that was the proper way to handle this situation.

Now I'm working on having a command-line parameter to specify the update host, and I once again need to carry that info from main.cpp to updatewindow.cpp. So what's the "right" way to do this: A classic global variable in main.cpp, with the associated "extern" definition in updatewindow.cpp? Another public variable in the Configuration class? A private variable in the Configuration class, with "trivial accessors" to get/set this data? Something else entirely?

(Note: I'm primarily a C programmer, so some of the C++ concepts are a bit foreign to me)

Global variables are a bad choice in OOP. In the case of "homeDir" it is most likely a sin from the time where all TMW programmers were less experienced than they are now. Please avoid global variables when possible. The updatehost to use should in my opinion be an argument which is passed to the constructor of Updatewindow. But I don't have the code in front of me right now, so this might not be the ultimate solution.

By the way: The best place to talk about programming issues is either the IRC channel #tmwdev (for short questions) or the mailing list (for more complex questions). Most people who read the forum aren't programmers and our most skilled programmers don't have time to read the forum regularily.

Thanks for the reply. Since the update window is created by main.cpp, it *should* be possible to pass the arguments to it's constructor.

I'll take a look at the mailing list.

Passing the updatehost as an argument to the update window gives me an idea: This would make it quite easy to implement downloading of different updates from multiple servers at the same time. This would make sense for people who run a private TMW server with only a few modifications. Your users could download the normal content from the official updateserver and the custom content from yours.

But this is something for the new server.

Probably the question has already been answered though...

Another method is using Singleton pattern. Sometimes it is very useful and probably having access to Conf’ class with its help might be good. There are some methods how to implement this pattern in C++. But there is a good example right in the code.

For instance, getting access to resources in the game: And yes, "Global variables are a bad choice" in the most of modern programming languages btw in C too. Just one reference, changing global [class] variables with Singleton pattern is a good solution only in some very special cases.

Dr. Alex

Axalix wrote:Another method is using Singleton pattern.

I'm not a developer on this project so feel free to ignore me, but I think a Singleton is just the object-oriented variant of a global variable and should also be avoided.
If one object depends on another, the dependency should just be given to the object (using the constructor or a setter method). That technique is called Dependency Injection.

Hanno wrote:I think a Singleton is just the object-oriented variant of a global variable and should also be avoided.

I agree with this but for 50%. One of the big problem with "global variables" is "scope" that is "global". So variable may be modified (often by-mistake) in "local scope" too. The second problem is (I agree with you in this) "strong dependency". Classes should know about this variable?! It is not OOP - it's failed encapsulation, of course.

What is "Singleton pattern"? The aim is to prevent more than one of "instantiation". (It’s like we have the only one configuration structure). Why it is not the same as "global"? - Because there is no any "scope" issues. Or I would say - it is hiding. Why it is "global"? - Because we have an access to the same object from everywhere.

Anyway it makes sense to avoid of "Singletonitis" (frequently using) but it is useful to use this for your question (configuration).

With regard to "Strong Dependency" and "Dependency Injection". Yes I agree it is good to organize separated (independent) sets of classes / structures for further reusing. But some things are impossible to implement or it will take to much time (complicated code as a result and hard maintains).

One more thing I want say. Sometimes bad things are not so bad. There are examples where better to use global variables.


Dr. Alex

Axalix wrote:What is "Singleton pattern"? The aim is to prevent more than one of "instantiation".

I've never had a class where I found this feature particularly useful. But that might be just my personal experience.

Axalix wrote:Anyway it makes sense to avoid of "Singletonitis" (frequently using) but it is useful to use this for your question (configuration).

Yes, I agree with this and the rest of what you say.
Especially if the singleton object is immutable (= read-only) like it would probably be the case with the configuration object, having a singleton is not that bad.

The world isn't black and white and sometimes it makes sense to use a singleton or global variable, as long as you're aware of the problems.
I think the main issue is code maintenance over time. Let's use a small singleton here and one there... what? We want to be able to change our configuration object at runtime now? Why not, let's just add the feature to the singleton.
Fast-forward 5 years and you end up with an intangible mess where it's impossible to understand what's accessing what.

Axalix wrote:With regard to "Strong Dependency" and "Dependency Injection". Yes I agree it is good to organize separated (independent) sets of classes / structures for further reusing. But some things are impossible to implement or it will take to much time (complicated code as a result and hard maintains).

I'm not sure if that's what you're referring to but it can be quite messy to always pass every single dependency around, especially if you have hierarchies of classes where you need to pass some dependencies from the top-level all the way to the inner classes.
My preferred solution to this problem is using a dependency injection framework. An example would be PicoContainer which is a Java library but I'm sure there's stuff like that for almost all languages. The PicoContainer website contains lots of information on that whole subject and is an interesting read, even for non-Java programmers.

Axalix wrote:One more thing I want say. Sometimes bad things are not so bad. There are examples where better to use global variables.

Yeah, as I said above: There's always shades of gray.

Fast-forward 5 years and you end up with an intangible mess where it's impossible to understand what's accessing what.

You said it -- there are a number of sections of the code that are already like this. Somebody who's not completely and intimately familiar with the code can very easily get lost.

Also new people trying to join are saying it's complex.

A codebase cleanup and restructuring iceberg ahead?