destructors

[sgiri1981]

Hi,
I have a hierarchical design of a class, say: BaseProcess, ....., MyXXXProcess.
The most derived class is not given a destructor. In this class, I m creating a array of another class, say MyClass, using pointers and new operator.

I wonder if the lack of destructor will create memory issues because I m not able to destroy the instances of MyClass that were created with the new operator.

If, instead I create the instances of MyClass as follows: MyClass obj1, obj2;
I guess in this case I dont need to worry about deleting the objects as they are created in stack and are released when the object goes out of scope. Is that correct?

Thanks,
sgiri

[JVene]

It's not just about releasing memory.

I see many, many times that programmers will say things like, "But, there's nothing to destory, so I haven't written a destructor" or some such explanation.

The fact is, the compiler generates an implied destructor, so there is one even if you don't write it. You must think in terms of "all circumstances" and avoid getting trapped into creating objects that work as long as you don't touch them. Such programmers engineer a house of cards when they tend to think that way.

The members of the derived object will need "destructing", and some of those might be objects that themselves have destructors that must be called. Even if you don't have such members now, that doesn't mean it will always be so.

Therefore, what you must do is to create a virtual destructor in the base most class. This means that all derived classes will have virtual destructors, and they'll be called appropriately even when you destroy from the base most perspecctive.

It's true that you don't have to write a destructor. You must still account for the destruction sequence, and the rule is that if you derive from a class, with very special exceptions, you should make the base class destructor virtual.

[GCDEF]

If the derived class has members that are created using new and you don't specifically delete them, you have a leak. Deleting your class won't delete memory it allocated.

[sgiri1981]

Therefore, what you must do is to create a virtual destructor in the base most class. This means that all derived classes will have virtual destructors, and they'll be called appropriately even when you destroy from the base most perspecctive.

It's true that you don't have to write a destructor. You must still account for the destruction sequence, and the rule is that if you derive from a class, with very special exceptions, you should make the base class destructor virtual.

Thanks for the explanation.

I just checked the base-most class - the destructor is virtual. So, that takes care of this class and all classes up its hierarchy.

However, for its members that were instantiated using new and other members, is it mandatory to call delete?

best,
sgiri

[sgiri1981]

If the derived class has members that are created using new and you don't specifically delete them, you have a leak. Deleting your class won't delete memory it allocated.

Hi GCDEF,
I was still composing my earlier reply (and cross-referencing my code and c++ book) and didnt see your reply.
This explains it.
Thanks a lot.

best,
sgiri

[sgiri1981]

Have to toss this thread as I encountered a weird thing.

In the hierarchy of classes I mentioned, the base most class has a destructor that is virtual. The 2 most derived classes do not have destructors. I tried to add a destructor to the most-derived class, but it gave a linker error that read something like: ~MyClass already defined in MyClass.obj...

Could it be because its immediate base does not have a destructor? I m not able to figure it out, but I m sure the error is because of the addition of destructor (i removed it and the build was successful)

Thanks in advance
sgiri

[Raislin]

Actually, this sounds exactly like a problem I was having recently. Are you defining the destructor in a header file, but outside of the class definition? i.e.:

//MyClass.h

class MyClass
{
   //stuff
public:
   ~MyClass();
}

MyClass::~MyClass()
{
   //destructor stuff
}

If so, then it is the same as my previous problem. You can define the destructor as inline:

inline MyClass::~MyClass()
{
   //destructor stuff
}

or you can define it normally when you declare it in the class definition. Or you could define it in a separate file.

If that's not what's going on, then hopefully someone else can help.

[sgiri1981]

Thats exactly what I m doing!
But some other classes up in the hierarchy (before the most-base class) are doing it the same way.

Only my class's immediate base does not have any. All classes above it in the hierarchy have a destructor declaration in header file and definition in .cpp file.

I will try building after making the changes you mention, but still I dont get the reasoning behind it.

Thanks,
sgiri

[Raislin]

See Lindley's explanation here:

http://www.codeguru.com/forum/showthread.php?t=478755

[sgiri1981]

That worked!!!

Here is what I think was happening (from Lindley's response in the earlier thread)

I have such a hierarchy: Base, Derived1, Derived2, Derived3.

The destructor in Base is virtual. The others dont have destructor. Thus, the compiler tries to put one. However, I attempted to put a destructor in Derived2.h and Derived2.cpp. I believe that the build process works in such a way that first the inheritance hierarchy is resolved by the compiler and appropriate destructors inserted. The compiler then found the destructed I defined in Derived2.cpp and compiled that too.
The linker was then confused by the presence of 2 destructors, one provided by the compiler and one provided by me.

I solved this by the suggestion in previous thread: make the destructor as an inline in Derived2.h.

Is there any other solution?

Thanks,
sgiri

[Raislin]

The compiler only provides a destructor if you do not explicitly define one.

Were you defining the destructor in both Derived2.h and Derived2.cpp? Can you show in code snippets?