I re-read Tyche's contributions to this thread and find no basis for the above observations.

He is, as usual, succinct, and on point.

Some of his "fancy terms", if one takes the time to look them up, may teach one something new.

If you don't think a post or a poster is fruitful, find one that you think is, and steer the discussion towards it. Useless bickering over who's a troll far exceeds the damage done by any actual trolling.

I looked at TeensyMud and there's one global, and it's only referenced in the line after it's defined.
Doesn't even need to be declared. Of course there are quite a few ruby built-in globals.

However, all locals in ruby are globals including those on the stack (other than immediate values).

Check this out…

def afunction
  a = "xyzzy"
  puts a
  change_local_a
  puts a
end

afunction

$ ruby globals.rb
xyzzy
plugh

Function change_local_a
Spoiler

And if course all automatics in C are allocated on a global stack and can also be accessed from anywhere in your program.

Try http://en.wikipedia.org/wiki/Algorithmic...

The stuff of real life coding? Have you ever been hired to maintain software (or a system) previously designed by one or many programmers who each had their own views on paradigm efficiency and locality and globals? Have you ever been hired in that position and discovered that they didn't document things well?

I know hobbyists are all about "real world coding" like MUDs and MUD clients - but schools are conducting business under the impression that after school you'll be going to "fantasy land" where you have a job maintaining legacy code for existing software systems.

I re-read Tyche's contributions to this thread and find no basis for the above observations. He is, as usual, succinct, and on point.

Some of his "fancy terms", if one takes the time to look them up, may teach one something new.

..but I wanted to clarify, by 'good point' I meant 'you should re-read all of my posts and your 'responses' to them while reflecting on the advice you just gave me'.

The stuff of real life coding? Have you ever been hired to maintain software (or a system) previously designed by one or many programmers who each had their own views on paradigm efficiency and locality and globals? Have you ever been hired in that position and discovered that they didn't document things well?

I clearly and openly stated I was going to troll you.

You think posting childish, insulting pictures and mocking posters is "succinct", "on point" and "fruitful"?

About six months ago I wrote some javascript that "skins" the site by filtering out features and posts/quote blocks coming from a particular source. It makes most threads 25-50 percent shorter and eliminates any temptations to respond to the deliberate misinterpretations and mischaracterizations of what I and other posters have written.

Share?

I'd very much like a copy as well please Tyche, if you're willing to share. I've asked several times for an "ignore" feature, and at one point it looked like it might be added, but by now I'm willing to try pretty much anything short of painting TipEx on the screen.

[offtopic]

Sounds like a job for a greasemonkey script. Is that what you used?

Maybe a new thread is in order…

[/offtopic]

If you disagree with his view

[link=post]47606[/link]

Works beautifully :D

Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.
Objects with static storage duration, including global variables, static variables, static class member variables, and function static variables, must be Plain Old Data (POD): only ints, chars, floats, or pointers, or arrays/structs of POD.

The order in which class constructors and initializers for static variables are called is only partially specified in C++ and can even change from build to build, which can cause bugs that are difficult to find. Therefore in addition to banning globals of class type, we do not allow static POD variables to be initialized with the result of a function, unless that function (such as getenv(), or getpid()) does not itself depend on any other globals.

Likewise, the order in which destructors are called is defined to be the reverse of the order in which the constructors were called. Since constructor order is indeterminate, so is destructor order. For example, at program-end time a static variable might have been destroyed, but code still running – perhaps in another thread – tries to access it and fails. Or the destructor for a static 'string' variable might be run prior to the destructor for another variable that contains a reference to that string.

As a result we only allow static variables to contain POD data. This rule completely disallows vector (use C arrays instead), or string (use const char []).

If you need a static or global variable of a class type, consider initializing a pointer (which will never be freed), from either your main() function or from pthread_once(). Note that this must be a raw pointer, not a "smart" pointer, since the smart pointer's destructor will have the order-of-destructor issue that we are trying to avoid.

Prefer nonmember functions within a namespace or static member functions to global functions; use completely global functions rarely.

Pros:
Nonmember and static member functions can be useful in some situations. Putting nonmember functions in a namespace avoids polluting the global namespace.

Cons:
Nonmember and static member functions may make more sense as members of a new class, especially if they access external resources or have significant dependencies.

Decision:
Sometimes it is useful, or even necessary, to define a function not bound to a class instance. Such a function can be either a static member or a nonmember function. Nonmember functions should not depend on external variables, and should nearly always exist in a namespace. Rather than creating classes only to group static member functions which do not share static data, use namespaces instead.

Functions defined in the same compilation unit as production classes may introduce unnecessary coupling and link-time dependencies when directly called from other compilation units; static member functions are particularly susceptible to this. Consider extracting a new class, or placing the functions in a namespace possibly in a separate library.

If you must define a nonmember function and it is only needed in its .cc file, use an unnamed namespace or static linkage (eg static int Foo() {…}) to limit its scope.

Place a function's variables in the narrowest scope possible, and initialize variables in the declaration.
C++ allows you to declare variables anywhere in a function. We encourage you to declare them in as local a scope as possible, and as close to the first use as possible. This makes it easier for the reader to find the declaration and see what type the variable is and what it was initialized to. In particular, initialization should be used instead of declaration and assignment, e.g.

int i;
i = f();      // Bad – initialization separate from declaration
int j = g();  // Good – declaration has initialization

Note that gcc implements for (int i = 0; i < 10; ++i) correctly (the scope of i is only the scope of the for loop), so you can then reuse i in another for loop in the same scope. It also correctly scopes declarations in if and while statements, e.g.

while (const char* p = strchr(str, '/')) str = p + 1;

There is one caveat: if the variable is an object, its constructor is invoked every time it enters scope and is created, and its destructor is invoked every time it goes out of scope.

// Inefficient implementation:
for (int i = 0; i < 1000000; ++i) {
  Foo f;  // My ctor and dtor get called 1000000 times each.
  f.DoSomething(i);
}

It may be more efficient to declare such a variable used in a loop outside that loop:

Foo f;  // My ctor and dtor get called once each.
for (int i = 0; i < 1000000; ++i) {
  f.DoSomething(i);
}

Avoid global variables.

Definition:
Variables that are declared at the module level.

Pros:
Occasionally useful.

Cons:
Has the potential to change module behavior during the import, because assignments to module-level variables are done when the module is imported.

Decision:
Avoid global variables in favor of class variables. Some exceptions are:

Default options for scripts.
Module-level constants. For example: PI = 3.14159. Constants should be named using all caps with underscores; see Naming below.
It is sometimes useful for globals to cache values needed or returned by functions.
If needed, globals should be made internal to the module and accessed through public module level functions; see Naming below.

"Don't use global variables" is kind of a stylistic choice.

If you're learning to program and planning to write non-trivial software, it's understood to be a "safe" and "proven" stylistic choice.

Tyche seems to think that finding any reason to support that stylistic choice makes a person ignorant, inferior, "going through a phase" or possessive of some other undesirable characteristic and that arguing against that stylistic choice by making attacks on the persons holding that view is somehow demonstrative of a superior understanding of both programming and social behavior.

Programmers are constrained not just by conscious application of rules and procedures, but also by
taboos that they have acquired as part of their formal education or informally from colleagues. These
taboos usually embody perceived sound advice and have generally been concerned with the breaking
of abstraction boundaries. However their effect can be to needlessly restrict the range of solutions to
design problems that programmers consider. This paper examines a set of common programming
taboos, and addresses both social aspects and technical reasons as to why programming taboos have
arisen.

It is like butchers banning knives because workers sometimes cut themselves.

The results show that, while most global variables have essentially no impact on program dependence, there are a few that have a large and significant effect. Moreover, though there may be few such global variables, many programs (more than half those studied) have at least one such significant variable.

For my mud I use a global data structure called mud, so I've got mud->time, mud->first_player, mud->first_area, etc, about 80 nested variables total, and 1 global variable. It gives the ease of use of global variables, without the worry about rogue variables.