Ranking from fast to slow .. interview question

[treuss]

int size need not be the natural data size for given architecture

In fact it is not on modern 64 bit CPUs/compilers, where sizeof(int) = 4 and sizeof(long) = sizeof(void*) = 8

[Graham]

int size need not be the natural data size for given architecture

The standard explicitly states that int is intended to have the natural size for the architecture of the target machine.

3.9.1/2:

Plain ints have the natural size suggested by the architecture of the execution environment.

[Vedam Shashank]

The standard explicitly states that int is intended to have the natural size for the architecture of the target machine.

What do they mean by "natural size" here ????

I ask this with regard to... this

[Brad Jones]

A company that asks questions like that probably isn't worth working for.

I disagree.

I think the amount of discussion generated in this thread indicates that this is an excellent interview question.

An internview question need not be answerable or correctly worded. After all, in an interview, it isn't the question that is being evaluated, but rather the answer (and the person giving that answer). How someone answers a question is often more important than getting the answer right -- if there even is a correct answer.

Brad!

[NMTop40]

I've had interview questions recently where the correct answer was "undefined behaviour" and they knew it was - they were testing.

[Noddon]

I disagree.

I think the amount of discussion generated in this thread indicates that this is an excellent interview question.

An internview question need not be answerable or correctly worded. After all, in an interview, it isn't the question that is being evaluated, but rather the answer (and the person giving that answer). How someone answers a question is often more important than getting the answer right -- if there even is a correct answer.

Brad!

Personally, I'm with Graham on this one, for technical questions at least.

I've been in interviews where answers to questions like this have become length discussions. In more than a few cases, this has come down to the interviewer setting a question they cannot correctly answer themselves. This question looks very much like one of those. Obviously, until you answer it and talk about it with the interviewer you don't really know for sure.

Interviews are two way processes: not only is it the employers chance to assess the would-be employee... but also for the employee to assess the would-be employer.

I've declined and accepted jobs based on whether the person giving a technical interview can knowledgably discuss their own questions. If they can't then it's not a good indicator of the quality of your would-be colleagues.

[exterminator]

It is really unlucky in those times when people ask you something.. you give the correct answer.. but they know the wrong answer themselves and hence rate your correct answer as wrong.

On one such ocassion - a guy said that the allocation using new in the initializer list (and exception later on generated before exiting from the constructor) is safe. Upon such exceptions the run-time rolls the allocation back. That is the use of initializer list... it is that safe.. I just struck my head and couldn't say a word.. that was an internal one...

Sorry for the off-topic post.

[SierraP]

I've been in interviews where answers to questions like this have become length discussions. In more than a few cases, this has come down to the interviewer setting a question they cannot correctly answer themselves.

I would think that would be a reason to keep the question in the interview. If it brings about discussion with the perspective employee. For the very reasons you submitted, if an employee can discuss something with you and you both feel each other is competent (and can communicate with each other) you are more apt to be able to work together. Many companies are looking for that golden mix: a competent programmer who is personable...I tend to take jobs based on what I perceive they can teach me and how I can grow as much as whether I can do what they immediately need me to fulfil.

[Paul McKenzie]

On one such ocassion - a guy said that the allocation using new in the initializer list (and exception later on generated before exiting from the constructor) is safe. Upon such exceptions the run-time rolls the allocation back. That is the use of initializer list... it is that safe..

Regards,

Paul McKenzie

[Sef]

I disagree.

I think the amount of discussion generated in this thread indicates that this is an excellent interview question.

An internview question need not be answerable or correctly worded. After all, in an interview, it isn't the question that is being evaluated, but rather the answer (and the person giving that answer). How someone answers a question is often more important than getting the answer right -- if there even is a correct answer.

Brad!

I hope you're right in this case but unfortunately, it's probably an idealistic and optimistic view of the world (with all due respect). The sad truth is that there's rampant incompetence in this field and the inteviewer himself, like most programmers, probably falls into that category (far more often than not anyway).

[Vedam Shashank]

Go daddy could u let us know where (i mean place not which company) did u take the interview, and how many questions were asked in that written round, and how many had to write it along with u????

[GoDaddy]

The correct answer is

5) None of the above.

It depends on the compiler's optimizer. That was a trick question.

Regards,

Paul McKenzie

Why would it depend on the compiler optimizer ?

4 .. is the slowest no ? ....

[Noddon]

Why would it depend on the compiler optimizer ?

4 .. is the slowest no ? ....

Compilers only have to produce a program that works "as if" it were the program you described in the code.

A "clever" (possibly even too clever!) compiler could optimise this:

for(int i=0;i<16;i++)
  for(int j=0;j<16;j++)
      array1[i]=array2[j];

to something that looks (algorithmically) like this:

for (int i=0;i<16;i++) array1[i]=array2[15];

or it could unroll the loop, or dozens of other things. The important thing is that the outcome is "as if" the code being compiled had been run. This could very well wind up being faster than the other examples since there are fewer memory accesses... even though it doesn't do the same thing!

In practice, many compilers optimisers won't do this (unless it's a trivial case) because they're difficult to spot, and programmers tend not to add loops pointlessly!

[sreehari]

to something that looks (algorithmically) like this:

for (int i=0;i<16;i++) array1[i]=array2[15];

[Noddon]

The inner for-loop:

for (j=0;j<16;j++) array1[i]=array2[j];

has the exact same side effect as:

array1[i]=array2[15];

since the only assignment to array1[i] which matters is the last one, when j is 15.