++*ptr and *ptr++ (Pointer arithmetic)

Okay, so I've learnt that:

1) ++*p means incrementing the value of de-referenced p
2) *p++ means incrementing p to the next address and de-referencing it

Code:

---

#include <iostream>


int main (void)
{
    int My_arr[] = { 1 , 4 };

    int* ptr = My_arr;

    std::cout << ++*ptr;
    std::cout << " " << *ptr++;

    return 0;
}

---

I expected the results to be "2 4" from what I've learnt. But, I'm getting "2 2" instead. I've compiled my code on C::B with latest GCC.

Am I invoking undefined behaviour by writing the incremental statements with cout?

[EDIT]
I feel like an idiot for starting this thread... I figured out what's happening. Doing a "cout << *ptr++" means display "*ptr" first and then increment it. Sorry for wasting the time of anyone who looked through this post...
[/EDIT]

I had this question come in a test a few months back. (Just so I don't seem like a complete idiot, here's the question for beginners in Pointers ;)) (Don't use a compiler though)

Code:

---

int Ar[] = { 10 , 13 , 1 , 4 , 2 , 6 , 7 } , I;

int *P = Ar;

cout << *P++ << "@";

I = Ar[3] - Ar[2];

cout << ++*P++ << "@\n";
cout << ++I + *P++ << "@";
cout << ++*P << "@\n";

for ( ; I >= 0 ; I-=2 )
    cout << Ar[I] << "@";

---

I'm guessing this pretty much has different behaviour with different optimisation settings but I don't know. Have fun!

Quote:

---

I'm guessing this pretty much has different behaviour with different optimisation settings

---

Quite likely, since the program invokes undefined behaviour (line 9).

Also beware of operator precedence with things like ++*P.

Quote:

---

Originally Posted by jimblumberg

Quite likely, since the program invokes undefined behaviour (line 9).

---

Line 9 actually is not undefined behavior. ++*P++ increments both P and *P once each.

@christop

What @jimblumberg is saying is correct.

It is among the "ISO" coding standards to never mix these operations in a single clause that way (Stroustrup/Sutter's site on ISO C++).

Very true. I was reading the Stroustrup FAQ and a PDF that I came across on the internet while doing my research on the evolution of C and C++. There's so many ways I've been invoking undefined behaviour in some of my programs that I didn't know about until I read through the PDF which cited many different examples (I would link it here but the PDF exceeds the max file size). There's so much to learn tbh that I have no clue about. Well, its all part of the learning process. I've been so into researching and reading more about programming and game development in the last 2 months that I've started to lack in my core subjects at school (Phy, Chem, Math). It's my last year in school so I need to get back to studying more of my core subjects but programming is so much more interesting. :)

Quote:

---

Originally Posted by Niccolo

@christop

What @jimblumberg is saying is correct.

It is among the "ISO" coding standards to never mix these operations in a single clause that way (Stroustrup/Sutter's site on ISO C++).

---

But it has defined behavior. There's no ambiguity in ++*P++. It is equivalent to ++*(P++) because of operator precedence. It increments the object pointed to by P and then increments P (it's implementation defined when P is actually incremented, but the result of the expression is defined).

If the same object were modified more than once between sequence points (with something like P++ - ++P), then it would be undefined, but two different objects are being modified in that statement.

Can you quote or link to Stroustrup's site where he says that statement is undefined?

Quote:

---

Originally Posted by Niccolo

@christop

What @jimblumberg is saying is correct.

---

Actually, jimblumberg said two things, and while the second one is certainly correct advice, christop was talking about the first one, i.e., concerning ++*P++ having undefined behaviour.

I think christop's analysis is correct: while it is true that the increment of P and the increment of *P are unsequenced relative to each other, the same object is never modified more than once in operations unsequenced relative to each other. Furthermore, the syntax constrains it such that the increment of P must happen as if it happened before the increment of *P, just like how in the expression *p++ the increment of p must happen as if it happened before the dereference of p, even though they are unsequenced relative to each other. Consequently, the behaviour is well defined, although of course the expression remains obfuscated.

Quote:

---

Originally Posted by Niccolo

It is among the "ISO" coding standards to never mix these operations in a single clause that way (Stroustrup/Sutter's site on ISO C++).

---

You're referring to the C++ Core Guidelines, and calling that "ISO" even if in quotes is misleading: it is even less of an ISO standard than an ISO draft standard. (This also means that while any proclamation about undefined behaviour there should be taken very seriously on the strength of Stroustrup et al., it is not necessarily correct, unlike the C++ standard itself.) The guideline about avoiding complex expressions is because of readability and sometimes they get written wrongly such that they result in undefined behaviour, not because such expressions always result in undefined behaviour.