global variables are bad?

[fabio]

Why? i' ve heard about this, the usage of global vars instead of
locals is discouraged, but why?
thx :)

[Michael Mair]

fabio schrieb:

Why? i' ve heard about this, the usage of global vars instead of
locals is discouraged, but why?

There is no such thing as a global variable in C.
What you probably mean is a variable with static storage duration
and external linkage. Why make such a fuss about denomination? The
storage duration and the linkage determine different sides of
"global".

Linkage: External linkage (implies file scope and) means that the
identifier (the "variable name") must be the only one with exactly
this name and linkage throughout the whole programme. As soon as
there is a declaration of the variable in scope, it is "visible"
and accessible in the respective scope. This can be another
translation unit; what does this mean? You are using the variable
for an internal status record and now someone, maybe even you
yourself, thoughtlessly or seemingly cleverly overwrites this
status. This can easily upset the internal workings of your
programme after some changes.
You now can reduce the visibility and accessibility of the variable
by giving it internal linkage (the declaration remains on file level
but is preceded by "static") which means it is only accessible within
one translation unit -- as long as you do not give its address to
some part of the programme outside --, or by giving it block scope and
no linkage (the declaration is within a function and preceded by
"static") which means it is only accessible from its declaration to
the closing } -- as long as you do not give its address to
some part of the programme outside.

Storage duration: Static storage duration means that your variable
exists throughout the whole life-time of your programme. It is
initialized only once and holds its value between two writing
accesses. How can this be bad?
1) Whatever part of your programme directly knows the variable or
at least knows its address, can modify it.
2) If a function uses this variable to keep track of some sort of
internal status and expects only certain status transitions, then
calling the function from two different points in your programme
can upset the function's logic and lead to invalid results. This
can be especially an issue if the function is part of a library
and this library is accessed by more than one programme or if you
have a multithreaded programme -- this situation is not covered by
standard C, so I will not go into detail. Read up on "reentrancy"
to understand the issues involved.

In addition, if you have more than one place in your programme
where a variable is used or modified, even if you all planned it
out carefully and have none of the situations described above, you
can more easily make a mistake when designing the algorithm using
this variable than when you just pass it or its address around in
a strictly controlled manner.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Heathfield]

Richard G. Riley said:

"Michael"posted the following on 2006-03-11:

There is no such thing as a global variable in C.

http://www.google.com/search?q=global+variables+in+c

http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[osmium]

"Richard Heathfield" wrote:

http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

And my personal favorite, "abraham lincoln" "quantum physics" 68K hits.

http://www.google.com/search?hl=en&q...=Google+Search

[Richard Heathfield]

Richard G. Riley said:

"Richard"posted the following on 2006-03-11:

Richard G. Riley said:

"Michael"posted the following on 2006-03-11:

There is no such thing as a global variable in C.

http://www.google.com/search?q=global+variables+in+c
http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

You dont say? But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.
No. Did
you read the initial reply?
Yes.
Did you think that was constructive for a newbie?
Yes. No point lyin' to 'em.
Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Malcolm]

"Richard Heathfield" <in*****@invalid.invalid> wrote

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Neither does "linked list". Or "pure function". Doesn't mean that such a
think doesn't exist.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $6.90 paper, available www.lulu.com

[Richard G. Riley]

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:

Richard G. Riley said:

"Richard"posted the following on 2006-03-11:

Richard G. Riley said:

"Michael"posted the following on 2006-03-11:
>
> There is no such thing as a global variable in C.

http://www.google.com/search?q=global+variables+in+c

http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

You dont say? But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.

No. Did
you read the initial reply?

Yes.

I did not think that reply in anyway
clarified anything.

Did you think that was constructive for a newbie?

Yes. No point lyin' to 'em.

One has to be practical. Not too clever for ones own good sometimes.

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Neither do lots of things : but the art is in recognising the meaning
from a newbie. Any half decent programmer worth his salt knows and
recognises what is meant by a global variable and in that context C
certainly does support them and the reasons for not using them are as
prevalent as in other languages : which is, fater all, what the OP was
asking. I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

[Michael Mair]

Richard G. Riley schrieb:

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:

Richard G. Riley said:

"Richard"posted the following on 2006-03-11:
Richard G. Riley said:

> "Michael"posted the following on 2006-03-11:
>
>>There is no such thing as a global variable in C.
>
>http://www.google.com/search?q=global+variables+in+c

http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

You dont say? But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.

No. Did
you read the initial reply?

Yes.

I did not think that reply in anyway
clarified anything.

You could have posted a direct reply.
You just could have expanded on mine and said that you consider
it too technical to be of any use to a newbie -- and be done.

For me, it was important to clarify that there are three
conceptual sides to it:
- Linkage
- Storage duration
- Ease or difficulty of seeing whether the implemented design
is the intended one, let alone correct

The former two are joined to the latter but may give toothaches
on their own. If I failed to carry this point over, then shame
on me. If you understood it but did not clarify it to suffice
your standards, shame on you.
In addition, it _is_ important to know what you are talking
about. The concepts mentioned should help the OP find his way
through it and also find out which side leads to which problem.
It may very well be that he decides to use a "global" variable
with internal linkage because this is exactly what he needs --
after having thought about why he does not want the uncertainties
involved in an object with external linkage and potential problems
when linking.

Did you think that was constructive for a newbie?

Yes. No point lyin' to 'em.

One has to be practical. Not too clever for ones own good sometimes.

This is true.
Nothing ever is simple, though, so I consider it fair to tell
people a little bit more.
A perfect reply certainly would be one of Chris Torek type (useful,
clear, concise, written nicely) but I certainly am not up to that
as I am neither a teacher nor a native speaker.

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Neither do lots of things : but the art is in recognising the meaning
from a newbie. Any half decent programmer worth his salt knows and
recognises what is meant by a global variable and in that context C
certainly does support them and the reasons for not using them are as
prevalent as in other languages : which is, fater all, what the OP was
asking. I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

The latter was not my intention. I post here to help and to
learn. I certainly do not pride myself on my often spotty knowledge
of the standard. You will guaranteedly find a couple of times
within the last month where I made a mistake and was glad because
it was corrected.
If you are saying that my reply was insufficient: You were free
to improve it. Next time I will take what you said into account
when answering a similar question.
If you are saying that I did it intentionally to show off, then I
think you are just once more out to look for an unnecessary fight
to pick -- and you are plain wrong.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Chris Torek]

>>> "Michael"posted the following on 2006-03-11:

There is no such thing as a global variable in C.

(I think this is a bit of an overstatement, but:)
Richard G. Riley said:

http://www.google.com/search?q=global+variables+in+c

"Richard"posted the following on 2006-03-11:

http://www.google.com/search?q=tooth+fairy (nearly four million hits).
Just cos it's on Google, doesn't mean it exists.

In article <uc************@cern.frontroom>
Richard G. Riley <rg*****@gmail.com> wrote, in part:... You dont know or agree with the common meaning of
"global variable" in C?

I do not know about the other Richard; but the problem I have with
the phrase is that there seem to be at least two *different*
"common meanings" for that phrase in C (there may be more, but
I have only seen two "commonly expressed" ones).

One refers to static-duration external-linkage objects:

% grep varx *.[ch]
foo.h: extern int varx;
bar.c: varx++;
foo.c: int varx = 42;
[etc]

These have uncontrolled access and "singleton" behavior (to borrow
terminology usually used with C++ and similar inferior attempts :-)
at OO languages).

Another refers merely to static-duragion objects, which may have
only internal linkage:

% grep didinit *.[ch]
bar.c: static int didinit;
bar.c: we use didinit to gripe rather than auto-init'ing in order to
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: didinit = 1;
bar.c: if (!didinit) gripe("missing call to init routine");

(people generally do not call these "global" if they are block-scope,
but do often call them "global" if they are file-scope). Variables
like this tend to be less objectionable; they have much better
controlled access, at least.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Richard G. Riley]

On 2006-03-11, Michael Mair <Mi**********@invalid.invalid> wrote:

Richard G. Riley schrieb:

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:

Richard G. Riley said:
"Richard"posted the following on 2006-03-11:
>Richard G. Riley said:
>
>> "Michael"posted the following on 2006-03-11:
>>
>>>There is no such thing as a global variable in C.
>>
>>http://www.google.com/search?q=global+variables+in+c
>
>http://www.google.com/search?q=tooth+fairy (nearly four million hits).
>
>Just cos it's on Google, doesn't mean it exists.

You dont say? But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.

No. Did
you read the initial reply?

Yes.
I did not think that reply in anyway
clarified anything.

You could have posted a direct reply.
You just could have expanded on mine and said that you consider
it too technical to be of any use to a newbie -- and be done.

I didnt : I didnt doubt the contents one bit. But at the end of the
day we know what is meant. It is a practical understanding that
evolves from knowing languages and what new programmers are really asking.

For me, it was important to clarify that there are three
conceptual sides to it:
- Linkage
- Storage duration
- Ease or difficulty of seeing whether the implemented design
is the intended one, let alone correct

The former two are joined to the latter but may give toothaches
on their own. If I failed to carry this point over, then shame
on me. If you understood it but did not clarify it to suffice
your standards, shame on you.
He was asking more about the use of them : not the issues with the
underlying system - unless I got the wrong end of the stick in which
case I apologise-
In addition, it _is_ important to know what you are talking
about. The concepts mentioned should help the OP find his way
through it and also find out which side leads to which problem.
My own thought is that it was way too technical for someone asking
about global and local variables in programming.
It may very well be that he decides to use a "global" variable
with internal linkage because this is exactly what he needs --
after having thought about why he does not want the uncertainties
involved in an object with external linkage and potential problems
when linking.

Did you think that was constructive for a newbie?

Yes. No point lyin' to 'em.
One has to be practical. Not too clever for ones own good sometimes.

This is true.
Nothing ever is simple, though, so I consider it fair to tell
people a little bit more.
A perfect reply certainly would be one of Chris Torek type (useful,
clear, concise, written nicely) but I certainly am not up to that
as I am neither a teacher nor a native speaker.

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Neither do lots of things : but the art is in recognising the meaning
from a newbie. Any half decent programmer worth his salt knows and
recognises what is meant by a global variable and in that context C
certainly does support them and the reasons for not using them are as
prevalent as in other languages : which is, fater all, what the OP was
asking. I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

The latter was not my intention. I post here to help and to
learn. I certainly do not pride myself on my often spotty knowledge
of the standard. You will guaranteedly find a couple of times
within the last month where I made a mistake and was glad because
it was corrected.

I'm not disputing the accuracy of you post. That is not my intent.
If you are saying that my reply was insufficient: You were free
to improve it. Next time I will take what you said into account
when answering a similar question.
If you are saying that I did it intentionally to show off, then I
think you are just once more out to look for an unnecessary fight
to pick -- and you are plain wrong.
No : but sometimes one must step back and consider who we are replying
to. Your reply was very, very technical IMO. And also it is unfair to
suiggest that "global variables do not exist in C". I still maintain
they do for the purposes of describing structured programming in C.



Cheers
Michael

[Michael Mair]

Richard G. Riley schrieb:

On 2006-03-11, Michael Mair <Mi**********@invalid.invalid> wrote:

Richard G. Riley schrieb:

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:
Richard G. Riley said:
>"Richard"posted the following on 2006-03-11:
>>Richard G. Riley said:
>>>"Michael"posted the following on 2006-03-11:
>>>
>>>>There is no such thing as a global variable in C.
>>>
>>>http://www.google.com/search?q=global+variables+in+c
>>
>>http://www.google.com/search?q=tooth+fairy (nearly four million hits).
>>
>>Just cos it's on Google, doesn't mean it exists.
>
>You dont say? But when we find x thousand courses which are quite
>happy to see "global variable" talked about in C then does it seem
>quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.

>No. Did
>you read the initial reply?

Yes.

I did not think that reply in anyway
clarified anything.

You could have posted a direct reply.
You just could have expanded on mine and said that you consider
it too technical to be of any use to a newbie -- and be done.

I didnt : I didnt doubt the contents one bit. But at the end of the
day we know what is meant. It is a practical understanding that
evolves from knowing languages and what new programmers are really asking.

For me, it was important to clarify that there are three
conceptual sides to it:
- Linkage
- Storage duration
- Ease or difficulty of seeing whether the implemented design
is the intended one, let alone correct

The former two are joined to the latter but may give toothaches
on their own. If I failed to carry this point over, then shame
on me. If you understood it but did not clarify it to suffice
your standards, shame on you.

He was asking more about the use of them : not the issues with the
underlying system - unless I got the wrong end of the stick in which
case I apologise-

In addition, it _is_ important to know what you are talking
about. The concepts mentioned should help the OP find his way
through it and also find out which side leads to which problem.

My own thought is that it was way too technical for someone asking
about global and local variables in programming.

Yep. However, if I am answering in c.l.c, I try to give a C answer.
If the OP asked in comp.programming, I would not have dwelled on
the term "global variable" at first but would have tried to shed
light on the different aspects nonetheless.
Stating that there are no global variables in C certainly is
hyperbole. Which was my intention: This makes one reconsider the
terminology used in this context.

If a colleague asks me a question, I often ask back what kind of
answer he is expecting -- the <insert product name here> internal
answer, the <insert product name here> user's view answer, the
general view answer and which flavour: the mathematician's answer,
the computer scientist's answer, the programmer's answer, or the
engineer's answer.
Not all combinations yield different answers, of course, but some
do -- and treating them this way can help the colleague much more
than a "default view" answer.

<snip>

>Yoou dont know or agree with the common meaning of "global variable" in
>C?

The term has no universally recognised meaning in C.

Neither do lots of things : but the art is in recognising the meaning
from a newbie. Any half decent programmer worth his salt knows and
recognises what is meant by a global variable and in that context C
certainly does support them and the reasons for not using them are as
prevalent as in other languages : which is, fater all, what the OP was
asking. I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

The latter was not my intention. I post here to help and to
learn. I certainly do not pride myself on my often spotty knowledge
of the standard. You will guaranteedly find a couple of times
within the last month where I made a mistake and was glad because
it was corrected.

I'm not disputing the accuracy of you post. That is not my intent.

This much I gathered -- I think you disputed the intent of my post.

If you are saying that my reply was insufficient: You were free
to improve it. Next time I will take what you said into account
when answering a similar question.
If you are saying that I did it intentionally to show off, then I
think you are just once more out to look for an unnecessary fight
to pick -- and you are plain wrong.

No : but sometimes one must step back and consider who we are replying
to. Your reply was very, very technical IMO. And also it is unfair to
suiggest that "global variables do not exist in C". I still maintain
they do for the purposes of describing structured programming in C.

If I write a design or algorithm, I may go with the term
"global", too. When writing code, I do not know a "global"
specifier or qualifier but implement what is conceptually meant
by "global variable".
As the concept is mapped to "static storage duration" but is not
clearly mapped to "external linkage" as it could also mean
"internal linkage", the implementation decision is a C specific
one.
In this case, I intentionally wore the _C_ programmer's hat.
As we are pretty much in agreement about the correctness but not
about the form of my reply, I suggest we end the discussion here.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Heathfield]

Malcolm said:

"Richard Heathfield" <in*****@invalid.invalid> wrote

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Neither does "linked list". Or "pure function". Doesn't mean that such a
think doesn't exist.

Sure - but when the term has no universally recognised meaning, it needs to
be defined (i.e. given a meaning) before it can be meaningfully used.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Richard G. Riley said:

I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

I advocate sticking to the terminology of the Standard not because I want to
score one-upmanship points (I already have plenty of those and to spare),
but because, in my experience, people learn to write portable C more
effectively if they can understand that terminology and thus apply the
information in the Standard to their own programming. This is why I
constantly refer to objects rather than variables, implicit conversions
rather than "implicit casts", and so on.

If you don't think I'm here to help people, you can't have been around very
long. (In fact, an archive search reveals that you've been posting to
comp.lang.c by the name "Richard G. Riley" since 23rd February of this
year.) I suggest you stick around a bit before you start passing judgements
on people.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Jordan Abel]

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:

Richard G. Riley said:

"Richard"posted the following on 2006-03-11:

Richard G. Riley said:

"Michael"posted the following on 2006-03-11:
>
> There is no such thing as a global variable in C.

http://www.google.com/search?q=global+variables+in+c

http://www.google.com/search?q=tooth+fairy (nearly four million hits).

Just cos it's on Google, doesn't mean it exists.

You dont say? But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?

The word "variable" isn't all that useful, and the term "global variable" is
less useful still.

No. Did
you read the initial reply?

Yes.

Did you think that was constructive for a newbie?

Yes. No point lyin' to 'em.

Yoou dont know or agree with the common meaning of "global variable" in
C?

The term has no universally recognised meaning in C.

Things that it's _not_ are universally recognized, though - about the
only things that can be a "global variable" are objects with static
duration and either external linkage or file scope.

[Jordan Abel]

On 2006-03-11, Chris Torek <no****@torek.net> wrote:

"Michael"posted the following on 2006-03-11:
> There is no such thing as a global variable in C. (I think this is a bit of an overstatement, but:)
Richard G. Riley said:
http://www.google.com/search?q=global+variables+in+c

"Richard"posted the following on 2006-03-11:

http://www.google.com/search?q=tooth+fairy (nearly four million hits).
Just cos it's on Google, doesn't mean it exists.

In article <uc************@cern.frontroom>
Richard G. Riley <rg*****@gmail.com> wrote, in part:

... You dont know or agree with the common meaning of
"global variable" in C?

I do not know about the other Richard; but the problem I have with
the phrase is that there seem to be at least two *different*
"common meanings" for that phrase in C (there may be more, but
I have only seen two "commonly expressed" ones).

One refers to static-duration external-linkage objects:

% grep varx *.[ch]
foo.h: extern int varx;
bar.c: varx++;
foo.c: int varx = 42;
[etc]

These have uncontrolled access and "singleton" behavior (to borrow
terminology usually used with C++ and similar inferior attempts :-)
at OO languages).

Another refers merely to static-duragion objects, which may have
only internal linkage:

% grep didinit *.[ch]
bar.c: static int didinit;
bar.c: we use didinit to gripe rather than auto-init'ing in order to
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: didinit = 1;
bar.c: if (!didinit) gripe("missing call to init routine");

(people generally do not call these "global" if they are block-scope,
but do often call them "global" if they are file-scope). Variables
like this tend to be less objectionable; they have much better
controlled access, at least.

What about external-linkage variables with block scope? [One could argue
that an external-linkage variable has an existence in its own right,
independent of a mere declaration, but is it "global"?]

[Richard G. Riley]

On 2006-03-11, Richard Heathfield <in*****@invalid.invalid> wrote:

Richard G. Riley said:

I dont know, maybe I'm getting too old for this : there was a
time when people wanted to help : not just get one upsmanship points
on who can read the standards the best.

I advocate sticking to the terminology of the Standard not because I want to
score one-upmanship points (I already have plenty of those and to spare),
but because, in my experience, people learn to write portable C more
effectively if they can understand that terminology and thus apply the
information in the Standard to their own programming. This is why I
constantly refer to objects rather than variables, implicit conversions
rather than "implicit casts", and so on.

Posting has a nasty habit of insinuating an attitude not there. I did
not suggest you were not trying to help : I suggested, rather, that to
deny "global variables" in C to a beginner is counter productive and
liable to confuse. Let people walk before they can fly IMO.

[Chris Torek]

>On 2006-03-11, Chris Torek <no****@torek.net> wrote:

... there seem to be at least two *different* "common meanings"
for that phrase in C (there may be more, but I have only seen two
"commonly expressed" ones). One refers to static-duration external-linkage objects ....
Another refers merely to static-duragion objects ....

In article <sl**********************@random.yi.org>
Jordan Abel <ra*******@gmail.com> wrote:What about external-linkage variables with block scope? [One could argue
that an external-linkage variable has an existence in its own right,
independent of a mere declaration, but is it "global"?]

This is why I said "at least" two: it depends on how fine you want
to make your various distinctions. :-)

To get an external-linkage block-scope variable in C, we have to
use the "extern" keyword:

void f(void) {
extern int somevar;
...
}

If f() actually uses "somevar", this code will only compile if some
other code supplies an appropriate "somevar" variable. Then we get
into the question of whether "somevar" in f() is *the* "global"(?)
variable, or if the definition in zorg.c -- if that is where it is
-- is the "real" global, and so on.

As an aside: note that limiting the scope of variables, whether
to files or blocks, allows us to have two different variables with
the same name. For instance:

void f(void) {
int x;
...
}
void g(void) {
double x;
...
}

Talking about "the" variable "x" is confusing since there are now
two variables both named "x". (Of course, I am used to this in
person, as "Chris" is a rather common name. As with "real names",
we generally like to add disambiguators. Sometimes people will
use full names or initials, but I have occasionally been numbered.%)
-----
% But never "Number 6"! I will not be pushed, filed, indexed, stamped...
-----

In C, "linkage" of identifiers allows us to decide whether or not
two identifiers with the same name refer to the same object.
Identifiers with "no linkage" *never* refer to the same object:

void h(void) {
int i; /* i has no linkage */
... /* use i */
if (somecond) h();
... /* use i some more */
}

When h() calls itself recursively, you get two active "i"s, and
in some cases you need to decide on some way to talk about both "i"s
at the same time, usually by adding a disambiguator like "the
outer i" or "the inner i".

In this case, when we have two "i"s due to h() calling itself, they
both have the same scope (block) and linkage (none), but they are
different objects. I think this is best viewed by saying that
scope and linkage apply to a variable's *name*, while storage-duration
-- which seems to be a key ingredient in deciding, informally,
whether to call a variable "global" -- is actually an attribute of
the underlying object.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Richard G. Riley]

On 2006-03-11, Chris Torek <no****@torek.net> wrote:

On 2006-03-11, Chris Torek <no****@torek.net> wrote:

... there seem to be at least two *different* "common meanings"
for that phrase in C (there may be more, but I have only seen two
"commonly expressed" ones). One refers to static-duration external-linkage objects ....
Another refers merely to static-duragion objects ....

In article <sl**********************@random.yi.org>
Jordan Abel <ra*******@gmail.com> wrote:

What about external-linkage variables with block scope? [One could argue
that an external-linkage variable has an existence in its own right,
independent of a mere declaration, but is it "global"?]

This is why I said "at least" two: it depends on how fine you want
to make your various distinctions. :-)

To get an external-linkage block-scope variable in C, we have to
use the "extern" keyword:

void f(void) {
extern int somevar;
...
}

For the sake of simplicity and using "global global" for the OP I
would envisage a simple example where a module links to a system wide
"global"

e.g

globals.h:
===========
extern int myGlobal;

globals.c:
==========
int myGlobal = 255; // defined in globals.h as externally linkable

useglobals.c:
=============
#include "globals.h"
..
..
..
int func(){
doSomething(myGlobal+1);
}
..
..
Now, to me that is and always has been a "global", but can see where
it can be complicated because it is not global if the include is
included or the extern is specifically embedded in the code.

[Richard G. Riley]

> Now, to me that is and always has been a "global", but can see where

it can be complicated because it is *only* global if the include is
included or the extern is specifically embedded in the code.

typo fixed *

[Malcolm]

"Chris Torek" <no****@torek.net> wrote

I do not know about the other Richard; but the problem I have with
the phrase is that there seem to be at least two *different*
"common meanings" for that phrase in C (there may be more, but
I have only seen two "commonly expressed" ones).

One refers to static-duration external-linkage objects:

% grep varx *.[ch]
foo.h: extern int varx;
bar.c: varx++;
foo.c: int varx = 42;
[etc]

These have uncontrolled access and "singleton" behavior (to borrow
terminology usually used with C++ and similar inferior attempts :-)
at OO languages).

Another refers merely to static-duragion objects, which may have
only internal linkage:

% grep didinit *.[ch]
bar.c: static int didinit;
bar.c: we use didinit to gripe rather than auto-init'ing in order to
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: if (!didinit) gripe("missing call to init routine");
bar.c: didinit = 1;
bar.c: if (!didinit) gripe("missing call to init routine");

(people generally do not call these "global" if they are block-scope,
but do often call them "global" if they are file-scope). Variables
like this tend to be less objectionable; they have much better
controlled access, at least.

So one is a static global, the other a global global.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $6.90 paper, available www.lulu.com

[Mark McIntyre]

On Sat, 11 Mar 2006 16:36:30 +0100, in comp.lang.c , "Richard G.
Riley" <rg*****@gmail.com> wrote:

But when we find x thousand courses which are quite
happy to see "global variable" talked about in C then does it seem
quite right to start pretending it doesnt apply anymore in ng?
It merely means that the course teachers were ignorant. Thats not the
fault of anytone in CLC
you read the initial reply? Did you think that was constructive for a newbie?

Yes.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Neil]

fabio wrote:

Why? i' ve heard about this, the usage of global vars instead of
locals is discouraged, but why?
thx :)

Side effects. The bigger the program and the more the globals the
bigger the problem. Unintended and unwanted change to the globals can
happen. Then you get to figure out what it happened.
Variable (and function) scope should be limited. Use global only when
needed.

[Laurijssen]

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:47************@individual.net...

fabio schrieb:

Why? i' ve heard about this, the usage of global vars instead of locals
is discouraged, but why?

There is no such thing as a global variable in C.

Can somebody from clc come and change the g_ prefix into something more C
like from all our projects please? :) maybe el_ and ssd_ ?

[Richard G. Riley]

On 2006-03-12, Laurijssen <se***@n.tk> wrote:

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:47************@individual.net...

fabio schrieb:

Why? i' ve heard about this, the usage of global vars instead of locals
is discouraged, but why?

There is no such thing as a global variable in C.

Can somebody from clc come and change the g_ prefix into something more C
like from all our projects please? :) maybe el_ and ssd_ ?

LOL. People need to understand that "global" is a concept : of course C
supports "global" variables. How global can be modified : but global
they are, and I'm yet to see a sensible argument to the contrary. The
fact that there might not be any "global" keyword doesnt alter
anything. Although looking at the asm output from Gcc is interesting :
hmm, whats, that? Aha : a .global data definition ....

[Mark McIntyre]

On 12 Mar 2006 14:02:33 GMT, in comp.lang.c , "Richard G. Riley"
<rg****@gmail.com> wrote:

of course C supports "global" variables.
Define 'global'.

FYR, the word is used three times in the ISO standad, once with
reference to the preprocessor, and twice with reference to
side-effects of FP operations.
How global can be modified : but global
they are, and I'm yet to see a sensible argument to the contrary.

Then presumably you selectively skipped all the earlier arguments in
this thread.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Michael Mair]

Laurijssen schrieb:

"Michael Mair" <Mi**********@invalid.invalid> wrote

fabio schrieb:

Why? i' ve heard about this, the usage of global vars instead of locals
is discouraged, but why?

There is no such thing as a global variable in C.

Can somebody from clc come and change the g_ prefix into something more C
like from all our projects please? :) maybe el_ and ssd_ ?

If you really have that many globals, please inform me
for which company you work so that I have a chance to avoid
your products.

Apart from that, if your coding guidelines prescribe a leading
g_ for all variables with external linkage and, say, sg_ for all
variables with internal linkage, then the mapping is injective and
well-defined. If you just threw external linkage and internal
linkage together or are not consistent in your naming scheme or
keeping to it, then there is not much hope -- neither for the
renaming nor for the conceptual cleanness of your programs.

If you really deem the replacement necessary, then use find and
grep to identify the files with
" word-boundary g _ alphanumeric word-boundary " and use your
shell's / DOS's for and sed for replacing. If you don't your way
around them, then there are still search and replace tools with
GUI to help you along.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard G. Riley]

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Laurijssen schrieb:

"Michael Mair" <Mi**********@invalid.invalid> wrote

fabio schrieb:

Why? i' ve heard about this, the usage of global vars instead of locals
is discouraged, but why?

There is no such thing as a global variable in C.
Can somebody from clc come and change the g_ prefix into something more C
like from all our projects please? :) maybe el_ and ssd_ ?

If you really have that many globals, please inform me
for which company you work so that I have a chance to avoid
your products.

Why do you make so many assumptions of how many he has? Lots of
systems have a good few globals for efficiency and ease of use. Of
course limiting them is a benefit.

Apart from that, if your coding guidelines prescribe a leading
g_ for all variables with external linkage and, say, sg_ for all
variables with internal linkage, then the mapping is injective and
No more than defining all externs in a globals include. Having said
that, I like hungarian notation although its frowned upon in the Linux
world. Makes it too easy for people to read the code or something :)
well-defined. If you just threw external linkage and internal
linkage together or are not consistent in your naming scheme or
keeping to it, then there is not much hope -- neither for the
renaming nor for the conceptual cleanness of your programs.

If you really deem the replacement necessary, then use find and
grep to identify the files with
" word-boundary g _ alphanumeric word-boundary " and use your
shell's / DOS's for and sed for replacing. If you don't your way
around them, then there are still search and replace tools with
GUI to help you along.

I await the answer with interest.

Cheers
Michael

[Michael Mair]

Richard G. Riley schrieb:

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Laurijssen schrieb:

"Michael Mair" <Mi**********@invalid.invalid> wrote
fabio schrieb:

>Why? i' ve heard about this, the usage of global vars instead of locals
>is discouraged, but why?

There is no such thing as a global variable in C.

Can somebody from clc come and change the g_ prefix into something more C
like from all our projects please? :) maybe el_ and ssd_ ?

If you really have that many globals, please inform me
for which company you work so that I have a chance to avoid
your products.

Why do you make so many assumptions of how many he has? Lots of
systems have a good few globals for efficiency and ease of use. Of
course limiting them is a benefit.

It sounds like it -- otherwise paying for me to come over and
fix it would certainly be a waste of time ;-)
Honestly, if you have one file with the "unavoidable globals"
and are careful using them then everything is alright; only if
your globals are happily distributed through the code is when
the overall integrity of the product can be doubted.

Apart from that, if your coding guidelines prescribe a leading
g_ for all variables with external linkage and, say, sg_ for all
variables with internal linkage, then the mapping is injective and

No more than defining all externs in a globals include. Having said
that, I like hungarian notation although its frowned upon in the Linux
world. Makes it too easy for people to read the code or something :)

Having seen identifiers which consist of five letters Hungarian
abomination and one or two letters "name" in order to keep the
6 letter limit, I cannot really claim that I am convinced.
Interestingly, even MS abandoned HN.

well-defined. If you just threw external linkage and internal
linkage together or are not consistent in your naming scheme or
keeping to it, then there is not much hope -- neither for the
renaming nor for the conceptual cleanness of your programs.

If you really deem the replacement necessary, then use find and
grep to identify the files with
" word-boundary g _ alphanumeric word-boundary " and use your
shell's / DOS's for and sed for replacing. If you don't your way
around them, then there are still search and replace tools with
GUI to help you along.

I await the answer with interest.

So do I :-)
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard G. Riley]

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Having seen identifiers which consist of five letters Hungarian
abomination and one or two letters "name" in order to keep the
6 letter limit, I cannot really claim that I am convinced.
Interestingly, even MS abandoned HN.

When reading code from a printout I like it. In a code environemnt, no
need since the tools show the type.

But Hungarian was not what I meant to be honest : I was too hasty and
annoyed from the other thread.

Whyt would you call this in the academic world?
CStructMine *ptrDate = &myStruct;

int numRollsOfTheDie = getRolls();

Possibly "loose hungarian" or just "common sense good naming"? On
more than one project we introduced some basic naming standards and
the productivity soared : really. Far easier to see type and use even
just adding "ref" or "ptr" to a variable name : one of the biggest
causes of issues in C/C++ code reading and function calls

[Michael Mair]

Richard G. Riley schrieb:

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Having seen identifiers which consist of five letters Hungarian
abomination and one or two letters "name" in order to keep the
6 letter limit, I cannot really claim that I am convinced.
Interestingly, even MS abandoned HN.
When reading code from a printout I like it. In a code environemnt, no
need since the tools show the type.

But Hungarian was not what I meant to be honest : I was too hasty and
annoyed from the other thread.

Happens :-)
Whyt would you call this in the academic world?

CStructMine *ptrDate = &myStruct;

int numRollsOfTheDie = getRolls();

Possibly "loose hungarian" or just "common sense good naming"?
I'd go for the latter. In the company I am working for at
the moment, the "naming conventions" go like that (parts of
that are C++, but there is only one set of conventions):
Start with 'p' for pointers and 'r' for references, accumulate
'p's and 'r's appropriately, with 'm_' for members and 's_' for
static members, do not use gratuitous '_' (essentially: Keep it
to the macros), use camel casing for member functions and
Pascal casing for other functions. Make the names telling.
In the case of libraries from different products, one also
gets some name prefixes, too, but these are not annoying.
There is some more stuff for enums, typedefs and classes but
that's about it. Personally, I'd even use less regulation
in some parts but this is about okay. When talking to the
oldstyle Windows programming disciples, I am very glad about
this set of rules in comparison.
On
more than one project we introduced some basic naming standards and
the productivity soared : really. Far easier to see type and use even
just adding "ref" or "ptr" to a variable name : one of the biggest
causes of issues in C/C++ code reading and function calls

Yep. Whatever helps and does not hinder.
The larger the group the more necessary to introduce this early.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard G. Riley]

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Richard G. Riley schrieb:

On 2006-03-12, Michael Mair <Mi**********@invalid.invalid> wrote:

Having seen identifiers which consist of five letters Hungarian
abomination and one or two letters "name" in order to keep the
6 letter limit, I cannot really claim that I am convinced.
Interestingly, even MS abandoned HN.
When reading code from a printout I like it. In a code environemnt, no
need since the tools show the type.

But Hungarian was not what I meant to be honest : I was too hasty and
annoyed from the other thread.

Happens :-)

Whyt would you call this in the academic world?

CStructMine *ptrDate = &myStruct;

int numRollsOfTheDie = getRolls();

Possibly "loose hungarian" or just "common sense good naming"?

I'd go for the latter. In the company I am working for at
the moment, the "naming conventions" go like that (parts of
that are C++, but there is only one set of conventions):
Start with 'p' for pointers and 'r' for references, accumulate
'p's and 'r's appropriately, with 'm_' for members and 's_' for

I hate m_ for members. There is "this" and the anchor object to
indicate that they are members. Es ist genug.
static members, do not use gratuitous '_' (essentially: Keep it
to the macros), use camel casing for member functions and
Pascal casing for other functions. Make the names telling.
"telling" can be difficult across languages (world), but at the end of
the day I've worked on many projects around the world and the code
language was in all cases, bar one, in English. Made for some pretty
freaky comments : we'd have been better off without them IMO:)
In the case of libraries from different products, one also
gets some name prefixes, too, but these are not annoying.
There is some more stuff for enums, typedefs and classes but
that's about it. Personally, I'd even use less regulation
in some parts but this is about okay. When talking to the
oldstyle Windows programming disciples, I am very glad about
this set of rules in comparison.

On
more than one project we introduced some basic naming standards and
the productivity soared : really. Far easier to see type and use even
just adding "ref" or "ptr" to a variable name : one of the biggest
causes of issues in C/C++ code reading and function calls
Yep. Whatever helps and does not hinder.
The larger the group the more necessary to introduce this early.

I had a huge argument about this. Some of the programmers wanted to
"express their freedom". After attempting to come to a "consensus" we
realised it was just getting silly : we instigated the rules against
the wishes of some of the older (more stuck in the wood) hands and the
proceeded to see nothing but better results. The code was regularly
reviewed, multistatement per line code removed, and guess what? The
programmers could move between modules with *ease* : in days before
people dreaded using "X"'s code because he used crap variable names,
insisted on breaking things down to a painfule level and basically not
use the strengths of the language. A few code reviews, standard
variable naming and standard ways of laying out loops and the issue
was gone. Underestimate something even as simple as the way you use
opening and closing braces : me, I'm a K&R man in that respect.
Cheers
Michael

cheers,

--
Debuggers : you know it makes sense.
http://heather.cs.ucdavis.edu/~matlo...g.html#tth_sEc

[John Bode]

fabio wrote:

Why? i' ve heard about this, the usage of global vars instead of
locals is discouraged, but why?
thx :)

File scope variables (globals) cause maintenance headaches mainly by
promoting tight coupling between what should otherwise be independent
functions or modules. If you're updating a function or module that
modifies a global, you have to make sure that change doesn't have
unintended side effects elsewhere. You have to make sure that the same
variable isn't being used in multiple, potentially conflicting contexts
(say as a sum in one function and an array index in another).
Otherwise you increase the risk of introducing bugs in other parts of
the program. It also makes it harder to make changes to the code as
the requirements change (which they do, a lot).

There are times when you need to preserve information between function
calls and have that information available to multiple functions;
however, those functions and globals should be grouped together and
placed in a file of their own, and the globals should not have external
linkage (i.e., they should be declared static at file scope). You
should *never* need to have a single variable visible across the entire
scope of a program (if you do, you may need to rethink your design).

[John Devereux]

"John Bode" <jo*******@my-deja.com> writes:

There are times when you need to preserve information between function
calls and have that information available to multiple functions;
however, those functions and globals should be grouped together and
placed in a file of their own, and the globals should not have external
linkage (i.e., they should be declared static at file scope). You
should *never* need to have a single variable visible across the entire
scope of a program (if you do, you may need to rethink your design).

This means putting the declaration in the header file, doesn't it?

I have always heard that was a bad idea. Or do you think it is just
less bad than the alternative of having a "variable with external
linkage" declared in the implementation (*.c) file, and defined in a
header file?

i.e. you could have just

module.h:

static int shared_int;
Or

module.h:

extern int shared_int;

module.c:

int shared_int;

--

John Devereux

[John Bode]

John Devereux wrote:

"John Bode" <jo*******@my-deja.com> writes:

There are times when you need to preserve information between function
calls and have that information available to multiple functions;
however, those functions and globals should be grouped together and
placed in a file of their own, and the globals should not have external
linkage (i.e., they should be declared static at file scope). You
should *never* need to have a single variable visible across the entire
scope of a program (if you do, you may need to rethink your design).

This means putting the declaration in the header file, doesn't it?

I have always heard that was a bad idea.

It's a bad idea to have a variable *definition* in a header file.
Or do you think it is just
less bad than the alternative of having a "variable with external
linkage" declared in the implementation (*.c) file, and defined in a
header file?

i.e. you could have just

module.h:

static int shared_int;
Or

module.h:

extern int shared_int;

module.c:

int shared_int;

If your intention is to have multiple modules access the same memory,
the second way is the correct way to do it (there are circumstances
where this is necessary, but not in the normal course of events). The
first way will cause each file that includes module.h to create its own
private instance of shared_int, so it won't really be shared.

[John Devereux]

"John Bode" <jo*******@my-deja.com> writes:

John Devereux wrote:

"John Bode" <jo*******@my-deja.com> writes:

> There are times when you need to preserve information between function
> calls and have that information available to multiple functions;
> however, those functions and globals should be grouped together and
> placed in a file of their own, and the globals should not have external
> linkage (i.e., they should be declared static at file scope). You
> should *never* need to have a single variable visible across the entire
> scope of a program (if you do, you may need to rethink your design).

This means putting the declaration in the header file, doesn't it?

I have always heard that was a bad idea.

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

I always get this terminology mixed up for some reason (definition vs
declaration). I know what I meant!

Or do you think it is just
less bad than the alternative of having a "variable with external
linkage" declared in the implementation (*.c) file, and defined in a
header file?

i.e. you could have just

module.h:

static int shared_int;
Or

module.h:

extern int shared_int;

module.c:

int shared_int;

If your intention is to have multiple modules access the same memory,
the second way is the correct way to do it (there are circumstances
where this is necessary, but not in the normal course of events). The
first way will cause each file that includes module.h to create its own
private instance of shared_int, so it won't really be shared.

Re the first way: Of course it won't work, I don't know what I was
thinking there! I never do that, so have never thought through the
consequences. I thought that is what you were proposing, but I now see
you just mean isolate all uses of the "global" variable into a single
module, then you can make it static and get rid of the external
linkage.

Re "variables with external linkage", I *have* had applications
degenerate into using them, even when starting out with good
intentions. For example, I have embedded systems that use shared
structures for e.g. "settings".

set.h:

struct
{
test_time;
temperature;
/*...(lots more items)...*/
} set;
A "user interface" module then allows the user to change the settings,
while the rest of the program is controlled by the setting values,
e.g. set.temperature. Everything has to include set.h.

I have not found a better way to do it, but don't really like the
result. I can make the structure definition static, then pass around
pointers to it everywhere, but that does not really change anything;
everything is still interdependent.
--

John Devereux

[cappeca]

Richard Heathfield wrote:

I advocate sticking to the terminology of the Standard not because I want to
score one-upmanship points (I already have plenty of those and to spare),
but because, in my experience, people learn to write portable C more
effectively if they can understand that terminology and thus apply the
information in the Standard to their own programming.
Which is not very helpful for newbies, now you know.
If you don't think I'm here to help people, you can't have been around very
long. I suggest you stick around a bit before you start passing judgements
on people.

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

[Chris Dollin]

cappeca wrote:

Richard Heathfield wrote:

I advocate sticking to the terminology of the Standard not because I want
to score one-upmanship points (I already have plenty of those and to
spare), but because, in my experience, people learn to write portable C
more effectively if they can understand that terminology and thus apply
the information in the Standard to their own programming.

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

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

If you don't think I'm here to help people, you can't have been around
very
long. I suggest you stick around a bit before you start passing
judgements on people.

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

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

--
Chris "sparqling" Dollin
"Who do you serve, and who do you trust?"

[John Bode]

John Devereux wrote:

"John Bode" <jo*******@my-deja.com> writes:

John Devereux wrote:

"John Bode" <jo*******@my-deja.com> writes:

> There are times when you need to preserve information between function
> calls and have that information available to multiple functions;
> however, those functions and globals should be grouped together and
> placed in a file of their own, and the globals should not have external
> linkage (i.e., they should be declared static at file scope). You
> should *never* need to have a single variable visible across the entire
> scope of a program (if you do, you may need to rethink your design).
This means putting the declaration in the header file, doesn't it?

I have always heard that was a bad idea.
It's a bad idea to have a variable *definition* in a header file.

I always get this terminology mixed up for some reason (definition vs
declaration). I know what I meant!

Yeah, I just wanted to amplify the point, as it's bitten me in the ass
on occasion.

Or do you think it is just
less bad than the alternative of having a "variable with external
linkage" declared in the implementation (*.c) file, and defined in a
header file?

i.e. you could have just

module.h:

static int shared_int;
Or

module.h:

extern int shared_int;

module.c:

int shared_int;

If your intention is to have multiple modules access the same memory,
the second way is the correct way to do it (there are circumstances
where this is necessary, but not in the normal course of events). The
first way will cause each file that includes module.h to create its own
private instance of shared_int, so it won't really be shared.

Re the first way: Of course it won't work, I don't know what I was
thinking there! I never do that, so have never thought through the
consequences.

Welcome to my world. God knows how many times I've written something
here that, on reflection, wasn't what I meant to write at all.
I thought that is what you were proposing, but I now see
you just mean isolate all uses of the "global" variable into a single
module, then you can make it static and get rid of the external
linkage.

Re "variables with external linkage", I *have* had applications
degenerate into using them, even when starting out with good
intentions. For example, I have embedded systems that use shared
structures for e.g. "settings".

set.h:

struct
{
test_time;
temperature;
/*...(lots more items)...*/
} set;
A "user interface" module then allows the user to change the settings,
while the rest of the program is controlled by the setting values,
e.g. set.temperature. Everything has to include set.h.

I have not found a better way to do it, but don't really like the
result. I can make the structure definition static, then pass around
pointers to it everywhere, but that does not really change anything;
everything is still interdependent.

Yeah, I can imagine that embedded programming is one area where this
sort of thing crops up a lot (I don't do embedded programming, so I'm
just guessing). I should probably never say "never"; there *are* times
when global access is the right answer, it's just that it isn't common
outside of certain domains. For general-purpose applications
programming, it should be pretty damned rare.

[Richard G. Riley]

On 2006-03-13, Chris Dollin <ke**@hpl.hp.com> wrote:

cappeca wrote:

Richard Heathfield wrote:

I advocate sticking to the terminology of the Standard not because I want
to score one-upmanship points (I already have plenty of those and to
spare), but because, in my experience, people learn to write portable C
more effectively if they can understand that terminology and thus apply
the information in the Standard to their own programming.
Which is not very helpful for newbies, now you know.

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.

If you don't think I'm here to help people, you can't have been around
very
long. I suggest you stick around a bit before you start passing
judgements on people.

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

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.

--
Debuggers : you know it makes sense.
http://heather.cs.ucdavis.edu/~matlo...g.html#tth_sEc

[Chris Dollin]

Richard G. Riley wrote:

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.]

--
Chris "sparqling" Dollin
"Who do you serve, and who do you trust?"

[Richard G. Riley]

On 2006-03-13, Chris Dollin <ke**@hpl.hp.com> wrote:

Richard G. Riley wrote:

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.

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]

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:47************@individual.net...

>There is no such thing as a global variable in C.

Can somebody from clc come and change the g_ prefix into something more
C like from all our projects please? :) maybe el_ and ssd_ ?

Why do you make so many assumptions of how many he has? Lots of
systems have a good few globals for efficiency and ease of use. Of
course limiting them is a benefit.

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:

Richard Heathfield wrote:

I advocate sticking to the terminology of the Standard not because I want
to score one-upmanship points (I already have plenty of those and to
spare), but because, in my experience, people learn to write portable C
more effectively if they can understand that terminology and thus apply
the information in the Standard to their own programming.

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.

If you don't think I'm here to help people, you can't have been around
very
long. I suggest you stick around a bit before you start passing
judgements on people.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Michael Mair]

Laurijssen schrieb:

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:47************@individual.net...

>>There is no such thing as a global variable in C.
>
>Can somebody from clc come and change the g_ prefix into something more
>C like from all our projects please? :) maybe el_ and ssd_ ?Why do you make so many assumptions of how many he has? Lots of
systems have a good few globals for efficiency and ease of use. Of
course limiting them is a benefit.
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.

*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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[CBFalconer]

John Bode wrote:

John Devereux wrote:

.... snip ...

This means putting the declaration in the header file, doesn't
it? I have always heard that was a bad idea.

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)