global variables are bad?

[Richard G. Riley]

Why do you think that it isn't helpful to newbies to learn the Standard
terminology?

Of course it is : when appropriate. A 3 page discourse on "globality"
in C is not necessarily a good idea when they are asking about
"global" versus "locals":

As for this terminology, "global" is a term which I suspect 99% of C
programmers recognise. There really is no need to be overtly clever
about it. There might not be a keyword, but it is a concept : one
which C supports/enables whichever way wou want to look at it or
represent it.

Didn't look like it to me. Not /only/ on post count, anyways.

Its not the first time. There is a trend here amongst certain posters
to do just that.

I look back through this thread and stick with my initial assertion
that the subject was unnecessarily muddied for a new programmer. This
is comp.lang.c : not comp.std.c where more anal tendencies are
embraced like a new born child.

 

[Chris Dollin]

I look back through this thread and stick with my initial assertion
that the subject was unnecessarily muddied for a new programmer. This
is comp.lang.c : not comp.std.c where more anal tendencies are
embraced like a new born child.

The topics of discussion are different: std.c is about the standard;
lang.c is about the standardised language.

So, whether or not std.c is "anal" (which, in my experience, is usually
a pejorative way of saying "precise") shouldn't really affect how we
discuss matters in lang.c.

["New" programmers don't have a /clue/ what a big, round variable
might be.]

 

[Richard G. Riley]

The topics of discussion are different: std.c is about the standard;
lang.c is about the standardised language.

So, whether or not std.c is "anal" (which, in my experience, is usually
a pejorative way of saying "precise") shouldn't really affect how we
discuss matters in lang.c.

You're right : but sometimes discussing "real issues" that real
programmers have with clipped precise textbook quotes is "anal" and
unhelpful. Not everyone can understand that type of direction : I can
still remember a situation where a new programmer was "let go" and it
was only after the dismissal that it filtered up that he couldnt
understand a word his team leader told him : all "precise" and
"proper" but unless you had a PhD in company acronyms and
businessspeak you might as well have been listening to an ET. Precise
has its moments : dont get me wrong.

["New" programmers don't have a /clue/ what a big, round variable
might be.]

New programmers often have a lot of ideas : some right, some wrong -
it is often difficult to glean just how much they do or do not
know. But when someone asks a question about "why globals are bad" in a
C language group it is only common decency to assume he

1) means it in the context of C, and
2) he means C globals as we all know them : regardless of specifics of
linkage : any C programmer knows what a "global" is unless they are so
precise that they have lost touch with the real world.

Of course as a footnote you might add, "oh. btw, have a look at this
which discusses the various issues with externals/globals in C".

Not doing the above, suggests to me, oneupsmanship

 

[Laurijssen]

It sounds like it -- otherwise paying for me to come over and
fix it would certainly be a waste of time ;-)

nonono, there's no payment involved, dont think I mentioned that
If you insist I'll buy you a beer after.

Anyway, sarcasm aside, there's a reason that some programmers use this
guideline for external variables. Programmers have many different
backgrounds and defining terms so people who use different programming
languages can still understand each other is a good thing IMO.

 

[Richard Heathfield]

cappeca said:

Which is not very helpful for newbies, now you know.

I disagree. As I just explained, it's easier to learn C properly if you're
talking the same language as the people helping you. It is a good idea to
adopt standard terminology early rather than late.

WTF? You're passing judgement on people based on post count?

I'm not passing judgement on anyone. Note the "if" in that paragraph. Who is
passing judgement? Not me.

 

[Michael Mair]

nonono, there's no payment involved, dont think I mentioned that
If you insist I'll buy you a beer after.
*g*

Anyway, sarcasm aside, there's a reason that some programmers use this
guideline for external variables. Programmers have many different
backgrounds and defining terms so people who use different programming
languages can still understand each other is a good thing IMO.

Of course -- the (probably well-hidden) point is that C is
not exactly the most forgiving of all languages to program,
say, BASIC in.
If programmers with different backgrounds and expertises
work together, everyone of them needs a "working knowledge"
of the language and has to agree on the same definitions;
even if you, after all, call entities with certain properties
"global variables", everyone should know what that means
exactly in the C context or -- if you work in a multilingual
environment -- how the concept of "global variable" maps to
the C language and whether C offers finer distinctions or
even throws together certain "variable kinds".
This is what motivates such a bold claim as the above ("There
is no such thing as a global variable in C."): to get people
to think about and clearly define the concept and its "C
stamping" -- especially as there is no standard or even
common-enough definition (for every definition you offer,
someone will come along and ...)


Cheers
Michael

 

[CBFalconer]

John Devereux wrote:
.... snip ...

It's a bad idea to have a variable *definition* in a header file.

If you keep the purpose of header files in mind you will have no
difficulty. They provide access to something. That may be some
functions or definitions needed to access and interface with a
module (a .c file, or compilation unit). They should have nothing
not required for that purpose. This is not spelled out in the C
standard, but is simply a matter of good practice.

Some newbies seem to feel that headers are a place to collect
prototypes and definitions. If those prototypes and definitions
are not used outside of the .c file, this is poor practice. In the
same vein functions in the .c file that are not called externally
should be marked static, thus limiting their scope. Again, this
practice is not spelled out in the C standard.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net> (C-info)