struct problems

[Mark Wooding]

I'd prefer:

struct cat kitty[] =

Seconded; but that changes the semantics of the program quite a bit, and
I didn't want to get into that mess...

[...] at some point you're very likely to want to herd these cats as a
group, rather than as individuals (an unenviable task).

Can felines be marshalled using a catherd ray tube?

-- [mdw]

 

[John Bode]

[...]
    I didn't know that the assignments couldn't be done outside of a
function.
An assignment (when followed by a semicolon) is a statement, and
statements can occur only inside functions.
So you are saying a line like
int bill = 1;
is NOT legal outside a function?

No.  He's saying that an assignment statement (which is an expression
statement) is not allowed outside of a function definition.  What you

I know. Hence I posed the question.

have there is an intialized declarator, which is not the same thing as
an assignment statement.  Both may have an assignment operator in the
middle, but they are not the same thing according to the language
grammar.

Sure. I always have and always will continue to refer to "int b=1;" as
"assigning 1 to be".

Whatever floats your boat. Personally, I think a distinction should
be maintained between "assignment" and "initialization", since a) the
language makes that distinction, and b) some valid initializers are
not allowed in regular assignments (which is part of what was tripping
up the OP).

I wonder if you would consider the DATA statement in Fortran to be the
same thing as an assignment.

No. As you well know. I knew this would happen.

Clairvoyance is *such* a burden, isn't it?

 

[Richard]

[...]
    I didn't know that the assignments couldn't be done outside of a
function.

An assignment (when followed by a semicolon) is a statement, and
statements can occur only inside functions.

So you are saying a line like

int bill = 1;

is NOT legal outside a function?

No.  He's saying that an assignment statement (which is an expression
statement) is not allowed outside of a function definition.  What you

I know. Hence I posed the question.

have there is an intialized declarator, which is not the same thing as
an assignment statement.  Both may have an assignment operator in the
middle, but they are not the same thing according to the language
grammar.

Sure. I always have and always will continue to refer to "int b=1;" as
"assigning 1 to be".

Whatever floats your boat. Personally, I think a distinction should
be maintained between "assignment" and "initialization", since a) the
language makes that distinction, and b) some valid initializers are
not allowed in regular assignments (which is part of what was tripping
up the OP).

Call me clever but I know from where the line is what is happening.

I wonder if you would consider the DATA statement in Fortran to be the
same thing as an assignment.

Why would you wonder that? I am talking about english language. And if
something is set I would indeed say values are assigned.

Clairvoyance is *such* a burden, isn't it?

As is being a clever clogs who feigns confusion with something as simple
as the subject in hand.

 

[Ben Bacarisse]

On Jan 20, 11:02 am, Richard <[email protected]> wrote:

Whatever floats your boat. Personally, I think a distinction should
be maintained between "assignment" and "initialization", since a) the
language makes that distinction, and b) some valid initializers are
not allowed in regular assignments (which is part of what was tripping
up the OP).

And vice versa. You can write the assignment x = f(); but a function
call in not a valid initialiser at file scope.

 

[Richard]

And vice versa. You can write the assignment x = f(); but a function
call in not a valid initialiser at file scope.

I feel I need to rewind here.

I made the observation that the distinction was NOT sufficiently
explained to a noob. And that to a noob and some of us older war horses
too then to say you can not assign outside of a function is confusing
since it would take a special kind of person to suggest that

int b=1;

can NOT be described as assigning a value to b. It might not be an a "C
assignment" but it IS still assigning 1 to b in all but the most
retentive circles.

 

[Mark Wooding]

My main issue was simply its very easy to confuse people.

It is, indeed. Especially beginners.

It is NOT clear to me why anyone would say "int b=1;" is NOT assigning
1 to b.

The main reason is because it isn't assigning. It's initializing.
They're distinct concepts.

I prefer to talk "English" than language dialect when explaining
things. Especially to Bill...

I prefer precision: drawing clear distinctions between distinct concepts
by using different words to describe them. That way confusion is less
likely to arise, and, when it does, we have prepared the vocabulary and
conceptual background necessary to deal with it in advance.

I will graciously withdraw from this thread now to let the usual
suspects huff and puff [...]

I think I might have been close to being a usual suspect about ten years
ago...

-- [mdw]

 

[Mark Wooding]

Pascal had a good answer.

Pascal has a very different syntactic structure. The equivalent
question for Pascal is: `If a statement were allowed outside of any
begin...end block, when would it be executed?'

-- [mdw]

 

[John Bode]

[...]
    I didn't know that the assignments couldn't be done outside of a
function.
An assignment (when followed by a semicolon) is a statement, and
statements can occur only inside functions.
So you are saying a line like
int bill = 1;
is NOT legal outside a function?
No.  He's saying that an assignment statement (which is an expression
statement) is not allowed outside of a function definition.  What you
I know. Hence I posed the question.
have there is an intialized declarator, which is not the same thing as
an assignment statement.  Both may have an assignment operator in the
middle, but they are not the same thing according to the language
grammar.
Sure. I always have and always will continue to refer to "int b=1;" as
"assigning 1 to be".

Whatever floats your boat.  Personally, I think a distinction should
be maintained between "assignment" and "initialization", since a) the
language makes that distinction, and b) some valid initializers are
not allowed in regular assignments (which is part of what was tripping
up the OP).

Call me clever but I know from where the line is what is happening.

So how would you explain it to someone like the OP who apparently
doesn't yet understand the difference? If both are assignments, why
are they treated differently by the language? Why is one okay here
but not there?

I mean, I know *you* get the difference, but for someone just learning
the language calling both an "assignment" probably confuses the issue
more than it helps. If "int bill=1;" is a legal assignment outside of
a function definition, then why isn't "bill=1;" a legal assignment
outside of a function definition? Why can't the OP just write

kitty1={"striper", "striped"};

to assign a struct?

At some point you have to discuss the difference between initializers
and assignment statements *anyway*, so why not do so from the
beginning?

 

[Ben Bacarisse]

I feel I need to rewind here.

There's no need. I am sure we understand each other perfectly well.

I made the observation that the distinction was NOT sufficiently
explained to a noob. And that to a noob and some of us older war horses
too then to say you can not assign outside of a function is confusing
since it would take a special kind of person to suggest that

int b=1;

can NOT be described as assigning a value to b. It might not be an a "C
assignment" but it IS still assigning 1 to b in all but the most
retentive circles.

Yup. That is exactly what you said before. It is still, in my
option, wrong.

 

[Keith Thompson]

int a = 1;
int b = a;

All anyone had to write to show the difference.

How does that show the difference? Those are both initializations
(and the second one would not be allowed outside a function, because
the initialization expression isn't constant).

 

[Keith Thompson]

No. He's saying that an assignment statement (which is an expression
statement) is not allowed outside of a function definition. What you
have there is an intialized declarator, which is not the same thing as
an assignment statement. Both may have an assignment operator in the
middle, but they are not the same thing according to the language
grammar.

Agreed, except for one point: "int bill = 1;" doesn't have an
assignment operator. It does have an "=" token, but it's not an
operator; it's part of the syntax for the declaration, which is
separate from the syntax for an assignment expression.

The language could just as easily have used different symbols for
initialization and assignment (say, "=" for initialization and ":="
for assignment).

[...]

 

[Keith Thompson]

And vice versa. You can write the assignment x = f(); but a function
call in not a valid initialiser at file scope.

Any non-constant expression is not a valid initializer at file scope;
"int x = 42; int y = x;" is illegal at file scope. On the other hand,
a function call is a perfectly valid initializer inside a function
definition.

 

[Default User]

Trying to take the mantle from CBF are we? ;-)

Richard the troll is correct in this case, although it's the fault of
Google Groups. There's nothing Nick can do about it except switch to a
real news service/reader or stop trying to use a .sig.




Brian

 

[Richard Bos]

int* pi, pj;

the person who wrote that might think pj was an int*.

That person should then switch to C++, since he's clearly not paying
enough attention to program in C.

Richard

 

[Bill Cunningham]

[snip]

You should not have learned that. You did find out that assignment
must be done inside a function but at least two posters suggested you
solve the problem you created by trying to assign outside of function
by using an initialisation instead. This which means that
initialisation *is* permitted outside of all functions.

Not that you *should* do this. Local variable are to be preferred in
almost all cases.

[snip]

I understand this much.

int a; /*declaration */
a=1; /* assignment of variable of type int */

This has worked for me outside of functions. I thought what was done outside
of functions was global; default extern and could be used in different
functions.

Bill

 

[Bill Cunningham]

[snip]

I'd prefer:

struct cat kitty[] =
{
{ "striper", "striped" },
{ "spook", "black" }
};

because it's hard to avoid the conclusion that at some point you're
very likely to want to herd these cats as a group, rather than as
individuals (an unenviable task).

Can you elaborate a little more if you would Richard? I see you are
using an array here.
Bill

 

[Keith Thompson]

I understand this much.

int a; /*declaration */
a=1; /* assignment of variable of type int */

This has worked for me outside of functions. I thought what was done outside
of functions was global; default extern and could be used in different
functions.

No, this has not worked for you outside of functions. The line
a=1;
is illegal if it appears outside a function definition.

I suspect what you meant was this:
int a = 1; /* declaration with initializer */
This is legal either inside or outside a function definition. Outside
a function definition, it makes ``a'' "global" -- more precisely, gives it
file scope, external linkage, and static storage duration.

The same line inside a function definition would give ``a'' block
scope, no linkage, and automatic storage duration. In that context,
this:
int a = 1;
is equivalent to this:
int a;
a = 1;
(unless there's some very subtle difference I haven't thought of).

 

[Ben Bacarisse]

No, this has not worked for you outside of functions. The line
a=1;
is illegal if it appears outside a function definition.

I think that depends on what Bill means by "works". Bill will
certainly have been able to compile and run programs with that syntax
despite it being a constraint violation in both C99 and C90 (which is
what I presume you mean by illegal). Even the latest gcc builds an
executable from such source and this may be enough for Bill to say it
works. "Illegal" is not enough to stop a program from compiling,
linking and running.

In early C there was the notion of a:

data-definition:
extern<opt> type-specifier<opt> init-declarator-list<opt> ;

in which everything was optional. Bill's two lines constitute a
declaration and a definition of an int called 'a' with external
linkage and was valid in the (very) old days.

By the time K&R1 came along this syntax had gone, but I remember
compilers sill accepting "a = 1;" at file scope (the extra "int a;" is
harmless) though they probably warned about it as they now must.

<snip>

 

[Keith Thompson]

Was thinking the second wasn't allowed ever. Toss an extern in
front of the first so it's value can't be known at compile time even
inside a function then. Isn't that the real root difference between
initialization and assignment, or call it the why both exist.

No, that's not the difference at all.

An initialization is always part of a declaration. It can occur
either outside any function definition (in which case the initializer
must contain only constant expressions), or at block scope (in which
case the initializer can contain any arbitrary expressions, as long as
they're of the right type).

An assignment is an expression (and adding a semicolon to it makes it
a statement). It's always separate from the declaration of the thing
being assigned to.

For example:

void foo(void)
{
int x = rand(); /* a declaration with an initializer */
int y; /* a declaration with no initializer */
y = rand(); /* an assignment, not a declaration */
/* ... */
}

In informal speech, it's common to mix up the two terms, but when
discussing writing C code it's important to keep the distinction in
mind. One example: it's very common to refer to a variable that's
never had a value assigned to it as "uninitialized"; it can be
"initialized" either with an initializer or with an assignment (or by
calling memcpy, or memset, or ...).

 

[Keith Thompson]

Keith Thompson wrote:

[explanation of declarations vs. assignments snipped]

You have done a nice job of describing the syntax.
Thanks.

You haven't touched on why.

Why what? I really don't know what you're asking.