Sign in to follow this  

Should all destructors be virtual?

This topic is 4137 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Shouldnt all destructors be declared virtual because of the possibility that an inherited object will be destructed through a base class pointer? This seems like a good precaution that would future-proof/idiot-proof your classes. Does this sound like a good practice? Do you guys do this?

Share this post


Link to post
Share on other sites
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
http://blogs.msdn.com/oldnewthing/archive/2004/05/07/127826.aspx

Share this post


Link to post
Share on other sites
Assuming C++.

No, many concrete classes shouldn't be inherited from. Just look at the SC++L, here many classes lack a virtual destructor because they shouldn't be inherited from. For more information (also about virtual functions in general) I suggest that you read this.

Share this post


Link to post
Share on other sites
Quote:
Original post by swordfish
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.


No, the problem is that the derived classes will compile, but the wrong destructor will be called if the class is deleted through a pointer to the base class.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by swordfish
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.


No, the problem is that the derived classes will compile, but the wrong destructor will be called if the class is deleted through a pointer to the base class.


I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

Slightly more on topic, C++ maintains the "If you don't want it, you don't pay for it" approach and declaring a destructor virtual for a concrete type that is not meant to be inherited from would add the unecessary overhead of a virtual table pointer to each instance of the class.

I quite like the extension described above though. I guess it could not become part of the standard though since there could be instances where you don't want it. Pretty rare though.

Share this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

That's not an extension; that's just plain broken. Inheriting from a class with a non-virtual destructor can be useful in instances such as policy classes with a protected destructor.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by EasilyConfused
I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

That's not an extension; that's just plain broken. Inheriting from a class with a non-virtual destructor can be useful in instances such as policy classes with a protected destructor.


Protected deconstructor? What does that do?

Doesnt that mean an cant be deleted/deallocated? When it goes out of scope or is explicitly delete'd wouldnt there be a runtime error or something?

Share this post


Link to post
Share on other sites
A protected destructor means the same thing that protected means for any class member: only friends, members of the class and members of derived classes can access the member. In particular, this means that only members of the class or derived classes can delete the object. However, derived classes can have public destructors and things can delete derived class objects through that. Ex:

class Base {
protected:
~Base();
};

class Derived : public Base {
public:
~Derived();
};

// somewhere else
Base b; // not good, can't destroy base object
Derived d; // fine, derived can be destroyed

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
A protected destructor means the same thing that protected means for any class member: only friends, members of the class and members of derived classes can access the member. In particular, this means that only members of the class or derived classes can delete the object. However, derived classes can have public destructors and things can delete derived class objects through that. Ex:

class Base {
protected:
~Base();
};

class Derived : public Base {
public:
~Derived();
};

// somewhere else
Base b; // not good, can't destroy base object
Derived d; // fine, derived can be destroyed


Thats really neat ... but scenarios where that would be useful are still lost on me. Could you give an example?

Share this post


Link to post
Share on other sites

class Policy1 {
public:
typedef int Argument;
void * allocate(size_t size) {
return std::malloc(size);
}
protected:
~Policy1();
};

class Policy2 {
public:
typedef long Argument;
void * allocate(size_t size) {
return ::operator new(size);
}
protected:
~Policy2();
};

template <typename Policy>
class PolicyUser : public Policy {
public:
void DoSomething(typename Policy::Argument) {
// blah blah blah
void * ptr = allocate(10);
// blah blah blah
}

~PolicyUser();
};

Share this post


Link to post
Share on other sites

This topic is 4137 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this