🚀 go-pugleaf

On Sun, 10 Dec 2000 21:54:59 -0500, Chun Jia <jiac@purdue.edu> wrote:
>Hi,

>I have tried a simple problem to understand pointers but found the cout
>give me a wrong output in my LM7.2 of a PIII box where the version on
>the Sun workstation give me the right output.

Your assumption is incorrect.  There is no "right output" for this program
under standard C++, because the program modifies an lvalue (the pointer p)
twice between sequence points, which results in undefined behavior
according to the C++ standard (and any visible behavior is possible).

> So there must be sth wrong
>with the LM7.2's g++ compiler.

Nope.  I'm afraid you misunderstand the (lack of) guarantees provided by
the C++ standard.

>The code is as below:

[ snipped all but the key part ]

>        cout<<"p= "<<p<<endl
>            <<"*p= "<<*p<<endl
>            <<"p++= "<<p++<<endl
>            <<" *p++= "<<(*p++)<<endl
>            <<" p= "<<p<<endl
>            <<" *p= "<<*p<<endl;
>}

Note that both of the postincrement operations take place in the same
expression, which means that 'p' can be modified twice without an
intervening sequence point (function call or end-of-expression, roughly).
This happens because function arguments can be evaluated in any order.

A simplified example:

	cout << "a=" << a++ << " a+1=" << a++;

can be written in function notation as:

	operator<<(				// 1
		operator<<(			// 2
			operator<<(		// 3
				operator<<(	// 4
				cout		// 5
				, "a=")		// 6
			, a++)			// 7 (i & ii)
		, "a+1=")			// 8
	, a++);					// 9 (i & ii)

This imposes a partial ordering on evalution, because the operands to a
function must be evaluated (i.e. calculated, with attendant side effects)
before that function is called.  But the ordering is not total - there
are several valid orderings:
	5, 6, 4, 7, 3, 8, 2, 9, 1 is one;
	5, 6, 7, 8, 9, 4, 3, 2, 1 is another; or, for that matter,
	9, 8, 7, 6, 5, 4, 3, 2, 1 is still another.

This example is actually a little more complicated, because lines 7 & 9
each embody two actions:  evaluate 'a', (subaction i above) and increment
'a' (subaction ii above).  The incrementing can actually happen any time
before the next sequence point.  Thus, we have more possible orderings:

	9i, 8, 7i, 9ii, 7ii, 6, 5, 4, 3, 2, 1; or
	9i, 9ii, 7i, 8, 7ii, 6, 5, 4, 3, 2, 1; or even
	9i, 8, 7i, 7ii, 9ii, 6, 5, 4, 3, 2, 1 (!)

or other possible permutations.

Since the two increment operations can be seen in the above example to
come out of order with respect to their evaluations, it is impossible
for the standard to say what the actual output of this program will be.

Thus, it is undefined - and any output (or none at all) is possible for
a program produced by a valid C++ compiler.

[ outputs that the program produced on two different compilers snipped ]

Both of these outputs are valid, since the behavior is undefined.

You also note that

> Actually, if I place extra cout after each endl, the output
>is correct.

This is because the introduction of the 'cout's means that you are also
adding ';'s, which produce sequence points which force the output into
the pattern you expect.

>Any response welcome.

Hope this helps,
-- 
    - Don Waugaman (dpw@cs.arizona.edu)    O-             _|_  Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/            |   for food
In the Sonoran Desert, where we say: "It's a dry heat..."  |     <><
Three out of every four people make up 75 percent of the population.