Since then I've stopped asking questions like this. Trick questions and logic questions I think are a bad metric. A person can be great at sudoku but be a horrible developer in terms of writing maintainable code. Instead, I tend to just talk about the macro-level stuff. "What have you built? Can I see it? How long did you maintain it? What was the trickiest part? I imagine it had performance issues; did you spend time optimizing it?" I do ask some tech questions. For example, for web developers I ask "Describe how an XHR request happens in detail." But that is as deep as typically go.
Kind of like if you got an interviewer that responds with a blank stare if you talk about version control and says they just make copies of the directory, or something like that.
I can't fanthom how would one come to the conclusion that there is a difference between the two otherwise.
Or maybe that's just me; nervousity in presentations or interviews or even talking is IMHO an indication of not knowing what you're talking about. And knowledge is confidence.
Personally at the end of the interview (as the interviewer) I would refer back to any of those sorts of questions and say.. "actually I was trying to catch you out, you did good there", or some such.
This not only stops them doubting themselves, but also clears the air if I was to come back to them and offer them the job. Who knows, maybe the interviewee ran off to SO and categorically proved me wrong.
And that might differ between JITs and compiled languages and different numerical types.
For any machine precision numerical types, if the code is compiled, it'll just become
TEST EAX, EAX ...set eax to 0 or 1 based on jmp...
So in most compiled languages, a bool cast on machine precision numerics, will be constant time.
Consider the case of converting an integer value to floating point. In order to normalize the floating point value, you'll have to do something equivalent to counting the number of leading zeros on the int, and many machines don't have an instruction for that, so you have to do a loop. Data-dependent timing like that needs to be studiously avoided in crypto code in order to prevent timing attacks. (Of course, crypto rarely uses floating point, but it's still a great example of how an O(1) operation can have variable execution time depending on the input.)
I wonder, how do you propose to measure the "size" of your input to bool cast?
I think that might be possible in dynamic languages like Lisp that can compile to assembly. Maybe Franz or Allegro Lisp compilers do something like that. For the JVM or .NET, I'm not sure that can happen. For C or C++, every typecast is constant time.
It seems we're all getting hung up on whether evaluating the truthiness of 1 or 2 is faster, but that's really immaterial.
while (1) { // code goes here }
I am having a really, really hard time contriving a reason for this, though. It may be my lack of imagination, but I feel like the only reason this would come up is if you deliberately designed a system specifically to make this an issue.
Honestly, you could take this question a bunch of ways. Maybe he's just trying to ask about whether the speed of a cast-to-bool depends on the value of the thing you're casting, maybe he's trying to get you to see that the compiled code won't even evaluate the conditional at runtime anyway or maybe he's trying to get you to realize that you'd almost certainly not care because even if it were evaluating the conditional, if you're using while(<true>), you're almost certainly waiting for some event, so the only thing it could possibly affect would be polling speed, negligibly.
I don't think anyone is missing the point that an infinite loop takes infinite time to terminate, it's just not a very interesting point to make. Getting "hung up" on (1) means missing out on potentially interesting insights found when answering (2).
However, back in the day, with some CPU architectures, and with some fairly primitive compilers, it is conceivable for while(1) and while(something) to iterate at different rates. That is if the compiler outputs literal unoptimised code, and the something is a number large enough to require a larger instruction to initialise in a register than the number 1.
For example, the 68000 CPU instruction code has a quick immediate addressing mode, which can form the moveq instruction that will embed a constant between -128 and 127 into the instruction. It also has a slower immediate addressing mode that allows full 32-bit numbers to be sourced from an extra 32 bits tacked onto the end of the instruction. Therefore, while(1) {} could conceivably be compiled to:
label:
moveq #1,D1
cmpi #0,D1
bne label (branch if not equal)
label:
movei #200,D1
cmpi #0,D1
bne label
At Mindtribe, our coding style suggests "for(;;)" instead of "while(1)". However, the reason isn't performance. Instead, it's that we've seen more than one compiler produce a warning about the testing of a constant in the case of "while(1)". And we have a policy of compiling without warnings.
int x;
while (true) {
x = 8;
break;
}
System.out.println(x);
Instead of `true`, you can also use things like `1==1` in the condition to the same effect. However, if you attempt the following:
int x;
boolean y = true;
while (y) {
x = 8;
break;
}
System.out.println(x);
While.java:9: error: variable x might not have been initialized
System.out.println(x);
^