5

I am relatively new to C++ (and programming in general) so please forgive me if the question is not perfectly clear immediately.

What I have is a program in which a certain number of objects of a internally defined class [let's call this "class1"] are created. The program works perfectly fine and the objects do what they should.

The problem that I am currently trying to solve is the following: these objects are not destroyed (and thus memory is not de-allocated) until the program exits, but I need that memory earlier.

Among the other members of the class there are objects of other internally defined classes (who also have members that are objects of a third class).

My question is the following: how do I properly define a destructor for the objects of "class1" so that all the data is cancelled and the memory deallocated?

I found out (probably this was obvious for you already) that a destructor like

class1::~class1(void) { }

won't work (I defined similar destructors for all internally defined classes).

Reading around I understood that my mistake could be that that is a destructor that does nothing. How do I solve this?

Thanks to anyone who will answer/help/comment.

Federico

Improve this question
6
  • How do you allocate these objects? Do you use new or create them globally? (Minor nitpick: they are called destructors.) Commented Aug 18, 2011 at 9:08
  • What does "won't work" mean? If class1 does not allocate resources that require special cleanup, this constructor works fine! It executes the destructors of all data members. Commented Aug 18, 2011 at 9:09
  • They are allocated with new. Thanks for the "nitpick" :) Commented Aug 18, 2011 at 9:10
  • @André it means that memory is not deallocated. The plot of the memory usage increases even after the destructor is called, without showing the drop that should be the consequence of the destructor. Commented Aug 18, 2011 at 9:12
  • @Frederico: what plot of memory usage? Are you looking at the windows task manager? That won't track low-level memory de-allocations as the memory is very likely to be kept by the process even though your code released it. Commented Aug 18, 2011 at 9:18

4 Answers 4

Reset to default
13

In C++ you need to free the memory manually. There's no garbage collector. You obviously need to free the memory manually inside your destructor. If you allocated the memory using new, you need to use delete for each resource you allocated with new inside the deconstructor, for example:

class1::~class1(void) { delete resource1; delete resource2; etc... }
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Understood. And what about the object of "class1" itself? Does it matter if it is allocated with new ?
This is one reason to avoid using new to allocate the resources. Then you don't need to delete anything either.
Yes, if it is allocated with new then it needs to be deleted as well. The rule is very simple for every new there should be a delete, for every new[] there should be a delete[]. You have to code them yourself. This is the reason you should avoid using new and delete, normally you would prefer to use standard library classes to avoid as much explicit allocation as you can.
@Federico of course if class1 was dynamically allocated by another class, it should be freed by that class. Obvioulsy class1 cannot free itself.
3

If you are allocating memory dynamically you need to free it in destructor, but better solution would be to use some smart pointer to hold dynamic data - std::auto_ptr or std::shared_ptr. Then you will not need to explicitly free memory - this will be done automatically in smart pointer destructor.

Improve this answer

Comments

2

First you should try to allocate your objects on the stack:

Object obj;

so you don't have to worry about memory allocation. The disadvantage is that the object life is limited to the current scope.

If that's not good for you, you should consider using smart pointers. If that's not an option use new / delete to create / destroy your objects. But you have to be careful, every new should lead to a delete at some point in time..

Improve this answer

1 Comment

I think that this could be the point: the program has not been developed by me and it is filled with news, but I hardly see any delete
2

Memory on stack

If there is no heap-allocated object inside your class, there is no need for you to explicitly define the destructor of your class. The compiler-generated one should handle the job quite well, i.e., call destructors for base class objects and member objects, etc.

Memory on heap - manual memory management

If there is any heap-allocated objects inside your class, you need manually deallocate them in your destructor. Make sure you have them deallocated properly at all possible exit points, e.g., handle exceptions and deallocate resources.

Memory on heap - RAII

Alternatively, you may use some well-defined RAII class to handle the resource management for you automatically, e.g., scoped_ptr, scoped_array in Boost, shared_ptr in STL, etc.

Improve this answer

2 Comments

For what I understood the compiler-generated destructor is called when the object goes out of scope; I need that memory earlier.
humm, if that memory is heap-allocated and you want it before the dtor gets invoked, you can just delete it.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.