Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Int a = 5; a = a++ + ++a; a =? (2011)

gynvael.coldwind.pl

Post reply on HN
Print view View original

31–40 of 246 posts

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#31

Post by mike_hock »

susam wrote: post #5

The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…

Do you want a job at a place where someone who doesn't understand UB makes the hiring decisions?

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#32

Post by yason »

The only point you can conclude out of these discussions, especially in an interview, that it doesn't matter what the answer happens to be on $CC and $ARCH but you wouldn't want anyone to write stuff like that in the first place.

Failing to recognize the dangers would be an instant fail; knowing that something reeks of undefined behaviour, or even potential UB, is enough: you just write out explicitly what you want and skip the mind games.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#33

Post by fc417fc802 »

bombcar wrote: post #25
Boxxed wrote: post #14

> The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13. No, if you invoke undefined behavior any result at all is possible.

I feel we need another category - unspecified behavior. I think everyone would agree the compiler should putout ONE of those answers and that nasal demons would be out of spec. The problem is that it’s not specified which should be picked, but all pick something.

I agree what you say seems reasonable at a glance. But (IIUC) the issue is that for optimization we want the compiler to assume that UB doesn't happen in order to constrain the possible code paths. So if it goes some distance down a possible execution branch and discovers UB it can trim the subtree. At that point "anything can happen" becomes an (approximate) reality.

The obvious counterpoint in this particular instance is that there's no good reason not to make such an awful expression a compile time error.

I also personally think that evaluation order should be strictly defined. I'm unclear if the current arrangement ever offers noticable benefits but it is abundantly clear that it makes the language more difficult to reason about.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#34

Post by throw_await »

saghm wrote: post #20
marcosdumay wrote: post #9

Earlier quoted context omitted.

Applying the increment or decrement operators over the same variable more than once on the same line should be a compile-time error. Anyway, yes, this one example has an obvious order it should be applied. But still, something like it shouldn't be allowed.

Honestly, having increment in expressions rather than a statement feels like more of a footgun than a benefit. Expressions shouldn't mutate things.

Wenn wouldn't have pearls like while (dst++ = src++);

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#35

Post by AlotOfReading »

xigoi wrote: post #21
AlotOfReading wrote: post #11

Earlier quoted context omitted.

It's valuable for compilers to be able to choose the instruction scheduling order. Standards authors try not to unnecessarily bind implementors. If post increment happened after the full statement is finished, then the original value has to be maintained until the next sequence point. Maybe the compiler will be smart enough to elide that, maybe not, but it's a lot more difficult to fix those kinds of edge cases than…

It would only make a difference in cases that are currently UB, so there is no program valid under current C that would be pessimized by this change.

It's a language feature that was in K&R, and the rules around sequencing were introduced in C89. There were good reasons to believe it would pessimize code in the following decades. Dennis Richie himself pointed out that Thompson probably added the operators because compilers of the time were able to generate better code that way.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#36

Post by summarybot »

> If you would like to test your compiler (posting back the results in the comments is really appreciated, especially from strange/uncommon compilers and other languages which support pre- / post- increment ....

Uh, 85% of them show the wrong result so 85% of them clearly do not support pre and post increment.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#37

Post by compiler-guy »

bombcar wrote: post #25
Boxxed wrote: post #14

> The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13. No, if you invoke undefined behavior any result at all is possible.

I feel we need another category - unspecified behavior. I think everyone would agree the compiler should putout ONE of those answers and that nasal demons would be out of spec. The problem is that it’s not specified which should be picked, but all pick something.

The C and C++ standards include "Implementation defined behavior", which means that a conforming implementation can do whatever it wants, as long as it specifically documents and sticks to that behavior.

This doesn't really help portability all that much.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#38

Post by kibwen »

saghm wrote: post #20
marcosdumay wrote: post #9

Earlier quoted context omitted.

Applying the increment or decrement operators over the same variable more than once on the same line should be a compile-time error. Anyway, yes, this one example has an obvious order it should be applied. But still, something like it shouldn't be allowed.

Honestly, having increment in expressions rather than a statement feels like more of a footgun than a benefit. Expressions shouldn't mutate things.

In any language where the practice of iteration isn't achieved via C-style for-loops, having an operator devoted to increment just doesn't make sense (let alone four operators, for each of pre/post-increment/decrement). This is one of those backwards things that just needs to be chucked in the bin for any language developed post-2010.

Re: Int a = 5; a = a++ + ++a; a =? (2011)

#39

Post by pplonski86 »

I love such puzzles! I used to use a lot ternary operators in C++ but one day friend of mine told me that I shouldn't nest ternary operators too much because code is too complicated to read - he understands code perfectly, he was just worried about younger programmers. Since then I started to use longer versions of code instead of smart shortcuts - to improve readability of code.
Post reply on HN