new and delete

[urika]

does EVERYTHING i new i have to delete?
the pointers that are newd are from a dll

[PadexArt]

You or someone else.

It depends on how that DLL is designed. You should have documentation for it and that documentation should specify who is respoonsable for the pointers allocated by the DLL .

[cvogt61457]

Each and every one !!!!
All of them !!!
None are excepted !!!

Everytime you allocate memory with a new, you MUST use a delete
to release the memory when you are finished.

Also, if you use the array version of the new, you must use the
array version of delete.

new --> delete
new [] --> delete []

Now for your dll question:
It is better to release the memory using the same module that
allocated the memory. There are many justifications for this, one
being that the allocator has a better understanding of how the
memory was allocated in the first place. new vs new[] is one.

If there DLL is yours, then it might be wise to add a function to
release the memory allocated.
If the DLL is purchased and you don't have the source, then the
documentation should have details on how you should release
the allocated memory.

[ReorX]

Not everything that is new'd by a User is allowed to be deleted by the User.
Frameworks like Qt for example take over the ownership for Widgets with a non-NULL-parent.
So you must not delete QT-Widgets - somebody else is going to do this (in this case: QT Framework).

Especially when DLLs are concerned: Whereever something is constructed, there it must be destroyed.

So usually DLLs supply function like CreateObject and DestroyObject instead of letting the User call new and delete on their objects. This prevents problems with objects created on one heap (inside the DLL with CRTx) and deleted in an environment with a different CRTy (where x maybe Debug and y maybe MT).

[cvogt61457]

If the OP uses new, then he should use delete.

The documentation should give details on how to handle objects
created by the DLL.

It all depends on the DLL operation.

I've not run across any libraries where I'm required to allocate
memory and never delete. The OP didn't say this in his description.

If the DLL does have this requirement, then must be documented.
Follow the DLL documentation.

[JohnCz]

Memory for all object instantiated (allocated) on the heap whether by using new or not, should release memory.
Some of the MFC classes are designed to do auto cleanup and explicitly calling delete for such object will cause problems.

All frame, view, document (if m_bAutoDelete is TRUE) and control bar (if m_bAutoDestruct is TRUE) are designed to do auto cleanup and delete should not be called.

[urika]

thank u for the answers !
i found my delete problem.
it is my dll so its my responsibility.
i have a dll that runs 4 apps and another dll that news and deletes pointers needed in the first dll.
example :
in order to run an app called map
i do
1. MapInit(..) (allocates pointers)
2. MapView(...) (runs the app)
3.MapClose(..) (deletes the allocations)

this , i think , works fine

However , the dlls are explicitly loaded and when i
do FreeLibrary(hVisual_Dll); Only after i run and close the map app i get an assertion failure _CrtIsValidHeapPointer (for the other three it works great )
any ideas why?
i hope i was understood

[JohnCz]

_CrtIsValidHeapPointer problem most likely indicates that you are using one of the Auto Cleanup classes.
Is it CView derived class? Did you change constructor from protected to public?

[urika]

its CDialog,
i didn't change public/protected
but i loaded the dlls in the contructor...

the problem occurs ONLY if i call the MapClose(...);
(though the MapClose itself runs fine)

[Paul McKenzie]

urika,

You could have corrupted memory anywhere within your application, causing the problem. Unless we have your entire app, there is no way for anyone to pin down exactly what happened in your application. Any memory corruption outside of MapClose() can cause things to go wrong.

This is why if you are dealing with pointers to dynamically allocated memory, you *must* know how to debug these problems, especially when dealing with DLL's, etc. In almost every case, you're the one who will have to figure out what you did wrong. All we can do is give you suggestions (unless you give us the entire code and tell us how to duplicate the problem).

Regards,

Paul McKenzie

[urika]

All we can do is give you suggestions

thats all i hope for.

i just want more experienced programmers to say what may cause the problem.

what does it mean that if i dont call mapclose there is no assertion?

[Paul McKenzie]

Originally posted by urika
thats all i hope for.

i just want more experienced programmers to say what may cause the problem.

what does it mean that if i dont call mapclose there is no assertion?

It means nothing really. All calling MapClose() does is show that you do have a memory bug in your program. If you don't call MapClose, you still have a memory bug in your program. If MapClose supposedly deletes all the dynamic memory that you allocated, then the problem isn't in MapClose. MapClose not working is just a symptom of the problem, and not the cause of the problem.

Inspect the pointers (or at least the data that they point to) to see if they are still valid -- have you done that first step?

Be glad that at least you can generate a crash. Many times, memory related bugs are hidden and are never caught by the programmer until it's too late (the app has been released and customers report a problem, or the big demo for your client crashes suddenly, etc.)

Regards,

Paul McKenzie

[JohnCz]

Originally posted by Paul McKenzie
All we can do is give you suggestions (unless you give us the entire code and tell us how to duplicate the problem).

Could not agree more. There are zillions reasons that may cause your problem.
Suggestions you receive, may even not apply to your problem.

[Paul McKenzie]

Originally posted by JohnCz
Could not agree more. There are zillions reasons that may cause your problem.
Suggestions you receive, may even not apply to your problem.

So true. Unless we get the entire code, problems with dynamic memory allocation, except for the rarest of cases, can only be solved by the programmer with the problem. We can only give suggestions as to what to try, and as you stated, may not apply to the problem. Not good news to new C++ programmers, but that's reality. If you get a memory related bug, and you don't know what to do next, then you're in big trouble.

Regards,

Paul McKenzie

[Mick]

_CrtIsValidHeapPointer is also an indication your using two different versions of the CRT (new in one, delete in the other). Check your versions of the CRT your using under program->settings->c++->use runtime library. Set them to multithreaded debug dll for your debug build and multithread dll for your release build.