-1

I'm confused. I would expect that the first print statement in the function would print 6 and not 5. Because a++ + c++ = (1+1) + (3+1) = (2+4 = 6).

#include <iostream>
#include <string>

int main()
{
    int a = 1;
    int b = 2;
    std::cout << "intitialisation b:"<< b << std::endl;
    int c = 3;
    {
        auto b = ++a + c++;
        std::cout << "increment b in function:" << b << std::endl;
        auto e = b;
        c += ++b;
        std::cout << "increment b in function:" << b << std::endl;
    }
    std::cout << "increment b out function:" << b << std::endl;
    int* p = &a;
    int* q = &b;
    std::cout <<"value pointer:" << *q << std::endl;
    ++(*q);
    std::cout <<"value pointer:" << *q << std::endl;
    *p += a++ + (*p)++;
}
 
intitialisation b:2
increment b in function:5
increment b in function:6
increment b out function:2
value pointer:2
value pointer:3

Nadine

Nadine
  • 51
  • 6
  • 3
    `++a` returns value after incremening. `c++` returns value before incrementing. – MikeCAT Nov 18 '20 at 16:21
  • Also, your code and your question text don't really match. – Adrian Mole Nov 18 '20 at 16:22
  • `the first print statement` the __first__ prints `intitialisation b:2` – KamilCuk Nov 18 '20 at 16:24
  • 3
    You posted the same code before and we already know that `*p += a++ + (*p)++;` does no good. Please consider to reduce your code to a [mcve] in case your question is only about `auto b = ++a + c++;`. You already got an answer that refers to the code as a whole, but I suppose the answerer would not be too upset if you changed your code – 463035818_is_not_an_ai Nov 18 '20 at 16:51

1 Answers1

0

The behaviour of the statement

*p += a++ + (*p)++;

is undefined. That's because you have simultaneous reads and writes to a (sometimes via the pointer) in an unsequenced step.

That means that the entire program is undefined, somewhat paradoxically perhaps, including any statements that, conceptually speaking, have already been ran prior to that one. And that includes the specific statement you're asking about!

Setting that aside, ++a evaluates to the incremented value of a, c++ evaluates to the unincremented value of c. So if there were no undefined constructs in your code, the output would be 2 + 3 which is 5.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • is it really like that? I watched a video recently, admittedly half asleep, and my takeaway message was that there are points of observable behavior and when there is UB between two points of observable behavior then from there on the program has UB. Can you back it up somehow, to make it more convincing? Any reference? – 463035818_is_not_an_ai Nov 18 '20 at 16:27
  • Apart from the last sentence, you wrote this [answer](https://stackoverflow.com/a/64894751/8372853) already, in response to the same OP, with the same code, just a couple of hours ago, so it should be quite clear that the UB part of the code is not relevant to this question. – cigien Nov 18 '20 at 16:29
  • @cigien read it again. The answer says that UB is traveling back in time, which is correct, I am just not convinced that it travels back that far – 463035818_is_not_an_ai Nov 18 '20 at 16:29
  • @cigien: Ha was it the same OP? I didn't check that - I only have my UB hat on today. In many ways this one is more interesting (it has the whole previous-statement-is-therefore-ub thing), but I may well tin it to keep the site clean. – Bathsheba Nov 18 '20 at 16:29
  • @idclev463035818: It travels right back to the first statement in `main()`. There's a *really* good question on this out in SO somewhere - I'll try to find it. – Bathsheba Nov 18 '20 at 16:30
  • this one https://stackoverflow.com/questions/24527401/undefined-behavior-causing-time-travel ? – 463035818_is_not_an_ai Nov 18 '20 at 16:31
  • I don't think the UB part of the code is relevant actually, and I think that can be edited out of the question instead. – cigien Nov 18 '20 at 16:31
  • @idclev463035818: I seem to recall seeing a better one. It's a pity that the great Kerrek SB no longer contributes. – Bathsheba Nov 18 '20 at 16:32
  • @cigien its not relevant for the question, thats why I suggested OP to reduce the code to a [mcve]. (removed that comment after this answer was posted) But the UB is relevant for the code as a whole and all its output (if this question is correct, which is what I am trying to get convinced) – 463035818_is_not_an_ai Nov 18 '20 at 16:33
  • @Bathsheba a pity indeed. Don't worry, I'll try to find it myself. You triggered my curiosity thats already a lot ;) – 463035818_is_not_an_ai Nov 18 '20 at 16:34
  • @idclev463035818: If I'm waiting for some tests to run later this evening, I'll try to come up with some code where prior statements are optimised out by aggressive compilers due to future UB statements (on the basis that a compiler is allowed to assume there are no undefined statements). – Bathsheba Nov 18 '20 at 16:35
  • @idclev463035818 Fair enough. Since the UB in the OP's code doesn't actually affect the behavior they're asking about, it feels like a red herring. But you're right, it's up to the OP to decide that. – cigien Nov 18 '20 at 16:43
  • There's some very fun examples [here](https://www.youtube.com/watch?v=ehyHyAIa5so) including time travel effects :) – cigien Nov 18 '20 at 16:45
  • @cigien: But it might! A standards compliant compiler with optimisations turned up to the maximum may well generate `int main(){}`. As compilers get more and more aggressive, these things are starting to happen with code that contains UB. – Bathsheba Nov 18 '20 at 16:45
  • Sure, I'm not disputing that it *could* affect the behavior, I'm just saying that it doesn't in this case. If the question is not edited, then it's just a dupe of the "undefined behavior and sequence points" target :( – cigien Nov 18 '20 at 16:48
  • 1
    @cigien I readded my comment, lets see what happens – 463035818_is_not_an_ai Nov 18 '20 at 16:52
  • 1
    @idclev463035818 • A former co-worker of mine wrote up a nice blog post on [Undefined behavior can result in time travel](https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633). Undefined behavior is the stuff nightmares are made of. – Eljay Nov 18 '20 at 17:55
  • @Eljay I know about the effect, but I haven't seen a conclusive example along the line of `int x = 0; /*some code all fine*/ std::cout << x; int y; std::cout << y;` yet. The second `cout` is UB no doubts, what guarantees do I get for the first? I know this is purely academical and maybe I am overthinking it, but ... you know... nightmares and all that, maybe it is a little less bad than this answer wants me to believe – 463035818_is_not_an_ai Nov 18 '20 at 18:33
  • @Eljay thanks for the article anyhow. – 463035818_is_not_an_ai Nov 18 '20 at 18:41