Global variables

In article <V1m4e.1136$vV3.610@fe04.lga>, brighamandrew@msn.com says...

> I need advice on when to use global and when not. I've always been taught to
> avoid useing globals as much as possible but recently since I've stepped
> into video game programming, I've heard that it's ok or "more accepted". I
> need a guideline for this matter, thanks.

Avoid them, unless you need them.

Why would you need them? Well, nobody will shoot you for having one
global object, on which you can string a few other variables or
functions that need to be accessed from all over. (For example, user-
selected interface options for a game.)

Other than that, though, it's hard to see the need. If you are passing
too much stuff up and down chains of functions, it may be better to
rethink your architecture rather than damaging encapsulation. Sooner
or later, you'll get a bug and realise that your program has turned
into spaghetti over time, and fixing it causes more bugs.

- Gerry Quinn

Tom Plunket wrote:

> It's best to put data where it belongs logically, for the
> programmers' sanity.

Tom, you ignorant slut!

Your sad fixation on this alleged "programmers' sanity" strawman argument
betrays nothing but your ignorance of modern software engineering! Why don't
you stop pretending to be a Real Game Programmer, and go back to Vermont and
play with your snowboard!

And because /I'm/ a REAL Game Programmer, and a published author, I can rant
and scream at anything I can pretend you said on the 'net, and it will make
me look respectable!

> I think that Singleton sucks.

Point. See /Working Effectively with Legacy Code/ by Satan. It says, on page
1,413, "Singleton sucks". Hence, read the page and learn more about why one
might decide it does.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Sorry- my response was a pretty
incomplete- thanx phillip.

nokturnal respect 4 phillip increases 100%

Phlip wrote:

>
> So: Time them and see. The C++ thought leaders, such as James Kanze,
> order their troups to never ever inline unless profiling reveals a real
> need.
>

I'll castigate every inline directive I see in our codebase. We have
some in the very low level point, vector and matrix geometry classes but
outside of that NO! Unless I get a profile or quantify report showing
that inline will speed up the method for every class I see with an
inline a task gets raised to remove and outline.

lilburne wrote:

> I'll castigate every inline directive I see in our codebase.

Except for the template libraries, like STL, where the opposite is true:
Everything and its granma is inline ;-)

> We have
> some in the very low level point, vector and matrix geometry classes but
> outside of that NO! Unless I get a profile or quantify report showing
> that inline will speed up the method for every class I see with an
> inline a task gets raised to remove and outline.

Way.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Phlip wrote:

> lilburne wrote:
>
>
>>I'll castigate every inline directive I see in our codebase.
>
>
> Except for the template libraries, like STL, where the opposite is true:
> Everything and its granma is inline ;-)
>


(un)fortunately we built our container stuff using the generic macros
years before templates and the STL became available. But I take your
point. Now if I could find a generic way of having templates without the
inline mess. Otherwise long handled spoons and all that.


>
>>We have
>>some in the very low level point, vector and matrix geometry classes but
>>outside of that NO! Unless I get a profile or quantify report showing
>>that inline will speed up the method for every class I see with an
>>inline a task gets raised to remove and outline.
>
>
> Way.
>

It normally only takes two or three such tasking to eradicate someone's
propensity to inline.

lilburne wrote:

> (un)fortunately we built our container stuff using the generic macros
> years before templates and the STL became available.

FORTUNATELY, they are stable and installed, and you have no need to touch
them, or cause cascading recompiles.

> But I take your
> point. Now if I could find a generic way of having templates without the
> inline mess. Otherwise long handled spoons and all that.

It's not a mess. Either you have everything inline and you out-of-line at
need, or you out-of-line everything and inline at need.

Out-of-line provides a compilation firewall. You need that anyway, so get it
with overt techniques like Dependency Inversion Principle.

> >>We have
> >>some in the very low level point, vector and matrix geometry classes but
> >>outside of that NO! Unless I get a profile or quantify report showing
> >>that inline will speed up the method for every class I see with an
> >>inline a task gets raised to remove and outline.
> >
> > Way.
>
> It normally only takes two or three such tasking to eradicate someone's
> propensity to inline.

Do you crack down on globals?

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Phlip wrote:

>
> Do you crack down on globals?
>

Yes and no.

We have a group of singleton classes at the top of the application which
the command processor interacts with. So there will be a singleton class
that processes wireframe geometry commands, and a singleton class that
processes machine tool commands. Which get directed to instances of
wireframe packages, or machine tools, etc. A singleton class that
interfaces to the natural language translation database. Below the
'command processing layer' we root out globals, no communication of data
is allowed via globals.

"Andy White" <brighamandrew@msn.com> wrote in message
news:V1m4e.1136$vV3.610@fe04.lga...
> I need advice on when to use global and when not. I've always been taught
to
> avoid useing globals as much as possible but recently since I've stepped
> into video game programming, I've heard that it's ok or "more accepted". I
> need a guideline for this matter, thanks.

The best response is, it depends. If you can't make a
strong case for a global value, don't make it global.

It also depends on what language/OS/hardware you are
programming, as well as the customary styles thereof.

If you find yourself passing a value into every function
call, or deriving it repeatedly (and its value doesn't
change), well, it might be a candidate for being global.
(A standard temp directory path, for example.) I wouldn't
start out making things global, though, unless you've
had enough experience to recognize a few standard values
as likely.

If you do use one or two, treat them as read-only except
as a very special case (during initialization, for
example).

FYI: I've seen a number of programmers who dislike
globals turn right around and create the functional
equivalent using whatever features their language
supports to hide the fact that it is, essentially, a
global value with nearly all the faults that implies.
Nothing wrong with that, but don't get all righteous
about it :-)

-Wm

Andy White wrote:
> I need advice on when to use global and when not. I've always been taught to
> avoid useing globals as much as possible but recently since I've stepped
> into video game programming, I've heard that it's ok or "more accepted". I
> need a guideline for this matter, thanks.

I think with video game programming, you have several different
requirements:

1) near-realtime speed
2) everything influences everything else
3) simultaneous use of multiple data structures

The rule I use in game programming (not that I've done a _lot_ of it,
mind you) is to use local variables when possible, but not rigidly. The
main lifecycle functions act mostly on globals, while the individual
functions act mostly on locals. For example, redraw(), move(), and
check_for_events() use global variables, but is_colliding uses only
locals.

Basically, in games, there is a lot of nonlocal interaction (killing a
person may cause a door to open, or you to win a level), and the only
way to do it with only local variables is to pass the entire world as a
local variable, which defeats the point of local variables anyway.

An alternative is to create a World class which holds everything, and
pass it as a parameter. This may or may not be useful or appropriate
for your game.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017