Globals

[Matt]

Hello,
I'm rather new to C++ and have a question about globals. What is the
big deal about them? They make things much easier to program because
you don't have to worry about all the passing back and forth between
functions. And, if you are going to give the reason about "it makes
it easier to debug your program if you don't use globals" well to that
I say, how so? Yes, not using globals prevents a random function
from setting values, but on functions where I am passing data back and
forth to the variable, I can still get into just as much trouble as if
it was defined globally... I guess I don't understand.... what's the
big deal about globals?

 

[Karl Heinz Buchegger]

Hello,
I'm rather new to C++ and have a question about globals. What is the
big deal about them? They make things much easier to program because
you don't have to worry about all the passing back and forth between
functions.

They make things much harder to program, because you never know if
a function you are calling is altering a global or not.
Passing parameters to functions isn't a problem at all. It's just
typeing. But typeing is the least of your problems when programming.

And, if you are going to give the reason about "it makes
it easier to debug your program if you don't use globals" well to that
I say, how so? Yes, not using globals prevents a random function
from setting values, but on functions where I am passing data back and
forth to the variable, I can still get into just as much trouble as if
it was defined globally...

You don't. If you don't pass a variable to a function, then the function
(and the functions it calls and the functions they call ...) has no way
of altering that variable. Plain and simple.

I guess I don't understand.... what's the
big deal about globals?

In short programs (toy programs), probably nothing.
But in medium to large projects (from 100 to 1000000 lines of code
and above) they *are* a problem. You call a function and as a result
you have no idea which global variables have changed state in which
way and worse: Which function made the change?

So best: Don't get in the habit of using them from the beginning and
they won't bite you.

 

[Phlip]

I'm rather new to C++ and have a question about globals. What is the
big deal about them? They make things much easier to program because
you don't have to worry about all the passing back and forth between
functions. And, if you are going to give the reason about "it makes
it easier to debug your program if you don't use globals" well to that
I say, how so? Yes, not using globals prevents a random function
from setting values, but on functions where I am passing data back and
forth to the variable, I can still get into just as much trouble as if
it was defined globally... I guess I don't understand.... what's the
big deal about globals?

What's the largest program you have seen its source?

If you saw a 10-million line program, how do you know which of those lines
changed the variable and added a bug?

 

[Matt]

What's the largest program you have seen its source?

If you saw a 10-million line program, how do you know which of those lines
changed the variable and added a bug?

But that's my point. If I passed the variables into the function,
then it will be able to change anyway.. and if I didn't and it was a
mistake on my end, well then shame on me... A line should not be
changing a variable unless I put something in there to make it
change.... and if I did then I had some reason to do that... and if I
didn't then sham eon me.. I don't care how big your program is... the
same rulesshould apply. PHP and perl don't have this issue.. why does
C++? it seems, to me at least, like C++ has several disabilities like
this one that modern languages don't suffer from.

 

[lilburne]

But that's my point. If I passed the variables into the function,
then it will be able to change anyway.. and if I didn't and it was a
mistake on my end, well then shame on me... A line should not be
changing a variable unless I put something in there to make it
change.... and if I did then I had some reason to do that... and if I
didn't then sham eon me.. I don't care how big your program is... the
same rulesshould apply. PHP and perl don't have this issue.. why does
C++? it seems, to me at least, like C++ has several disabilities like
this one that modern languages don't suffer from.

As he said you definitely haven't seen a 10-million line
pearl or PHP program. Probably not even a 10,000 line one
either.

 

[Karl Heinz Buchegger]

But that's my point. If I passed the variables into the function,
then it will be able to change anyway..

If you pass a variable to a function then either you want
* the function to use that value for some computations
* the function to alter that variable.

In any case: the shere fact that you pass something to a function documents
that intent.
Using only global variables the situation is different. You call the function.
End of story. What variables get used? what variables get changed? Nobody knows
unless you have written the function on your own in the last 3 days. If you
didn't write that function or you wrote that function half a year ago: Welcome
to the analyze board: In order to use that function you have to analyze the
inner workings of that function (and hopefully you get this analyze correct
the first time .

and if I didn't and it was a
mistake on my end, well then shame on me... A line should not be
changing a variable unless I put something in there to make it
change....

Good luck.
Search and find in a 10 million lines program where exactly a global
variable gets the value you see in the debugger. You call a function
and when the function returns 10 global variables have changed their
value, but one of them shouldn't. Hmm. Where did it change? (The
function calls other functions which by themself call other functions etc...)

and if I did then I had some reason to do that... and if I
didn't then sham eon me.. I don't care how big your program is...

You should.
Things that work in toy programs and are acceptable there
don't work any longer and are not acceptable in larger programs.
You will learn that eventually.

the
same rulesshould apply.

You forget one thing: we are all human. We make mistakes. Our brain
has a border on how many things it can remember at once.

PHP and perl don't have this issue.. why does
C++?

It is not an issue of perl or PHP or C++ or ...
It is not a language problem. It is a problem with us, the
programmers! We, the humans are not able to manage and coordinate
that many informations found in real world programs. The only
way we can deal with this complexity is a devide and conquer
strategie: Divide the whole program into modules. Divide modules
into functions. Give each function its own variable space such that
the individual functions and modules don't interact with
each other except in documented and known ways: the function arguments
and return values.

it seems, to me at least, like C++ has several disabilities like
this one that modern languages don't suffer from.

C++ has several disabilities but this is not one of it.
C++ has global variables. But not using them is simply an agreement
and millions of programmers have found this a good agreement.
Of course there are excpetions but they should stay what they
are: exceptions which are rarely used.

 

[Adam Fineman]

If I passed the variables into the function,
then it will be able to change anyway..

'It' meaning the variables you passed into the function? Only if they
were non-const references or pointers to non-const. Otherwise, the
calling function would not see any changes to these variables.

A line should not be
changing a variable unless I put something in there to make it
change.... and if I did then I had some reason to do that...

Or you made a mistake. Common bugs, such as off-by-one errors, can have
side effects that are much harder to isolate in the presence of globals.

This is a very basic concept. You really should read up on software
design. _Large Scale C++ Design_ and _Code Complete_ are excellent
title. Check out more book reviews at http://www.accu.org.

PHP and perl don't have this issue..

Of course they do. Both the languages you've mentioned provide for the
use of global variables, as well as scoped variables. The main
difference is that large projects don't tend to be written in scripting
languages so finding bugs associated with global variables is often
faster. This difficulty seems to increase exponentially with the size
of the project, so small projects written in scripting languages allow
developers to not think much about design.

- Adam

 

[Adam Fineman]

news:<[email protected]>...

I'm very sorry, Phlip. I attributed what Matt wrote to you.

I was responding to what Matt wrote in my previous post.

 

[Phlip]

I'm very sorry, Phlip. I attributed what Matt wrote to you.

No worries.

I /was/ looking for someone to e-stalk for the rest of my life, but I
let this one slide - this time!

 

[Micah Cowan]

But that's my point. If I passed the variables into the function,
then it will be able to change anyway..

Only if the parameter was passed by pointer/reference, and not
properly protected. This is programmer error. Otherwise, it is
not possible for the variable to be accidentally changed.

and if I didn't and it was a
mistake on my end, well then shame on me...

Shame on you, maybe: but we all make mistakes, including ones
with unintended consequences (such as changing a variable we
meant only to evaluate).

A line should not be
changing a variable unless I put something in there to make it
change.... and if I did then I had some reason to do that... and if I
didn't then sham eon me..

"Shame on you" is small consolation when you're poring through
tens of thousands of lines of code to find the solution.

I don't care how big your program is... the
same rulesshould apply. PHP and perl don't have this issue..

?!?!? In PHP and Perl this is still *very* much an issue. What
makes you think otherwise?

But I love that Perl at least has a mechanism for
variables with program-duration lifetime, but restricted scopes
(via the "our" keyword).

why does
C++? it seems, to me at least, like C++ has several disabilities like
this one that modern languages don't suffer from.

C++ is a very modern language. Don't forget that PHP and Perl
were both written using C: therefore it stands to reason that
anything that is possible with those languages is also possible
in C (and C++), if you include the system-specific extensions
that are relied upon by those languages (POSIX, for example).

 

[red floyd]

[ argument in favor of globals only redacted]

Just out of curiosity, how do you plan on handling recursion? Or multithreaded processing?

Why do you even need subroutines and functions, since you can write the code inline?

 

[Phlip]

I'm rather new to C++ and have a question about globals.

A global object is often called a Singleton.

Here's Mike Feathers ragging on why even high-level encapsulated
globals are bad:

P> I revile 'if' statements.

P> The OP appeared to identify the trouble "singleton", not the
trouble "cruft
P> caused by a singleton".

That was just shorthand. Mike Hill has seen an incredible number of
systems, doubtless with an incredible number of reasons to dislike
singletons.

P> Where's the cruft the singleton caused?

Not all singletons are terrible. In the most benign cases, you have a
singleton without mutable state, one that you can send messages to
over and over again without getting different answers or affecting the
state of the system via side effects. In those cases, the bad thing
is really the concrete dependency on the singleton. Because it is
concrete, you must have the singleton available when you are testing.
In some systems, this is a serious link-time dependency. In others,
where the singleton does substantial work, it's a serious running time
issue when you are testing.

The worse ones are singletons that house mutable state. These
singleton objects create singleton systems. When you use the
singleton, you are saying that the code that uses it is part of one
and only one system. You can't take the "using" code and create an
other instance of it that will run on the same VM or machine, run it
and expect the same results. You've taken any hope that you might
have of internally reusing those chasses and shot it in the foot.

There are teams who don't practice enough internal reuse (i.e.,
duplication removal) to care about that, so the other time that the
"singleton system effect" hits them is when they want to write tests
for a piece of code. At that point, they notice that they have a
singleton system. Why? When we test, we want each test to run in its
own little world, to be its own system. With a mutable singleton, you
are just stuck with the world that it defines, unless you do something
like use a static setter.

Looking for cruft? Look in test setups.. you have to remember which
singletons to set instances on. If you forget, you could be silently
leaking state from test to test. If you are writing tests to
characterize the behavior of the system so you can refactor, you may
not even know about the state leaks. Silent error.

I try not to rail too hard about singletons. Like "if"s they are fine
in moderation But, as a guy who goes around and helps people get
chunks of code under test, I see more than my share of trouble caused
by them.

Michael Feathers
www.objectmentor.com