A Stupid Question. Pls Help.

[Antigloss]

Given the following program

#include <stdio.h>

int main(void)
{
    int a = 5;

    printf( "%d\n", ++a * --a );
}

Will it guaranteed to print 25 ?
I compiled it using vc6 and gcc3.2, and the result were 25.
But I doubt if it's guaranteed.
The standard didn't define whether ++a or --a is evaluated first, right? So, if ++a is evaluated first, then it will be a temperory variable hold 6 at the left-hand-side of operator *, right? Ater that, --a is evaluated and generates a temperory variable hold 5, right? So the result will be 6 * 5 = 30.
If --a is evaluated first, then the result will be 5 * 4 = 20, right?

[loko]

a = 5;

I was expecting 30 was the output but you said its 25.

I compiled it with turbo C i got 30.

Devc++ gave me 25 .

[kermit]

Have a look at this.

[cwr]

To reiterate the above FAQ link, it's worse than just an ambiguous order, the expression is undefined. The compiler could make the code format your hard drive and still be conforming, however unlikely that is.

[Antigloss]

hmm...
Then what about the order of the evaluation? Is it guaranteed that ++a will be evaluated first? Or is the order of evaluation undefined?

[cwr]

The whole expression is undefined, the order of evaluation is irrelevant, and yes, undefined. Once the expression is undefined, everything is undefined.

#include <stdio.h>

int main(void)
{
    int a = 5;

    printf( "%d\n", ++a * --a );
}

If I ran that code, and it outputted "-42", I couldn't complain my compiler was buggy.

[prasath]

In Case of Visual c++, the order of evaluation will from right to left and on the precedence of operators

#include <stdio.h>

int main(void)
{
    int a = 5;

    printf( "%d\n", ++a * --a );
    return 0;
}

from right to left and higher precedence for pre incrementing operators than multiplication operator.so compiler will execute like this
value of "a" after decrementing will be 4
value of "a" after incrementing will be 5

now value of a is 5

so the result is 25.

regards
prasath

[cwr]

In Case of Visual c++, the order of evaluation will from right to left and on the precedence of operators

#include <stdio.h>

int main(void)
{
    int a = 5;

    printf( "%d\n", ++a * --a );
    return 0;
}

from right to left and higher precedence for pre incrementing operators than multiplication operator.so compiler will execute like this
value of "a" after decrementing will be 4
value of "a" after incrementing will be 5

now value of a is 5

so the result is 25.

regards
prasath

Visual C++ documents this behaviour? That's disgusting, it's undefined in C. Don't expect the code to work on another compiler. Is there an online link of this documentation? I'm interested to read it. I don't have Visual C++, or Windows.

[Dave Evans]

In Case of Visual c++, the order of evaluation will from right to left and on the precedence of operators

Not true:

from msdn

Order of operations is not defined by the language. The compiler is free to evaluate such expressions in any order, if the compiler can guarantee a consistent result.

Only the sequential-evaluation (,), logical-AND (&&), logical-OR (||), conditional-expression (? :), and function-call operators constitute sequence points and therefore guarantee a particular order of evaluation for their operands.

So Microsoft documentation agrees with the C standard: the order of evaluation for operators ++ and -- is undefined.

There is room for confusion between "order of evaluation" and "order of assignment" of components of an expression. The order of evaluation for things like ++ and -- is undefined.

As far as Microsoft compilers: consider the following:

#include <stdio.h>

int main(void)
{
    int a = 5;
    int b = 5;

    printf("astuff = %d\n", ++a * --a);
    printf("bstuff = %d\n", --b * ++b);

    return 0;
}

My output with Visual C++ from Visual Studio 6:

astuff = 25
bstuff = 25

It doesn't matter what the compiler prints here, the values of the expressions are undefined. Any compiler can give whatever answer it wants to.

Borland bcc32 gives this:

astuff = 30
bstuff = 20

GNU gcc (cygwin on Windows XP) gives this

astuff = 25
bstuff = 25

None of these is the "right" answer. None of these is the "wrong" answer. The values of the expressions are undefined.

Regards,

Dave

[itsme86]

The values of the expressions are undefined.

Not just the values. People tend to underestimate what the C standard means when it says something is "undefined." It doesn't just mean it can set the value to whatever, it means the program could make your computer do any arbitrary thing. It's much worse than just having an unpredictable end value. It's like trying to divide a number by 0.

[Dave Evans]

Not just the values. People tend to underestimate what the C standard means when it says something is "undefined." It doesn't just mean it can set the value to whatever, it means the program could make your computer do any arbitrary thing. It's much worse than just having an unpredictable end value. It's like trying to divide a number by 0.

The order of evaluation is unspecified. Unspecified behavior is not the same as undefined behavior. I should have been more careful with my terminology. Since the order of evaluation is unspecified, the values of the expressions are unspecified.


ISO/IEC 9899

3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.


3.4.4
1 unspecified behavior
behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

2 EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated.

.
.
.

J.1 Unspecified behavior
1 The following are unspecified:

.
.
.

— The order in which subexpressions are evaluated and the order in which side effects take place, except as specified for the function-call (), &&, ||, ?:, and comma operators (6.5).

So the compliant compiler is allowed to use any order of evaluation that it wants to, but is not free to format your hard drive.

Also, note that no matter what order of evaluation you apply, the value of neither of the expressions in my example will be 42, so we must continue to look for the Question.

Regards,

Dave

[kermit]

But even with the new 64 bit processors, the computers are still not big/fast enough to figure out exactly what the question is.