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

141–150 of 246 posts

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

#141

Post by _kst_ »

mywittyname wrote: post #87
p0w3n3d wrote: post #53

On my CS lectures algorithms professor used this pseudo language when writing an algorithm on a whiteboard : I On the next hour another professor was giving lecture on C++ programming. I asked him the question: what would happen if we compiled i = i++ He went into some deep elaboration on it, but reassumed that only idiot would write like this...

Out of curiosity, I checked if gcc would optimize i = i++ out, and it does!

What can be optimized out depends on the context.

If you write:

    int i = 0;
    i = i++;
and never use the value of i, the declaration and assignment are likely to be optimized out. (The behavior of the assignment is undefined, so this is a valid choice).

If you print the value of i, the compiler can still optimize away the computation, but is perhaps less likely to do so.

The solution, of course, is not to write code like that. Decide what you want to do, and write code that does that. "i = i++" will never be the answer to "how do I do this?", and wouldn't be even if the behavior were well defined. If you want i to be 1, write "int i = 1;".

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

#142

Post by marcosdumay »

fc417fc802 wrote: post #76
kibwen wrote: post #58

Earlier quoted context omitted.

> I don't see what it has to do with for loops or operators specifically. The reason that these operators pull their weight in C is because iteration over arrays is achieved by manual incrementation (usually via the leading clauses of the for-loop) followed by direct indexing. Languages with a first-class notion of iteration don't directly index in this way, which overwhelmingly eliminates not only the vast majority…

For loops are hardly the only usecase and built in iteration constructs frequently fall short. For example any mildly complex loop that involves pointer juggling can benefit. > which doesn't have the footguns of `++` due to assignment being a statement rather than expression, So then I implement the local equivalent of inc( v ) and ... same issue, right? Plus with rust macros is there any technical reason you can't t…

In Rust you hide all kinds of error prone iterations behind the "iterator" interface. Both the "for(int x=0;..." and the "while(list[i++])" are implemented at the standard library.

People tend to use FP abstractions for the "x[i++] = f(y[j++])" though, not iteration.

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

#144

Post by tialaramex »

IshKebab wrote: post #84
tzs wrote: post #74

Earlier quoted context omitted.

> 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” That's half of a reasonable answer. The other half is "but I do know the answer so if I see it when reviewing or working on someone else's code I can flag it or rewrite it, and explain to them why it is bad".

No it isn't. You don't need to know the answer to know that it is bad code. The very fact that it isn't clear shows that.

Right, the feedback I'd expect in a code review interview is something like "This is unclear or wrong, write what you actually meant".

That's the feedback I would want, and it's the feedback I give to my colleagues in reviews. Actually I tend to be too verbose, so you might get a full paragraph explaining what the ISO document says and that you shouldn't assume it does whatever it is your compiler says.

My actual feelings for this specific case are that the language is defective, but if we're wedded to a defective language then the reviews need to call out such usage.

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

#145

Post by bombcar »

IshKebab wrote: post #98
fc417fc802 wrote: post #33

Earlier quoted context omitted.

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 insta…

As I understand it UB was not really intended to be for optimisation. It was so that C could compile on wildly different architectures that existed at the time. Today we don't have nearly the variety of architectures, so they in theory C doesn't need nearly as much UB (like more modern languages). Although there is one modern case where C's "anything goes" attitude has actually helped: CHERI works pretty well with C/…

Which is a form of optimization- if you don’t require something that may be incredibly difficult on a given CPU it makes portability easier.

The reality is these are all edge conditions rarely encountered.

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

#146

Post by IcyWindows »

IshKebab wrote: post #88
LPisGood wrote: post #57

Earlier quoted context omitted.

I don’t work a ton with C, but I wonder how C programmers keep track of what behavior is and is not defined. It seems like there are many possible edge cases.

They don't really. In fact there are many things that are technically UB but are so common that compilers can't really treat them as UB. E.g. type punning via unions.

Yeah, undefined behavior just means not defined in the specification.

I would argue that most languages only have one compiler so it doesn't matter what is in the specification.

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

#147

Post by wat10000 »

MaxBarraclough wrote: post #116
wat10000 wrote: post #62

Earlier quoted context omitted.

We get by on a combination of matching patterns (any pointer cast gets a lot of scrutiny, for example), compiler warnings, tools like UBSan, debugging when things go wrong, and sheer dumb luck. Having an understanding of how the code gets transformed into machine code helps. For this case, there's the basic idea that `a++` will boil down to three basic conceptual operations: fetch, add, and store, and those can be po…

> Having an understanding of how the code gets transformed into machine code helps I'm not sure about that. Knowing assembly is not a substitute for knowing how the language is defined. Sometimes C/C++ programmers with some assembly knowledge reason themselves into thinking that what they're asking of the language must have well-defined behaviour, when in fact it's undefined behaviour. It doesn't really matter whethe…

I don't mean assembly in this case, but something more like the compiler's view of the code. a++ can be broken down into more primitive operations, and might actually be, depending on how the compiler is implemented. The fact that the ordering of those more primitive operations with respect to other operations isn't very tightly constrained is something you'd just have to know about the language, I suppose.

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

#148

Post by lmm »

thaumasiotes wrote: post #113
Dylan16807 wrote: post #108

Earlier quoted context omitted.

Compilers are not able to prevent you from violating must/shall in the general case. So they're not held to that bar. Unless the standard says not to compile it, it's not a compiler bug. 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 sa…

> 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?

> OK. What is the value of a spec to which compliance is impossible?

It lets you tell people you have a spec? It makes it easy for compiler developers to dismiss bug reports with "your code violated the spec"?

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

#149

Post by susam »

thaumasiotes wrote: post #99
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…

> 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 bugs and security issues result from it, was seen only as a trivia quiz by the interviewers, with the expectation of an answer that was incorrect, no less.

Your phone screen story is quite nice. When I read your question, I would have answered with successive doubling as well. In fact, I faced the same question at an AWS interview a long time ago. The question was mathematically the same question but formulated differently. I answered with the doubling solution too, which leads to an O(log n) time solution, asymptotically. Your interviewer's immediate objection to your squaring solution seems like a major failure in their intuition. When I read your solution, purely by intuition, that is, without resorting to any rigorous reasoning, I felt: wow, that's interesting, your solution would land on the zero region in merely O(log log n) time. Why didn't I think of it? I think your solution should spark interest rather than dismissal in a curious person. Of course, the binary search after that to find the exact transition point blows up the time consumed back to O(log n).

Once again, thanks for these really interesting comments!

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

#150

Post by genxy »

p0w3n3d wrote: post #55
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…

How many tennis balls can fit in a bus?

Under what pressure?
Post reply on HN