|
|
 |
 |
 |
 |
question on C language
runa2@gmail.com said:
> Interview Question > Visit this site it is really good question on C language. > http://[elided]/c-question.html
and some of them betray staggering ignorance about the C language.
Example: "Why n++ executes faster than n+1?"
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
On May 29, 12:46 pm, Richard Heathfield <r@see.sig.invalid> wrote:
> Actually, it's a list of questions. None of them are particularly good,
> and some of them betray staggering ignorance about the C language.
> Example: "Why n++ executes faster than n+1?"
That might actually make it a good interview question :-)
The answer could give you a very good reason to hire or to not hire
the interviewee.
christian.bau said:
> On May 29, 12:46 pm, Richard Heathfield <r @see.sig.invalid> wrote: >> Actually, it's a list of questions. None of them are particularly
>> good, and some of them betray staggering ignorance about the C
>> language. Example: "Why n++ executes faster than n+1?"
> That might actually make it a good interview question :-)
> The answer could give you a very good reason to hire or to not hire
> the interviewee.
could give the interviewee a very good reason to accept or reject a
subsequent offer of a job.
The question is extraordinarily poorly formed. For one thing, the
expressions are not even equivalent! So the matter of relative speeds
is meaningless. For another thing, even if they were equivalent, the
question is based on at least one false premise, and possibly two.
Unpicking that to the satisfaction of a clueful interviewer would take
only a few seconds, of course, but persuading the "potentially bright"
(to borrow Douglas Adams's marvellous phrase) could take substantially
longer. It's probably more cost-effective just to say "so long, and
thanks for the coffee".
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
>>>>> "RH" == Richard Heathfield <r @see.sig.invalid> writes:
RH> particularly good, and some of them betray staggering
RH> ignorance about the C language. Example: "Why n++ executes
RH> faster than n+1?"
This might be a very *good* interview question; it can simultaneously
demonstrate familiarity with C and what the interviewee does when he
disagrees with someone in a position of authority.
It can also be a very good interview question in that, depending on
how it's handled, it can signal to the interviewee that he's being
interviewed by an ignoramus.
Interviews are not solely about ascertaining whether the candidate is
right for the company; they are also about ascertaining whether the
company is right for the candidate. As someone who has been a
candidate in past and who probably will be again in future, I find the
latter to be far more important.
Charlton
--
Charlton Wilbur
cwil@chromatico.net
On May 29, 1:28 pm, "christian.bau" <christian.@cbau.wanadoo.co.uk>
wrote:
> On May 29, 12:46 pm, Richard Heathfield <r @see.sig.invalid> wrote: > > Actually, it's a list of questions. None of them are particularly good,
> > and some of them betray staggering ignorance about the C language.
> > Example: "Why n++ executes faster than n+1?"
> That might actually make it a good interview question :-)
> The answer could give you a very good reason to hire or to not hire
> the interviewee.
like a reasonably straightforward context:
#include <stdio.h>
int main(void)
{
int n=0;
n++; /* increment n */
n+1; /* no effect */
printf("%d\n",n);
return 0;
}
I'd suspect that in most modern compilers the n+1 would be optimised
away to nothing (with a diagnostic telling me that it has no effect;
neither of these actions is required by the standard), and so would
execute faster than the n++, so the question is wrong.
The alternative is much worse:
#include <stdio.h>
int main(void)
{
int n=0;
n=n++; /* undefined behaviour */
n=n+1; /* increment n */
printf("%d\n",n);
return 0;
}
Here, it's hard to tell how long the n=n++ will take, especially as I
wouldn't advise running it or even compiling it (after all, anything
could happen). Nevertheless, I came across this code given as an
example of 'code fragments you may want to use' for a compiler for a
language that is not C89, but is the same in the relevant parts of
this discussion. (One of its many sins was that int was unsigned and 8-
bits wide by default, which is one of the reasons I was chafing at
being forced to use it. You could #implemenation_defined_directive it
into a legal 16-bit signed form, at the cost of breaking library
code.)
i=i++;
So by placing this, and some increment code into this non-C-but-close-
enough-for-this-explanation undefined-behaviour-is-bad-but-only-when-
running-the-program-and-at-least-compiling-it-won't-kill-me compiler,
with optimisation off, wrapped in a program to make it legal:
void main(void) /* another of the compiler's sins, but as it was
technically meant to be a
freestanding implementation they may have thought
they could get away with it */
{
int i;
i++;
i=i++;
i=i+1;
i+1;
}
the output was a good guide to the speed of the various commands. I
won't post assembler to comp.lang.c, but instead translate each
statement of the result into C below (with the proviso, of course,
that doing so won't result in a legal C program in almost every case).
The embedded nature of the target meant that the length of time for
each instruction was deterministic, so I'll add it in comments.
/* no startup code was generated, typical for some embedded systems */
/* from i++ */
i++; /* 1 microsecond */
/* from i=i++ */
__W=i; /* 1 microsecond */
i++; /* 1 microsecond */
i=__W; /* 1 microsecond. Of course, as it's UB, this ends up not doing
what you -
or the person who gave it to me as a "useful code fragment"
- might expect. */
/* from i=i+1 */
__W=i; /* 1 microsecond */
__W+=1; /* 1 microsecond */
i=__W; /* 1 microsecond. */
/* from i+1 */
__W=i; /* 1 microsecond */
__W+=1; /* 1 microsecond */
So I suspect on this compiler, the answer is "you didn't turn
optimisation on". The general answer to the question is "It isn't, in
general. In a specific case it may be faster, but it depends on the
compiler, and as the two expressions do different things you shouldn't
have been trying to optimise by hand anyway. Even for a specific
implementation you can't answer the question without knowing the
context in which the expressions appear, and even then just profiling
and finding out yourself is likely to be the most accurate way, but be
careful not to cause undefined behaviour along the way."
--
ais523
|
 |
 |
 |
 |
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc