some C++-specific interview questions

[Digital Puer]

I'm not the world's greatest C++ programmer, so I had a hard
time with these. Some help would be appreciated.

1. Comment on the declaration of function Bar() below:
class Foo
{
static int Bar(int i) const;
}

(I said that since Bar is a static method, it can only access
static variables, not member variables, so the const is
irrelevant.)
2. If you have virtual functions in your class, do you need a virtual
destructor? Why?

(My gut answer was that no, you don't NEED a virtual destructor
unless the derived class is handling its own dynamically-managed
data.)

3. Comment on the following function. What would you change? State
your assumptions:

string & Foo()
{
string default_string = "default answer";
for (vector<node>:: iterator iter = mynodes.begin() ;
iter != mynodes.end();
iter++)
{
cout << iter;
}
return default_string;
}
4. When would you use private inheritence? (I have never personally
used this.)

5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

[Phlip]

Digital Puer wrote:

I'm not the world's greatest C++ programmer, so I had a hard
time with these. Some help would be appreciated.

The next problem is your interviewer might not be the world's greatest,
either... ;-)

1. Comment on the declaration of function Bar() below:
class Foo
{
static int Bar(int i) const;
}

(I said that since Bar is a static method, it can only access
static variables, not member variables, so the const is
irrelevant.)

I suspect it should not even compile.

2. If you have virtual functions in your class, do you need a virtual
destructor? Why?

(My gut answer was that no, you don't NEED a virtual destructor
unless the derived class is handling its own dynamically-managed
data.)

In this case, you must answer twice; both the safest way and the technically
correct way. The safest way is "all destructors are virtual unless profiling
reveals the need to remove a virtual". That's safe, because a teammate might
write a class that inherits your class, and then write a 'delete' that uses
a pointer to your class, not the derived class. Deleting such an object,
without a virtual destructor, is undefined behavior.

The technical answer is no, you never are required to make a destructor
virtual, if you know that nobody will ever delete it through a pointer to
the base class.

And the other virtual methods are only indirectly indicated. They don't
influence the technical or semantic decision to make the destructor virtual.
Indirectly, semantically, you should not inherit from a class with no
virtual methods, hence you should never delete a pointer to its base class.

At least the question wasn't "If a destructor releases no resources, must it
be virtual?" That implies the common fallacy that deleting a pointer to the
base class will only create undefined behavior if it creates a leak. The
undefined behavior actually starts at destructor time, regardless what then
leaks.

3. Comment on the following function. What would you change? State
your assumptions:

string & Foo()
{
string default_string = "default answer";
for (vector<node>:: iterator iter = mynodes.begin() ;
iter != mynodes.end();
iter++)
{
cout << iter;
}
return default_string;
}

It returns a reference to a destructed local, so that's undefined.

Next, vector<nodeis not typedeffed.

Next, the default_string has nothing to do with the for-loop, which could be
just a decoy. Regardless, you should announce the function does two
independent things and should be split in two.

Next, cout << iter is poorly defined to produce something useless, possibly
a pointer address. If operator<< is defined for 'node', then cout << * iter
might be more useful.

Next, all iterators should always be called 'it'. ;-)

4. When would you use private inheritence? (I have never personally
used this.)

Per /C++ Coding Standards/ by Sutter and Alex A., you should prefer it to
public inheritance.

Consider the Abstract Template Pattern, but where only the derived classes
know they call a secret parent that then, in turn, calls their specialized
methods to help it perform their templated action.

(Warning: That's not a C++ template...)

5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

I don't know how Standard this answer is, but it's stored in the initialized
global data segment. This fact (even its accurate version) should never be
used in practice, except in the sickest debugging situations.

6. Consider member initialisation lists. Why are they needed?

Because they explicitly declare intent, to both your colleagues and to the
compiler.

Why are
they considered more efficient than initialising members in the body of
the constructor?

Because the compiler can generate the most efficient code to implement them.
They are defined to occur in the same order as the members appear in the
class's definition, so the compiler could get as efficient as an unrolled
loop to stomp them all in.

Further, some systems can provide a warning if you write them out of order.
This helps your code self-correct.

Next, your constructor's body should be exception neutral and safe. So
putting pointer(NULL) in the member list, and then a pointer=new in the
body, can lead to a safer 'delete' if the constructor then blows. (But the
destructor won't call, so still prefer smart pointers!)

Next, if any member's initialization throws an exception, the stack unwinder
will call the destructor of each fully constructed member, in reverse order.

In general, efficiency is a poor taskmaster. Premature optimization is the
root of all evil. In this case, you may err on the side of efficiency if the
result is also _cognitively_ efficient. Member initialization lists are
easier to comprehend, after you train to recognize them as important parts
of constructors. So follow this rule: Never enter the opening { of a
constructor with any member in an uninitialized state.

You can get that rule easily by only using smart data members, such as smart
pointers and other contained objects with default constructors.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Murali Krishna]

Digital Puer wrote:

1. Comment on the declaration of function Bar() below:
class Foo
{
static int Bar(int i) const;
}

(I said that since Bar is a static method, it can only access
static variables, not member variables, so the const is
irrelevant.)

I think you are right. const is irrelavant.

2. If you have virtual functions in your class, do you need a virtual
destructor? Why?

(My gut answer was that no, you don't NEED a virtual destructor
unless the derived class is handling its own dynamically-managed
data.)

What about the private data members of base class? They are not
inherited in any case. So how to delete them? I think we need that in
both classes.

I can't understand the third one.

4. When would you use private inheritence? (I have never personally
used this.)

me too. but it is used to make all public and protected members of base
class as private members in derived class. (I think you already know
this)

5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

The V-table pointer is generally stored just after the elements of the
base class. That means it is heap. When you see the class size, the
class size will contain member variables size and (no of virtual
functions * pointer size)

6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

I am just guessing on the 6th Question.
Why are they needed?
They are generally used to initialize const member variables (also non
const).
why are they more efficient?
really don't know. but normally when you write in the body, you write
statement wise. but here you write using comma operator and assign
through braces. So does this bring any performance? please let me know.

-- Murali Krishna

[Carlos Martinez]

Digital Puer wrote:

I'm not the world's greatest C++ programmer, so I had a hard
time with these. Some help would be appreciated.

1. Comment on the declaration of function Bar() below:
class Foo
{
static int Bar(int i) const;
}

(I said that since Bar is a static method, it can only access
static variables, not member variables, so the const is
irrelevant.)

I think it doesn't compile because const is not permitted with static
functions

>
2. If you have virtual functions in your class, do you need a virtual
destructor? Why?

(My gut answer was that no, you don't NEED a virtual destructor
unless the derived class is handling its own dynamically-managed
data.)

Virtual destructor is needed for calling the apropiate destructor when
delete a pointer-to-base. Heap memory is one reason, but in general, is
necessary when derived class's destructor has something to do.

In general, when yo have virtual functions make destructor virtual.

3. Comment on the following function. What would you change? State
your assumptions:

string & Foo()
{
string default_string = "default answer";
for (vector<node>:: iterator iter = mynodes.begin() ;
iter != mynodes.end();
iter++)
{
cout << iter;
}
return default_string;
}

You are returning a reference to local data of your function. As it's
local it will be destroyed when function is finished.
Usually when you construct a constact value inside a function you make
the variable static. With static variable you can return value by
reference, but I'd make return type const, for fobidding modification on
its value.

Iterator acts like a pointer, thus you must derrefence it:
cout << *iter;

4. When would you use private inheritence? (I have never personally
used this.)

When inheritance is for reusing implementation but hasn't a is-a
relationship. With private inheritance implicit pointer-to-base
conversion is not permitted.

>
5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

I think vtable details are not covered in C++ standard (I'm not sure,
but I think it).
Usually compilers construct it (I don't know where), and pointers and
references have a "link" to it.
I'm not sure on this question, because I don't remember well what I read
about it in the past. I suggest you to read Stanley B. Lippman's "Inside
the C++ object model".

6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

They are needed for initializating not-default constructor of base clases.
When you don't initialise a member in an initialisation list, it is
initialised by default, thus when you initialise it inside the body of a
constructor it's initialised twice.
When you initialise a member in the initialisation list, that is the
unique inisialization.

[Gernot Frisch]

> string & Foo()
{
string default_string = "default answer";
for (vector<node>:: iterator iter = mynodes.begin() ;
iter != mynodes.end();
iter++)
{
cout << iter;
}
return default_string;
}

It returns a reference to a destructed local, so that's undefined.

Next, vector<nodeis not typedeffed.

Next, the default_string has nothing to do with the for-loop, which
could be just a decoy. Regardless, you should announce the function
does two independent things and should be split in two.

Next, cout << iter is poorly defined to produce something useless,
possibly a pointer address. If operator<< is defined for 'node',
then cout << * iter might be more useful.

Next, all iterators should always be called 'it'. ;-)

I'd make that:
static string default_string = "default answer";

and change iter++ to ++iter, since that's a micro optimization.

>5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

I don't know how Standard this answer is, but it's stored in the
initialized global data segment. This fact (even its accurate
version) should never be used in practice, except in the sickest
debugging situations.

I think that depends on the compiler. The std does not say anything
about it.

[Stuart Redmann]

Murali Krishna wrote:

Digital Puer wrote:

>>6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

why are they more efficient?
really don't know. but normally when you write in the body, you write
statement wise. but here you write using comma operator and assign
through braces. So does this bring any performance? please let me know.

The comma operator isn't involved in member initialization lists, that's
just part of C++ syntax (like the semi-colon at the end of each
statement). Member initializations is generally to be prefered, since
members that are initialized in the member initialization list are
initialized by their constructors. If a member is not mentioned in the
member initialization list, it's default constructor will be invoked
(which would assign values that will most likely get overwritten in the
constructor anyway).
Consider the following program and its output:

#include <iostream>
class A
{
int m_a;
public:
A ()
: m_a (0)
{ std::cout << "default constructor of A invoked.";
std::cout << std::endl;}
A (int p_a)
: m_a (p_a)
{ std::cout << "initializa tion constructor of A invoked.";
std::cout << std::endl;}
A& operator= (int p_a)
{ m_a = p_a;
std::cout << "Assignment operator for A invoked.";
std::cout << std::endl;
return *this;}
};

class B
{
A m_Aobj;
public:
B (int p_b)
: m_Aobj (p_b)
{}
};

class C
{
A m_Aobj;
public:
C (int p_b)
{ m_Aobj = p_b; }
};

int main ()
{
B b (0);
C c (0);
return 0;
}

In those cases where you have no default constructor available, you
cannot get around member initialization lists.

[m_schellens]

2. If you have virtual functions in your class, do you need a virtual

destructor? Why?

(My gut answer was that no, you don't NEED a virtual destructor
unless the derived class is handling its own dynamically-managed
data.)

What about the private data members of base class? They are not
inherited in any case. So how to delete them? I think we need that in
both classes.

Of course private members are inherited.
The base class methods access them.

5. Where in memory is the virtual function lookup table stored?
(I found this one to be way too detailed for me.)

The V-table pointer is generally stored just after the elements of the
base class. That means it is heap. When you see the class size, the
class size will contain member variables size and (no of virtual
functions * pointer size)

As stated elsewhere, there is no place where the vtable has to be
stored.
But what you describe would be a very poor implementation.

In most cases, with each instance, there is ONE pointer to a vtable of
that class.
The vtable then contains one pointer per virtual member function and
exists
only once per class.
In g++ this is in the object file (.o) where the destructor of that
class is defined.

It is nice that you want to help, but please comment only on stuff you
really know.
Otherwise your answer just causes confusion.

Regards,
Marc

[Philip Potter]

"Carlos Martinez" <cm****@nospam. tid.eswrote in message
news:ed******** *@news.hi.inet. ..

4. When would you use private inheritence? (I have never personally
used this.)

When inheritance is for reusing implementation but hasn't a is-a
relationship. With private inheritance implicit pointer-to-base
conversion is not permitted.

But you could just use simple composition anyway - include class B as a data
member of class D instead of as a private parent. I've never found a need
for private inheritance, though the FAQ has a couple of interesting bits on
it.

6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

They are needed for initializating not-default constructor of base clases.
When you don't initialise a member in an initialisation list, it is
initialised by default, thus when you initialise it inside the body of a
constructor it's initialised twice.

Minor nit: It's only initialized once, and then assigned to.

Philip

[Philip Potter]

"Phlip" <ph******@yahoo .comwrote in message
news:Mv******** **********@news svr29.news.prod igy.net...

At least the question wasn't "If a destructor releases no resources, must

it

be virtual?" That implies the common fallacy that deleting a pointer to

the

base class will only create undefined behavior if it creates a leak. The
undefined behavior actually starts at destructor time, regardless what

then

leaks.

Thanks, I didn't know that. Learn something new every day.

Philip

[Carlos Martinez]

Philip Potter wrote:

"Carlos Martinez" <cm****@nospam. tid.eswrote in message
news:ed******** *@news.hi.inet. ..

>>4. When would you use private inheritence? (I have never personally
used this.)

When inheritance is for reusing implementation but hasn't a is-a
relationship . With private inheritance implicit pointer-to-base
conversion is not permitted.

But you could just use simple composition anyway - include class B as a data
member of class D instead of as a private parent. I've never found a need
for private inheritance, though the FAQ has a couple of interesting bits on
it.

Yes, the same thing may be implemented in different ways. What you say
is called dellegation and is an alternate to inheritance. It's used for
example to reduce multiple inheritance to single inheritance (inherit
from main concept and delegate the others.

Private inheritance is not the only way of reusing implementation, but
it's a way.
I prefer private inheritance over delegation for example when I must
partially export base's interface, with base::myMethod

>>6. Consider member initialisation lists. Why are they needed? Why are
they considered more efficient than initialising members in the body of
the constructor?

They are needed for initializating not-default constructor of base clases.
When you don't initialise a member in an initialisation list, it is
initialised by default, thus when you initialise it inside the body of a
constructor it's initialised twice.

Minor nit: It's only initialized once, and then assigned to.

Yes. I prefer for simplicity, to create an init member function called
from constructor instead of initialization list, because you centralize
the "reset" of attributes in one function instead of duplicating
initialisation of members in initialisation list of different
constructors and "reset" functions (adding an attribute generates fewer
changes on code because it is located only in a portion of code
(initialisation function)).
But academically, it's a question of performance to prefer
initialisation list over assignment in the body of constructor.

>
Philip