question on C language

Discussion in 'C Programming' started by runa2104@gmail.com, May 29, 2007.

  1. Guest

    , May 29, 2007
    #1
    1. Advertising

  2. said:

    > Interview Question
    > Visit this site it is really good question on C language.
    >
    > http://[elided]/c-question.html


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

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, May 29, 2007
    #2
    1. Advertising

  3. On May 29, 12:46 pm, Richard Heathfield <> 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, May 29, 2007
    #3
  4. christian.bau said:

    > On May 29, 12:46 pm, Richard Heathfield <> 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.


    Ha! :) And the interviewer's response to the interviewee's answer
    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.
     
    Richard Heathfield, May 29, 2007
    #4
  5. >>>>> "RH" == Richard Heathfield <> writes:

    RH> Actually, it's a list of questions. None of them are
    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
     
    Charlton Wilbur, May 29, 2007
    #5
  6. ais523 Guest

    On May 29, 1:28 pm, "christian.bau" <>
    wrote:
    > On May 29, 12:46 pm, Richard Heathfield <> 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.


    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
     
    ais523, May 29, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ed
    Replies:
    24
    Views:
    1,075
    Dimitri Maziuk
    Mar 27, 2006
  2. DaveInSidney
    Replies:
    0
    Views:
    467
    DaveInSidney
    May 9, 2005
  3. pabbu
    Replies:
    8
    Views:
    772
    Marc Boyer
    Nov 7, 2005
  4. Shravani
    Replies:
    8
    Views:
    828
    Bartc
    Mar 16, 2008
  5. Replies:
    28
    Views:
    1,217
Loading...

Share This Page