Hi guys,
Just a quick question, as I am quite puzzled about the verdict difference.
Those two codes are identical, but it passes in G++17 and fails in G++14.
Locally, those two seem to both produce -2 as an answer for the first test case for both G++14 and G++17.
I am guessing I made a trivial mistake somewhere.
Could you guys enlighten me with why it passes on one but not the other? I am guessing it could be due to using unsupported/undefined behavior in G++14.
Thanks a lot!
Yongwhan
EDIT: this is wrong, see comment below
I think it may be this compiler bug.
If you run the code in custom invocation with #define _GLIBCXX_DEBUG on the first line (before any includes) on g++ C++11, an error message is produced:
This doesn't happen on g++ C++14 or g++ C++17 though, so I'm not completely sure if this is the cause. Note that g++ C++11 also outputs -7 (the wrong output).
Compiling with G++ 9.3.0 on my local machine with any C++ version and with all debugging flags and sanitizers enabled does not lead to any error and your code produces the right output. So I think your code is fine.
Also, it works fine with Clang++17 diagnostics.
Nevermind, ffao has pointed out the actual issue is that you're doing
f[x] = eval(x)
.See ffao's submission
The order of evaluation here is undefined. The left-hand or the right hand side could be evaluated first. Note that
f[x]
may create the key x with value 0 in the map, so it affectsf.count(x)
.That begs the question: why does this work in C++17? Because the rules for order of evaluation were changed in C++17 so that the right-hand side must be evaluated before the left-hand side.
Awesome, removing it worked!
The fixed link is https://codeforces.net/contest/402/submission/84291680. It turns out I do not even need f[x]=eval(x) assignment.
Thanks a lot ramchandra and ffao!
https://en.cppreference.com/w/cpp/language/eval_order
For those looking for mentions of this rule in the reference. You can find it on rule 20.