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.invalidwrote:
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.
The question makes no sense without some context. Providing what seems
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
