473,796 Members | 2,609 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

i need some C/C++ test intervie questions

hello everyone,
Iam vasant from India..
I have a test+interview on C /C++ in the coming month so plz help me
by giving some resources of FAQS, interview questions, tracky
questions, multiple choice questions.etc..
I'll be indebted to everyone..
Thanks in advance..
regards
vasant shetty
Bangalore
India
Nov 13 '05
162 14931
On Thu, 04 Sep 2003 21:30:13 +0000, Richard Heathfield wrote:
Ben Pfaff wrote:
Martin Dickopp <ex************ *@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into the C
standard? After all, I can also consult the standard while actually
programming.


Out of curiosity, how many people actually do this?


Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"


How nice. My experience of consulting the standard during an office
debate is less gratifying:

... so you see, according to the standard, that code has undefined
behavior. If you change this one line the code will work.

No, it didn't crash with the previous version of the compiler. The
new version must be buggy. I'm not changing my code.

Nov 13 '05 #141
Duncan Harvey wrote:
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:
Consult the standard during office debates? Well, it's rare. The usual
reaction to "let me just show you the bit..." is "Rich! Rich! We
***believe*** you, okay?!?!?!?!?!"

Anyone would think they didn't like reading technical documents. Odd,
that.
The reaction might not be odd at all.

Some people have no fear of, nor dislike of, reading technical documents
but are instead mindful of how such documents are structured and are
well aware of the perils of receiving information out of context. With
special regard to standards documents, the context /is the entire
document/. One cannot just look at a single paragraph in isolation and
declaim "this proves what I say is true".


This is in fact absolutely key to understanding the Standard. From the
Jargon File: "A language lawyer is distinguished by the ability to show you
the five sentences scattered through a 200-plus-page manual that together
imply the answer to your question "if only you had thought to look there"."

(The only difference here being that the C Standard is rather more than 200
pages long!)

<snip>
I can imagine scenarios where "Yes, yes. I believe you." is a
convenient and reasonably polite shorthand for, "this is indeed
interesting, but I consider it a minor point that does not affect the
outcome of the subject we were discussing, nor the project we are
working on, and it would not be a good use of our employer's time
[remember, this is an office debate] to spend a lot of time discussing
this, however engrossing it may be for us as individuals to do so, and
why can't I finish saying this run-on sentence?".
That is certainly true, but alas, it's all too rarely the true motivation
behind the reaction. Fortunately, it is /sometimes/ the motivation. ;-)

"Yes, yes. I believe you." might mean "Yes, I believe that you believe
what you say is true, but to be sure that it is actually true I'd have
to check for myself, and I don't have time/cannot be bothered/have
better things to do/don't like reading technical documents/etc.".
This is rather more common, I'm afraid.

I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.
And this, unfortunately, is the most common scenario of all, although I am
delighted to report that there are some very honorable exceptions (see
above).

[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.


"Octal is dead (and dead is hexadecimal)."
- Profound Quotations That Nobody Ever Actually Said, Vol III, p28.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #142
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:
Duncan Harvey wrote:
Some people have no fear of, nor dislike of, reading technical documents
but are instead mindful of how such documents are structured and are
well aware of the perils of receiving information out of context. With
special regard to standards documents, the context /is the entire
document/. One cannot just look at a single paragraph in isolation and
declaim "this proves what I say is true".


This is in fact absolutely key to understanding the Standard. From the
Jargon File: "A language lawyer is distinguished by the ability to show you
the five sentences scattered through a 200-plus-page manual that together
imply the answer to your question "if only you had thought to look there"."


I suspect we agree on the essentials, but to belabour the point: either
the non-language lawyer has to read the entire standard under discussion
to be sure the LL isn't mistaken or has merely forgotten a relevant but
tucked-away subsection, or they have to, well, believe them.
I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.


And this, unfortunately, is the most common scenario of all


Heh. I never said the scenarios were mutually exclusive.
[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.


"Octal is dead (and dead is hexadecimal)."


<slaps head> It took me a couple of re-reads to get that one... ;-)

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D
Nov 13 '05 #143
"Kevin D. Quitt" <KQ****@IEEInc. com> wrote in message
news:ub******** *************** *********@4ax.c om...
On Tue, 2 Sep 2003 12:37:40 -0400, "Xenos" <do**********@s pamhate.com>
wrote:
Personally, in my job hunting days, I walked out on an interviewer that
presumed to give me a test. I find the practice insulting.

[Personally, I'd love to be given that chance! Australian organisations (or
at least Canberra's) don't seem to bother with aptitude tests.]
As an occasional interviewer, I find I have to give a test. The first
question asks the applicant to rate their knowledge of C from 1 to 10,
where 1 is "What's C?" and 10 is "I'm Dennis Ritchie".


I certainly don't wish to be disrespectful, but Dennis Ritchie's role with
the Standards was consultative, and even the Committee members focused on
separate aspects of the standards. So, is Dennis necessarily at the top end
of the scale?

Another question is: does designing a language necessarily make you the top
expert at programming in that language? There are always some bright sparks
that can conjure up codings (at the very least) possibly undreamt of by the
instigator of a language. [Duff's Device would be one C example.]

I guess I think such ratings are rather nebulous and we might as well be
discussing which C programmer is the most sexiest or most likely to appear
in a movie playing themselves! :-)

--
Peter
Nov 13 '05 #144
Ben Pfaff wrote:
Martin Dickopp <ex************ *@zero-based.org> writes:
Out of curiosity, would you allow the applicant to look into the C
standard? After all, I can also consult the standard while actually
programming .


Out of curiosity, how many people actually do this? I know that
I fairly often refer to it myself while programming and have even
cited bits of it in debates at the office (VMware at the moment,
Stanford later this month).


My copy of the standard resides on a biz-card sized CD-R that
travels in my brief case. I've used it frequently and have
managed to convince a few of my clients that it should be
standard issue for their libraries and/or their individual
programmers.

It's amazing how many C programmers aren't even aware that there
is a formal C language standard.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

Nov 13 '05 #145
Duncan Harvey wrote:

<snip>
I suspect we agree on the essentials, but to belabour the point: either
the non-language lawyer has to read the entire standard under discussion
to be sure the LL isn't mistaken or has merely forgotten a relevant but
tucked-away subsection, or they have to, well, believe them.


Right. Of course, the correct choice is to re-read the entire C Standard.
Over time, this will lead to more lawyers and fewer clients. It will not,
however, diminish the number of arguments. :-)
--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #146
In article <1g************ **************@ hubris2.demon.c o.uk>,
sp**@hubris2.de mon.co.uk (Duncan Harvey) wrote:
Randy Howard <ra**********@F OOmegapathdslBA R.net> wrote:
In article <3f55b901.87113 5703@news-server>, oz****@spamenot .bigpond.com
says...
Those of us who have been in the game for decades find this sort of
practice demeaning, and a good indication that it is a job we don't
want anyway. Therefore, it saves time on both persons' parts.
[..snip..]

Not all "decades of experience" programmers are equal. [...]


Quite right.

When my employer receives a CV (or 'resume' if you don't mind the lack
of accent) they provide a trivial aptitude test for the candidate to
complete. Recently I've been required to review and comment on
candidates' CVs and tests. One guy claimed over twenty years of C
experience. Judging from his test results he'd never had occasion to
use C strings or dynamically allocated memory. It is certainly possible
to write interesting programs in C using neither of those facilities.
But for twenty years? That's either stupidity or wilful perversion. I
have no particular desire to see either close up.


I can't remember when was the last time that I would have used C strings
and C memory allocation without any intervening layer on a major
project.

I have worked on projects where there was no need for string handling
whatsoever, and I have worked on projects where C string handling was so
inadequate for our purposes that it was useless. In both cases, no C
constant strings, no strcpy.

When you wrote "never had occasion to use dynamically allocated memory"
you probably mean "never used malloc". malloc is programming on the raw
iron. On many implementations , malloc is so broken it is basically
useless (returns a non-NULL pointer and your machine crashes if you try
to access the memory), so at the very least you have a layer in between.
FWIW I actually do believe that he'd been writing C for twenty years.
That's what scares me.

Nov 13 '05 #147
On Sat, 6 Sep 2003 22:36:51 +0100
sp**@hubris2.de mon.co.uk (Duncan Harvey) wrote:
Randy Howard <ra**********@F OOmegapathdslBA R.net> wrote:
In article <3f55b901.87113 5703@news-server>,
oz****@spamenot .bigpond.com says...
Those of us who have been in the game for decades find this sort
of practice demeaning, and a good indication that it is a job we
don't want anyway. Therefore, it saves time on both persons'
parts.


[..snip..]

Not all "decades of experience" programmers are equal. [...]


Quite right.

When my employer receives a CV (or 'resume' if you don't mind the lack
of accent) they provide a trivial aptitude test for the candidate to
complete. Recently I've been required to review and comment on
candidates' CVs and tests. One guy claimed over twenty years of C
experience. Judging from his test results he'd never had occasion to
use C strings or dynamically allocated memory. It is certainly
possible to write interesting programs in C using neither of those
facilities. But for twenty years? That's either stupidity or wilful
perversion. I have no particular desire to see either close up.

FWIW I actually do believe that he'd been writing C for twenty years.
That's what scares me.


I spent a few years writing C code without using either dynamic memory
allocation or strings. It was embedded code which had no reason to use
strings (no display, no string inputs, nowhere to send string outputs)
and the coding standard (not written by me) did not allow dynamic memory
allocation or unbounded recursion since then you would not know how much
memory the application used and therefor whether it would work. Do you
fancy having the altimeter on an aircraft reporting an out of memory
error?

So it is entirely possible depending on what area the person was working
in.

Since then I have moved on to other fields where I regularly use strings
and dynamic memory.
--
Mark Gordon
Nov 13 '05 #148
Christian Bau <ch***********@ cbau.freeserve. co.uk> wrote:
I have worked on projects where there was no need for string handling
whatsoever, and I have worked on projects where C string handling was so
inadequate for our purposes that it was useless.
I presume that to make that assessment you had to be aware of how C
strings worked?
When you wrote "never had occasion to use dynamically allocated memory"
you probably mean "never used malloc".
Possibly. I suspect the candidate in question had never programmed
equipment whose finite amount of memory affected them or their software.
malloc is programming on the raw iron.
I'd quibble about that.
On many implementations , malloc is so broken it is basically useless
(returns a non-NULL pointer and your machine crashes if you try to access
the memory), so at the very least you have a layer in between.


If your point is that you can find fault in such tests and in the test
setters, then you're absolutely right. But as has been shown elsewhere
in this thread people who have such knowledge find inventive and often
amusing ways to convey this fact. Few will merely flunk the test out of
disgust for the fools that made it. They often answer the question as
'expected' and then add an interesting, mildly sarcastic comment like
yours, quoted above. Such a comment would merit a higher score from me.

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D
Nov 13 '05 #149
Mark Gordon <sp******@fla sh-gordon.me.uk> wrote:
I spent a few years writing C code without using either dynamic memory
allocation or strings. It was embedded code which had no reason to use
strings (no display, no string inputs, nowhere to send string outputs) and
the coding standard (not written by me) did not allow dynamic memory
allocation or unbounded recursion since then you would not know how much
memory the application used and therefor whether it would work.
You live and learn. Thank you. I should have known better.
Do you fancy having the altimeter on an aircraft reporting an out of
memory error?
Yes, if the alternative is an incorrect reading.

Naturally, I'd hope that the device would operate uninterrupted and
correctly unless damaged or destroyed (or suffering power-loss, I
assume?).
So it is entirely possible depending on what area the person was working
in.


I cannot recall I'm afraid, but believe that the person had no embedded
experience whatsoever.

--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D
Nov 13 '05 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.