Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- From: jellybean stonerfish <stonerfish@xxxxxxxxxxxxx>
- Date: Wed, 02 Jan 2008 18:13:15 GMT
On Mon, 31 Dec 2007 14:00:46 +0000, Richard Heathfield wrote:
For the record, I was boasting when I posted my score. I realize the test
is flawed, but I was boasting that I am so good at taking test on subjects
I know a little about.
I have no particular comment to make on question 1, although I wouldn't
have worded the question like that.
Question 2 is unfortunate, since it has two correct answers; although it's
obvious which one is wanted, another of the answers is perfectly
defensible. Neither is exclusively correct.
I agree. It is obvious that a member function can manipulate variables
defined inside the member function. And it was obvious to me that the
tester wanted the 'member data' answer, because in stroustrups book he
suggests using member functions to access member data.
Question 5 is broken. None of the specified types guarantees the
necessary precision for dealing with twenty decimal digits. The long
double type only guarantees ten. One could reasonably argue that any of
the integer types mentioned gives an adequate basis for developing a
bignum library that could give the required precision.
While reading question 5 I realized that using more than one integer would
be easier to represent 20 digit precision. (The word bignum library was
not quite in my mind, but I can think of ways to do it. ) And I felt that
a long double would not be big enough. I answered long double because it
is the largest type in the list, and I wanted to get a good test score.
Question 6 is broken. None of the supplied answers gives the required
output, which is:
a c b d
(A) will give a\t\nb\td
(B) will give some output dependent on the (unsupplied) values of the
objects given in the expression.
(C) will give acb\nd
(D) will give ab\nc\td
In the cases of A, C, and D, the backslashes shown here do not introduce
escape sequences (which would in any case break their conformance to the
requirement), but literally part of the output, as they are themselves
escaped.
I got that one wrong. I should have realized that the double backslashes
were a typo. I think they were included because the coder of the page
thought the first backslash would make the second backslash appear on the
page. I kicked myself for missing that one.
Question 7 is trivial.
Not even a c++ question really, is it?
Question 8 is broken. All of the suggested answers except A exhibit
undefined behviour, and answer A modifies the value of x. There is no
correct answer.
I will disagree with you here. Digging out my copy of the c++ programming
language on page 125, stroustrup says that y=++x is equivalent to y=(x+1)
but y=x++ is equivalent to y=(t=x, x+=1, t) Or in other words if the ++
is before the variable the 1 is added first, and if the ++ is after the
variable the 1 is added after the variables value is used.
Question 9 is trivial.
It was kind of hard for me. I couldn't remember if a '.'or a ':' was the
correct separator. I guessed correctly.
Question 10 fails to account for pointer comparison, but is otherwise
trivial.
It also fails to account that with objects the comparison operators can
compare other things than numbers. As only one answer returned a
boolean, I picked that answer. I still don't quite understand, is there
a difference between 'logical values' and 'boolean'?
Question 14 is ambiguous - it depends on whether you consider 'between'
to be inclusive. I don't, so I might disagree with the marker over which
answer should be considered correct.
I don't consider 'between' to be inclusive. As the other two answers were
more wrong, I picked 'a'.
Question 16 is trivial if you discount the possibility that the break
appears inside a switch.
Yes, again if you filter out the possibilities the answer is easy.
Questions 17 and 18 are trivial, but 18 is very badly worded.
The wording on 18 almost tricked me.
Questions 19, 20, and 21 are trivial.
I missed 20. I answered car.accelerate(). When I read #20 and saw that
they used '.' for a separator not ':' I scrolled back up to problem 9 to
make sure I had it right. Then came back down to 20 and clicked without
reading carefully.
Question 22 is incorrect. sqrt is declared in <math.h> but only a
complete bozo would define it there.
Not having a clue where sqrt was defined I answered 'b' because the syntax
looked correct to me. Now looking at my /usr/include/math.h I see that
sqrt is not even declared in there on this system. Probably in one of the
files included from math.h. But I really don't care right now.
Questions 23-27 are trivial.
Question 28 has no good answer. There's no reason why you can't write a
linked list class (although there's no point, because there's one in the
STL). Nor is there any reason why you couldn't use structs to implement
a linked list. Nor is there any reason why you can't construct a linked
list that can hold only a single type.
Nor is there any point in
constructing a linked list that can only have a fixed number of elements.
I don't understand your statement. Why is answer 'c' (can hold any type
of data ) not a good answer?
Question 29 has no correct answer. Arrays don't hold types. They *have*
types, but they are aggregate types that can store multiple *objects* of
a given type. If we agree that that's kinda what the guy meant only he
didn't say it very well, we must discount (A) as being incorrect
(because they can hold complicated types such as user-defined types). We
must also discount (B) because arrays can't hold function types
(although they /can/ hold function pointer types). And we must discount
(C) for the same reason as (B).
Ok, I thought I was totally on with my 'c' answer. I didn't even think
there was a problem with that question until I read you post.
Questions 30 and 31 are trivial.
Question 32 has no correct answer.
I got that one right! But after referencing my book, I see that by
definition 'a struct is a class in which the member are by default public'
struct s { ...
is simply shorthand for
class s { public ...
Questions 33-43 are trivial.
38 was not trivial, but I should have guessed 'a' instead of 'b'
Question 44 has no clearly correct answer. (A) is wrong because it
doesn't access the base class function. (B) is wrong because it uses a
class name in an object context. (C) is wrong unless the code exists
within the class of which the function is a member.
Base_class is an object of the base class?
Questions 45-47 are trivial.
Not really. 45 and 47 showed that I do not know the rules inheritance.
Questions 48-49 seem to use the word "composition" in a way I'm not
familiar with. I think of the term as applying to the moving of a
subexpression evaluation into an object that stores the subexpression to
make subsequent evaluation of the whole expression simpler and quicker.
It is not obvious that the suggested answers have anything to do with
this! This may simply be because I'm not as up on C++ as the author of
the quiz. Given the brokenness of the rest of it, however, I do not find
that possibility to be terribly likely.
I believe 'composition' in this context means to put together parts to
make a bigger object, so I picked 'c', the correct answer.
Question 50 is trivial.
Again only trivial if you know the subject matter.
I didn't give answers to the ones I thought had no correct answer. I
scored 80% (i.e. 40 out of 50).
stonerfish
.
- Follow-Ups:
- Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- From: Richard Heathfield
- Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- Prev by Date: Re: script editor
- Next by Date: Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- Previous by thread: Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- Next by thread: Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum
- Index(es):
Relevant Pages
|