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]

Kai-Uwe Bux wrote:

>And C++ is multi-paradigm, so within the template paradigm, you should
not
inherit except to specialize a member.

The fourier example did not do that. Generally, when inheriting from
unary_function you will not specialize any of the members of
unary_function.

That's why I wrote "operator()...m ight not exist in the parent":

>Your example "overrode" operator(). I am aware it was not virtual, and
might not exist in the parent.

You are using the term "override" strangely.

And that's why I wrote "very similar to an override":

>Yet what you did was very similar to an override, from the caller's point
of view.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Kai-Uwe Bux wrote:

I see, you generalized your position to: one should not inherit unless one
overrides something (virtual or not) or adds something (which is what you
call overriding with quotation marks). In other words, one should not do

class X : public y {
...
}

unless X behaves at least a little different from Y. Well, I might grant you
that. However, In my eyes,

Well, that would not exactly help with regard to template programming.
For instance one couldn't do something like this:

template < typename D, typename U >
struct unit : dimension_type< D>, convertable<U>. ..
{
};

struct seconds : unit<time_d, seconds{};
double const seconds::cvf::v alue = 1.0;

"seconds" doesn't add any behavior to the unit type (unless you
consider different conversion values an extension) and the unit type
adds nothing to its parents beyond the conglomeration of various
parents' features into one type. However, a decent syntax for creating
new unit types has been created and these static types can be used in
template programming in unit based dimensional analysis and custom
printing:

template < typename U >
struct unit_printer {}

template <>
struct unit_printer<se conds>
{
std::string operator () () { return "s"; }
};

So there can be numerous reasons to subclass something but not extend
it and with MI you can be extending simply through inheritance.

And it's Friday and I'm particularly out of it today or I'd give a
better argument but I think that saying, "never inherit without
extending or changing behavior," as a rule can be very limiting in many
aspects of C++ programming. It also seems to be less than accurate as
you can extend at least without inheriting. The more narrow guideline
given by Sutter and Myers (don't inherit unless you need to override
some polymorphic function) is more to the point but still fails in
light of certain idioms in generic programming where inheritance isn't
necissarily used according to the standard OO definition. For
instance, such a guideline would say never do the above, and maybe it
really isn't the best way to do what I want, but there is no reason not
to when your parents exist solely for the purpose of generating new
static types without having to type the same things repeatedly and/or
provide special compile time functionality to test types and compile in
different behavior based on the inherited metafunction members.

[Phlip]

Noah Roberts wrote:

And it's Friday and I'm particularly out of it today or I'd give a
better argument but I think that saying, "never inherit without
extending or changing behavior," as a rule can be very limiting in many
aspects of C++ programming. It also seems to be less than accurate as
you can extend at least without inheriting. The more narrow guideline
given by Sutter and Myers (don't inherit unless you need to override
some polymorphic function) is more to the point but still fails in
light of certain idioms in generic programming where inheritance isn't
necissarily used according to the standard OO definition.

The most general way to say it is "prefer weak coupling to strong coupling".
Delegation is weak, and the various forms of inheriting and specializing are
strong. Don't do it unless you get a benefit, and that benefit often appears
as an "override" of some kind.

For
instance, such a guideline would say never do the above, and maybe it
really isn't the best way to do what I want, but there is no reason not
to when your parents exist solely for the purpose of generating new
static types without having to type the same things repeatedly

If that is a "convenienc e class", then at least you _know_ that it is. You
are not going down the path of inheritance as an arbitrary form of
categorization, without any design value.

and/or
provide special compile time functionality to test types and compile in
different behavior based on the inherited metafunction members.

"different behavior" is the meaning of the "override" in the original
admonition.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:

Noah Roberts wrote:

and/or
provide special compile time functionality to test types and compile in
different behavior based on the inherited metafunction members.

"different behavior" is the meaning of the "override" in the original
admonition.

However, in this case the "different behavior" is based on members that
are inherited, not overridden. For instance one might have the
following:

struct seconds : unit<time_d, seconds>, unit_is_static< seconds, true>
{};

template < typename U, bool is_static >
struct unit_is_static;

template <typename U>
struct unit_is_static< U, false{ struct is_static :
boost::mpl::boo l_<false{}; };

template <typename U>
struct unit_is_static< U, true{
struct is_static : boost::mpl::boo l_<true{};
static U const value;
};

template <typename U>
U const unit_is_static< U, true>::value = U(); // necissary to access
double conversion

Now later you could very concievably use mpl::if_ based on the
"is_static" metafunction member. That member is an inherited member so
behavior doesn't change based on differences in the derived class but
by which class it inherits from.

[Phlip]

Noah Roberts wrote:

Now later you could very concievably use mpl::if_ based on the
"is_static" metafunction member. That member is an inherited member so
behavior doesn't change based on differences in the derived class but
by which class it inherits from.

Another important point is we are all discussing design at a level much
higher than the newbies who need to be taught "don't inherit unless you then
override a virtual method"... ;-)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:

Noah Roberts wrote:

Now later you could very concievably use mpl::if_ based on the
"is_static" metafunction member. That member is an inherited member so
behavior doesn't change based on differences in the derived class but
by which class it inherits from.

Another important point is we are all discussing design at a level much
higher than the newbies who need to be taught "don't inherit unless you then
override a virtual method"... ;-)

Actually I think that some of the paradigms and idioms beyond OO should
be taught to new C++ programmers. Concepts like policies are very
useful but unfortunately not taught in any class I am aware of. Hell,
the concept of a concept was never taught to me and this seems rather
fundamental in anything remotely interesting in C++.

[Kai-Uwe Bux]

Phlip wrote:

Noah Roberts wrote:

>Now later you could very concievably use mpl::if_ based on the
"is_static" metafunction member. That member is an inherited member so
behavior doesn't change based on differences in the derived class but
by which class it inherits from.

Another important point is we are all discussing design at a level much
higher than the newbies who need to be taught "don't inherit unless you
then override a virtual method"... ;-)

Newbies do not need to be lied to :-) Your sound piece of advice would be
more helpful to newbies if it came with appropriate qualification: "in OO
design, don't inherit unless you then override a virtual method." You do
not help newbies by giving advice that is implicitly biased toward one of
the various paradigms supported by C++. That way you would be narrowing the
perspective of the newbies on C++ instead of opening up their view.
Best

Kai-Uwe Bux

[Phlip]

Kai-Uwe Bux wrote:

Newbies do not need to be lied to :-) Your sound piece of advice would be
more helpful to newbies if...

You have a typo there. You were trying to write "Scott Meyers's, Herb
Sutter's, and Andrei Alexandrescu's advice would be helpful to newbies..."

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Kai-Uwe Bux]

Phlip wrote:

Kai-Uwe Bux wrote:

>Newbies do not need to be lied to :-) Your sound piece of advice would be
more helpful to newbies if...

You have a typo there. You were trying to write "Scott Meyers's, Herb
Sutter's, and Andrei Alexandrescu's advice would be helpful to newbies..."

Your appeal to authority is well taken. However, should you mean to imply
that, say, Alexandrescu has given that advice of yours without
qualification somewhere in his writings, I would (a) ask for an actual
quote, and (b) should you be able to provide one, maintain, that he slipped
there. However, from his writings I have read, I would be very surprised if
he actually stated an unqualified oversimplificat ion like "do not inherit
unless you override a virtual function".
Best

Kai-Uwe Bux

[Digital Puer]

Stuart Redmann wrote:

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.

Thank you for the excellent example above. The output I
get is that for B, the initialisation contructor is called,
whereas for C, the default constructor is called, followed
by a call to the assignment operator function.

This is a bit puzzling for the case of B. I thought that before
B's constructor is entered, all of B's member variables must
have already been constructed, meaning that A's
default constructor should have already been called.
Is this not the case when an initialisation list is
present that uses a member variable?