Talk:Global variable

Disagree that global variables to be merged into scope of programming because there's other meaning of global variables for different field, such as economic, sustainable development.

I also disagree with the merge. While scope is very relevant to global variables, the term "global" refers specifically to the widest scope, and use of that particular scope level should be restricted. The two topics are, however, connected, and the articles should definately reference each other. scot 16:51, 3 November 2005 (UTC)[reply]

Removed this obviously incorrect paragraph

"The use of global variables is particularly bad for functional programming languages (such as Haskell). It violates referential transparency and makes it very difficult to analyze code."

It should be obvious that global variables can cause absolutely no problems with functional programming and they cannot violate referential transparency because in functional code they are immutable (as in Haskell).

They also don't increase the difficulty of code analysis.

The only place that global variables can violate referential transparency is in non-functional programming where they are mutable, and this has nothing to do with being global -- it has to do with their being mutable.

Local variables can also violate referential transparency in these situations. e.g.

(let ((a 1) (b 0))
  (define (foo)
    a)
  (set! b (+ b (foo)))
  (set! a 2)
  (set! b (+ b (foo))))  —Preceding unsigned comment added by 203.222.167.145 (talk) 04:04, 30 November 2010 (UTC)[reply]

The scheme reference is incorrect

(a) Scheme is a procedural language.

Changed to Haskell Traxer (talk) 17:03, 3 November 2010 (UTC)[reply]

(b) Global variables do not affect referential transparency any more than local variables (see lexical closure).

Yes, they do. When a call f(x) to a function f modifies a global variable, that function call cannot be replaced by the value returned by f, because calls (to f or other functions) might return different values due to the global variable having a different value than when f(x) was actually executed. Traxer (talk) 17:03, 3 November 2010 (UTC)[reply]

And the same applies to local variables captured via lexical closure. Being global is irrelevant to this.

 (let ((a 10))
   (lambda ()
     (set! a (+ a 1))
     a))

The problem is due to free variables in the presence of mutation. Global scope is completely irrelevant.

—Preceding unsigned comment added by 203.222.167.145 (talk) 08:20, 12 November 2010 (UTC)[reply]

C++ Example is incorrect

Just thought I would mention that in the example provided, int global is not truly "global" in scope but merely at file scope, which is the widest scope possible in C++ (and C). Oddity- (talk) 17:45, 8 November 2009 (UTC)[reply]

This is incorrect. A variable which is not declared static has external linkage, it is truly global, accessible by any module in the system. Another module can declare extern int global to reference the same global. Omitting the extern keyword in this case would result in a linker error (duplicate global).

Wrong. Linkage is not scope.

foo.c

int foo;

bar.c

/* Oh, look -- foo is not in scope here */ int bar(void) {

 extern int foo;
 /* Ok, look -- foo is a local variable here */

}

A file scope variable (e.g. static int global) is visible only within the module in which it is defined. EricTetz (talk) 03:27, 10 July 2010 (UTC)[reply]

static and global in C

What is the semantical difference in C between a global variable (being declared as int a) and a static global variable (being declared as static int a, see static variable)?
Thanks, --Abdull (talk) 17:22, 7 January 2010 (UTC)[reply]

See above. A static variable defined at file scope accessible only within the module in which it is defined, a non-static variable defined at file scope is visible to the entire program. See above. You are wrong. Linkage is not scope. EricTetz (talk) 03:27, 10 July 2010 (UTC)[reply]

Protected memory versus read only

Surely global variables are safe if they are rendered read only by any mechanism, including compilers and interpreters enforcing them as read only irrespectively of implementation details? 1Z (talk) 17:26, 16 July 2011 (UTC)[reply]

System versus global versus file level sscope

"where each file defines an implicit namespace eliminate most of the problems seen with languages with a global namespace "

File level namespaces per se don't eliminate any problems. If globals are enforced to be read only, action at a distance becomes impossible. However, it is perfectly possible, naturally or artificially, for an entire programme to reside in one file , so that file scope = global scope.

What's more, there are scopes wider than programme scope. Environment variables in *nix systems can apply to any number of processes with a commmon ancestor.Of course they are safe because they cannot be written to non-locally (writes only propagate down to grandchildren). 1Z (talk) 17:46, 16 July 2011 (UTC)[reply]

Corresponding simulation aspects of global variables vs bed file direction of global variables

The article lacks fundamental descriptions between field uses. A well rounded global variables library for bed file i/o functionality, Staqtapp library @github, actually improves merge accuracy regarding descriptions point to point of global scopes if advanced implemented; or customized to the calling mechanics that could change. This change functionality is not a precedent limit of represented simulation of the merged variable definitions definitely as the article suggests repeatedly. Lastforkbender (talk) 20:28, 15 December 2023 (UTC)[reply]