If I don't see a destructor, then I'll look at the class definition to see if one is necessary, then wonder whether the author forgot. And check the copy constructor and copy assignment at the same time.
Printable View
If I don't see a destructor, then I'll look at the class definition to see if one is necessary, then wonder whether the author forgot. And check the copy constructor and copy assignment at the same time.
But why is that important to me as user of a code? IMO, if class does not need destructor, then don't litter the code.Quote:
Originally Posted by code_carnage
In the general case, I completely agree with not littering the code. Don't implement a destructor if it is not necessary. The ONLY reason for an empty destructor is if you are intending the class to be inherited. The general rule I follow:
1) Class is NOT designed to be inherited: Either no explicit desctructor or a non-virtual distructor.
2) Class is designed to be inherited but is of use by itself. A virtual (non-pure) destructor (empty if necessary)
3) Class is designed to be inherited and is NOT of use by itself (it is conceptually abstract): A Pure Virtual Destructor (empty if necessary).
One condition that often occurs in (other peoples implementations. if the following:
Since C++ does not (currently) have a "sealed" construct, it can be difficult to indicate that Derived2 should NOT be derived from....Code:AbstractBase
-- Derived1 (intended for further drivation if necessary)
-- Derived2 (not structured for further derivation)
Since my design pattern uses the destructor for all of the other conditions, and that is where I look for a quick glance at the "inheritance intent", I will sometimes put an emp-ty destructor in a derived class which simply contains the comment
Code:~YadaYada()
{
/* This Class should NOT be used as a base class */"
}
I'd add a number 4 to that list:
4) Class is designed to be inherited, is NOT of use by itself and its implementation is strictly hidden (i.e. it's an exported interface to a "black-box" component): a non-virtual, protected destructor. All responsibility for the lifetime of the object is taken by the owning component. Client code must not be allowed to call delete on a pointer to this class, since there is no guarantee that a) the implementation is not doing other things, b) the client code is the only code using that pointer and c) the target object may not have been created with new.
Regarding "#4".... :thumb: That is a dfinate real world design pattern (although one I thing occurws with lower frequency than #1-#3).
Do you have any better suggestions for the marking of a "leaf" class in a hierarchy than the "coment in descructor" approach? I have been searching for one for over a decade....
Scott Meyers's advice is that all non-leaf classes should be abstract. So, on that basis, a lack of pure virtuals indicates a leaf class. It's a good idea, and the arguments in its favour are compelling, but it can be difficult to achieve in practice.
I should add that I like, wherever possible, to construct components whose only visible classes are pure abstract "interfaces", so I tend to use the protected, non-virtual destructor quite a lot. The only problem that that produces is all the idiot compilers that warn me about a class with virtual functions and non-virtual destructor. HELLO! It's protected, so SHUT UP about it.
Again agreeing with you (on both points) :DQuote:
Originally Posted by Graham
For those who are willing to use a microsoft extension, you can ENFORE pure abstract interfaces: __interface (V7.1 and later only)
Regarding Scott Meyers' architectural pattern, I try to follow it when ever possible. But you are right it can be difficult to achieve in practice. Worse, it is (to the best of my knowledge) impossible to enforce.
One way to help is the following (abbreviated) Design Pattern:
1) Create Abstract Base Class
2) Create "General" derived leaf class which encapsulates a pointer to a "Specific" derived leaf class. All operations are directed to the encapsulated instance
3) Create as many "Specific" derived leaf classes as needed. Provide a conversion operator to return a "General" class instance.
Now, you can NOT create the abstrace base class but you CAN create instances of the "General" leaf class. Since you can create instances, you can easily create STL "value" (not pointer) collections of these instances. This neatly avoids the memory management issues with collections of pointers (where the collection conceptually owns the items as it does with value collections), and provides performance that is equivilant.