Live data from Hacker News

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

gynvael.coldwind.pl

191–200 of 246 posts

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

#191
post #124
post #117

Earlier quoted context omitted.

Well... tried it on macOS using vanilla gcc, the results surprised me: $ /bin/cat x.c; gcc -w -o x x.c; ./x #include int main() { int a = 5; a += a++ + a++; printf("a = %d\n", a); } a = 18 Not what I expected. This must be how it works: - The first a++ expression results in 5, after a = 6 - The second a++ expression results in 6, after a = 7 - Only then the LHS a is evaluated for the addition-assignment, so we get: a…

the original question has a=, you have a+=

I was just replying to the comment ¯\_(ツ)_/¯

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

#192

Earlier quoted context omitted.

> Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. OK. What is the value of a spec to which compliance is impossible?

>What is the value of a spec to which compliance is impossible? Are you saying, what's the value of a language spec that allows undefined behavior , as C does? Well, it's that it allows for compiler implementations that aren't too hard to implement and maintain. It allows for a language that's close enough to hardware (and allows you to do programming on a low level), while still offering a reasonable amount of abstr…

> Well, it's that it allows for compiler implementations that aren't too hard to implement and maintain.

> It allows for a language that's close enough to hardware (and allows you to do programming on a low level), while still offering a reasonable amount of abstraction to be useful (and usable).

I can see the first of these. The second appears to be untrue; if you removed the concept of undefined behavior from C, it wouldn't get farther away from the hardware.

Is that first point actually something that somebody wants? Who benefits from the idea that it's easy to write a "standards-compliant" compiler, because you are technically "standards-compliant" whether you comply with the standard or not?

At that point, you've given up on having a standard, and the interviewers Susam calls out, who say that the correct answer is whatever their compiler says it is, are correct in fact. Susam is the one who's wrong, for reading the standard.

You can run a language that way just fine. I had the impression that Perl was defined by a reference implementation. But it's the opposite of having a standard.

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

#193

Earlier quoted context omitted.

> Also, imagine a situation where the line of code actually lists three different variables, but all three of them are passed in by address. It quickly becomes impossible for the compiler to know you violated the spec by reusing the same variable. OK. What is the value of a spec to which compliance is impossible?

The compiler does comply to the spec. It's the program that fails to comply with the spec. It's definitely possible to write programs that have no undefined behavior.

The compiler is supposed to compile programs that comply with the spec, and not compile programs that don't.

The concept of "compiling a program that doesn't comply with the spec" doesn't even exist! A text file that doesn't comply with the C spec isn't a C program. That's what it means to be "the spec".

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

#194
post #181

Earlier quoted context omitted.

It's the job of a language designer to define everything.

C should do better about the things that could be readily defined, but there's no way to have arbitrary pointers and define everything .

> but there's no way to have arbitrary pointers and define everything.

What's the undefined behavior in assembly?

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

#195
post #23
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…

IMO, The only reasonable answer if asked this in an interview is “I would not write code where I have to know the answer to this question” These sorts of things are neat trivia to learn about things like sequence points but 99.9% of the time if it matters in your codebase you're writing something unmaintainable.

The answers to some questions must be known in order to be able to write a correct program.

In the vast majority of the programming languages, the order of evaluation for the actual parameters passed to a function is undefined. In the few programming languages where the order of evaluation is defined, that is actually a mistake in the design of that programming language.

This is something about which any programmer must be well aware, because when composing function invocations it is very easy to write a function invocation where the result would depend on the order of evaluation of the expressions passed as actual parameters. The arithmetic operators are also function invocations, so that applies to them too.

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

#196
post #149

Earlier quoted context omitted.

> I am very glad these types of interview questions have become less prevalent these days. They have, right? Right? Are you referring to the type of interview questions where the question is ill-defined and no one should know the answer, or the type where the question is reasonable and well-defined, but the interviewer doesn't know the answer? I had a phone screen with Google once where they asked how to determine th…

I meant the latter. I think the question is fine. It can lead to a good discussion, similar to what we are having in this thread. It has been a long time (almost 20 years), but I remember that most interviewers who asked this seemed to be convinced that the output they had seen with their compiler version was the correct answer. What could be a nice and relevant discussion, especially considering that some classes of…

From first principles, it seems unlikely that interviewers selecting their own questions would be able to eliminate this class of question, since by definition they cannot know whether the answer they believe is correct really is correct or not.

I would be 100% behind a movement to replace interviewer freedom with externally-set, vetted questions.

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

#197
post #78
post #38

Earlier quoted context omitted.

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.

I always hate C-style for-loops because even thought I learned C over 40 years ago, I can never remember whether the increment comes before the test or the test comes after the increment. Fortunately, modern IDEs let me continue to be ignorant on those occasions when they’re necessary (usually because I need the index for some reason).

[deleted]

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

#198

Earlier quoted context omitted.

The compiler does comply to the spec. It's the program that fails to comply with the spec. It's definitely possible to write programs that have no undefined behavior.

The compiler is supposed to compile programs that comply with the spec, and not compile programs that don't. The concept of "compiling a program that doesn't comply with the spec" doesn't even exist! A text file that doesn't comply with the C spec isn't a C program. That's what it means to be "the spec".

> The concept of "compiling a program that doesn't comply with the spec" doesn't even exist!

Wrong. Lots of spec violations only happen at runtime and can't be predicted at compile time.

Here's an easy example. You're the compiler. I hand you what appears to be valid C code that allocates an array and then asks the user which slot to use. It doesn't verify the slot is in bounds, just puts a number in array[slot], does some math with it, and then prints the result. Does my program comply with the spec? Do you compile it?

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

#199

Earlier quoted context omitted.

C should do better about the things that could be readily defined, but there's no way to have arbitrary pointers and define everything .

> but there's no way to have arbitrary pointers and define everything . What's the undefined behavior in assembly?

Assembly is kind of at the crossroads of everything being defined and nothing being defined, when you consider things like writing random data to memory and executing it... But anyway here's the first thing I found to answer that: https://news.ycombinator.com/item?id=9578178

Probably more important, way too many things in assembly vary by exact model. Can you name a portable language that fits those criteria?

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

#200

Earlier quoted context omitted.

It's been quite a while, but IIRC, in Java these statements actually do have a defined behavior. The ++x is a "pre-increment", meaning the value of the variable is incremented prior to evaluating the expression, while the "post-increment" "x++" is the other way around: the expression evaluates to x, then x is incremented afterwards. All expressions are left-to-right.

That behavior is inherited from C. The pre/post increment behavior is actually the same in every language that uses them. The priority of operation is also usually the same as well. The reason the question is tricky is because those operators change the value of a as the full expression is progressively executed. It's not immediately clear to me what the answer in Java would be. Just take a++ + ++a for example: If th…

The value of the variable is not hoisted by the Java compiler. (It's not that JVM, that only executes the byte code, what y doesn't have that kind of ambiguities.)

The semantics of Java is not undefined on multiple assignments to the same variable in an expression, so it can't hoist something if it would change the outcome.

Now, I don't actually know what the outcome is, because I don't remember whether `a += e` reads the value of `a` before or after evaluating `e`. The code is still confusing and unreadable to humans, so you shouldn't write it, but the compiler behavior is not undefined.

And if your variable is accessed from multiple threads, it may be undefined which intermediate values night be seen.

Post reply on HN