[BEGINNER] Some questions

[Last Timer]

I need help with the following questions:
a) if a class has virtual functions, is it better to make the
destructor virtual
b) can a friend function be inherited
c) if a function argument is const, is it better to pass non-const
values
The following questions don't make sense to me, but they are asked in
an interview
d) if B is a subclass of A, can an array of A's be used in the place of
an array of B
e) is the first catch statement is used or the best match is used in a
catch block
f) can reference to an object modified to point to another object

Thanks

 

[Victor Bazarov]

I need help with the following questions:
a) if a class has virtual functions, is it better to make the
destructor virtual

It definitely won't hurt [much]. It can help in certain situations.

b) can a friend function be inherited

Friendship is not inhertied nor can it be transferred.

c) if a function argument is const, is it better to pass non-const
values

I am not sure I understand the question.

The following questions don't make sense to me, but they are asked in
an interview
d) if B is a subclass of A, can an array of A's be used in the place of
an array of B

The term "subclass" is definitely not C++. IIUIC here, B is derived
from A. In that case, no, an array of A cannot be used in place of
an array of B.

e) is the first catch statement is used or the best match is used in a
catch block

The best match.

f) can reference to an object modified to point to another object

No, it cannot. The [hypothetical] act of "pointing to another object"
is called "reseating a reference", and in C++ it cannot be done.

V

 

[Michael Etscheid]

The best match.

That's not true. The first statement that maches is used.

 

[Chris Theis]

That's not true. The first statement that maches is used.

Well, IMHO the first one that matches is implicitly the best one as the
standard mandates that the handlers are tried in order of appearance.

Chris

 

[Victor Bazarov]

That's not true. The first statement that maches is used.

So, if the "first catch statement" doesn't match, it is not used, right?
Read the question again.

 

[Pete Becker]

So, if the "first catch statement" doesn't match, it is not used, right?
Read the question again.

Without the testosterone <g>:

struct base {};
struct derived : base {}

void f()
{
try {
throw derived();
}
catch(int)
{
cout << "We never get here.\n";
}
catch(const base&)
{
cout << "We get here, 'cause this is the first match.\n"
}
catch(const derived&)
{
cout << "We don't get here, even though "
"this is the 'best' match.\n"
}

Naturally, this explains why catch(...) should only be used as the last
catch clause in a series.

 

[evaned]

if a class has virtual functions, is it better to make the destructor
virtual

Absolutely. Consider the following:

class base
{
public:
base() {}
~base() {}
};

class derived : public base
{
some_big_class* p;

public:
derived() { p = new some_big_class(); }
~derived() { delete p; }
};

main()
{
base* myobj = new derived();
// ...
delete myobj;
}


The destructor will never be called, and your program will leave blobs
of garbage behind it. If you make the destructor virtual, the 'delete
p;' line will be called and your memory leak will be fixed. (You can
convince yourself of this by adding a line of output in derived's
constructor.)

if B is a subclass of A, can an array of A's be used in the place of

an array of B

This is asking if the following.

Since B derives from A, an object of type B can be used any place an
object of type A is expected, e.g.:
void foo(A* somearg);
// ...
B someobj;
foo(&someobj);
This is okay. But should an object of type B[] be substituted for a
type A[]? So should the following work?
void foo(A somearg[]);
// ...
B somearray[100];
foo(somearry);
My understanding (and Victor's answer) is no. From an implementation
perspective, the sizes of A and B are different. Thus when foo looks
for somearg[1], it won't be where it thinks it is because that will be
the end of somearray[0]. Graphically:
| somearg[0] | somearg[1] | .... | somearg[n-1]
| somearray[0] | somearray[1] | ... |
somearray[n-1]

More theoretically, imagine somearg[] as a collection of base objects.
Thus foo should be able to add something to that collection (and could
if the program was using vectors or another containter class instead of
arays). But foo thinks they are base objects, so adds a new base
object. But now somearray[], which is supposed to be a collection of
derived objects, now isn't because it has a base object in it! Oops!


Despite what I said before, the following code compiles and crashes at
runtime under VS.Net 7. Is this correct behavior on the part of the
compiler?

int gid;

class base
{
int id;
public:
virtual int ID() { return id; }
base() { id = gid++; }
virtual ~base() {}
};

class derived : public base
{
int did;
public:
int ID() { return did; }
derived() {base(); did = 1000;}
~derived() { }
};


void foo(base a[])
{
for(int i = 0 ; i<100 ; ++i)
cout << a.ID() << endl;
}

int main()
{
derived d[100];
foo(d);
}