question about "++"

[mdh]

Given the expression:

while (isaspace(c = *s++))
x+1;
(s is an array)

Does the increment to 's' occur after "x+1" is evaluated, or after
the content of s is assigned to c? Is there a general rule as to when
this type of increment occurs? ( I understand that the increment in "c
= ++*s" occurs immediately before assignment, so my guess is the same
would apply in the "after" scenerio, but not sure).

thank you.

[Richard Heathfield]

mdh said:

Given the expression:

while (isaspace(c = *s++))
x+1;
(s is an array)

Does the increment to 's' occur after "x+1" is evaluated,

No, before.

or after
the content of s is assigned to c?

Maybe.

Here is one possible ordering:

(1) assign *s to c
(2) increment s

Here's another:

(1) assign *s to a temp
(2) increment s
(3) assign the temp to c

Here's another:

(1) increment s
(2) assign *(s - 1) to c

In any event, all is definitely done and dusted before x+1 happens.

Between one sequence point and the next, the compiler has considerable
freedom with regard to what it does when. (Across sequence points, it
has rather less freedom - it can only mess about if a strictly
conforming program can't tell that it has done so.)

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

[mdh]

On May 29, 6:41 pm, Richard Heathfield <[e-mail]:

mdh said:>
while (isaspace(c = *s++))

x+1;

>

Does the increment to 's' occur after "x+1" is evaluated,

No, before.

or after
the content of s is assigned to c?

Maybe.

Here is one possible ordering:

In any event, all is definitely done and dusted before x+1 happens.

thank you Richard. That explains a "bug" I had with s incrementing
before I wanted it to.

[Old Wolf]

On May 30, 1:32 pm, mdh <[e-mail]:

Given the expression:

while (isaspace(c = *s++))
x+1;
(s is an array)

If s is an array then this code has a constraint
violation, as arrays cannot be incremented.

Did you mean (*s)++ ?

[Richard Heathfield]

Old Wolf said:

On May 30, 1:32 pm, mdh <[e-mail]:

>Given the expression:

while (isaspace(c = *s++))
x+1;
(s is an array)

If s is an array then this code has a constraint
violation, as arrays cannot be incremented.

Did you mean (*s)++ ?

At a guess, he meant that s points to an element within an array.

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

[Old Wolf]

On May 30, 2:09 pm, Richard Heathfield <[e-mail]:

Old Wolf said:

Did you mean (*s)++ ?

At a guess, he meant that s points to an element within an array.

Perhaps; but in the original post he gave the
preincrement version as ++*s (not *++s).

[newbee1984]

On May 30, 10:28 am, Old Wolf <[e-mail]:

On May 30, 2:09 pm, Richard Heathfield <[e-mail]:

Old Wolf said:

Did you mean (*s)++ ?

At a guess, he meant that s points to an element within an array.

Perhaps; but in the original post he gave the
preincrement version as ++*s (not *++s).

i think he want to say the increment of 's' occurs before assignment
*s,that's *++s

[mdh]

On May 29, 7:09 pm, Richard Heathfield <[e-mail]:

Old Wolf said:

Did you mean (*s)++ ?

At a guess, he meant that s points to an element within an array.

Good guess :-)

[Richard Heathfield]

mdh said:

On May 29, 7:09 pm, Richard Heathfield <[e-mail]:

>Old Wolf said:

Did you mean (*s)++ ?

At a guess, he meant that s points to an element within an array.

Good guess :-)

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

s = zog; (*s)++;
/* zog is now { 13, 42 }, *s = 13 */

s = zog; *++s;
/* zog is now { 13, 42 }, *s is 42 */

s = zog; ++*s;
/* zog is now { 14, 42 }, *s is 14 */

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

[mdh]

On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0]. On the face of
it, 12 is assigned to zog[0], then the pointer is incremented by one
and dereferenced. This makes sense, but then I looked at P53 of K&R
and am confused. If I read this correctly, the assignment should occur
last, as it is the lowest order of precedence. Then if * and ++ are
of equal precedence ( line 2, same page) and the associativity is
right to left, why am I incorrect ( and I must be ) in saying that *s+
+ = 12 should first increment the pointer, then dereference it, then
assign 12 to that index, and give zog { 6, 12} /** wrong **/ but why?
I will leave the others for now, as I am sure the answer to this will
help with those examples.

Thank you as usual.

>
s = zog; (*s)++;
/* zog is now { 13, 42 }, *s = 13 */

s = zog; *++s;
/* zog is now { 13, 42 }, *s is 42 */

s = zog; ++*s;
/* zog is now { 14, 42 }, *s is 14 */

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

[Chris Dollin]

mdh wrote:

On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>>
Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0].

Yes.

On the face of it, 12 is assigned to zog[0],

Yes, via `s`.

then the pointer is incremented by one and dereferenced.

No. The deference happens as part of the assignment; the increment
happens sometime between the beginning of the statement and the
end.

This makes sense, but then I looked at P53 of K&R
and am confused. If I read this correctly, the assignment should occur
last, as it is the lowest order of precedence.

Be warned. /Precedence/ and /order of evaluation/ are not the
same thing. Precedence says what things are operands of what
operators; order of evaluation says what orders of things happening
are allowable.

In `*s++ = 12`, the order of the assignment and the incrementing
/is not specified/; either can happen before the other.

Then if * and ++ are of equal precedence ( line 2, same page)
and the associativity is right to left, why am I incorrect ( and
I must be ) in saying that *s++ = 12 should first increment the
pointer, then dereference it,

The binding in `*s++` is `*(s++)`. The thing that is dereferenced
is the /value of `s++`/, which is the /original/, unincremented,
value of `s`. Contrast with `++s`, which yeilds the /incremented/
value of `s`.

Note that the increment of `s` doesn't have to take place immediately,
either. It's legal to evaluate `*s++ = 12` as

*s = 12; s += 1

if we can ignore the value of the expression.

--
"If there is a problem, you must confess it, Mr Chaplin"/The Beiderbeck Affair/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[mdh]

On May 31, 3:45 am, Chris Dollin <[e-mail]:

>Be warned. /Precedence/ and /order of evaluation/ are not the

same thing. Precedence says what things are operands of what
operators; order of evaluation says what orders of things happening
are allowable.

Aha...so are you saying that the table on page 53 ( Table 2-1) has
nothing to do with the order of evaluation? ( You say this is
essentially undefined?) Could you please clarify what the term
"associativity" then means?

>

[Chris Dollin]

mdh wrote:

On May 31, 3:45 am, Chris Dollin <[e-mail]:

>>Be warned. /Precedence/ and /order of evaluation/ are not the

same thing. Precedence says what things are operands of what
operators; order of evaluation says what orders of things happening
are allowable.

Aha...so are you saying that the table on page 53 ( Table 2-1) has
nothing to do with the order of evaluation?

My copy of K&R II is at home, but if it's the "usual" table of
precedences, yes.

( You say this is essentially undefined?)

Unspecified. ("Undefined" has a specific meaning here; "all bets
are off, anything could happen, demons could fly out of your nose";
the latter is a Bad Thing even if you have a very heavy cold.)

There are some exceptions: && || ?: and ,-operator have defined
order-of-evaluation rules.

And typically an expression `L op R` can't be evaluated without
first evaluating `L` and `R`. (Exceptions again: || and &&, which
may not need to evaluate `R` at all, and `X ? Y : Z`, which will
evaluate `X` first then exactly one of `Y` or `Z`.)

Could you please clarify what the term
"associativity" then means?

When precedence won't tell you what the operands are, associativity
will. In `A + B + C` it says that it's structured as `(A + B) + C`;
stuff groups to the left.

--
"He could not weigh up which was worse and so tried not to think about either."
/The Spellgrinder's Apprentice/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[mdh]

On May 31, 4:28 am, Chris Dollin <[e-mail]:

>

Be warned. /Precedence/ and /order of evaluation/ are not the

same thing.

Aha...so are you saying that the table on page 53 ( Table 2-1) has
nothing to do with the order of evaluation?

>Unspecified.

Meaning that things that will happen will be as expected,( versus
undefined) except that "my" anticipated order ( with exceptions you
mentioned) can not be relied upon?

Could you please clarify what the term
"associativity" then means?

.........

So it sounds like "associativity" and "binding" is synonymous?

So, may I try and summarize what you have told me?

Precedence "asscociates" an operand with an operator ( unary
operator), or 2 operands with and operator. This is very different
from evaluating an expression. (I looked for a definition of
evaluation, and did not find one, but I suppose conceptually it is the
act of "resolving"? an expression.) What you have said is that with
exceptions, the language does not specify an order in which this is to
occur..and I guess, one has to be careful in crafting code to be
unambiguous, in this regard.

So, to go back where this all started:

>int zog[2] = { 6, 42 };
int *s;

>s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

>The deference happens as part of the assignment; the increment
happens sometime between the beginning of the statement and the
end.

means: ( (*(s++)) = 12 ); /** in terms of precedence **/

Now...I hope I don't get you pulling your hair out ....but...does the
's++' imply that s will only increment AFTER something has happened to
it, which in this case is to have the '12' assigned to that which it
points at, now it is incremented, then it is dereferenced? I think
that I am still a little fuzzy as to the exact meaning of
"evaluation" and "precedence/assocition"..or it may just be too damn
late/early in the morning? :-) In other words, is 's++' an evaluation
or an 'association'? Is it obvious to you what I am perhaps missing?

[Chris Dollin]

mdh wrote:

On May 31, 4:28 am, Chris Dollin <[e-mail]:

>>

Be warned. /Precedence/ and /order of evaluation/ are not the

>same thing.

Aha...so are you saying that the table on page 53 ( Table 2-1) has
nothing to do with the order of evaluation?

>>Unspecified.

Meaning that things that will happen will be as expected,( versus
undefined) except that "my" anticipated order ( with exceptions you
mentioned) can not be relied upon?

It means that the Standard doesn't say what order things happen
in (except when it does), and programs that try to find out risk
falling into Undefined Behaviour.

Could you please clarify what the term
"associativity" then means?

........

So it sounds like "associativity" and "binding" is synonymous?

Associativity is a way of describing how to get the binding (of
operands to operators).

Note that the Standard doesn't talk about precedence and doesn't
talk about associativity: it just has grammar rules. They Are In
Charge.

Precedence "asscociates" an operand with an operator ( unary
operator), or 2 operands with and operator. This is very different
from evaluating an expression. (I looked for a definition of
evaluation, and did not find one, but I suppose conceptually it is the
act of "resolving"? an expression.) What you have said is that with
exceptions, the language does not specify an order in which this is to
occur..and I guess, one has to be careful in crafting code to be
unambiguous, in this regard.

Unambiguous or indifferent.

So, to go back where this all started:

>>int zog[2] = { 6, 42 };
int *s;

>>s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

means: ( (*(s++)) = 12 ); /** in terms of precedence **/

Now...I hope I don't get you pulling your hair out ....but...does the
's++' imply that s will only increment AFTER something has happened to
it,

No.

It's an expression whose result is the original value of `s`. At
some point (here, sometime before the semicolon; the Standard talks
in terms of "sequence points" which cover those && and ?: etc cases)
`s` will be incremented. That may happen before, after, or during the
delivery of `s`s original value.

which in this case is to have the '12' assigned to that which it
points at, now it is incremented, then it is dereferenced?

Well, really `s` isn't dereferenced; it's original value is. It's
because `s` may be incremented any time before the `;` that you
have to be very careful about the language you use.

I think
that I am still a little fuzzy as to the exact meaning of
"evaluation" and "precedence/assocition"..or it may just be too damn
late/early in the morning? :-) In other words, is 's++' an evaluation
or an 'association'? Is it obvious to you what I am perhaps missing?

`s++` is an expression; it has operator `postfix ++` and operand
`variable s`. To evaluate it, deliver the value `s` had before the
(entire) expression was evaluated and arrange for `s` to be incremented
by the time the (entire) expression has finished evaluating.

--
"Go not to the Drazi for counsel, Unsaid /Babylon 5/
for they will answer both 'green' and 'purple'."

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Richard Heathfield]

mdh said:

On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>>

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0]. On the face of
it, 12 is assigned to zog[0], then the pointer is incremented by one
and dereferenced.

No. As a result of *s++ = 12; there are two changes to the values stored
in objects:

* The object zog[0] gets the new value 12
* The object s gets the new value &zog[1]

The order in which these values are given is unspecified.

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

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

mdh said:

>On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>>>

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0]. On the face of
it, 12 is assigned to zog[0], then the pointer is incremented by one
and dereferenced.

No. As a result of *s++ = 12; there are two changes to the values stored
in objects:

* The object zog[0] gets the new value 12
* The object s gets the new value &zog[1]

The order in which these values are given is unspecified.

In the context if single threaded programs dont you think this is
slightly unnecessary complication?

It is playing with the english language.

It is perfectly "normal" so say

"the value 12 is stored at the address held in s, s is then incremented
to point to the next element"

Its why "++" is called increment,

Yes, I know what you are saying, I fail, however, to see the reason why
in the context of a beginner learning post increment and
reference/dereference.

[Richard Heathfield]

Richard said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>mdh said:

<snip>

>>>
So, s is initialized to point at the address of zog[0]. On the face
of it, 12 is assigned to zog[0], then the pointer is incremented by
one and dereferenced.

No. As a result of *s++ = 12; there are two changes to the values
stored in objects:

* The object zog[0] gets the new value 12
* The object s gets the new value &zog[1]

The order in which these values are given is unspecified.

In the context if single threaded programs dont you think this is
slightly unnecessary complication?

Not at all. Getting "order of evaluation", "precedence", and
"associativity" separated out is a key step in the journey from
accident to design.

It is playing with the english language.

It is perfectly "normal" so say

"the value 12 is stored at the address held in s, s is then
incremented to point to the next element"

Yes, and that's (roughly) how I'd choose to say it, were it not for the
fact that it is *misleading*, given that this is the very point about
which the O.P. is confused and seeks clarification.

Its why "++" is called increment,

Yes, I know what you are saying, I fail, however, to see the reason
why in the context of a beginner learning post increment and
reference/dereference.

The fact that you fail to see a reason for something does not mean that
no reason exists.

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

[Ben Bacarisse]

mdh <md**@comcast.netwrites:

On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>>

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0]. On the face of
it, 12 is assigned to zog[0], then the pointer is incremented by one
and dereferenced.

At the risk of labouring the point, imagine executing a C program on a
computer consisting of room full of people. The C standard states
that we can only be sure of what has and has not happened at certain
points. These are the "sequence points" you may have heard about and
we may only open the door of the room at these sequence points.

The program starts:

int zog[2] = { 6, 42 };

We open the door (the ; is a sequence point) and we see two people
standing in a row called zog[0] and zog[1]. They have 6 and 42 pounds
in their pockets respectively. We close the door.

s = zog;

We open it, and see a person, s, pointing at zog[0]. We close the
door.

*s++ = 12;

Upon opening the door we know that the person s was pointing at when
we last looked will now have 12 pounds in his/her pocket, and that s
will now be pointing at the next person in the zog line (zog[1]).
*s++ means "the person s was pointing at (oh, and make sure you are
pointing at their neighbour when we next get to look)".

You are not allowed to know, or even care, exactly what happened in
the room while you were not looking. Did the 12 pounds go into the
pocket before, after, or during s's arm movement? You can't tell and
you should not care.

The *reason* the standard is like this, is to allow compilers (which
issue much more detailed instructions to the people in the room) a
lot of flexibility so they can arrange thing as efficiently as
possible. The compiler might have told s to give zog[0] an extra six
pounds while moving her arm -- no assignment of 12 and no absolute
ordering of the events either.

--
Ben.

[Bart van Ingen Schenau]

mdh wrote:

On May 31, 4:28 am, Chris Dollin <[e-mail]:

>>

Be warned. /Precedence/ and /order of evaluation/ are not the

>same thing.

Aha...so are you saying that the table on page 53 ( Table 2-1) has
nothing to do with the order of evaluation?

>>Unspecified.

Meaning that things that will happen will be as expected,( versus
undefined) except that "my" anticipated order ( with exceptions you
mentioned) can not be relied upon?

No.
Meaning that the compiler can use any order it likes, as long as the
correct operands are used for each operator.

>

Could you please clarify what the term
"associativity" then means?

........

So it sounds like "associativity" and "binding" is synonymous?

So, may I try and summarize what you have told me?

Precedence "asscociates" an operand with an operator ( unary
operator), or 2 operands with and operator.

Almost.
The combination of precedence and associativity can tell you (in most
cases) which operands an operator works on.
Basically, precedence and associativity tell you how to create a fully
parenthesised expression that is equivalent to the original expression.

As an example, we take the expression
*s++ = 12
Precedence tells us that = has low precedence, and ++ and * have the
same, higher, precedence. This leads to the parenthesised form
(*s++) = 12
Because * and ++ have the same precedence, we can't use that to place
further parentheses. Now associativity comes into play. The
associativity of these operators is 'right to left', so that is the
order in which we should place our next parentheses:
(*(s++)) = 12
Now it is clear that the * operates on the result of the expression s++.

This is very different
from evaluating an expression. (I looked for a definition of
evaluation, and did not find one, but I suppose conceptually it is the
act of "resolving"? an expression.) What you have said is that with
exceptions, the language does not specify an order in which this is to
occur..and I guess, one has to be careful in crafting code to be
unambiguous, in this regard.

Or even better, write code that does not care about the order of
evaluation.

>
So, to go back where this all started:

>>int zog[2] = { 6, 42 };
int *s;

>>s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

>>The deference happens as part of the assignment; the increment
happens sometime between the beginning of the statement and the
end.

means: ( (*(s++)) = 12 ); /** in terms of precedence **/

In terms of the combination of precedence and associativity. (or more
correct: in terms of the language grammar).

>
Now...I hope I don't get you pulling your hair out ....but...does the
's++' imply that s will only increment AFTER something has happened to
it, which in this case is to have the '12' assigned to that which it
points at, now it is incremented, then it is dereferenced?

Not exactly.
You can interpret 's++' best as: Schedule an increment of s and continue
working with the old value.
In the same way, ++s can be read as: Schedule an increment of s and
continue working with the new value.

For a well-formed program, it does not matter when the compiler finally
gets around to perform the scheduled increment.

I think
that I am still a little fuzzy as to the exact meaning of
"evaluation" and "precedence/assocition"..or it may just be too damn
late/early in the morning? :-) In other words, is 's++' an evaluation
or an 'association'? Is it obvious to you what I am perhaps missing?

I would call it both.
To me, association is the process of determining which operands an
operator works on, so the operator++ is associated with the operand s.
Evaluation is more a runtime thing, where the actual calculation is
performed.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[mdh]

On May 31, 10:34 am, Bart van Ingen Schenau <[e-mail]>
wrote:

mdh wrote:
Thanks Bart for that nice explanation and thanks all for the help in trying to understand this. It really did take time to understand the concept of "ordering", or more specifically, the lack thereof to the compiler. The explanation of sequence points finally cemented this for me. (I am not sure if "2" thank-you s will appear as once again, Google is on the Fritz....which seems to be happening just about weekly now. )

thanks all again.

[Barry Schwarz]

On 31 May 2007 03:35:27 -0700, mdh <md**@comcast.netwrote:

>On May 30, 12:50 am, Richard Heathfield <[e-mail]:

>>

Beware. *s++ and (*s)++ mean different things.

int zog[2] = { 6, 42 };
int *s;

s = zog; *s++ = 12;
/* zog is now { 12, 42 }, *s = 42 */

At the risk of showing total ignorance...( except by now I suppose a
lot of people who answer my queries are used to this !!! :-))

So, s is initialized to point at the address of zog[0]. On the face of
it, 12 is assigned to zog[0], then the pointer is incremented by one
and dereferenced. This makes sense, but then I looked at P53 of K&R
and am confused. If I read this correctly, the assignment should occur
last, as it is the lowest order of precedence. Then if * and ++ are
of equal precedence ( line 2, same page) and the associativity is
right to left, why am I incorrect ( and I must be ) in saying that *s+
+ = 12 should first increment the pointer, then dereference it, then
assign 12 to that index, and give zog { 6, 12} /** wrong **/ but why?
I will leave the others for now, as I am sure the answer to this will
help with those examples.

You need to distinguish between the evaluation of an operator (or
perhaps more precisely the expression the operator is part of) and any
side effect the operator may have.

The ++ operator always evaluates to the original value of its operand.

As a side effect, it increments the value of the operand. The only
thing you know about the timing of this side effect is that it will be
completed at or before the next sequence point.

For your example:

*s++ associates right to left and therefore is parsed as
*(s++). We know that s++ evaluates to &zog[0]. We also know that s
will eventually be incremented to &zog[1] but that has nothing to with
the evaluation of the expression s++.

The * operator will be applied to the evaluated expression (it
is completely unaffected by the side effect) and will result in the
object zog[0]. Therefore the left operand of the = operator is
zog[0].

The actual incrementing of s can occur any time the compiler
feels like it as long as the resulting executable code evaluates the
expression correctly.
Remove del for email

[mdh]

On May 31, 6:41 pm, Barry Schwarz <[e-mail]:

>>

You need to distinguish between the evaluation of an operator ....... and any
side effect....

The ++ operator always evaluates to the original value of its operand.

As a side effect, it increments the value of the operand.......
completed at or before the next sequence point.

For your example:

*s++ associates right to left and therefore is parsed as
*(s++). We know that s++ evaluates to &zog[0]. We also know that s
will eventually be incremented to &zog[1] but that has nothing to with
the evaluation of the expression s++.

The * operator will be applied to the evaluated expression (it
is completely unaffected by the side effect) and will result in the
object zog[0]. Therefore the left operand of the = operator is
zog[0].

And this was certainly a large part of the confusion for me.

And, as you say in the next paragraph, understanding that "timing"
plays no role, is crucial, and has been nicely pointed out, by you
here.

>
The actual incrementing of s can occur any time the compiler
feels like it as long as the resulting executable code evaluates the
expression correctly.

Thank you Barry. I think this, as RH explained, once understood,
really does take one to the next level of understanding of C. I am
just beginning to wonder how many levels there are? :-)

[CBFalconer]

Barry Schwarz wrote:

>

.... snip ...

>
For your example:

*s++ associates right to left and therefore is parsed as
*(s++). We know that s++ evaluates to &zog[0]. We also know that
s will eventually be incremented to &zog[1] but that has nothing
to with the evaluation of the expression s++.

Which I suspect is the cause of the confusion. People aren't
separating the side effect (incrementing) from the value of the
expression (unincremented). For this ignore the *, which uses the
value of the expression.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Bart van Ingen Schenau]

mdh wrote:

Thank you Barry. I think this, as RH explained, once understood,
really does take one to the next level of understanding of C. I am
just beginning to wonder how many levels there are? :-)

There always seems to be at least one level more that you have not
reached yet.
In contrast, in C++ there always seem to be at least 10 levels more :-)

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[Johan Bengtsson]

Bart van Ingen Schenau wrote:

mdh wrote:

>Thank you Barry. I think this, as RH explained, once understood,
really does take one to the next level of understanding of C. I am
just beginning to wonder how many levels there are? :-)

There always seems to be at least one level more that you have not
reached yet.
In contrast, in C++ there always seem to be at least 10 levels more :-)

Winning IOCCC (or even making an entry) is one personal goal of mine and
lots of level up (I am not that far away - from making an entry...)
Perhaps not a recommendable goal in life and not a recommended level to
reach for "normal" programming but anyway...