A very **very** basic question

[lovecreatesbeauty]

So, rather than treating it as a statement and then complaining that a
statement isn't allowed in that context

A compiler doesn't have the choice. A conformance compiler follows the
standard and won't treat any code in file scope as statement.

gcc treats it as a
declaration and then complains that it's an invalid form of
declaration because of the missing type.

Yes.

As for why statements outside functions aren't allowed

Because Standard forbids this. A program or translation unit contains
directly declares only.

 

[dj3vande]

Yes. But we are not compilers.

Just for if anybody still thinks Richard _ has any shreds of
credibility left, allow me to reinstate what mdh said in reply to Keith
Thompson's comment (and Richard cut out):

}}Which was the key issue I was missing. Not sure if I missed this in
}}K&R ( Probably) and the importance of the location in which these are
}}allowed to occur, but it has come up a few times in my coding, so
}}wanted to clarify it.

Yes. But we are not compilers.

If you're going to claim that ignoring the distinctions a compiler
makes is a good route to learning a language, a follow-up to a post by
a beginner stating that *making* those distinctions helps understand
things is not exactly a good place to do it.


dave
(on the other hand, if you're just trolling...)

 

[James Kuyper]

(e-mail address removed) writes: ....
You have lost me.

That's too bad. As they say, you can lead a horse to water, but you
can't make him drink.

It is a petty difference when teaching someone new.

When I was teaching mdh, I didn't mention the fact that "int i=0;" is a
declaration that initializes 'i', while "i=0;" is a statement that
assigns a value to 'i'. All I did was point out that the first was a
declaration, while the second one was a statement; that's all I needed
to say to answer his question.

I didn't mention the difference between initialization and assignment
until I was explaining, to YOU, why your answer was not a useful one.
When you say "It is a petty difference when teaching someone new", does
that mean that you are new, and that I'm teaching you? I didn't get that
impression; I got the impression that you're an experienced programmer,
well practiced in variety of bad habits, and not currently learning much
of anything from me.

....

int i=0;

You really want to tell me that in plain english 0 is not assigned to
the global variable i at program initialisation?

I wouldn't even attempt to use plain English for that task; it's not a
suitable language for such discussions. If I'm working with an
experienced programmer, I'd describe the behavior correctly and expect
to be understood; If I'm working with a newbie, I would first teach him
the specialized meanings of the words needed to describe it correctly,
and then describe it correctly.

....

I have no idea what that last little soap box was about.

That follows from you're comment "You lost me" up above.

....

And if you try to tell me that

int i=3*4;

is NOT C code then please don your kevlar helmet ....

You may have noticed that I did not endorse the use of the word "code"
for explaining the relevant rule, quite the contrary. The relevant word
is "statements", not "code".

 

[James Kuyper]

Richard wrote:
....

and "int i=0;" is not a statement now?

See section 6.8p1:

statement:
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement

If you have any doubts, just check the definitions of each of the
individual statement types. Sooner or later you'll figure out that
declarations do not qualify as statements, as far as the C standard is
concerned.

This is another one of those silly pieces of jargon that you despise so
much. Failing to understand what it means in a C context won't cost you
too much trouble; unless you're trying to communicate something about
the subject with someone else who does know what it means. Then it's
going to make you sound like an idiot.

 

[Keith Thompson]

This is a definition and initialization statement for a global.

It's a declaration, not a statement. The distinction is important.

This is executable code.

More precisely, it's a statement.

You are not allowed to place executable code outside of a function.

For greater accuracy and clarity, replace "executable code" by
"statements".

 

[Keith Thompson]

They are being typically difficult.

And you're not?

My favorite so far is

is "#include <stdio.h> code ?

It is of course. Since it contains/can contain all sorts of stuff
including inline function, defines, macros etc. And if thats not "C
code" then i dont know what it.

Quite possibly.

The word "code" is ambiguous. The C99 standard itself refers to
"mixed declarations and code", meaning declarations and statements,
but it also uses the terms "code" and "source code" in a more general
sense.

In each case, the meaning is clear from the context. You, of course,
choose to interpret in whatever way appears to make the other guy
wrong.

The language lawyers in this group will be the death of it.

Don't let the door hit you on the way out.

 

[Keith Thompson]

A compiler doesn't have the choice. A conformance compiler follows the
standard and won't treat any code in file scope as statement.

Sure it does. A conforming compiler could use a grammar that allows
it to recognize statements in all contexts, and issue a diagnostic
whenever it sees one outside a function definition.

Because Standard forbids this. A program or translation unit contains
directly declares only.

Right, the standard forbids it because the standard forbids it. But
the standard doesn't exist in a vacuum, and understanding *why* the
rules are as they are can be useful.

 

[lovecreatesbeauty]

I would suggest being more precise yourself.

I'm always trying

What I really
ought to have done is to draw the distinction between declarations and
statements, yes? Oh, but wait - if you read my article again, you'll find
that I did exactly that.

Yes, your post is right. I just felt that the term "code" in your post
may bring some confusion.

 

[Kenny McCormack]

....

In each case, the meaning is clear from the context. You, of course,
choose to interpret in whatever way appears to make the other guy
wrong.

Oh.

The.

Irony.

 

[lovecreatesbeauty]

Right, the standard forbids it because the standard forbids it. But
the standard doesn't exist in a vacuum, and understanding *why* the
rules are as they are can be useful.

Yes

 

[Kenny McCormack]

Writing the explicit assignment i=0 however, would probably generate some
executable code.

Compilers of course can implement these as they like, but I think the
behaviour above is typical.

But such speculation/discussion is, of course, off-topic, since we are
supposed to remain completely oblivious to such things (messy details).

 

[Kenny McCormack]

Yes

But (again), we're not allowed to think about such things ("why" questions)
here.

 

[Old Wolf]

But (again), we're not allowed to think about such things ("why" questions)
here.

Why?

 

[Nick Keighley]

Why?

Kenny is trolling

 

[August Karlstrom]

There is a fundamental difference between assignment and [compile
time] initialization (as I tried to explain in a different posting in
this thread).

But the distinction between assignment and initialization isn't a
run-time vs. compile-time distinction.

As far as I know, in C compile-time initialization can only be applied
to variables declared outside a function. If that is the case I consider
my statement above to be correct.


August

 

[Ben Bacarisse]

Yes. But we are not compilers.

And to say "0 is assigned to global i at program initialization" is not
exactly going to break the bank.

I would not object to that wording but I would try to avoid in
teaching. The things that can go on the right of the = in an
initialisation are quite different to the things that can go there in
an assignment, so I would want to stress the distinction as soon a
possible since it is not a difficult point. If it were in some way
very complex, I might want to simplify and then expand later, but I
don't think this is the case here.

Initialisations give an initial value to an object through a mechanism
that is quite different to assignment despite the similarity when the
object is not an aggregate.

If you go on to learn other languages, the distinction is even greater
and that can be an important factor when teaching a first language.

 

[Kenny McCormack]

....
Because that's what the regs have decreed.

Kenny is correctly and truthfully pointing out the that the emperor is naked.

HTH.

 

[August Karlstrom]

There is a fundamental difference between assignment and [compile
time] initialization (as I tried to explain in a different posting in
this thread).

But the distinction between assignment and initialization isn't a
run-time vs. compile-time distinction.

As far as I know, in C compile-time initialization can only be applied
to variables declared outside a function. If that is the case I
consider my statement above to be correct.

#include <stdio.h>
int main(void) {
static char hello[] = "Hello, world!";
puts (hello);
return 0;
}

It's impossible to say whether the initialization of hello[] actually
occurs at compile time, but we do know it occurs before main() begins
to execute.

OK, you got me. I should change "compile-time initialization" to
"initialization of variables with static extent."


August