l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2002 Sep 20 14:33

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] global variables in C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] global variables in C



On Fri, 20 Sep 2002, Peter Jay Salzman wrote:

> 
> ok, first i'd like to apologize for bringing up such a tired subject,
> but i'd like to understand this better.
> 
> 
> conventional wisdom says that you should avoid using globals.
> 
> reading through some C books like the deitel book which is used at UCD
> and SAMS "C primer plus", i find that they don't really address this
> issue at all.  when i talk to people, i hear the same two reasons over
> and over:
> 
> 1. name clashing
> 2. readability
> 
> what i'd like to know is if this is all there is.  are there more
> reasons why we should follow conventional wisdom?  or is this more of a
> guiding principle and not something to be followed blindly?   it seems
> like for some applications, like GUI and multi-thread programming, the
> use of globals can really simplify things a lot.
> 
> please no sarcasm or flames -- just lucid explanations.  i'd like to
> understand this better.

I can't promise lucidity... :)

Not using globals is not a hard and fast rule.  EVERY program uses some
globals... even if only in the underlying runtime.

However, I think the key issue is the number of routines that directly
access those variables.  Having a large amount of code dependent on a
variable makes changing the semantics of that variable's use difficult...
you have a lot of dependent code to examine and possibly change.  Also, it
means many code module compilations depend on one module that contains
that variable, so if you do change it then the recompilation can become a
serious time eater in development (in hundred-thousand-line programs and
up, this is not to be laughed at!).

As for multi-threading... globals can be necessary, but they also couple
the threads.  When one thread starts changing that global, any other
thread needing access has to block... turning a multi-threading program
into an inefficient single-threaded program.  And if you try to turn a
single-threaded program that has non-atomic globals in it into a
multi-threaded program, you may dearly regret thinking globals were a good
idea because it will lack appropriate semantics for blocking reads during
writes.

As for GUI... see my response to Bill.

Never say never to globals... but if you can avoid them you can avoid
numerous problems down the line.  At least try using statics if you think
you need globals.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.