Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > question on C language

Reply
Thread Tools

question on C language

 
 
runa2104@gmail.com
Guest
Posts: n/a
 
      05-29-2007
Interview Question
Visit this site it is really good question on C language.

http://techinterviewquestion.blogspo...-question.html

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      05-29-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
 
Reply With Quote
 
 
 
 
christian.bau
Guest
Posts: n/a
 
      05-29-2007
On May 29, 12:46 pm, Richard Heathfield <(E-Mail Removed)> 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.

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-29-2007
christian.bau said:

> On May 29, 12:46 pm, Richard Heathfield <(E-Mail Removed)> 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.
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      05-29-2007
>>>>> "RH" == Richard Heathfield <(E-Mail Removed)> 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
(E-Mail Removed)
 
Reply With Quote
 
ais523
Guest
Posts: n/a
 
      05-29-2007
On May 29, 1:28 pm, "christian.bau" <(E-Mail Removed)>
wrote:
> On May 29, 12:46 pm, Richard Heathfield <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
writing a compiler for Monster language using C language Shravani C Programming 8 03-16-2008 09:36 PM
A language-agnostic language Ed Java 24 03-27-2006 08:19 PM
c is a low-level language or neither low level nor high level language pabbu C Programming 8 11-07-2005 03:05 PM
Using a Scripting Language as Your Scripting Language DaveInSidney Python 0 05-09-2005 03:13 AM
Python is the best and most popular general purpose scripting language; the universal scripting language Ron Stephens Python 23 04-12-2004 05:32 PM



Advertisments