• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
shurcool

Avoiding Global Variables

71 posts in this topic

I was under the impression that if one had a lot of freedom and time to write high quality C++ code and follow best practices, then one could avoid having global variables altogether. After all, global variables often feel like quick hacks in order to code something up quickly, rather than "take your time and do it properly", and when a project gets larger they get in the way. Often, you'll need to replace a single global class instance with a list of properly maintained objects.

Anyway, if the general idea above is sort of true (that it's better code practice to avoid globals when possible, and it is possible to avoid them in all cases), what happens if...

Suppose you have a list of a lot of items. And each of these items needs to have some sort of connection to the outside world, i.e. for example to the list itself.

If you had a global variable, the problem would be solved trivially. But otherwise, would you have to specify that variable and add it to each instance of your item collection?

[CODE]
struct MyCustomContainer
{
int Whatever;
SomeGlobalClass * ConnectionToOutsideWorld; // This becomes a huge waste of memory because it's there in each instance, only to replace 1 global variable
}
std::vector<MyCustomContainer> LotsOfItems;
[/CODE]

Please offer some advice.
0

Share this post


Link to post
Share on other sites
Here's some reference for advocating that global vars can/should be avoided: [url="http://www.gamedev.net/topic/621707-singleton-template/"]http://www.gamedev.net/topic/621707-singleton-template/[/url]

Basically, my question is this: Do I need to redesign my code so that the items in a huge list do not need a connection to the outside world... Or is there a better solution than to waste memory by padding each item with a variable (which could be replaced by 1 global variable or singleton).
0

Share this post


Link to post
Share on other sites
Ok, let me look up what exactly I was doing that required a connection to the outside. I'm pretty sure it seemed hard not to require it.
0

Share this post


Link to post
Share on other sites
[quote name='DvDmanDT' timestamp='1332181915' post='4923379']
Why do all the object need that outside connection? That's the key here. They probably shouldn't. Perhaps they need it for some operation? In that case, pass that data to that operation instead.
[/quote]
Okay, you were right. They need it for a few operations, and in theory I could be passing the outside-connection variable as a parameter to those functions. But I'll have to start passing it in oh-so-many places which is annoying given how much less typing it'd be to just have a reference.

Basically, I have a WidgetManager class that contains a bunch of instances of classes derived from a Widget class.

The Widget class has functions like CheckHover(), CheckActive() and CheckAnyActive() that return true if the currently hovering/active widget (info available in parent WidgetManager class) happens to be _this_ widget.

[code]bool Widget::CheckHover()
{
return (this == m_WidgetManager.m_HoverWidget);
}
bool Widget::CheckActive()
{
return (this == m_WidgetManager.m_ActiveWidget);
}
bool Widget::CheckAnyActive()
{
return (nullptr != m_WidgetManager.m_ActiveWidget);
}[/code]

The classes that derive from Widget (e.g. ButtonWidget and whatnot) use those methods from Widget to do their jobs.

So it looks like I'd have to rewrite those functions as Widget::CheckHover(WidgetManager & WidgetManager), etc. if I want to avoid storing a WidgetManager & m_WidgetManager; variable in each instance of Widget. Of course, in this case there's probably not that many of them, but I just felt it was unnecessary duplication of memory in order to avoid globals...
0

Share this post


Link to post
Share on other sites
What about:

[code]
Widget::SetHover(bool hovered)
[/code]

which is called by the window manager.
0

Share this post


Link to post
Share on other sites
[quote name='Madhed' timestamp='1332183764' post='4923398']
What about:

[code]
Widget::SetHover(bool hovered)
[/code]

which is called by the window manager.
[/quote]
A WidgetManager will contain many Widgets. By design, there will at all times be 1 or no hover objects. So it makes sense to have one variable that represents which Widget (if any) is hover.

If each Widget has a bool hover, then:

1. It wastes memory.
2. Due to bugs or memory errors, it may be the case there will be more than 1 Widget with hover set to true, causing further bugs.

I want to follow the [url="http://en.wikipedia.org/wiki/Don"]DRY principle[/url]. If some concept requires only one variable to represent it, I don't see any compelling reason (other than ease of writing code) to use more memory than that to represent it.
0

Share this post


Link to post
Share on other sites
Why have a variable at all? Use the mouse-move event to search for the widget under the cursor and tell said widget to do whatever it needs to do due to the on-hover condition.
0

Share this post


Link to post
Share on other sites
There is some state that needs to be kept track of from the past. Current mouse event isn't enough. For example, when releasing the mouse button, it matters where it was clicked to begin with. But this is off topic.

What I'm more interested in knowing is this:

If you have a large list of custom structs that needs an "outside world" connection, there two solutions that use no more memory than is least required:
1. global variable/singleton
2. pass in the variable as a parameter to functions that need it, every time

Any other solutions?
0

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1332186115' post='4923415']
If you have a large list of custom structs that needs an "outside world" connection, there two solutions that use no more memory than is least required:
[/quote]
It would be easier to answer if you would provide an example of when knowledge of the outside world needs to be known.
If hovering requires special changes to the graphics of the widget, then the widget needs to know it is hovering or not hovering.
If there can be only one widget that can hover at a time, then the manager of the whole set of widgets needs to tell the previously hovering widget that it is no longer hovering (change a state flag) and tell the new one it is. Fairly trivial if the manager simply keeps a pointer to the one widget that is hovering.

Here is the problem.
Let’s assume both of the above rules are necessary, and that is what you tried to explain.
But when you explained it you stated it as a single rule.


It isn’t one rule. It is 2 separate rules localized to the objects that made those rules exist.
If a widget needs to do special rendering for a hover state, then all widgets need a flag for that, since it is their own job to live inside their own little box ([b]with no knowledge of the outside world[/b]) and handle the functionality they were meant to handle.

And if only one widget can be hovering, or have focus, or whatever else, then you need to think about who actually made that rule. It certainly wasn’t the widgets themselves.
They live in a box, with no connection to the outside world.
It was the widget manager who decided it could only keep track of one widget having focus or hovering.
It should obviously be the widget manager who tracks that data.


Data about past clicks?
Considering that users could drag from one control and into another, it probably makes the widget manager a good candidate for the task of keeping track of the mouse history.



Basically, if you ever need to ask how to make widgets aware of the outside world, you are doing it wrong, because there [i]is[/i] no reason. It should [i]never[/i] happen under any circumstances.
So next time you feel the urge to ask that question, consider that it means you have not properly separated the rules for objects and what should handle those rules, and rethink your design.


L. Spiro
1

Share this post


Link to post
Share on other sites
Thanks for your post, YogurtEmperor.

[quote name='YogurtEmperor' timestamp='1332247815' post='4923594']Basically, if you ever need to ask how to make widgets aware of the outside world, you are doing it wrong, because there [i]is[/i] no reason. It should [i]never[/i] happen under any circumstances.[/quote]
But what if I want a very basic widget system that encloses all the widget-related code within the widgets. Including rendering, and input handling, both of which require the knowledge of hover/active states. Keeping a bool inside each widget is not an option in my view because it's unnecessary duplication.

The WidgetManager's job is to manage which of its widgets is being hovered (if any), and which one is active (if any).


[quote]So next time you feel the urge to ask that question, consider that it means you have not properly separated the rules for objects and what should handle those rules, and rethink your design.[/quote]
My widget system is rapidly changing as I'm developing it. However, in the process of doing so, I've come up with the previous abstract question and I wanted to ask in order to see what some answers might be.

My current understanding of the best answer: Yes, you can avoid global vars/singletons while maintaining DRY principle. In the case that a large number of instances [b]need[/b] access to "the outside world" inside certain functions, then you should pass that reference as a parameter to the function. The main downside is extra typing of code.
0

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1332256900' post='4923638']
My widget system is rapidly changing as I'm developing it.[/quote]

As evidence of this, consider that I originally had just one hover/active object per WidgetManager.

Now, I've changed it so that WidgetManager doesn't keep track of one hover/active object, but another class called Pointer does. WidgetManager has a variable number of Pointer instances (typically one). This Pointer represents some abstract input device that has the capability to independently hover or activate Widgets. For example, a mouse pointer. Or a finger touch input. But there might be two finger touches, both of which can be hovering over various widgets. Or a finger plus the mouse pointer.

This redesign allows multiple widgets to be interacted with simultaneously, which is something I wanted to be possible.
0

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1332256900' post='4923638']
Thanks for your post, YogurtEmperor.

[quote name='YogurtEmperor' timestamp='1332247815' post='4923594']Basically, if you ever need to ask how to make widgets aware of the outside world, you are doing it wrong, because there [i]is[/i] no reason. It should [i]never[/i] happen under any circumstances.[/quote]
But what if I want a very basic widget system that encloses all the widget-related code within the widgets. Including rendering, and input handling, both of which require the knowledge of hover/active states. Keeping a bool inside each widget is not an option in my view because it's unnecessary duplication.
[/quote]
To be completely blunt, the root of your problems is that your design stinks. You're trying to shoe-horn your problem into your pre-conceived solution and ignoring the fact that all the evidence is waving you off, not to mention us here. That's about as effective as leading a horse by the cart.

Yes, you should be suspicious of duplicated code and duplicated values, but that doesn't mean it should be avoided out-of-hand. Concern yourself with choosing the correct solution, not the one that fits into some notion of being "optimal" in some dimension. In short, what you *think* you want very often turns out to be wrong, and that's especially true with the less experience you have in programming or with a particular type of problem.

[quote name='YogurtEmperor' timestamp='1332247815' post='4923594']So next time you feel the urge to ask that question, consider that it means you have not properly separated the rules for objects and what should handle those rules, and rethink your design.[/quote]

Quoted for emphasis. Problems lead *you* to the solution, you don't lead problems to the solution.

[quote]My current understanding of the best answer: Yes, you can avoid global vars/singletons while maintaining DRY principle. In the case that a large number of instances [b]need[/b] access to "the outside world" inside certain functions, then you should pass that reference as a parameter to the function. The main downside is extra typing of code.
[/quote]

That's more-or-less right. However, let me emphasize that parameter passing is a *good* thing -- taking the opposite view corrupts modularity, and all too often leads to half-baked "solutions" like Singleton.

Never let the amount of typing sway you from using parameters -- "less typing" is an excuse used by lazy typists who fancy themselves programmers. The only good thing that has *ever* come out of programmers typing fewer characters is functional programming [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
2

Share this post


Link to post
Share on other sites
globals should be avoided. And often CAN be avoided. what about making every ojbect as child of a parent class from wich each child can get all other missing informations?
-2

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1332256900' post='4923638']Now, I've changed it so that WidgetManager doesn't keep track of one hover/active object, but another class called Pointer does. WidgetManager has a variable number of Pointer instances (typically one). [...snip...] there might be two finger touches, both of which can be hovering over various widgets. Or a finger plus the mouse pointer.

This redesign allows multiple widgets to be interacted with simultaneously, which is something I wanted to be possible.[/quote]

I think this turn of design illustrates that your initial intuition was a little off. It turns out that Widgets each storing hover state is only redundant in the special case that only one could ever be "hovered" at a time.

I suspect that your concerns about wasted space in the Widgets is unfounded. If you ever have enough of them that you really do need to start worying about their per-instance bytes, then you should re-visit this.

But if you'd still like to be concerned, just for the sake of argument, then you might try this: Decide on a maximum number of simultaneous hovers, and put a static array of references to "hovered Widgets" in the Widget base class (perhaps with accompanying references to respective "Pointer" class objects). That way, all Widgets can look up whether or not they're being hovered (and by which pointer), without adding per-Widget storage.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1332263502' post='4923680']
But if you'd still like to be concerned, just for the sake of argument, then you might try this: Decide on a maximum number of simultaneous hovers, and put a static array of references to "hovered Widgets" in the Widget base class (perhaps with accompanying references to respective "Pointer" class objects). That way, all Widgets can look up whether or not they're being hovered (and by which pointer), without adding per-Widget storage.
[/quote]
That's not avoiding a global variable. Static variables pretty much are global variables; they're just in a class and not a namespace.

I think the answer to avoiding global variables in this instance (and some others) is avoiding premature optimization.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1332263502' post='4923680']
[quote name='shurcool' timestamp='1332256900' post='4923638']This redesign allows multiple widgets to be interacted with simultaneously, which is something I wanted to be possible.[/quote]

I think this turn of design illustrates that your initial intuition was a little off. It turns out that Widgets each storing hover state is only redundant in the special case that only one could ever be "hovered" at a time.[/quote]

It's not really a special case. Unless each and every one of my widgets can be active and hovering independently, it makes no sense to store a bool inside each one.

[quote]I suspect that your concerns about wasted space in the Widgets is unfounded. If you ever have enough of them that you really do need to start worying about their per-instance bytes, then you should re-visit this.[/quote]

It's not about wasting space, it's about duplicating the same piece of information in multiple places - and having to write additional code to maintain a valid in-sync state. Having just one variable to store one piece of independent data solves this problem trivially.

I'm basically explaining DRY here, but consider a situation where you need a single integer variable for storing a single value.

You could do this:

[code]int SomeValue; // A single variable
SomeValue = 500;
// Use the variable later on
[/code]

or this:

[code]int SomeValue[10]; // 10 copies of the same single variable
for (int i = 0; i < 10; ++i)
SomeValue[i] = 500;
// Use 10 copies of the same variable later on (remember, if you want to change the value, you should change all 10 variables)[/code]

In this case, it's completely obvious the second solution makes no sense. It duplicates the same information 10 times, without any benefit. It only creates problems, because there's extra effort to write code to keep 10 copies in sync, and to make sure they don't go out of sync. It's bug-prone, as the 10 copies of the same variable might fall out of sync due to a logic bug. It's also more coding effort, which is why no one does this.

That's my motivation for not repeating information in more places than necessary. But in other cases, you have to do more coding effort to maintain a single copy of single piece of data rather than duplicating it, but I think it's worth it in the end.


[quote name='Ravyne' timestamp='1332260621' post='4923668']
That's more-or-less right. However, let me emphasize that parameter passing is a *good* thing -- taking the opposite view corrupts modularity, and all too often leads to half-baked "solutions" like Singleton.

Never let the amount of typing sway you from using parameters -- "less typing" is an excuse used by lazy typists who fancy themselves programmers. The only good thing that has *ever* come out of programmers typing fewer characters is functional programming [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]
[/quote]
Excellent! That's great news for me and what I wanted to hear.

I am not afraid of extra coding effort/amount of typing required. I just wanted to know, ignoring the implementation effort, if the solution is a more desirable one. The extra coding effort is only a problem in [url="https://twitter.com/#!/shurcooL/status/173110768726839296"]existing IDEs[/url].
-1

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1332264295' post='4923686']Static variables pretty much are global variables; they're just in a class and not a namespace.[/quote]

It's providing global [i][b]access [/b][/i]to state which makes global variables harmful. The whole point of adding things like static members to C++ is fine control over not just instancing, but access. So, no; Having the same sort of lifetime does not make them the same thing.

Granted, allowing all Widgets access to all hover data is not as safe as hiding data within each Widget instance, but design is about finding the best trade-off for you. In this case, giving access only to the Widgets doesn't seem unreasonable, and is a far cry from global accessibility.

But this approach does add look-up and management cost. Again, if per-Widget space is that important, then maybe it's worth the cost.
0

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1332265523' post='4923692']Unless each and every one of my widgets can be active and hovering independently, it makes no sense to store [this state data] inside each one.[/quote]

I don't think this is necessarily true. What if all but one could?

What if 75% could? 50%?

Yeah, there might be a more efficient way to represent the data - some way that has less redundancy - if only one, or only a few can be "active and hovering" at a time (like the way I described above). But only when we limit it to exactly one, can we say that per-Widget state data is completely redundant. And redundant per-Widget data wouldn't really add maintenance complexity.

Anyway, I realize that I didn't really answer the original question. Instead of coming up with a way to give list items access to an external resource, without a reference, I've proposed doing away with the external resource and moving the desired data into static class storage (in the case that [i][b]every [/b][/i]instance of a list item is interested in the same data).

Perhaps a solution more in line with your thinking, if you want some sort of render related processing to go through the Widgets, would be for that processing to go through the Widget Manager first. So instead of some other system telling the Widget to do render processing, and the Widget then looking to the WidgetManager for data, that other system could tell the Widget Manager to initiate processing for all of its Widgets, and the Widget Manager could pass each one whatever additional data it needs.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1332266324' post='4923694']
[quote name='Cornstalks' timestamp='1332264295' post='4923686']Static variables pretty much are global variables; they're just in a class and not a namespace.[/quote]

It's providing global [i][b]access [/b][/i]to state which makes global variables harmful. The whole point of adding things like static members to C++ is fine control over not just instancing, but access. So, no; Having the same sort of lifetime does not make them the same thing.
[/quote]

I'll have to disagree with you there. Global access is one of the things that makes global variables harmful, shared state is another. Privatly shared state can be just as bad if not worse. You're still limited to one instance, which can create all sorts of headaches, and you still need to make sure it's valid/reset it whenever you load a game or whatever. I'd say the shared state is the real problem with globals, not the global access (although, that is also pretty bad).
1

Share this post


Link to post
Share on other sites
[quote name='DvDmanDT' timestamp='1332270854' post='4923714']You're still limited to one instance...[/quote]

If you need more than one instance, I can see how only having one instance might be a problem. If we actually [i][b]have [/b][/i]this problem, we're doing something very wrong.

[quote name='DvDmanDT' timestamp='1332270854' post='4923714']...you still need to make sure it's valid/reset it whenever you load a game or whatever.[/quote]

Constructors and destructors should properly handle static data as well as dynamic storage. Proper setup/shutdown/reset/etc. is business as usual for both static and non-static member data. The two are not exactly the same, but managing static member data is not inherently tricky.

[quote name='DvDmanDT' timestamp='1332270854' post='4923714']...shared state is the real problem with globals, not the global access.[/quote]

Any time any object can trade information (get or set) with any other object, they're sharing state. Shared state is a given. The question is how state sharing is [i][b]restricted[/b][/i]. It's the fact that they're shared [i][b]globally [/b][/i](i.e. sharing of state is [i][b]not[/b][/i] restricted) that makes globals so problematic. Global access [i][b]is [/b][/i]the state sharing issue with globals.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1332276083' post='4923732']
[quote name='DvDmanDT' timestamp='1332270854' post='4923714']You're still limited to one instance...[/quote]

If you need more than one instance, I can see how only having one instance might be a problem. If we actually [i][b]have [/b][/i]this problem, we're doing something very wrong.
[/quote]
Surely you can't be serious?

[quote name='VReality' timestamp='1332276083' post='4923732']
[quote name='DvDmanDT' timestamp='1332270854' post='4923714']...you still need to make sure it's valid/reset it whenever you load a game or whatever.[/quote]

Constructors and destructors should properly handle static data as well as dynamic storage. Proper setup/shutdown/reset/etc. is business as usual for both static and non-static member data. The two are not exactly the same, but there's nothing inherently trickier about managing static member data.
[/quote]
Not quite. With statics, you get the joy of worrying about the static initialization order fiasco, you have to worry about locking/unlocking with multiple threads all sharing the same static variable, you limit the design of your program by saying all objects associate with one object, rather than certain objects being collected into logical groups (i.e. all Widgets share this value, rather than this group of Widgets sharing a value, and another group of objects sharing a different value), etc.

[quote name='VReality' timestamp='1332276083' post='4923732']
[quote name='DvDmanDT' timestamp='1332270854' post='4923714']...shared state is the real problem with globals, not the global access.[/quote]

Any time any object can trade information (get or set) with any other object, they're sharing state. Shared state is a given. The question is how state sharing is [i][b]restricted[/b][/i]. It's the fact that they're shared [i][b]globally [/b][/i](i.e. sharing of state is [i][b]not[/b][/i] restricted) that makes globals so problematic. Global access [i][b]is [/b][/i]the state sharing issue with globals.
[/quote]
Not quite. If I understand what you're saying here, state is copied, not shared. There's a difference.

[edit]

For the record, yes, there is a minor difference between a static and normal global variable (like you said, visibility). But that's quite small. You could easily just take out the static, make a global in a private implementation header and source files, and only use it in the class, and bam, you've got virtually the exact same thing. Sure, making the variable less visible by making it protected/private in a class helps, but it doesn't fix the problem. It just masks it.
0

Share this post


Link to post
Share on other sites
[quote name='Cornstalks' timestamp='1332276888' post='4923738']With statics, you get the joy of worrying about the static initialization order fiasco.[/quote]

[EDIT: The standard states, "Zero-initialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. Objects of POD types (basic.types) with static storage duration initialized with constant expressions (expr.const) shall be initialized before any dynamic initialization takes place." In other words, if initialization involves only "constant expressions" (i.e. no function calls, object creation, references to other statics, etc.), this is a non-issue.]

[quote name='Cornstalks' timestamp='1332276888' post='4923738']you have to worry about locking/unlocking with multiple threads all sharing the same static variable.[/quote]

As you would with any resource used by multiple threads. If you spread processing on this list of Widgets over multiple threads, and stored hover states in a single place, then you would have this threading issue regardless of how or why you arrived at the shared resource.

[quote name='Cornstalks' timestamp='1332276888' post='4923738']you limit the design of your program by saying all objects associate with one object, rather than certain objects being collected into logical groups (i.e. all Widgets share this value, rather than this group of Widgets sharing a value, and another group of objects sharing a different value), etc.[/quote]

Again (as seriously as I can state it), if this is a design decision we're actually making, then this is not a problem. The only way this can be a problem is if we need one design and yet choose another. This is nonsensical.

[quote name='Cornstalks' timestamp='1332276888' post='4923738']If I understand what you're saying here, state is copied, not shared.[/quote]

By shared you mean multiple parts of the program can write to it? And by copied you mean that most parts can't? Globally "copy-able" data is all that's required for side effects to grow out of control over time (again, this [i][b]is [/b][/i]the problem with "globals").

As for non-global shared resources - some data set which multiple objects read and write - they're a fact of life whether they're in static members or not. I can understand why you would want to minimze them, but they don't rise to the trouble level of globally visible state, and you'll have them either way.
0

Share this post


Link to post
Share on other sites
[quote name='VReality' timestamp='1332281553' post='4923754']
The only way this can be a problem is if we need one design and yet choose another.
[/quote]

Requirements change. This is a known fact of pretty much all software since the beginning of time. What design you need is based of off [i]need[/i], not any decision you make.
0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0