frequently asked C and C++ interview questions along with their answers

I

Ioannis Vranos

Spacen said:
Yes, it's true. I think the best interviews are those that ask a variety of
questions. 3 questions arn't really enough. And in my opinion good C
knowledge is not necessarily enough -- but on the other hand if you have
good C knoweledge then you are likly to be more rounded since you've had to
spend time learning about all sort of things while putting C to use.



C++ and C are separate languages. Also C++ provides superior
alternatives to many C idioms and facilities. An example is the use of
void * pointers for generic purpose functions in C and templates in C++b
to do the same stuff elegantly and efficiently.


You should concentrate on the higher level facilities of C++.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
I

Ioannis Vranos

DaKoadMunky wrote:

Should this result in an executable program?

I was expecting a linker error.

I am aware that in certain contexts the name of an array can be converted to a
pointer and used as though if it were a pointer. I did not expect this to be
one of them though.

When executed the program crashes.

If the declaration in c1.c and the definition in c2.c are made to match then
the program executes without error.

Was MSVC++.NET correct in allowing this program to build?



The extern declaration becomes a definition in the absence of another
definition or the other declarations are using also extern.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
I

Ioannis Vranos

Julie said:
I find it somewhat dichotomous how we programmers deal with extreme precision,
something that isn't precise usually doesn't work or worse, yet we allow
ourselves to be treated as morons and never attempt to establish what is really
intended by those that we work for.

My original response was somewhat facetious, intended to bring up some points
about the interviewing process and the capacity of the interviewer.

Honestly, if I were in an interview like that:

interviewer: <code snippet>, "what's wrong with this code?"

me: "Without knowing the specific requirements, it is hard to really determine
what is really 'wrong' as it looks like it would compile just fine to me. I do
see it resulting in undefined behavior when executing, however. Can you tell me
what the requirements are?."

interviewer: "I'll get to the requirements in a sec; what do you mean by
undefined behavior?"

me: "Well, there is a problem when derefrencing x because it hasn't been
initialized. The standard indicates that doing such results in 'undefined
behavior', so just about anything can happen at that point, but will probably
result in a crash."

interviewer: "By the way, the requirement was to 'write a program that exhibits
undefined behavior' -- nice job, you have been the only candidate to realize
that requirements are an important part to the development process."



Ehehehe, what requirements and stuff. The question is simple: "What's
wrong with this code?".


The answer is: "(The wrong with this code is that) It produces undefined
behaviour.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
S

Shailesh Humbad

Julie said:
Well then, that is the misfortune of the company.

I find it somewhat dichotomous how we programmers deal with extreme precision,
something that isn't precise usually doesn't work or worse, yet we allow
ourselves to be treated as morons and never attempt to establish what is really
intended by those that we work for.

My original response was somewhat facetious, intended to bring up some points
about the interviewing process and the capacity of the interviewer.

Honestly, if I were in an interview like that:

interviewer: <code snippet>, "what's wrong with this code?"

me: "Without knowing the specific requirements, it is hard to really determine
what is really 'wrong' as it looks like it would compile just fine to me. I do
see it resulting in undefined behavior when executing, however. Can you tell me
what the requirements are?."

interviewer: "I'll get to the requirements in a sec; what do you mean by
undefined behavior?"

me: "Well, there is a problem when derefrencing x because it hasn't been
initialized. The standard indicates that doing such results in 'undefined
behavior', so just about anything can happen at that point, but will probably
result in a crash."

interviewer: "By the way, the requirement was to 'write a program that exhibits
undefined behavior' -- nice job, you have been the only candidate to realize
that requirements are an important part to the development process."

Yeah, it's a good point, and I had a laugh. But remember, you should
always answer a question from the point of view of the questioner.
Questions are always asked in a vast context that exists at the time
of the interview, as opposed to the threadbare context that exists in
a newsgroup posting. It is unlikely that the interviewer would want
to know about language correctness or program requirements. If the
interviewee did quibble about these, the interviewer would most likely
think the candidate is being snobbish and wasting their time.
Creativity is good, but not when someone is asking you questions and
expecting certain responses. This is especially true in an interview,
because people tend to hire other people who think like themselves.

If I were interviewing, I would ask them what are the four components
of the stack frame created by a function call.

Answer:
return address
saved machine state
copies of function parameters
space for local variables
 
D

DaKoadMunky

If I were interviewing, I would ask them what are the four components
of the stack frame created by a function call.

Answer:
return address
saved machine state
copies of function parameters
space for local variables

That is certainly not a C++ question and the interviewee not knowing the answer
is not an indicator as to whether or not they can be an effective C++
developer.

If the domain you are interviewing for is compiler writing I suppose the
question has merit, but I am not sure it is relevant for your average
application developer, but I would give extra points to those who did have such
knowledge because it might indicate that they are the type of person who likes
to know how and why things work...not just that they do work. That might be a
desirable trait.
 
J

JKop

Ioannis Vranos posted:
The extern declaration becomes a definition in the absence of another
definition or the other declarations are using also
extern.


Gotta love it!


-JKop
 
J

JKop

Q: What's wrong with this car?

A: It's windscreen is smashed, it has four flat tyres, both
sidemirrors are broken off, the bonnet is bent, the back
passenger side door is missing.

No, nothing's wrong with the car - it's supposed to be like
that.



-JKop
 
I

Ioannis Vranos

Shailesh said:
Yeah, it's a good point, and I had a laugh. But remember, you should
always answer a question from the point of view of the questioner.
Questions are always asked in a vast context that exists at the time of
the interview, as opposed to the threadbare context that exists in a
newsgroup posting. It is unlikely that the interviewer would want to
know about language correctness or program requirements. If the
interviewee did quibble about these, the interviewer would most likely
think the candidate is being snobbish and wasting their time. Creativity
is good, but not when someone is asking you questions and expecting
certain responses. This is especially true in an interview, because
people tend to hire other people who think like themselves.


Furthermore there can not be an application requirement for "undefined
behaviour". Because undefined behaviour would mean that the program may
or may not do something when it is executed.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
A

Alf P. Steinbach

* Shailesh Humbad:
If I were interviewing, I would ask them what are the four components
of the stack frame created by a function call.

Hello? I wouldn't have _any_ idea what in the world you were talking
about. And I do know both various assembly languages and C++.

Answer:
return address
saved machine state
copies of function parameters
space for local variables

Well that's incorrect however one looks at it.

Return address, sure. Almost any call pushes a return address. Except
on the MIX computer (do read your Donald Knuth).

Machine state? Only for an interrupt.

_Copies_ of function parameters? Nope, not at all. The function
parameters may be on the stack, but e.g. for Windows "fastcall"
convention they don't need to be there.

Space for local variables -- depends on whether ones thinks a
function prologoue is part of the _call_ or the _function_; I think
most people regard it as part of the function, because it's very
very easy to dip down to that level and put local variables
elsewhere, and the calls will still be the good old calls.
 
D

David Harmon

On Sat, 17 Jul 2004 11:30:17 -0700 in comp.lang.c++, Julie
I'm not a fool, nor a language lawyer. However, I do answer the question
_asked_. What do you do? Answer what isn't asked?!

In answer to the question, nothing is wrong. How can you determine what is
wrong when what is expected isn't defined? Suppose the requirement was to
"create a program that exhibits undefined behavior" --

Ah, so you are a requirements lawyer.

There are many answers to the question and even several correct answers.
Which answer you give tells the interviewer what kind of thinker you
are.

My answer is given in
http://groups.google.com/[email protected]
 
D

David Rubin

If I were interviewing, I would ask them what are the four components
of the stack frame created by a function call.
[snip]
If the domain you are interviewing for is compiler writing I suppose the
question has merit, but I am not sure it is relevant for your average
application developer, but I would give extra points to those who did have such
knowledge because it might indicate that they are the type of person who likes
to know how and why things work...not just that they do work. That might be a
desirable trait.

This is one I like:

a) What is the difference between *arguments* and *parameters*?

b) Assume the existence of a function 'void *foo(void *adt)' which
takes an an opaque pointer 'adt' that must be cast to a pointer to a
user-defined type containing various members. (A concrete example of
'foo' is 'pthread_create'.) Do you call this user-defined type
'my_FooParameters' or 'my_FooArguments'?

/david
 
O

Old Wolf

/* File: c1.c */

extern char *str;

/* File: c2.c */

char str[] = "Hello world";

Should this result in an executable program?

I was expecting a linker error.

Linkers don't know anything about types. In c2.c, str could have been an
int, or even the name of a function, and it would still link correctly
(and produce undefined behaviour at runtime). This is why it is a good
idea to put 'extern' statements in header files, and ensure that the
header file is included in the TU that defines the object.

More info:
http://www0.us.ioccc.org/1984/mullender.c
 
A

Alf P. Steinbach

* David Rubin:
This is one I like:

a) What is the difference between *arguments* and *parameters*?

They're two different words.

b) Assume the existence of a function 'void *foo(void *adt)' which
takes an an opaque pointer 'adt' that must be cast to a pointer to a
user-defined type containing various members. (A concrete example of
'foo' is 'pthread_create'.) Do you call this user-defined type
'my_FooParameters' or 'my_FooArguments'?

No.

And it's a Very Bad Design (TM).
 
I

Ioannis Vranos

David said:
This is one I like:

a) What is the difference between *arguments* and *parameters*?



For functions they mean the same thing while "argument" is more often
used for specific objects passed in a function, but there is no specific
rule in reality.


b) Assume the existence of a function 'void *foo(void *adt)' which
takes an an opaque pointer 'adt' that must be cast to a pointer to a
user-defined type containing various members. (A concrete example of
'foo' is 'pthread_create'.) Do you call this user-defined type
'my_FooParameters' or 'my_FooArguments'?



Whatever fits the application better.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys
 
M

Mathew Hendry

For functions they mean the same thing while "argument" is more often
used for specific objects passed in a function, but there is no specific
rule in reality.

Yes there is. Their definitions appear quite early in the standard:

| 3. Terms, definitions, and symbols
|...
| 3.3
| 1 argument
| actual argument
| actual parameter (deprecated)
| expression in the comma-separated list bounded by the parentheses in a
| function call expression, or a sequence of preprocessing tokens in the
| comma-separated list bounded by the parentheses in a function-like macro
| invocation
|...
| 3.15
| 1 parameter
| formal parameter
| formal argument (deprecated)
| object declared as part of a function declaration or definition that
| acquires a value on entry to the function, or an identifier from the
| comma-separated list bounded by the parentheses immediately following
| the macro name in a function-like macro definition

More loosely, arguments are what are passed to functions and macros; they
receive them as parameters.

-- Mat.
 
M

Mathew Hendry

| 3. Terms, definitions, and symbols
|...
| 3.3
| 1 argument
| actual argument
| actual parameter (deprecated)
| expression in the comma-separated list bounded by the parentheses in a
| function call expression, or a sequence of preprocessing tokens in the
| comma-separated list bounded by the parentheses in a function-like macro
| invocation
|...
| 3.15
| 1 parameter
| formal parameter
| formal argument (deprecated)
| object declared as part of a function declaration or definition that
| acquires a value on entry to the function, or an identifier from the
| comma-separated list bounded by the parentheses immediately following
| the macro name in a function-like macro definition

More loosely, arguments are what are passed to functions and macros; they
receive them as parameters.

Oops, that's from the C standard. :) C++ adds to these definitions for
templates and exceptions.

-- Mat.
 
D

DaKoadMunky

The extern declaration becomes a definition in the
absence of another
extern.

Could someone with a copy of the standard verify this and provide the relevant
text?

I had never heard this before and flipping through TCPPPL I can't find anything
regarding this.

Thanks.
 
D

DaKoadMunky

Linkers don't know anything about types. In c2.c, str could have been an
int, or even the name of a function, and it would still link correctly
(and produce undefined behaviour at runtime).

Actually on my platform changing str in c2.c to an int did produce a linker
error indicating an unresolved external symbol.

Maybe MSVC is just smarter than your average linker. Ha ha.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top