Interview Questions

[laserlight]

Technically, you didn't answer my first question as you just parroted "what's written in one of the websites" instead of applying your knowledge to the code presented by Paul McKenzie. In theory, you could still be clueless as to which is which. Then, you didn't answer my second question.

[gulHK]

The value of "cNancy" in both of the above cases is eventually equal to that of "cMark". Is this correct?

[laserlight]

The value of "cNancy" in both of the above cases is eventually equal to that of "cMark". Is this correct?

Yes, if the usual semantics of copy construction and copy assignment are followed (i.e., if the author of the class implemented them to work that way).

Why won't you answer my questions?

[gulHK]

I am sorry for being silly Paul and Laserlight.

I think I need detailed study to fully understand the concepts. Any way thanks a lot.

[D_Drmmr]

Cents cNancy; // calls Cents default constructor
cNancy = cMark; // calls Cents assignment operator

These two lines should not have been shown like this in an example. It's actually a style error to do this. There is no reason not to use the copy constructor here.

However, if some other code is placed in between these two lines, it may well be a valid example.

Cents cNancy;
if (someCondition) {
    cNancy = cMark;
}

In this case, using the assignment operator really is necessary.

[gulHK]

Thanks D_Drmmr for this useful example

[Paul McKenzie]

These two lines should not have been shown like this in an example. It's actually a style error to do this. There is no reason not to use the copy constructor here.

If the assignment operator is inaccessible, that code will cause a compiler error even if the copy constructor is accessible.

class Cents
{
    private:
        Cents& operator=(const Cents&);
    public:
        Cents(const Cents&);
        Cents(int x=0);
};

int main()
{
    Cents cMark(5); 
    Cents cNancy; 
    cNancy = cMark;   // error
    Cents newCents = cNancy;
}

Thank you for testing your code with Comeau C/C++!
Tell others about http://www.comeaucomputing.com/tryitout !

Your Comeau C/C++ test results are as follows:


Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing. All rights reserved.
MODE:strict errors C++ C++0x_extensions

"ComeauTest.c", line 14: error: "Cents &Cents::operator=(const Cents &)" (declared
at line 4) is inaccessible
cNancy = cMark;
^

1 error detected in the compilation of "ComeauTest.c".

In strict mode, with -tused, Compile failed
Hit the Back Button to review your code and compile options.
Compiled with C++0x extensions enabled.

Everything up front still has to follow the rules of C++, and the rule is that laserlight's example must logically call the assignment operator, even if the compiler may do things differently with the code once optimizations are applied.

Regards,

Paul McKenzie

[ZuK]

There is one thing that has not been stated clearly when talking about the difference between copy constructor and assignement operator.
The assignement operator has to release any resorces that the object already holds before it can do the exact same thing as the copy constructor does.
Kurt
EDIT: Hope I'm not stating the obvious.

[OReubens]

1) If any of the functions of the base class is virtual then destructor should also be virtual. What will happen if destructor is not virtual?

This is bogus. The need for a virtual destructor has NO RELEVANCE AT ALL with the presence of other virtual functions in the base class or the derived class.

[laserlight]

This is bogus. The need for a virtual destructor has NO RELEVANCE AT ALL with the presence of other virtual functions in the base class or the derived class.

Not really. The presence of other virtual functions in the base class is relevant (sign that the class is likely to be a polymorphic base class), but not a necessary condition for a virtual destructor.

[OReubens]

Not really. The presence of other virtual functions in the base class is relevant (sign that the class is likely to be a polymorphic base class), but not a necessary condition for a virtual destructor.

And yet, I stand by my words. There is no actual relevance.
A virtual destructor is needed ONLY if at any point in your code you will be deleting a base pointer. While such a thing does occur, my personal experience is that it's rare. Depending on the libraries and type of code you write, that may be very different of course



That said, if you are making generic class libraries to be used by others and those classes are very likely going to be derived from, then you'll probably want to make the destructor virtual... even if you don't have virtual functions yourself just so whomever derives from your class has the ability for deletion through a base pointer.

Also, there is very little lost by getting into a habit of making ALL your destructors virtual. It can save a lot of headaches somewhere down the line. The cases where a virtual destructor would actually cause problems and where it needs to be non-virtual are very rare.

[laserlight]

That said, if you are making generic class libraries to be used by others and those classes are very likely going to be derived from, then you'll probably want to make the destructor virtual... even if you don't have virtual functions yourself just so whomever derives from your class has the ability for deletion through a base pointer.

Yes, if your class is designed to be a polymorphic base class, then it should either have a virtual destructor that is public, or a non-virtual destructor that is protected. At the same time, if a class has virtual functions, it is likely to be designed to be a polymorphic base class. As such, I find the insistence that such a factor has no relevance at all to be an exaggeration.

Also, there is very little lost by getting into a habit of making ALL your destructors virtual. It can save a lot of headaches somewhere down the line. The cases where a virtual destructor would actually cause problems and where it needs to be non-virtual are very rare.

I agree that there is little lost in terms of efficiency, but I would rather not define a concrete class to have a virtual destructor when my intention is for it to not be derived from, at least not with public inheritance.

[ninja9578]

A good IDE should tell you that you inherit from a class that does not have a virtual destructor. I'd personally be surprised if the compiler didn't at least warn you as well. For the sake of documentation, I actually usually do this. Not so much in my own code, but when I am working with a team of people.

/* final */ class nonpolymorphic {
...

That way at a quick glance, you know whether or not a class may be inherited from. It's actually a little strange that C++ has no keyword for this like other languages.


@OReubens Wouldn't making all of your destructors virtual mean that all of your objects have vtables?



Also, lol, why does the text input box not have word wrap?

[nuzzle]

Also, there is very little lost by getting into a habit of making ALL your destructors virtual.

Maybe not but what happens to your dignity? Before you know it you will be programming in Java!

[D_Drmmr]

A good IDE should tell you that you inherit from a class that does not have a virtual destructor.

Why would it do that? I don't want to get a warning message whenever I derive, say, a function object from std::unary_function.