i need some C/C++ test intervie questions

[Richard Heathfield]

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!)

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.

 

[Duncan Harvey]

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.

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... ;-)

 

[Peter Nilsson]

[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!

 

[Morris Dovey]

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.

 

[Richard Heathfield]

Duncan Harvey wrote:

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.

 

[Christian Bau]

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.

 

[Mark Gordon]

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.[/QUOTE]

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.

 

[Duncan Harvey]

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]

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.

 

[Simon Biber]

"Name the ISO International Standard number for the C/C++
language."

9899 / 14882 = 0.66516597231554898535143125923935

 

[Mark Gordon]

On Sun, 7 Sep 2003 12:22:38 +0100

Yes, if the alternative is an incorrect reading.

The alternative is you design a solution that does not require *alloc.
For all of the embedded work I did this was easy since where data was
being read in to buffers you had exact specifications at to the maximum
data rates and what to do if you could not process data fast enough (in
my cases selectively throwing data away) so you could calculate buffer
sizes at design time.

Naturally, I'd hope that the device would operate uninterrupted and
correctly unless damaged or destroyed (or suffering power-loss, I
assume?).

For safety critical work you have all sorts of things done to ensure
continued operation such as an independent backup. The details depend on
how safety critical the system is (there are different levels) and what
is practical. Almost all of my work was *not* safety critical so I'm not
an expert.

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

I've written (or been involved in writing) large programs in Pascal that
did not use dynamic memory allocation and would not have used *alloc
functions if written in C. However they did you string manipulation.

I find it hard to believe that someone could work for along time in C
outside the embedded market without having to use C strings and str*
functions and *alloc functions. Although as another poster said the
*alloc functions could be used through wrapper functions.

 

[Martin Dickopp]

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

I disagree. While it is in fact often necessary to consider serveral
paragraphs scattered throughout the standard, theorems about the language
can be proven or disproven without considering the entire document.

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.)

Maybe I misunderstand your example completely, but I don't see how it
supports your position. Person A simply misunderstands the scope of
the standard, which describes the behavior of an abstract machine.
A conforming implementation need only match the /observable/ behavior
of the abstract machine. But it is not necessary to read the entire
standard to understand its scope.

Martin

 

[LibraryUser]

9899 / 14882 = 0.66516597231554898535143125923935

Excellent. A fairly close approximation is 2/3.

 

[Richard Heathfield]

Mark Gordon wrote:

I find it hard to believe that someone could work for along time in C
outside the embedded market without having to use C strings and str*
functions and *alloc functions.

So do I. Nevertheless, either it's true, or people lie on their CVs about
how much experience they have of programming in the C language.

Which would you bet on? ;-)

Although as another poster said the
*alloc functions could be used through wrapper functions.

True; but, even so, you'd expect a guy with 20 years under his belt to have
worked out how to call malloc by now.

 

[Kevin D. Quitt]

Anybody who claims they are, aren't. With, perhaps, two or three
exceptions.

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.
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].

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.

Indeed. I would accept an "I'm not sure, but..." with the above as a
reasonably correct answer. It seems pretty obvious to me, but then, I'm
Mr. Wonderful. 8o/

 

[Kevin D. Quitt]

You mean you are hiring? I can be bought.

You live in SoCal?

 

[Kevin D. Quitt]

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?

My intent was to be whimsical, implying that the scale is not a
hard-and-fast thing with objective values. How about "I'm Henry Spencer"?
There doesn't seem to me to be any serious way to represent the top end of
the scale, or a more meaningful one no matter how it's expressed. I am
open to ideas, of course.

Another question is: does designing a language necessarily make you the top
expert at programming in that language?

For a while, at least. 8o)

I guess I think such ratings are rather nebulous

Intentionally, but not meaningless.

 

[Kevin D. Quitt]

glad you realise it no one is. but ttry telling a prima donna
that they write faulty code.

Been there, done that, got the scars. It's my experience that prima
donnas don't last long. Too long, sometimes.

<sigh> not really. you get labelled as a "lone programmer" (as opposed
to a "team player") if you hurt the prima donnas feelings.

I meant with my exam (or code, for that matter). I am an ego-less
programmer. If there's a bug in my code, I'm delighted when somebody can
tell me what it is or what it does, so that they or I can fix it; I only
care that the code be properly functional. My expertise is ultra-reliable
code; you can't have that if you aren't willing for it to be beaten to
death by everyone involved.

<grin> not even my partially complete rtos written mostly in std C
(with all the platform-specific stuff in seperate files) ???
but i'm *proud* (or rather, was) of it...

Actually, *hearing* about it would be of interest - how it was organized,
etc., and it doesn't matter what language it was written in. That
information is *useful*: it helps me see how you think. I am also
interested in seeing clever code snippets, whether they're "good" code or
not. Because I'm such a swell guy, see the program below.

or you can ask them to name the ergs on clc ;-)

ergs?


Notes: There are no tab characters.
Each line starts with a greater-than which must be removed.

(*O/*_/
Cu #%* )pop mark/CuG 4 def/# 2 def%%%%@@P[TX---P\P_SXPY!Ex(mx2ex("SX!Ex4P)Ex=
CuG #%* *+Ex=
CuG #%*------------------------------------------------------------------*+Ex=
CuG #%* POLYGLOT - a program in seven languages 15 February 1991 *+Ex=
CuG #%* *+Ex=
CuG #%* Written by Kevin Bungard, Peter Lisle, and Chris Tham *+Ex=
CuG #%* *+Ex=
CuG #%* We have successfully run this program using the following: *+Ex=
CuG #%* ANSI COBOL: MicroFocus COBOL85 (not COBOL74) *+Ex=
CuG #%* ISO Pascal: Turbo Pascal (DOS & Mac), Unix PC, *+Ex=
CuG #%* AIX VS Pascal *+Ex=
CuG #%* ANSI Fortran: Unix f77, AIX VS Fortran *+Ex=
CuG #%* ANSI C (lint free): Microsoft C, Unix CC, GCC, Turbo C++, *+Ex=
CuG #%* Think C (Mac) *+Ex=
CuG #%* PostScript: GoScript, HP/Adobe cartridge, *+Ex=
CuG #%* Apple LaserWriter *+Ex=
CuG #%* Shell script: gnu bash, sh (SysV, BSD, MKS), ksh *+Ex=
CuG #%* 8086 machine language: MS-DOS 2.00, 3.03, 4.01, 5.00 beta *+Ex=
CuG #%* VPix & DOS Merge (under unix) *+Ex=
CuG #%* SoftPC (on a Mac), MKS shell *+Ex=
CuG #%* *+Ex=
CuG #%* Usage: *+Ex=
CuG #%* 1. Rename this file to polyglot.[cob|pas|f77|c|ps|sh|com] *+Ex=
CuG #%* 2. Compile and/or run with appropriate compiler and *+Ex=
CuG #%* operating system *+Ex=
CuG #%* *+Ex=
CuG #%* Notes: *+Ex=
CuG #%* 1. We have attempted to use only standard language features. *+Ex=
CuG #%* Without the -traditional flag gcc will issue a warning. *+Ex=
CuG #%* *+Ex=
CuG #%* 2. This text is a comment block in all seven languages. *+Ex=
CuG #%* *+Ex=
CuG #%* 3. When run as a .COM file with MS-DOS it makes certain *+Ex=
CuG #%* (not unreasonable) assumptions about the contents of *+Ex=
CuG #%* the registers. *+Ex=
CuG #%* *+Ex=
CuG #%* 4. When transfering from Unix to DOS make sure that a LF *+Ex=
CuG #%* is correctly translated into a CR/LF. *+Ex=
CuG #%* *+Ex=
CuG #%* Please mail any comments, corrections or additions to *+Ex=
CuG #%* (e-mail address removed) *+Ex=
CuG #%* *+Ex=
CuG #%*------------------------------------------------------------------*QuZ=
CuG #%* *+Ex=
CuG #%*!Mx)ExQX4ZPZ4SP5n#5X!)Ex+ExPQXH,B+ExP[-9Z-9Z)GA(W@'UTTER_XYZZY'CPK*+
CuG #(* *(
C # */); /*(
C # *) program polyglot (output); (*+
C # identification division.
C # program-id. polyglot.
C #
C # data division.
C # procedure division.
C #
C # * ))cleartomark /Bookman-Demi findfont 36 scalefont setfont (
C # * (
C #
C # * hello polyglots$
C # main.
C # perform
C * ) 2>_$$; echo "hello polyglots"; rm _$$; exit
print
C stop run.
-*, 'hello polyglots'
C
C print.
C display "hello polyglots". (
C */ int i; /*
C */ main () { /*
C */ i=printf ("hello polyglots\n"); O= &i; return *O; /*
C *) (*
C *) begin (*
C *) writeln ('hello polyglots'); (*
C *) (* )
C * ) pop 60 360 (
C * ) pop moveto (hello polyglots) show (
C * ) pop showpage ((
C *)
end .(* )
C)pop% program polyglot. *){*/}

-----------------------8<--------------------------

 

[Kevin D. Quitt]

a trivial aptitude test

THat's what mine is supposed to be, except a little more, as well. I'll
show you mine if you'll show me yours. 8o)

 

[Randy Howard]

Do you fancy having the altimeter on an aircraft reporting an out of
memory error?

Conventional aircraft have traditional altimeters which function off
barometric pressure, no firmware required. The error is likely to be
due to changes in atmospheric pressure, which is normally corrected
by locale specific data given by air traffic control, or an automated
weather reporting system (radio) such as AWOS.

Even modern "glass cockpit" planes that have altitude information fed
to an electronic display from a source such as a 3D-nav GPS feed still
typically have a backup altimeter that will function even in the event
of an electrical failure which will render altitude data from a GPS
useless. It's also typically less accurate to use the "modern" GPS-
based solution (provided the manual altimeter is calibrated for local
pressure).

The only "out of memory error" likely on an actual altimeter is the
one where the senile pilot forgets to adjust for current pressure
conditions on a regular basis.