Is it a good habit to use global variables in member functions?

[northfly]

what do you think?

[MiiNiPaa]

No. It does not matters if it is member or freestanding function. All arguments againt still apply.

[northfly]

But scientific computing really don't want the big chunk of data transfer here and there. How did the industry solve this problem? Thanks.

[MiiNiPaa]

Pointers References and smart pointers.

[JLBorges]

Global variables are fine (and in many cases preferable) as long as their programmatic visibility is limited to the implementation.

This:

struct A // header
{
      // ...
      static int foo( int arg ) ; 

      private: static int s ;
     // ...
};

// implementation
int A::s = 0 ;

int A::foo( int arg ) { return s += arg ; }

has worse coupling than:

struct A // header
{
      // ...
      static int foo( int arg ) ; 

      // private: static int s ;
     // ...
};

// implementation
// int A::s = 0 ;
namespace { int s = 0 ; } // internal linkage

int A::foo( int arg ) { return s += arg ; }

[MiiNiPaa]

Well this is not global variables. More like file-scope ones.

All argument for or against global/file-scope etc. still apply no matter where they are used.

Global variables are like goto: useful in specific cases but I cannot say that it is a good habit.

[JLBorges]

> Well this is not global variables. More like file-scope ones.

There is no scope called file-scope in C++. It is a variable at namespace-scope.

The outermost declarative region of a translation unit is also a namespace, called the global namespace. A name declared in the global namespace has global namespace scope (also called global scope). -IS

A variable declared at namespace scope may have either internal linkage (as in the example above)
or external linkage (as for std::cout).

[BHX]

Okay, the way I understand it:

// namespace scope

// this is frowned upon due to being able to accidentally change it 
// later in the code and not catch it, causing all kind of bugs
int SCREEN_W = 640;  
             
// this is perfectly fine because it is constant and can't be 
// changed to cause unexpected bugs                      
const int SCREEN_H = 480;

I use constant globals regularly. I think the thing that most frown on is what I pointed out, the issue of changing the non-const globals which can lead to bugs.

// collision detection code messed up
// checking to see if the screen width is 
// equal to the right wall of a sprite (object a member x + objec width
if (SCREEN_W = ObjA.x + w){  // meant to do == instead of = so changed 640 to new value (say 64)
      //...... 
      // now anything dealing with SCREEN_W will cause funky
     // screens, bugs, or possibly crashes
}

[JLBorges]

Changing non-const globals is a manifestation of the fundamental issue:
programmatic visibility of variables ant namespace scope leading to tight coupling.

int a = 640; // programatically visible and changeable from other translation units.
// tight coupling

extern const int b ; // programatically visible in other translation units.
const int b = 640 ; //  but not changeable
// still not ideal because someone could write code relying on 'b' being defined
// or worse: relying on 'b' having a value of 640
// looser coupling
  
static int c = 640 ; // programatically not visible in other translation units.
// that there is a global 'c' is an implementation detail that is not visible to other components.
// no coupling