0
#include <iostream>
using namespace std;
class A {
    int x, y;

public:
    A(int a, int b)
    {
        x = a;
        y = b;
    }
    void out()
    {
        cout << "\nx=" << x << "\ny=" << y;
    }
    void operator++(int)
    {
        x = x++;
        y = y++;
    }
};
int main()
{
    A ob(5, 20);
    ob.out();
    ob.operator++(2);
    ob.out();

    return 0;
}

When I use only X++ it works but when I use X=X++ it doesn't increment the values. I don't understand why does this happening.

it gives 2 errors as

operation on '((A*)this)->A::x' may be undefined [-Wsequence-point]
operation on '((A*)this)->A::y' may be undefined [-Wsequence-point]

In the output values are not changed

x=5
y=20
x=5
y=20
drescherjm
  • 10,365
  • 5
  • 44
  • 64
Satyabrata Kar
  • 19
  • 4
  • 5
    why would you want to write `x = x++;` ? – 463035818_is_not_an_ai Nov 24 '21 at 14:06
  • 4
    `x = x++` (for any `x`) have always been *undefined behavior*. – Some programmer dude Nov 24 '21 at 14:06
  • 3
    btw `void` return for `operator++` is not wrong but uncommon and surprising – 463035818_is_not_an_ai Nov 24 '21 at 14:07
  • 3
    This https://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points and this https://stackoverflow.com/questions/4421706/what-are-the-basic-rules-and-idioms-for-operator-overloading – 463035818_is_not_an_ai Nov 24 '21 at 14:08
  • 1
    Do you ***want*** to increment X or not? If you do, simply write `X++;`. If not, don't. – Tim Randall Nov 24 '21 at 14:11
  • I would say that `void` return for `operator++(int)` *and* explicitly calling `operator++(2)` *with argument* are both so surprising that they are wrong. @463035818_is_not_a_number I would agree that `void` return for `operator++()` is just a bit suprising. – Hans Olsson Nov 24 '21 at 14:12
  • 3
    @Someprogrammerdude Didn't C++17 make `x = x++;` defined behavior with the new guarantees on assignment ordering and sequencing? – NathanOliver Nov 24 '21 at 14:13
  • @HansOlsson "just a bit surprising" is evil enough, maybe I wasnt clear about that. Surprises are not nice and lead to bugs and errors – 463035818_is_not_an_ai Nov 24 '21 at 14:14
  • I want to know the answer to @NathanOliver's comment. Should that be a separate question? – Tim Randall Nov 24 '21 at 14:16
  • 1
    @TimRandall Not sure. Found [this answer](https://stackoverflow.com/a/46171943/4342498) on the sequencing canonical which seems to answer that question. Not sure if we need a Q explicitly for that one point. – NathanOliver Nov 24 '21 at 14:18
  • 3
    @TimRandall See rule 20 : https://en.cppreference.com/w/cpp/language/eval_order#Rules – François Andrieux Nov 24 '21 at 14:18
  • @NathanOliver It seems like I missed that... :) Thanks for pointing it out. – Some programmer dude Nov 24 '21 at 14:19
  • @463035818_is_not_a_number i got the code from our college pdf i have written same as it was on the pdf. When i executed it it didn't incremented – Satyabrata Kar Nov 24 '21 at 14:19
  • 1
    @SatyabrataKar Depending on the version of C++ you are using to compile this, either it is Undefined Behavior, or it doesn't do anything. Either way it is undoubtedly incorrect. – François Andrieux Nov 24 '21 at 14:20
  • 1
    when you got code from somewhere you should give proper credits. Not only to give proper credits, but also because knowing why you want to write `x = x++;` helps to answer. The code in the pdf was just utterly wrong (and the duplicates explain why) – 463035818_is_not_an_ai Nov 24 '21 at 14:21
  • @FrançoisAndrieux I don't think rule#20 mean what you think. But that's more part of https://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points – Hans Olsson Nov 24 '21 at 14:34
  • @HansOlsson Can you please elaborate? I believe it means `i++` including all side effects are sequenced before the assignment, making `i = i++;` well defined since C++17. – François Andrieux Nov 24 '21 at 14:38
  • @463035818_is_not_a_number in case of prefix ++ **X = ++X** worked. So I wanted to gave the same to postfix ++ operator i.e "**X = X++**". – Satyabrata Kar Nov 24 '21 at 14:53
  • @HansOlsson why void return for postfix ++ is wrong? – Satyabrata Kar Nov 24 '21 at 14:56
  • The only reason for using post-fix instead of pre-fix is that you want the value. Using void defeats that. – Hans Olsson Nov 24 '21 at 15:05
  • @FrançoisAndrieux Rule 20 doesn't say "assignment" but side-effects of E1 (the left-hand-side). And Rule 8 that wasn't changed in C++17 mentions the assignment, but excludes the side-effects of E2 (the right-hand-side) (and E1). – Hans Olsson Nov 24 '21 at 15:08
  • @HansOlsson Wasn't the absence of guarantee on argument evaluation side effects the only reason this would have been UB in the first place? – François Andrieux Nov 24 '21 at 15:13
  • @FrançoisAndrieux For "X=X++;" I would say it is argument evaluation side-effects vs the actual assignment. But I still think this is best cleaned up in https://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points – Hans Olsson Nov 24 '21 at 15:27
  • @HansOlsson This is answered here https://stackoverflow.com/a/47702440/7359094 – François Andrieux Nov 24 '21 at 15:56
  • @FrançoisAndrieux - Thanks for the link; that cleared it up. Note that it uses a different restriction in C++17 that isn't listed in cpp-reference. (It's the sequencing of operands - not sequencing of values computations of operands - that matters.) – Hans Olsson Nov 24 '21 at 16:20

0 Answers0