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  14918 
Martin Dickopp wrote: Tom Zych <tz******@pobox .com> writes:
IIRC, Ramanujan learned from one book and figured out the rest on his
own. You can do that with math[1], because math is self-contained and
deductive.
Actually, Kurt Gödel proved that no complete axiomatic system can be free
of undecidable theorems. So not only is mathematics not self-contained and
deductive, but it couldn't even be replaced by an alternative complete
axiomatic system which is. :)
Hmm. I don't really see how Gödel's theorem contradicts what I
said. IIRC, he proved that in any sufficiently complex formal
system, there are true statements that can't be proved
algorithmically , within the system. That doesn't mean they can't
be proved some other way; he had to do that to prove his result.
"Self-contained" != "complete". I meant that, unlike most
subjects, you don't have to know anything about the real world to
do math, because any resemblance between math and the real world
is purely coincidental. Damned useful, but still coincidental.
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk. pbz' | rot13
On Thu, 4 Sep 2003, Richard Heathfield wrote:
Denis Perelyubskiy177 0880499 wrote: On 9/4/2003 2:30 PM, Richard Heathfield: 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.
Consult the standard during programming? Frequently.
To me, this would mean one of two things: programmer who does so
either does not know C, or uses obscure constructs.
Without looking it up in any reference whatsoever, please tell me which way
round the middle two arguments of fread go.
I agree with your point, of course, but here's the mnemonic I eventually
managed to bash into my brain, and which might help some people:
Little number first, big number second.
unsigned char buffer[10];
fread(buffer, 1, 10, fp);
(Of course, this works only if you're like me and do fread/fwrite
with unsigned char buffers, rather than reading and writing whole
structs at a time. But that's not portable, so I know Richard
doesn't do it. ;-)
It works for memset, too:
Little number first, big number second.
unsigned char buffer[10];
memset(buffer, 0x00, 10);
It *doesn't* work for qsort. Now why on earth did they switch
those parameters around for qsort? Geez... but qsort has enough
other quirky bits that I end up looking it up anyway, just to
make sure I got the int (*)(const void *, const void *) correct.
HTH,
-Arthur
Richard Heathfield wrote:
Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?
#include <stdio.h>
#include <ctype.h>
int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++) ; /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).
But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?
Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).
The sequence point at the function call is a red herring.
It separates the `*p++' and its side-effect(s) from the body
of the function, but does not separate them from the evaluation
of the lvalue `p[-1]'.
-- Er*********@sun .com
Tom Zych wrote: Richard Heathfield wrote:
...is the behaviour of this program well-defined?
#include <stdio.h>
#include <ctype.h>
int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++) ; /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
I'm not a standard C guru (yet). My answer is, it doesn't matter,
because even if one can dig into the standard and show that this
works reliably, it's bad code.
This is a very important aspect of the answer, which no self-respecting
interviewee should ignore as a possible lifeline if they are floundering on
the actual sequence point issue.
You can't tell if it works without
being a language lawyer, and it offers no advantage over clear and
reliable code. It should be rewritten and the original coder
should be shot[1].
Yes, I think that's a fair summary. :-) My thanks to all those who
answered.
--
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
On Thu, 4 Sep 2003, Richard Heathfield wrote:
Denis Perelyubskiy177 0880499 wrote: On 9/4/2003 2:30 PM, Richard Heathfield: 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.
Consult the standard during programming? Frequently.
To me, this would mean one of two things: programmer who does so
either does not know C, or uses obscure constructs.
Without looking it up in any reference whatsoever, please tell me which way
round the middle two arguments of fread go.
I agree with your point, of course, but here's the mnemonic I eventually
managed to bash into my brain, and which might help some people:
Little number first, big number second.
unsigned char buffer[10];
fread(buffer, 1, 10, fp);
(Of course, this works only if you're like me and do fread/fwrite
with unsigned char buffers, rather than reading and writing whole
structs at a time. But that's not portable, so I know Richard
doesn't do it. ;-)
It works for memset, too:
Little number first, big number second.
unsigned char buffer[10];
memset(buffer, 0x00, 10);
It *doesn't* work for qsort. Now why on earth did they switch
those parameters around for qsort? Geez... but qsort has enough
other quirky bits that I end up looking it up anyway, just to
make sure I got the int (*)(const void *, const void *) correct.
HTH,
-Arthur
In article <3F************ ***@sun.com>,
Eric Sosman <Er*********@su n.com> wrote: Richard Heathfield wrote:
Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?
#include <stdio.h>
#include <ctype.h>
int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++) ; /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).
But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?
Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).
Even if it were not undefined behaviour, the evaluation order is
unspecified, so you don't know whether the result would be stored int
buf [-1] or buf [0] and storing into buf [-1] is certainly not a good
idea.
Depending on your impression of the interviewer, that might be the
better answer. The interviewer might never have heard of "undefined
behavior" or "C Standard", but any interviewer should be able to
understand that this code could store into buf [-1].
In article <3F************ ***@sun.com>,
Eric Sosman <Er*********@su n.com> wrote: Richard Heathfield wrote:
Okay, I'm listening. Here's the question: is the behaviour of this program
well-defined?
#include <stdio.h>
#include <ctype.h>
int main(void)
{
char buf[] = "hello world";
char *p = buf;
p[-1] = (toupper)(*p++) ; /* This is the trouble spot. */
printf("%s\n", buf);
return 0;
}
When I first saw this, I thought "no way". Then, after discussions with a
clc regular and much thumbing of the Standard, I began to come to the
conclusion that it might be okay (for suitably pedantic values of "okay",
obviously -- the code sucks, after all).
But I'm no longer certain, because... well, never mind! Is it well-defined?
If so, why? If not, why not?
Stick with your first impression, I'd say. Undefined
behavior: Without intervening sequence points, `p' is both
modified and read for a purpose other than to determine the
new value (6.5, paragraph 2).
Even if it were not undefined behaviour, the evaluation order is
unspecified, so you don't know whether the result would be stored int
buf [-1] or buf [0] and storing into buf [-1] is certainly not a good
idea.
Depending on your impression of the interviewer, that might be the
better answer. The interviewer might never have heard of "undefined
behavior" or "C Standard", but any interviewer should be able to
understand that this code could store into buf [-1].
Ben Pfaff <bl*@cs.stanfor d.edu> wrote in message news:<87******* *****@pfaff.sta nford.edu>... ru**@webmail.co .za (goose) writes:
ah ... see .. any test that tests me on anything /other/ than
C (or any programming language I may claim to know), i'd do badly
on. my experience is a rather limited problem domain.
go on. ask me about emv :-)
What's emv?
(in case you were serious:-)
smartcard standard for financial transactions ...europay/mastercard/visa
goose,
by day, i'm a boring terminal developer!!! but by *night*, i'm a
boring PIC developer :-)
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.
--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D
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". <memo to self: insert comedy
remark about religious texts and their followers> For (a silly)
example, person A might be optimising an inner loop that invoked
ispunct() a lot. They start to do bizarre things to 'optimise' away this
call to "avoid function call overhead". Person B says that it might be
the case that the implementation has already done this for them. Person
A snorts and replies, '7.3.1.11 states "The ispunct() *function* tests
[...]"'[1] and slumps back into his chair satisfied. (I admit, as
hypothetical examples go, that is not entirely convincing but I trust
that you'll see what I'm driving at.)
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?".
"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.".
I can imagine a further scenario, where the person saying "Yes, yes. I
believe you." is merely an idiot.
[1] For some unknown reason Person A always cites section numbers using
octal. And may not be aware of C99.
--
Duncan Harvey
"One is all you need"
-- J.B., Tenacious D This thread has been closed and replies have been disabled. Please start a new discussion. |
