Back to General and Gameplay Programming

Globals, pros and cons?

General and Gameplay Programming Programming

Started by simon10k April 10, 2006 10:44 AM

25 comments, last by Mxz 18 years ago

rip-off

11,000

April 10, 2006 06:02 PM

Quote:Original post by Riekistyx

Look into singleton instance and use it heavily where needed.

I fail to see how a singleton can be redeemed of the cons of globals as have been described so far. A singleton is often just a global with an excuse for someone to think they are being "Object Oriented".

blog | twitter

Oluseyi

2,123

April 10, 2006 06:04 PM

Quote:Original post by Riekistyx
Look into singleton instance and use it heavily where needed.

Well, you're on a rash of giving out insufficiently thought out advice, aren't you?

Singletons are not a panacea for globals. In fact, they exhibit many of the same design flaws, albeit alleviating the issue of resource management.

Darragh

308

April 10, 2006 06:22 PM

The main reason not to use globals is to make debugging much easier. If you have a global variable thats getting some funny values put into it then it can be very difficult to find out what part of the program is screwing up- since any function which accesses the global could potentially be the culprit. I haven't done any multithreaded programming yet, but I would image in a multithreaded environment such a problem would be made even more difficult- nightmarishly so !!

Global variables won't work also with recursive algorithms such as flood filling and quicksort.

www.darraghcoy.com - projects

Sneftel

1,788

April 10, 2006 06:26 PM

Quote:Original post by Riekistyx
Look into singleton instance and use it heavily where needed.

Ugh. Someone who uses singletons as a replacement for globals may as well just use globals. He gains nothing except the opportunity to do some misguided lip service to OOP.

Anonymous

April 10, 2006 06:37 PM

Quote:Original post by Riekistyx
globals;

con: globals->quit c++()->quit programming();

pros: Newbstick coding.

Look into singleton instance and use it heavily where needed.

singleton;

con: singleton->global->quit c++()->quit programming();

pro: Newbstick OOP coding.

We just went over this down the hall.
http://www.gamedev.net/community/forums/topic.asp?topic_id=386290

Mxz

504

April 11, 2006 02:30 AM

Quote:Original post by Anonymous Poster
Quote:Original post by Mxz
That depends on what you mean by global, it is perfectly possible for a variable in the global namespace to be 'owned' by a particular translation unit, you simply need to give it internal linkage.

*** Source Snippet Removed ***

Clearly the variable global is owned by my.cpp in this case. Similarly you can imitate a primitive form of private global data which can be 'owned' by a particular translation unit in the following manner.

I don't think that's doing what you think it's doing. I can still

extern const int global;
class MyPrivateClass { /* ... */ };
extern MyPrivateClass GlobalInstance;

in any file to access it (cf. header files). What you need is

static const int global;

or, to follow the C++ idiom

namespace { const int global; }

These will create "private globals" in a less primitive way.

No, I was correct.

static variables at namespace scope are deprecated in C++. const variables have internal linkage by default. You can verify this with the following code.

my.cppconst int i = 10;

myother.cppextern const int i;int main(){int j = i;}

Which fails to compile with an unresolved external symbol.

As to your other example, yes you can do that, but then you can do similar things to break any of C++s encapsulation features. I'm not sure what your point is there.

[Sudoku]

Troll

246

April 11, 2006 02:56 AM

Quote:Original post by Mxz
static variables at namespace scope are deprecated in C++. const variables have internal linkage by default. You can verify this with the following code.

static variables are deprecated, but that's irrelevant for two reasons:

1) They're deprecated in favor of, of all things, globals. Namespace-scoped statics are deprecated in favor of globals in unnamed namespaces. They're fairly (but not completely) identical.

2) Even without #1, they'll never be removed because they're too prevalent in pre-existing code.

I'm a big fan of namespace-level statics or #1 now that they are deprecated. They're much preferable to a private class static. If it's a private static, it's an implementation detail, and I'd rather not change a header file when I change an implementation detail.

Riekistyx

100

April 11, 2006 04:23 AM

So people who teach this methods are incorrect, wrong, and its never used eh?

I know a place that teachs it heavily and relies on it.

So let me ask you this. Are you in companies saying this to me? Or just some persons who dont prefer singletons.

I cant begin to see how its messy at all. Infact Hungrian notation is probably more ugly to look at than this. So you tell me...

Mxz

504

April 11, 2006 04:38 AM

Quote:Original post by Troll
Quote:Original post by Mxz
static variables at namespace scope are deprecated in C++. const variables have internal linkage by default. You can verify this with the following code.

static variables are deprecated, but that's irrelevant for two reasons:

1) They're deprecated in favor of, of all things, globals. Namespace-scoped statics are deprecated in favor of globals in unnamed namespaces. They're fairly (but not completely) identical.

2) Even without #1, they'll never be removed because they're too prevalent in pre-existing code.

I'm a big fan of namespace-level statics or #1 now that they are deprecated. They're much preferable to a private class static. If it's a private static, it's an implementation detail, and I'd rather not change a header file when I change an implementation detail.

I don't think you are correct to say that a deprecated feature will never be removed, for the very reason that the definition of the word deprecated in C++ is: Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions.

If they had no intention of removing it then they would not have made it deprecated, but if you wish to carry on using it, that is your prerogative. I think it is also worth stating explicitly that use of the static keyword is only deprecated when declaring objects in namespace scope, your post seemed to confuse that slightly.

However, I do agree that static namespace scoped variables being deprecated is largely irrelevant to this discussion (assuming that is what you meant). I used it merely as an example of why the static keyword is not needed to give a variable internal linkage, and hence give the translation unit conceptual ownership of that 'global' variable.

[Sudoku]

etothex

728

April 11, 2006 04:41 AM

I'm suprised no one's mentioned aliasing. Unless you've got some form of inter-translation-unit optimizer, like MSVC++'s whole program optimization, you can encounter aliasing of global variables and prevent the optimizer from working, well, optimally :)

Globals, pros and cons?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Globals, pros and cons?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines