Interview Questions

Hello All

Below are the few questions that were asked in an interview. Can anyone please explain to me the answers in an easiest way with examples.

Code:

---

1)        Volatile object
3)        Can constructor/destructor be private?
4)        Problems normally faced in multithreading
6)        Data serialization/de-serialization
7)        Layers of TCP/IP
12)        Mutable
13)        Why do we use virtual destructors?
14)        what is a copy constructor and why do we use it?
15)        Smart pointers
16)        Case where exception handling is not safe
17)    Static and non-Static member variables/functions

---

Thanks

You are not in an interview, and neither are we (presumably). So, make use of the resources at your disposal. You can pretty much search the Web for the answers. The "mutable" one might be hard to find specific stuff on, but if you search it with "C++", you will find the answer.

Quote:

---

Originally Posted by gulHK

Below are the few questions that were asked in an interview. Can anyone please explain to me the answers in an easiest way with examples.
...
7) Layers of TCP/IP
...

---

That is not a C++ question.

Technically, this isn't a C++ question either:

Quote:

---

4) Problems normally faced in multithreading

---

You can be an ace in C++ and not know a single thing about multithreading. I know that many companies will refuse to hire a C++ programmer if their software uses multithreading and the coder has no experience in these types of applications, regardless of how much C++ they know.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by gulHK

in an easiest way

---

You must understand that your question is rubbing programmers the wrong way. They've spent lots of time and effort learning C++ to get a good job. And here comes some lazy dude who not only knows very little C++ but also has the nerve to ask them to silverspoon him into their company to become their new deadweight collegue. It's not going to happen.

There are books to prepare you for the interview situation with focus both on C++ and general programming. But in my view for this to work you must already have the knowledge and only need a refresher to summarize and bring things to the top of your head for fast recollection and coherent presentation. If you cram such books you only end up with shallow and superficial knowledge that an experienced interviewer will expose as bull in no time.

Instead use the flunked interview to identify your weak areas and get the proper books and get down to some serious studying and coding. You're wellcome here if you get stuck with something.

1) volatile is a compiler hint. The correct answer is compiler dependant.
The fact they are asking this probably means they either don't fully understand the meaning/concept behind it. Or they're trying to trick you into a false/incomplete/incorrect answer. (i.e. ther eis no right answer until they can be more specific)

6) mostly irrelevant, other than trivial examples and handling plain text. Every other form of (de)serialization is implementation specific.
Again. See 1). either they have wrong ideas of it, or it's a trick question.

7) look up "OSI model" on wikipedia.

Thank you all

I still have few confusions.

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?

2) And I have always found Copy Constructor and copying an object through assignment operator. Will you please explain to me what are these and in what situations are these used? When to use which one? Please with an example

Thanks

Quote:

---

Originally Posted by gulHK

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?

---

If you attempt to delete an object of a derived class through a base class pointer that points to it, and the base class destructor is not virtual, then the behaviour is undefined.

Quote:

---

Originally Posted by gulHK

2) And I have always found Copy Constructor and copying an object through assignment operator. Will you please explain to me what are these and in what situations are these used? When to use which one? Please with an example

---

I shall not explain with an example. Rather, I shall explain with a book: Accelerated C++.

Thanks laserlight :). Virtual destructor concept is now clear to me

I have now gone through few of the websites to clear my concepts about copy constructor and assignment and have found out that these are just two different ways that serve the same purpose, one through copy constructor and one through assignment. Then why are there two different ways when one will do? Please correct me if I am wrong.

Quote:

---

Originally Posted by gulHK

I have now gone through few of the websites to clear my concepts about copy constructor and assignment and have found out that these are just two different ways that serve the same purpose

---

Is that what these "websites" taught you? Then it's time to get a book.

Code:

---

class foo
{
};

int main()
{
    foo f;
    foo f2 = f;
    foo f3(f2);
    foo f4;
    f4 = f;
}

---

So after going through these "websites" as you claimed, you should know which lines of code invoke the copy constructor of foo and which ones invoke the assignment operator, right?

There is a big difference in the two -- the copy constructor constructs a new object, while the assignment operator assigns to an existing object. That's why one is called a constructor and the other one is called assignment.

Regards,

Paul McKenzie

Paul I know which one uses copy constructor and which one uses assignment but what are the uses of each of these two ways? why not we just always use a copy constructor or why not always an assignment? Are there certain situations where copy constructor works best or where assignment works best. Does the usage depend on any situation?

Quote:

---

Originally Posted by gulHK

I know which one uses copy constructor and which one uses assignment but what are the uses of each of these two ways?

---

Please answer these questions:

• Which of them use the copy constructor and which of them uses the copy assignment operator?
• What is the difference between constructing an object and assigning to it?

That's what's written in one of the websites

Code:

---

Cents cMark(5); // calls Cents constructor
Cents cNancy; // calls Cents default constructor
cNancy = cMark; // calls Cents assignment operator


Cents cMark(5); // calls Cents constructor
Cents cNancy = cMark; // calls Cents copy constructor!

---

Quote:

---

Originally Posted by gulHK

Paul I know which one uses copy constructor and which one uses assignment

---

OK, so tell us -- which ones invoke the copy constructor and which ones invoke the assignment operator?

Quote:

---

why not we just always use a copy constructor or why not always an assignment?

---

I already stated it to you:

A copy constructor constructs a brand new object from an existing object. An assignment object takes an existing object and turns it into a copy of another object. It can't be explained more simply than that.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by gulHK

That's what's written in one of the websites

Code:

---

Cents cMark(5); // calls Cents constructor
Cents cNancy; // calls Cents default constructor
cNancy = cMark; // calls Cents assignment operator


Cents cMark(5); // calls Cents constructor
Cents cNancy = cMark; // calls Cents copy constructor!

---

---

So what's the question?

Regards,

Paul McKenzie

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.

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

Quote:

---

Originally Posted by gulHK

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?

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.

Quote:

---

Originally Posted by gulHK

Code:

---

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.

Code:

---

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

---

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

Thanks D_Drmmr for this useful example :)

Quote:

---

Originally Posted by D_Drmmr

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.

Code:

---

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;
}

---

Quote:

---

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

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.

Quote:

---

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.

Quote:

---

Originally Posted by OReubens

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.

Quote:

---

Originally Posted by laserlight

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.

Quote:

---

Originally Posted by OReubens

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.

Quote:

---

Originally Posted by OReubens

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.

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.

Code:

---

/* 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?

Quote:

---

Originally Posted by OReubens

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! :)

Quote:

---

Originally Posted by ninja9578

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.

Quote:

---

Originally Posted by ninja9578

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

---

Yes...
So it adds a 4 byte (8 on 64bit) table. big deal
So it adds a few bytes of extra code to deal with this virtual destructor. big deal.

In the big light of things, and with a growing trend for VM's, and intermediate languages. The above will as I stated have little impact on the totality of your program. There are very few cases where that virtual will cause unwanted effects.

FORGETTING the virtual when it was needed otoh. can have significant effects on your program.


Is it ideal. no. but that can be said about a lot of programming habits you do "just in case".

it's also a good habit to initialize every single member variable in your class. Even if you never end up using them. and even when you know that when you will be needing it, you're setting it to a valid value anyway. That's also code wasted. but somewhere down the line maintaining your code, it's a good habit anyway. :)

Quote:

---

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.

---

Even it the class is NOT designed to be a polymorphic base class. If you are making class libraries that other will be using, you are only restricting their possibilities by not doing this.

For this very same reason, unless you have VERY VERY good reason to, it's probably a bad idea to mark your classes as sealed. You may not see a need to derive further from them, but someone using your classes may have different ideas/needs.


I find it strange you're calling it an exaggeration when it is obviously correct. There IS NO direct correlation between a class having (or not having) virtual functions and the need for a virtual destructor. It is perfectly possible for a class to have no virtual functions at all and yet needing a virtual destructor to function properly. (written and used plenty of them). It is equally possible to have a class with virtual members and NOT needing a virtual destructor because even though the class is used through a base pointer does not imply that it will be deleted through a base pointer.

I will sort of agree that a class with virtual members is a likely candidate for needing a virtual destructor as well (without conclusions about the opposite). But that relation is much much less of a formal rule than than say the relation between a class that has a copy constructor also needing an assign operator (or vice versa).

Quote:

---

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

---

Heh. :)
There are worse choices to loose your dignity in.
Either way, I'm happy i don't need to program in java, although I occasionally need to read/review it.

Quote:

---

Originally Posted by OReubens

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.

---

Are you advocating to actually make virtual destructor for any class even if it does not have any other virtual methods?

Quote:

---

Originally Posted by D_Drmmr

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.

---

Well, a good IDE would allow you to switch off such warning if you didn't like them. And even switch them off selectively for say structs and std classes.

For example the Eclipse Java IDE issues error messages when you break the rules of the language of course, but it also keeps track of best practices of the language and issues warnings if you don't follow them. There are hundreds of such "meta" warnings each of which can be enabled/disabled individually.

This ability to enforce C++ best practices of your choise is something I miss in VC++.

Quote:

---

Originally Posted by OReubens

Yes...
So it adds a 4 byte (8 on 64bit) table. big deal
So it adds a few bytes of extra code to deal with this virtual destructor. big deal.

---

Are you sure about this?

A vtable is an implementation detail and not something a C++ compiler is required to add by the standard. Couldn't it be possible during a whole program optimization to remove vtables (or parts thereof) that are never used?

Java compilers can do this. In Java methods are virtual by default but if they're not used virtually they're defacto treated as if they were non-virtual thus removing any overhead.

Quote:

---

Originally Posted by nuzzle

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

---

LOL. I've seen how much you hate Java back when you went to the Java forums and posted a rant about it (:D), but I think Java deserves better than that. As for "loosing dignity", that's just smug C++ dev talk (don't be offended, any of you :)): among the Java community are some of the most OO-literate and Architecture-literate people, and it also appears to me that Java programers are generally more familiar with software design and architecture than most developers working with other popular languages (although I have no formal study to back that up with) - and that's a respectable thing.

But C# is better :D.

About your comment to OReubens' post (in relation to vtables): language implementation details aside, that actually provides further support for his point of view. A question: I'm not familiar with the mechanisms Java compilers use to accomplish this, but, isn't there a potential problem with binary compatibility here - what if I derive from that class? Or you're talking about JIT compilation?

Quote:

---

Originally Posted by TheGreatCthulhu

I've seen how much you hate Java back when you went to the Java forums and posted a rant about it

---

Sure I've been ranting but that's mostly just a way of learning. When you get flak from everywhere you're forced to sharpen your argumentation. And I've calmed down here at this forum. :)

I'm actually very fond of Java. There have been issues over the years but they've been technology shortcomings mostly, nothing to do with the language per se. And Java has improved immensely over the years and probably continued to do so the last couple of years while I've been using C++ exclusively.

The cultural difference you mention between Java and C++ programmers is real in my experience. That's why I'm prepared to give OReubens right in principle. For certain types of applications the typical C++ programmer's tendency to spend lots of time trying to reach small performance gains is counter-productive. This effort will be drowning in the whole of the application anyway and the only noticeable result will be unsafe and brittle code.

My main objection to OReubens suggestions (virtual destructors as standard and general initializations of variables) is that it's too little. If one wants to use C++ in a more Java-like fashion one should and easily could do more. For example a general application-wide reference counting scheme would be a given thing.

Regarding the Java compiler, yes I meant JIT. But some information a Java compiler must wait for until runtime, a C++ compiler has available statically already. At least if a whole program compilation is made. So maybe a statical analysis could allow a compiler to treat virtual language constructs as non-virtual if they're used non-virtually throughout. It's not that far-fetched. Then OReubens suggestion would both increase safety and be for free. Maybe someone knows for sure.

Quote:

---

Originally Posted by OReubens

Yes...
So it adds a 4 byte (8 on 64bit) table. big deal
So it adds a few bytes of extra code to deal with this virtual destructor. big deal.

In the big light of things, and with a growing trend for VM's, and intermediate languages. The above will as I stated have little impact on the totality of your program. There are very few cases where that virtual will cause unwanted effects.

---

First of all, I don't understand what virtual machines or intermediate languages have to do with C++.
Second, it is a big deal when your class is, say, an iterator that only wraps a single pointer. If all of the classes in the STL would have virtual destructors, I would certainly not be happy. There is no reason to use these classes in a runtime polymorphic way, so they don't need a virtual destructor. Adding one can cause major performance penalties. Here's a little test I did with VS2005. The cost of this premature pessimization in this case is a factor 3.8 performance loss. That's a big deal!

Code:

---

#include <cstdlib>
#include <ctime>
#include <iostream>
#include <vector>
#include <windows.h>

const int ArraySize = 1000000;

struct Array
{
        std::vector<int> data;

        struct iterator {
                explicit iterator(int* p = NULL) : ptr(p) {}
                virtual ~iterator() {}

                int& operator *() const { return *ptr; }
                int* operator ->() const { return ptr; }

                iterator& operator ++() { ++ptr; return *this; }
                iterator operator ++(int) { iterator copy(*this); ++(*this); return copy; }

                bool operator ==(const iterator& that) const { return ptr != that.ptr; }
                bool operator !=(const iterator& that) const { return !(*this == that); }

        private:
                int* ptr;
        };

        Array() : data(ArraySize) {}

        iterator begin() { return iterator(&data[0]); }
        iterator end() { return iterator(&data[0] + ArraySize); }
};

int main()
{
        std::srand(std::time(0));
        Array a[500];

        LARGE_INTEGER start, stop, freq;
        QueryPerformanceFrequency(&freq);
        QueryPerformanceCounter(&start);
        for (int loop = 0; loop < 1000000; ++loop) {
                for (int i = 0; i < 500; ++i) {
                        for (Array::iterator it = a[i].begin(), end = a[i].end(); it != end; ++it) {
                                *it = std::rand();
                        }
                }
                for (int i = 0; i < 500; ++i) {
                        double sum = 0.;
                        for (Array::iterator it = a[i].begin(), end = a[i].end(); it != end; ++it) {
                                sum += *it;
                        }
                }
        }
        QueryPerformanceCounter(&stop);

        std::cout << double(stop.QuadPart - start.QuadPart) / freq.QuadPart << std::endl;
}

// results of 5 runs with the virtual destructor in iterator
6.91767
6.90869
6.93206
6.91705
6.91032
// results of 5 runs when the virtual destructor in iterator is removed
1.962
1.97473
1.97738
1.96257
1.97505

---

Quote:

---

Originally Posted by nuzzle

Well, a good IDE would allow you to switch off such warning if you didn't like them. And even switch them off selectively for say structs and std classes.

---

My point is that such a warning would hardly ever be useful. There would be way too many cases for which it would produce nothing but an annoying bogus message. A more useful warning IMO is something like this: http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx.

Quote:

---

Originally Posted by D_Drmmr

The cost of this premature pessimization in this case is a factor 3.8 performance loss. That's a big deal!

---

... moreover, with SCL iterators turned off, it's a 2x size penalty ( 3x if D_Drmmr composed his iterator with an std::vector::iterator with its own virtual dtor, (1+N)x with iterators made of N iterators compositions ( unless inheritance is (awkwardly) used ), etc ... ).

Hence, I agree with D_Drmmr, it can be a big deal, especially with generic code where you have to maximize optimal scalability both in space and time, as you don't know how your type will be instanced, you just know its expected semantics.
For example, if you give me a vector<T> I expect it to be used muldimensionally in an optimal way: so I can write, say, vector<vector<... vector<T>>>: in this case, a (useless) pointer per instance would mean a sizeof(void*)*( N^(D-1) + N^(D-2) + ... + 1 ) overhead, with dimension D and mean size per dimension N ( and note that a vector has a size of the same order of magnitude of a pointer; therefore, if sizeof(T)~sizeof(void*) the resulting overhead would not be negligible with respect to its "optimized" size ).

just to show that these things matter in the real world too, here is a quote from the vc2012 development team:

Quote:

---

Finally, in addition to numerous bugfixes, we've performed a major optimization! All of our containers (loosely speaking) are now optimally small given their current representations. This is referring to the container objects themselves, not their pointed-to guts. For example, vector contains three raw pointers. In VC10, x86 release mode, vector was 16 bytes. In VC11, it's 12 bytes, which is optimally small. This is a big deal if you have 100,000 vectors in your program - VC11 will save you 400,000 bytes. Decreased memory usage saves both space and time.

This was achieved by avoiding the storage of empty allocators and comparators, as std::allocator and std::less are stateless. (We'll activate these optimizations for custom allocators/comparators too, as long as they're stateless. Obviously, we can't avoid storing stateful allocators/comparators, but those are quite rare.)

---

now, maybe there's some marketing at play here, but at least it shows that there's a strong request from the community for these kind of optimizations ...

Quote:

---

Originally Posted by nuzzle

Couldn't it be possible during a whole program optimization to remove vtables (or parts thereof) that are never used?

---

even ignoring binary compatibility issues, you would need an unbelievably smart compiler to achieve that: just consider that the size of a type ( however compiler dependent ) must be known and consistent for complete types in each translation unit, independently on how that type is "used" in them. BTW, what do you mean by "parts of the vtable" ? note that the actual vtable is stored just once in any case ...

Quote:

---

Originally Posted by D_Drmmr

First of all, I don't understand what virtual machines or intermediate languages have to do with C++.

---

They're examples of how Java and C# trades efficiency for other gains such as a higher degree of programmer safety than you find in C++.

If I get OReubens correctly he's suggesting to "borrow" some safety features of those languages and apply them to the context of OO programming in C++. This would include the liberal use of virtual destructors as well as initialization of variables throughout. My only objection to this approach is that it's not far-reaching enougth. In my view as a minimum every application object also should be reference-counted.

So it's not about spoiling C++ by introducing mandatory virtual destructors in the language. It's a design question. You want to write an OO application (or support libraries for OO applications) in C++ and you want to make it as safe as possible. What measures do you take?

Regarding your example. If you add ~iterator() {} it degrades performance as much as virtual ~iterator() {} does (at least with my VS2010 compiler and the settings I'm using). So this example doesn't show especially a virtual destructor will degrade performance. It shows a user added default destructor, virtual or non-virtual alike, may degrade performance more than an automatically generated one depending on the compiler implementation.

Quote:

---

Originally Posted by superbonzo

now, maybe there's some marketing at play here, but at least it shows that there's a strong request from the community for these kind of optimizations ...

---

I don't see how OReubens' suggestion goes against "these kinds of optimizations". On the contrary, his suggestion would be even better if everything declared virtual would be optimized into non-virtual when used non-virtually. This would be fully in the spirit of C++. You pay for what you use.

When MS manages to shave a few extra bytes out of its vector implementation it's good news of course. More of that in all of STL. Lean and mean standard libraries is what everyone expects and demands.

But I doubt this reduction of the overhead of vector will have much impact on the typical C++ application. And if you use a lot of vectors it's probably more important to make them shrink-to-fit. Having 100.000 vectors each with just 100 bytes of excess capacity on average would total 10.000.000 bytes. That's a lot of wasted memory and dwarfs any gain from the leaner vector implementation.

As nuzzle said, this is a question of software design. Design principles and practices, as well as best practices in general, are not set in stone, and are not to be followed with religious zeal: they all have some reasoning behind them, their pros and cons, and thus a defined domain of applicability. If the requirements for your software put it outside of this domain (or not entirely within it), you make some effort to gain a deeper understanding of the system you're building, and then either modify the design principle/practice, or throw it away entirely as inapplicable in favor of something else.

Are many of you going to develop alternatives to the STL? The concerns you're expressing about the virtual destructor appear to me to be related to rather specific cases - cases where the practice shouldn't, but more importantly, where it doesn't have to be followed. No one's forcing you to do anything. A principle/practice should be considered on the basis of its applicability, and it should be estimated how relevant and beneficial it is in general (what nuzzle called "far-reaching", if I understood correctly). Once you've made that estimation, you can decide how often and in what cases you are going to follow this principle/practice (if at all).
Whether the compiler should issue a warning or not is a different matter.

OReubens' argument was that it "can save a lot of headaches somewhere down the line", and that the cases "where a virtual destructor would actually cause problems and where it needs to be non-virtual are very rare". All you have to do now is decide if you agree with this observation or not.
But that's from your personal experience and most likely from the perspective of a field you're working in. Language (and compiler) designers, on the other hand, have to analyze how the language is (or is going to be) truly used in the majority of cases (possibly giving some important cases more weight than others), and make language design (or compiler design) decisions based on that, including whether to support a principle or a best practice through the language, through compiler warnings or otherwise, doing their best not to jeopardize how people use the language for other things. Tricky business...

Quote:

---

Originally Posted by TheGreatCthulhu

No one's forcing you to do anything.

---

I disagree. Correct me if I'm wrong, but the whole discussion was about the possibility of enforcing ( at the language level or as a self-imposed rule ) virtual destructors on all types ( being designed for inheritance or not ) as a precautionary measure against unwanted UB.

If OReubens' view was just "for types whose foreseeable usage would imply public inheritance, make the destructor virtual unless there's a very good reason to not do so" then I think everybody would agree with him. But this is not the case ( unless I misinterpreted his words, of course :) ).

Quote:

---

Originally Posted by nuzzle

I don't see how OReubens' suggestion goes against "these kinds of optimizations". On the contrary, his suggestion would be even better if everything declared virtual would be optimized into non-virtual when used non-virtually. This would be fully in the spirit of C++. You pay for what you use.

---

first of all, as I alluded in my previous post, such global optimization is just nearly-impossible with the c++ compilation model and a dynamic type implementation that can influence the size of types. So, in essence, OReubens' suggestion does imply a size overhead on polymorphic types and hence does go against such micro-size optimizations.
Moreover, I'd say that the spirit of C++ is not just "you pay for what you use", it's more something like "you pay for what you want". That is, I think most C++ programmers would be nervous at managing types whose size, binary content and behavior could change in response to a code change in a different traslation unit ...

Quote:

---

Originally Posted by nuzzle

But I doubt this reduction of the overhead of vector will have much impact on the typical C++ application. And if you use a lot of vectors it's probably more important to make them shrink-to-fit. Having 100.000 vectors each with just 100 bytes of excess capacity on average would total 10.000.000 bytes. That's a lot of wasted memory and dwarfs any gain from the leaner vector implementation.

---

yes, but if design decisions were just a matter of plain asymptotics, then essentially all languages would be the same. Sometimes, small effects do add up to produce noticable effects, especially with bounded resources or when there is a non trivial relation between resouces (time,space,...) and the perceived "value" of the final product; in such a case, being able of fine tuning code translates in greater value.
For example, consider GUI responsivity: the curve that relates, say, the time needed to visually feedback a user action and the user perception of its delay is non linear, like a steep ramp. Now, what if your 1.0 release stays near the edge of that ramp ? a C++ programmer would have the highest chance ( with respect to other programmers ) of moving from that edge both by fine tuning code but also proactively, by choosing designs that combine good abstractctions <and> optimal behavior. BTW, is this why managed apps are universally perceived as "slower" ? :)

Quote:

---

Originally Posted by nuzzle

So it's not about spoiling C++ by introducing mandatory virtual destructors in the language. It's a design question. You want to write an OO application (or support libraries for OO applications) in C++ and you want to make it as safe as possible. What measures do you take?

---

As superbonzo, I also read OReubens' suggestion as using virtual destructors for every class (or struct), even those that have no virtual functions and, therefore, are not designed to be used in an OO way. That just doesn't make sense to me. IMO, you gain nothing and potentially loose a lot.
I have never found it a problem to decide which classes need a virtual destructor (after I learned about them, that is). Every base class that has virtual functions gets a virtual destructor - no problem there. Similarly, I often find it relatively easy to figure out which class or object is responsible for the memory management of a certain object. Only in those cases where shared ownership makes sense, have I used shared_ptr (or intrusive_ptr with an internal reference count where performance really mattered). When there is a single owner, I'd say the use of reference counting is premature pessimization. You don't need it, and it can hurt you, not just in terms of performance, but it also opens the possibility to circular dependencies. There are plenty of other smart pointers (unique_ptr if you can use it, I'm stuck with boost::scoped_ptr) that you can use to prevent memory leaks or dead pointers. However, the most important guideline to prevent all of these problems is not to use OO for everything in C++.

Quote:

---

Originally Posted by nuzzle

Regarding your example. If you add ~iterator() {} it degrades performance as much as virtual ~iterator() {} does (at least with my VS2010 compiler and the settings I'm using). So this example doesn't show especially a virtual destructor will degrade performance. It shows a user added default destructor, virtual or non-virtual alike, may degrade performance more than an automatically generated one depending on the compiler implementation.

---

If every class should/must have a virtual destructor, you don't have the option of using the compiler implementation.

Quote:

---

Originally Posted by superbonzo

I disagree. Correct me if I'm wrong, but the whole discussion was about the possibility of enforcing ( at the language level or as a self-imposed rule ) virtual destructors on all types ( being designed for inheritance or not ) as a precautionary measure against unwanted UB.

---

It's definately not about enforcing anything at the language level. C++ is C++ and stays C++.

It's about using virtual destructors as a self-imposed standard in the OO part of an OO dominated application. As a precautionary safety measure they may as well be introduced throughout even for classes at the perimeter of OO.

But I suggest more. I suggest all OO objects also should be reference counted by default in an application-wide memory management scheme. This approach is quite common today even in C++ libraries. The C++ Direct3D library has it and the C++ Metro library will too.

It's important to realize that C++ is a very versatile multi-paradigmic language that can be used very differently. Some usages will want to favour general safety over efficiency in every detail. It's a treadoff that may not be as expensive as many would think. This idea has even spawned new languages such as Java and subsequently C#.

It's almost become a general wisdom that you cannot or shouldn't program in C++ like you do in Java. I don't share this view. One of the major design goals of Java was to be a safer C++ and I believe the findings can be successfully adopted back to C++. I'm doing that, I'm using the Java programming style in C++. It works fine and I'm still reaping the full power of C++. Perfect.

Quote:

---

Originally Posted by D_Drmmr

If every class should/must have a virtual destructor, you don't have the option of using the compiler implementation.

---

Your example didn't back up the claims you've made about the inefficiency of virtual destructors. I think you should acknowledge that.

You relied on a compiler dependent optimization. This backfired. The C++ standard doesn't state compiler generated destructors must be faster than user supplied empty ones. So generally it's a bad idea to bet on this for the performance of a program. And it's even worse to recommend others to do it.

It's called premature optimization. In my view many C++ programmers spend too much time fiddling with implementation detail they don't know will have any impact on the overall application performance. If you have this inclination it's better to use C. Far less abstraction and much more sweating the small stuff.

Quote:

---

Originally Posted by STLDude

Are you advocating to actually make virtual destructor for any class even if it does not have any other virtual methods?

---

And again...
The need for a virtual destructor has NO RELEVANCE AT ALL to the class having other virtual functions.

see previous posts...


And no, I'm not advocating adding virtual to all destructors.
But on all classes that may get useed as a base class by someone other than you. It's probably a good idea.



Rereading my own answer on this... I guess what I really wanted to say...
It is a better to get into a habbit of making all your destructors virtual by default and asking yourself if it really needs to be, than doing the opposite. Making them non-virtual by default and asking yourself if it maybe needs to be virtual.

Doing the former, will almost never result in failing code, only in code that's "a bit" slower than it needs to be.
Doing the latter, could result in a program that leaks, crashes, or does all sorts of nasty things.

Quote:

---

Originally Posted by D_Drmmr

First of all, I don't understand what virtual machines or intermediate languages have to do with C++.

---

I was merely pointing out a trend. THere is a growing trend in using "higher level" languages that add extra layers between what you wrote and the actual hardware. All those layers take time as well. If people accept the added performance loss of those extra layers. Then the extra performance lost of virtual destructors over regular ones is negligeable.

Quote:

---

Originally Posted by D_Drmmr

Second, it is a big deal when your class is, say, an iterator that only wraps a single pointer. If all of the classes in the STL would have virtual destructors, I would certainly not be happy. There is no reason to use these classes in a runtime polymorphic way, so they don't need a virtual destructor. Adding one can cause major performance penalties. Here's a little test I did with VS2005. The cost of this premature pessimization in this case is a factor 3.8 performance loss. That's a big deal!

---

And you can "proove" just about anything this way. :)
I never claimed that making a destructor virtual has no performance implications.

But in this particular instance. We're talking about a performance lost of 5 sec over 500million iterations.
Yes, it's 5sec difference. but with an example that's tailored into forcing a bad result.
5sec lost over 500million iterations is "negligeable" most of the time.

I can proove that all STL algoritms are "bad" if I "proove" that each of them against their worst case scenario does significantly less than algorithms tailored to those specific worst cases.


Note that I never claimed to just add virtual to everything. classes you are 100% sure that will never be derived from don't need it.
But if you are designing libs, you don't always know how users of your lib will use the classes you design. So adding virtual to "all" classes is probably a good idea. iterators are probably one of the few cases where you can be sure people will never derive of them. If you have all the code under your own control. THen stuff is always easier :)

Quote:

---

Originally Posted by D_Drmmr

As superbonzo, I also read OReubens' suggestion as using virtual destructors for every class (or struct), even those that have no virtual functions and, therefore, are not designed to be used in an OO way. That just doesn't make sense to me. IMO, you gain nothing and potentially loose a lot.

---

Performance is a secondary issue. Your users are not going to love you if you make the fastest possible code that crashes. Or makes their machine go wonky.
Code that works is the more important issue.

Adding virtual anywhere "just in case" is thus the better strategy. That doesn't mean optimisation has no relevance at all. If you can 100% guarantee a class will never be deleted polymorphically then you can remove the virtual and gain some performance.

If you can 100% guarantee the class will not ever by anyone using your code now or in the future be deleted polymorphically, then don't add the virtual. In all other cases "it is probably a good idea to do it anyway".

Quote:

---

Every base class that has virtual functions gets a virtual destructor - no problem there.

---

And you too seem to imply a relation to the class having other virtual functions. Again, THIS IS NOT what decides the need for a virtual destructor.
The ONLY thing that makes a virtual destructor necessary is if you new a derived class and delete it through it's base pointer.
If you're not doing this, then you don't need a virtual destructor, regardless of if the class (or base class) has
or doesn't have virtual members.

Quote:

---

Originally Posted by OReubens

iterators are probably one of the few cases where you can be sure people will never derive of them.

---

Sorry, but you cannot be sure of that.

Quote:

---

Originally Posted by OReubens

If you can 100% guarantee the class will not ever by anyone using your code now or in the future be deleted polymorphically, then don't add the virtual. In all other cases "it is probably a good idea to do it anyway".

---

Unless the destructor is non-public, or the class is defined in an unnamed namespace in one of your source files, you cannot "100% guarantee (that an object of) the class will not ever by anyone using your code now or in the future be deleted polymorphically".

I think that your approach is pragmatic. That's good. But just as you have such confidence about C++ programmers when it comes to deriving from iterators, I have confidence that C++ programmers understand that they should not be publicly deriving from a class that is not designed to be a polymorphic base class such that objects of derived classes will be destroyed by deleting a pointer to the base class. If they betray my confidence, then it is their foolishness.

Consequently, I would rather signal this by not declaring the destructor virtual if I really do intend my class to be a concrete class that does not serve as a polymorphic base class. It may be inconvenient to a user of the class if he/she wants to derive from it, but that is likely to be a sign that public inheritence is a wrong design to begin with.

Quote:

---

Originally Posted by OReubens

Rereading my own answer on this... I guess what I really wanted to say...
It is a better to get into a habbit of making all your destructors virtual by default and asking yourself if it really needs to be, than doing the opposite. Making them non-virtual by default and asking yourself if it maybe needs to be virtual.

---

I don't think we should have a habit of making destructors virtual or non-virtual by default. We should have a habit of making our destructors virtual or non-virtual by intention.

Quote:

---

Originally Posted by OReubens

And you too seem to imply a relation to the class having other virtual functions. Again, THIS IS NOT what decides the need for a virtual destructor.
The ONLY thing that makes a virtual destructor necessary is if you new a derived class and delete it through it's base pointer.
If you're not doing this, then you don't need a virtual destructor, regardless of if the class (or base class) has
or doesn't have virtual members.

---

When you talk about "need" here, I definitely agree. Note that in post #6, the word used is "should". I'm not going to quibble on this though, since you later conceded:

Quote:

---

Originally Posted by OReubens

I will sort of agree that a class with virtual members is a likely candidate for needing a virtual destructor as well (without conclusions about the opposite). But that relation is much much less of a formal rule than than say the relation between a class that has a copy constructor also needing an assign operator (or vice versa).

---

Which is also something that I agree with. (However, I note that your related example is unclear: a class that has a copy constructor defined does not always need to have a copy assignment operator defined, since it could be the case that the copy assignment operator is declared private but not defined.)