i = i++ for class types...still undefined?

[Phlip]

This might be a question for another posting or group, but here goes...

int n = 0;

n = n++; //Undefined due to multiple modifications between SP

If this is undefined why even allow it to compile?

Compilers are not required to specify what happens to undefined behavior.
When the behavior is easy to detect, the compiler might bounce it, or warn
about it.

When the behavior is hard to detect, a compiler

And a compiler might just produce opcodes without bothering to warn
anything, even if it's easy to detect.

Consider:

SimCity & aCity = *(SimCity *) NULL;

Null references are undefined. The indefinity occurs at the left star *.
However, if a compiler added a check for this situation, it would commit to
checking where the right argument is less obvious. Checking at runtime would
slow down millions of innocent and correct dereferences. So the compiler
compiles the well-formed code, and lets the programmer live with the
consequences of their actions.

What is the value in allowing this to be syntatically correct yet saying
anything at all could happen?

As a false convenience for naive programmers.

But what if n and m were references to the same integer. A compiler might
not easily be able to check that. If it can't check all forms of a
situation, it won't check any, including the obvious ones.

 

[Pete Becker]

This might be a question for another posting or group, but here goes...

int n = 0;

n = n++; //Undefined due to multiple modifications between SP

If this is undefined why even allow it to compile?

Because that's a simple example of a more complicated problem:

void f(int& a, int& b)
{
a = b++;
}

int i = 3;
f(i,i);

Generally speaking this problem isn't easy to recognize, so the standard
doesn't require a diagnostic (the standard never requires that something
not compile -- that's the hook for conforming extensions: issue a
diagnostic then do the extension).

 

[Old Wolf]

Pete Becker posted:

Why would you think that?

signed main()
{
int i = 5;

i = i++;
}

If we're to be realistic, then I am right, there's two possible things that
may happen.

I've heard of a compiler that results in i == 11, and of one that
causes a segmentation fault, for that code

Overall, you think that you are right and I think that I am right. There's
no more arguments so it look like end of conversation.

You left out one minor detail: the standard (and the C faq and the C++ faq)
say that you are wrong and Pete is right.

 

[Pete Becker]

Please be more careful with attributions. I didn't write anything in the
text you included.

 

[Ron Natalie]

This might be a question for another posting or group, but here goes...

int n = 0;

n = n++; //Undefined due to multiple modifications between SP

If this is undefined why even allow it to compile?

In this case a compiler could recognize the undefined behavior and issue
a diagnostic. It is free to do so. However with a more complex expression:

int x;
int* p1 = &x;
int* p2 = &x;

// obfuscating pointer manipulations

*p1 = *p2++;

etc... might not be detectable at compile time.