Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualAardvajk

Posted 01 January 2013 - 01:17 AM

I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.

This view seems to be resurging around here at the moment. Some points...

If you are finding you need to pass a resource container around all over the place, there is something wrong with your design at a higher level. Making the container global state just masks this problem, it doesn't solve it. How many places should it be necessary to access a texture? A sound file? A script? What kind of extensible and robust design would require access to such things peppered all over the codebase?

One of the many problems with using global state is it makes it too easy to cut corners. I'm in the depths of my physics code and have an urge to play a sound when objects collide, or update a texture to show a hit mark. Easy to do and forget that I did later. But my physics code is now linked to my audio or rendering code in a way it needn't be. If the resources are not available, it forces me to stop and think of a less intertwined solution.

Nobody is suggesting the alternative to globals is to pass a pointer to some kind of state container into every function. This is a (real-world) anti-pattern that suffers from almost all of the issues that having global state can have in terms of design. The point is it is good to let the compiler and language enfore constraints about what can access what from where.

Robust and extensible code, we have learned over the years, is build from modular, black-boxed components that can be tested in isolation and interconnected in the minimal way required. Any design that moves away from this, whether it be global state, passing pointers around to a global container, singletons, whatever, is probably not going to lead to a maintainable design when projects grow out of triviality.

#1Aardvajk

Posted 01 January 2013 - 01:17 AM

<blockquote class="ipsBlockquote" data-author="JarkkoL" data-cid="5016238"><p>I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.</p></blockquote><br />This view seems to be resurging around here at the moment. Some points...<br /><br />If you are finding you need to pass a resource container around all over the place, there is something wrong with your design at a higher level. Making the container global state just masks this problem, it doesn't solve it. How many places should it be necessary to access a texture? A sound file? A script? What kind of extensible and robust design would require access to such things peppered all over the codebase?<br /><br />One of the many problems with using global state is it makes it too easy to cut corners. I'm in the depths of my physics code and have an urge to play a sound when objects collide, or update a texture to show a hit mark. Easy to do and forget that I did later. But my physics code is now linked to my audio or rendering code in a way it needn't be. If the resources are not available, it forces me to stop and think of a less intertwined solution.<br /><br />Nobody is suggesting the alternative to globals is to pass a pointer to some kind of state container into every function. This is a (real-world) anti-pattern that suffers from almost all of the issues that having global state can have in terms of design. The point is it is good to let the compiler and language enfore constraints about what can access what from where.<br /><br />Robust and extensible code, we have learned over the years, is build from modular, black-boxed components that can be tested in isolation and interconnected in the minimal way required. Any design that moves away from this, whether it be global state, passing pointers around to a global container, singletons, whatever, is probably not going to lead to a maintainable design when projects grow out of triviality.

PARTNERS