Memory Management in C++

Iceberg76

Hello, I have a few questions regarding Memory Management in Visual C++. I am using Visual Studio .NET 2002 and as a sidenote I am creating a Win32 application that uses the DirectX API. I am compiling in Debug mode (not Release). If I create a Class, I generally make a constructor and destructor for each class. I know the constructor is called when the user creates (instantiates) a class object. When is the destructor called? Do I need to do something to my class object to call the destructor? Or is this automated somehow? Also, I want to be sure I don't have any memory leaks (releasing all COM objects and freeing all pointers). How do I specifically check to see that I have successfully done so in Visual Studio .NET? Thank You, CBerg

Arcrest

the destructor will be called when an object leaves its living scope,for example function returning. You should not try to call it directly,or the comiler may complains about that because it knows when to call the destructor. You should read some C++ textbooks to gain more about C++. the second one: the return type of all COM interfaces is HRESULT,which is a 32bit integer. The first bit of it indicates whether an operation succeeded or failed: 0 for success and 1 for fail,so if the returing value is less than 0, you can know that the operation failed,otherwise success. Usually you can use the following macro which is defined in the Winerror.h: #define SUCCEEDED(Status) ((HRESULT)(Status) >= 0) #define FAILED(Status) ((HRESULT)(Status)<0) but for the IUnknown::Release,you should always get S_OK result.

Keith Vitali

Hi, Just to add to what exRange said. If you allocate objects on the heap (through the keywork 'new'), then you are responsible for freeing the memory by calling delete. Generally, it is a good idea to allocate resources in the constructor and make sure they are freed in the destructor. Keith

Gary R Wheeler

Essentially, there are three ways to create an object:

class Object {
public:
Object();
~Object();
// ...
};

Object GlobalObject;

void Function()
{
Object StackObject;
//...
Object *HeapObject = new Object;
//...
delete HeapObject;
}

First, we have a class Object, with a constructor and a destructor. There are three instances of the class in the code: GlobalObject, StackObject, and HeapObject (which is a pointer). Since GlobalObject is at file scope, the constructor for GlobalObject is called by the C++ runtime when the program starts, and its destructor when the program exits. StackObject is created on the stack, inside the function Function. It's destructor is called when Function() exits. More precisely, the destructor is called when execution leaves the enclosing scope (the outermost braces "{" "}" of the function). HeapObject is a pointer to an Object allocated on the heap using the new operator. In this case, the user (you the programmer) must explicitly destroy the object using the delete operator. The delete operator calls the destructor. COM objects are slightly different. You 'allocate' COM objects using CoCreateInstance or one of the related functions, which return an interface pointer. All COM interfaces derive from the IUnknown interface, which has three methods: AddRef, Release, and QueryInterface. When you are done using a COM object, you release it by calling the Release method through its interface pointer.

Software Zen: delete this;

Iceberg76

That was a beautiful answer! Thank You. Do heap objects need to be called within functions, or can they be global as well? When should I use a heap object rather than using a global or stackobject? As a sidenote, I am using C++ with DirectX to create different objects in my world space. I have implemented both the global object and heap objects, but I couldn't really tell a difference. Both versions of the object worked fine.

Gary R Wheeler

Iceberg76 wrote: Thank You You're welcome. Iceberg76 wrote: Do heap objects need to be called within functions, or can they be global as well? Pointers to heap objects can be global, or can be passed from routine to routine as needed. The objects themselves reside on the heap, which in a sense is a global data structure. Iceberg76 wrote: When should I use a heap object rather than using a global or stackobject? Using the heap is a good idea when you don't know how many objects you'll need. One time, you may only allocate one object. The next time, maybe you'll need ten. The heap lets you adapt to that kind of situation. Global objects have their good and bad points. They are good, in that a global object is easy to access from a lot of points in your software. Unfortunately, that's also their weak point. Since they can be accessed from everywhere, your software can get pretty tangled up. You'll find out that you can't change this feature of the object, because that part of the application depends on it. It can make maintenance and debugging a nightmare. Stack objects are useful when you know you only need the object for the duration of a given routine.

Software Zen: delete this;