When to delete a pointer (C++)...
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
it's impossible to say. is aFunction returning a pointer to a global, or to an object that is it managing somehow ?
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
Don't assume that a pointer you get has been created with
new. Read the code, or documentation, to find out what your responsibilities are. It might have been created withnew, in which case you need to calldeletewhen you are done with it. It might have been created withmalloc(or one of its relatives), in which case you need to callfreewhen you are done with it. It might point to a global or static piece of data, in which case you don't release it. Never assume when it comes to memory management. In this case, it seems likely you do not need to release the pointer, but the only way to be sure is to read up on how it is created and what your responsibilities are. -
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
DanielSheets wrote:
However... When I delete someClass on app exit, the app crashes.
At any point do you reassign or increment
someClasssuch that it points to a different location? For example:SomeClass *someClass = new SomeClass();
someClass++;
delete someClass; // will crash"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
Try deleting the pointer immediately after you receive it. Maybe it's deletetd inbetween and not set to null (bad practice), in which case a second delete would lead to a crash. Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll. On a more general note: Deleting a pointer on app exit doesn't make much sense, except if you need it for the whole lifetime of your application. Typically you should delete it as soon as you don't need it anymore.
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
DanielSheets wrote:
aFunction()
You should have the documentation (or the source code) of
aFunctionin order to know what to do.THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?! -- C++ FQA Lite
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
Thanks for the replies. All of them helped to shed light on the subject for me. This is for a project being done with Qt. The documentation doesn't mention much about it (I couldn't find it anyway). I do have the source code though. Thanks again.
-
Thanks for the replies. All of them helped to shed light on the subject for me. This is for a project being done with Qt. The documentation doesn't mention much about it (I couldn't find it anyway). I do have the source code though. Thanks again.
A pointer is merely an address. In 32-bit Windows, it is a DWORD value. It's not even guaranteed that the address is valid, or that some data exists at that address. A safe way to 'delete' your pointer, is just to assign it a value of zero. That way, you can check first before attempting to use it.
-
Try deleting the pointer immediately after you receive it. Maybe it's deletetd inbetween and not set to null (bad practice), in which case a second delete would lead to a crash. Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll. On a more general note: Deleting a pointer on app exit doesn't make much sense, except if you need it for the whole lifetime of your application. Typically you should delete it as soon as you don't need it anymore.
The good thing about pessimism is, that you are always either right or pleasently surprised.
Freak30 wrote:
Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll.
Actually, if the pointer points to memory allocated in a different DLL, that memory can only be safely deallocated through that DLL! That would be bad design, but maybe the DLL provides some Release function for that purpose.
Freak30 wrote:
On a more general note: Deleting a pointer on app exit doesn't make much sense,
I don't quite agree. Calling delete does more than just free memory. E. g. a the destructor of a file class might be implemented to flush the buffers and close the file properly. Not calling it would cause data loss! Other examples could be objects that stream data to the display or sound card: not closing them down properly may result in nasty artifacts. or think of a web connection to your bank account - do you want to leave it open?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Thanks for the replies. All of them helped to shed light on the subject for me. This is for a project being done with Qt. The documentation doesn't mention much about it (I couldn't find it anyway). I do have the source code though. Thanks again.
Typically, well designed API functions (like those from QT) will not pass pointers to allocated memory and expect you to free it - unless the function is specifically designed to do just that. For the reasons pointed out above, that would be bad design. In such cases, a better design would be to either return a container object by value, or a smart pointer (which, in a way, is also a kind of container), or the caller must pass a buffer to the function to hold the returned data - in which case both the allocation and deallocation are in the responsibility of the caller.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
Be aware that in Qt, you don't always have to delete/free a pointer. When you add widgets, for example, the parent object takes ownership. I suspect that is the case here. (Moreover, you could argue that not freeing memory on exit isn't a leak since the entire process is going away and the applications heap will be deleted.)
-
Thanks for the replies. All of them helped to shed light on the subject for me. This is for a project being done with Qt. The documentation doesn't mention much about it (I couldn't find it anyway). I do have the source code though. Thanks again.
I've found the Qt documentation isn't all that great. The documentation for the MS frameworks is actually surprisingly good in comparison.
-
Freak30 wrote:
Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll.
Actually, if the pointer points to memory allocated in a different DLL, that memory can only be safely deallocated through that DLL! That would be bad design, but maybe the DLL provides some Release function for that purpose.
Freak30 wrote:
On a more general note: Deleting a pointer on app exit doesn't make much sense,
I don't quite agree. Calling delete does more than just free memory. E. g. a the destructor of a file class might be implemented to flush the buffers and close the file properly. Not calling it would cause data loss! Other examples could be objects that stream data to the display or sound card: not closing them down properly may result in nasty artifacts. or think of a web connection to your bank account - do you want to leave it open?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
Freak30 wrote:
On a more general note: Deleting a pointer on app exit doesn't make much sense,
I don't quite agree. Calling delete does more than just free memory. E. g. a the destructor of a file class might be implemented to flush the buffers and close the file properly. Not calling it would cause data loss! Other examples could be objects that stream data to the display or sound card: not closing them down properly may result in nasty artifacts. or think of a web connection to your bank account - do you want to leave it open?
You conveniently left the conditional part of my sentence out of the quote. If you e.g. have a text editor application that only allows opening one file at the time and the only way to close the file is by closing the application, of course you need to delete the file object on application exit. But if you had an editor that can keep open multiple files at once and one of the files is closed, would you keep the object for this file active and delete it on application exit? I would delete it as soon as the file is closed. So my intention wasn't to say that you should never delete a pointer on appliaction exit. I wanted to say that it isn't a good idea to keep every pointer and delete all ofthem on application exit.
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
Stefan_Lang wrote:
Freak30 wrote:
On a more general note: Deleting a pointer on app exit doesn't make much sense,
I don't quite agree. Calling delete does more than just free memory. E. g. a the destructor of a file class might be implemented to flush the buffers and close the file properly. Not calling it would cause data loss! Other examples could be objects that stream data to the display or sound card: not closing them down properly may result in nasty artifacts. or think of a web connection to your bank account - do you want to leave it open?
You conveniently left the conditional part of my sentence out of the quote. If you e.g. have a text editor application that only allows opening one file at the time and the only way to close the file is by closing the application, of course you need to delete the file object on application exit. But if you had an editor that can keep open multiple files at once and one of the files is closed, would you keep the object for this file active and delete it on application exit? I would delete it as soon as the file is closed. So my intention wasn't to say that you should never delete a pointer on appliaction exit. I wanted to say that it isn't a good idea to keep every pointer and delete all ofthem on application exit.
The good thing about pessimism is, that you are always either right or pleasently surprised.
My point was different from yours - I was focusing on the misguided perception some people (not you) might have that the whole point of delete is freeing memory. Specifically programmers coming from C and used to malloc/free might not consider it worthwhile deleting every leftover object upon exiting an application because of that. I pointed out why this would be a mistake that could lead to problems beyond the lifetime of the program. I do agree that any object allocated on the heap should be released (with delete) as soon as possible and not be kept around for longer than necessary. That is not what I understood from your statement though. Thanks for the clarification.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
My point was different from yours - I was focusing on the misguided perception some people (not you) might have that the whole point of delete is freeing memory. Specifically programmers coming from C and used to malloc/free might not consider it worthwhile deleting every leftover object upon exiting an application because of that. I pointed out why this would be a mistake that could lead to problems beyond the lifetime of the program. I do agree that any object allocated on the heap should be released (with delete) as soon as possible and not be kept around for longer than necessary. That is not what I understood from your statement though. Thanks for the clarification.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
I pointed out why this would be a mistake that could lead to problems beyond the lifetime of the program.
Yes, great point!
Erik Westermann
-
I know that if you allocate an object on the heap using 'new', it needs to be deleted. But what if it's a function that returns a pointer to an object? For example...
SomeClass *someClass = aFunction(); // aFunction returns a pointer to SomeClass.
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere. However... When I delete someClass on app exit, the app crashes. If I comment out the delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
Hi, I think this may help you to get clarification, please see once. :) class student { int x; public: student() { x=0; } ~student() { cout<<"I am in student destructor\n"; } }; student* fun() { student *s = new student(); return s; } int main() { student *s = fun(); delete s; getchar(); return 0; }