Heap object created on the stack isn't cleaned up properly

Code:

---

m_vRenderObjects.push_back(new Objects(mOperatorMesh));

/// this is never called
~Objects(void) {
                OutputDebugStringA("Cleanup Objects\n");
                if (StateMachine != NULL)
                {
                        delete StateMachine;
                        StateMachine = NULL;
                }

                if (m_pAnimCtrl != NULL)
                {
                        m_pAnimCtrl->Release();
                        m_pAnimCtrl = NULL;
                }
       
                dtFreeNavMeshQuery(m_navQuery);
                m_navQuery = NULL;
        }

---

This leads to ugly memory leaks.
Help please.
Thanks
Jack

You could use a std::shared_ptr<Objects> or perhaps std::unique_ptr<Objects> instead, or use a container like boost::ptr_vector. Otherwise, you need to delete what you new.

Quote:

---

Originally Posted by lucky6969b

[code]
m_vRenderObjects.push_back(new Objects(mOperatorMesh));

/// this is never called
~Objects(void)

---

Unless your program just aborts, destructors are always called.

Code:

---

if (StateMachine != NULL)

---

An unnecessary test. There is no need to test for NULL if you're calling delete. Calling delete on a NULL pointer results in no operation being performed.

Quote:

---

Heap Object created on the stack...

---

It doesn't matter where the heap object is created (whatever that means). If you call "new", then it's your responsibility to call delete, unless you wrap the call to "new" in a smart pointer, as laserlight pointed out. Getting involved in whether a heap object is created here or there misses the point.

Regards,

Paul McKenzie

From Paul McKenzie:

Quote:

---

An unnecessary test. There is no need to test for NULL if you're calling delete.

---

Quite true! What fools some programmers into thinking otherwise is that the C Run Time will sometimes check the integrity of the heap in a debug build on calls to delete (or at least it used to in earlier versions of Visual Studio). If the heap is corrupted those versions put up an error box and halted the program.

I worked with a programmer once who insisted deleting a NULL pointer wasn't generally safe, but it was because this was happening to him at a point where he was calling delete on a pointer that happened to be NULL. It seems people assume if they get the detection on deletion of a non-NULL pointer, something is wrong with their program, but they won't reach that same conclusion if they are deleting NULL.

Apparently there are quite a few people out there who've been conditioned to wrap their deletes, perhaps because of this. (?)

I used to wrap if(p != 0) around my deletes for some time.
The reason was, as you mentioned above, that older VS runtimes would popup an error when deleting NULL.