|
Hello comunity
i use many times in my project "new" to create an object, in my case this is own class derived from
CObject! So, how to cleany the heap properly??
I hope that is my question is easy to understand?!
What ist different between this two my samples:
CMyClass* pMyClass = new CMyClass();
delete pMyClass;
CMyClass* pMyClass = new CMyClass();
pMyClass = NULL;
delete pMyClass;
thanks in advance
break;
|
|
|
|
|
break; wrote:
CMyClass* pMyClass = new CMyClass();
pMyClass = NULL;
delete pMyClass;
This won't work: you will first set the adress to a NULL pointer and then try to free the memory at this adress, which will fail (logical, because the memory at address 0x0000 was not allocated). You should first delete the pointed memory and then set your pointer to NULL to specify that the pointer doesn't point to a valid memory.
|
|
|
|
|
Thanks very much!
break;
|
|
|
|
|
Cedric Moonen wrote: This won't work:
As a minor technicality, it will WORK, but it won't work as expected. That is, there is nothing syntatically wrong with the code. deleting a null pointer is perfectly valid (and does nothing), but the code will have a memory leak since the memory allocated will never be deallocated.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Yes, that's what I wanted to say. Ok, it wasn't very clear :p. I know that you can delete a NULL pointer but this will simply be ignored (thus leaving a memory leak).
|
|
|
|
|
what were you thinking of when you wrote this ?
delete needs an adress to clean !! (the address which new returned when allocated the memory).
if you assign the pointer variable BEFORE delete ing, delete will try to free the memory at address 0 -> bug
but NULL ing after the delete is the thing to do...!
|
|
|
|
|
toxcct wrote: delete will try to free the memory at address 0 -> bug
That part isn't really a bug; the memory leak is, though. There is nothing wrong with deleting a null pointer.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
i was making it easy for the guy...
|
|
|
|
|
The two lines at the bottom must change places, otherwise you'll get a runtime error when trying to delete the NULL pointer.
The what-about-this-line -line is considered best practice because you will be able to check the pointer if it equals NULL.
Always NULLify pointers that are not used after freeing up their memory to be able to tell if the memory has been freed or not.
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998 "...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Roger Stoltz wrote: The two lines at the bottom must change places, otherwise you'll get a runtime error when trying to delete the NULL pointer.
Incorrect. There will be a memory leak, but there is no runtime exception in the code as written.
delete NULL;
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Yeah!
I was waiting for your post since I saw you lecturing crusade.
Seriously Zac, where can that be found in the C/C++ specs?
Isn't this an unspecified behaviour?
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998 "...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Roger Stoltz wrote: Seriously Zac, where can that be found in the C/C++ specs?
Isn't this an unspecified behaviour?
I gave you a link to the CPP FAQ. If you want the spec, you'd have to buy it (~$30US) so I obviously can't provide you a direct link to the line in the spec. You can either google it yourself, read "Effective C++" by Scott Meyers, buy the standard, read the FAQ, or take my word for it that the standard states that deleting a NULL pointer is both defined and does nothing.
Sorry, I forgot the link I provided was from a site using frames. Here is the link to directly answer your question:
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.8
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Roger Stoltz wrote: Seriously Zac, where can that be found in the C/C++ specs?
Isn't this an unspecified behaviour?
Per Stroustrup's book:
The effect of applying delete to a pointer not obtained from the new operator without a placement specification is undefined and usually harmful. Deleting a pointer with the value zero, however, is guaranteed to be harmless.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
In my opinion, in the second case:
pMyClass = NULL;
delete pMyClass;
you will not receive any run-time error, since deleting of null pointer is not an error (delete simply does nothing).
But in this case your object, allocated with new , will remain unused in the heap memory, producing "memory leak".
Therefore, the correct way is:
delete pMyClass;
pMyClass = NULL;
If you are familiar with STL, you can also consider this approach:
std::auto_ptr< CMyClass > pMyClass(new CMyClass);
I this case the de-allocation will be performed automatically.
I hope this helps.
|
|
|
|
|
Hello,
thank you for answer, i try to use auto_ptr, but im not familiar with this!!
regards
break;
|
|
|
|
|
break; wrote: i try to use auto_ptr, but im not familiar with this!!
Make sure you read up on auto_ptr if you plan to use it. The assignment of auto_ptr's can cause problems if you don't realize what it is actually doing.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
break; wrote: CMyClass* pMyClass = new CMyClass();
// and later
//
delete pMyClass;
As a general rule, only use the ()'s when you have an argument to pass the constructor. There are cases where using empty ()'s will actually call a function and you will get very different results from what you expect.
CMyClass* pMyClass = new CMyClass;
delete pMyClass;
pMyClass = NULL;
or better yet:
</code>std::tr1::shared_ptr<CMyClass> pMyClass = std::tr1::shared_ptr<CMyClass>(new CMyClass);</code>
Calling delete on a NULL pointer will do nothing to it, but setting the pointer to NULL prior to deleting it will cause a memory leak (bad!).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Hi everyone,
i made already my own WM and it works nice
i made it like this:
In the Grid :
GetParent()->PostMessage(WM_COMMAND, WM_GRID_DOWN);
with a define for this kind of mesage :
#define WM_GRID_DOWN (WM_USER + 1)
and in my View :
ON_COMMAND(WM_GRID_DOWN,On_Grid_Down)
with a function :
afx_msg void On_Grid_Down();
Now, i need to send a message from the Grid to the View with a parameter.
Is there another kind of message?
Thanks a lot !
|
|
|
|
|
What are you doing?
Why are you posting a WM_COMMAND with a self made up UI event and control ID?
Why do I ask these questions???
Here's what MSDN[^] has to say about WM_COMMAND message:
"The WM_COMMAND message is sent when the user selects a command item from a menu, when a control sends a notification message to its parent window, or when an accelerator keystroke is translated."
Furthermore the wParam for WM_COMMAND has two meanings (your made up WM_GRID_DOWN):
it's a concatenation of the notification code and the ID of the control that sends the WM_COMMAND message.
Clearly you have not understood how to use user defined messages.
Your code "works", but it has about a dozen built-in assumptions that you don't seem to know about and it might make a little more sense if you were subclassing a control but I get the impression that it's not what you're doing.
Even if you are subclassing a control, you're not using WM_COMMAND correctly.
Read Joe Newcomer's article[^] on how to use user defined messages.
While you're at it, have a go on his other articles as well. They're outstanding IMHO. Especially how to use worker threads, the one suggested to you by David Crow about a week ago.
Please read those articles! A hundred questions on this forum cannot make up for not getting the concept and we, at least not I, cannot help you if you don't.
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998 "...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
Sorry, but it's quite difficult to learn MFC into 2 month at work.
I don't make "Hello World" Projects from MFC-Books, i learn a basic operation of MFC
and must applic it directly on my big project with all conditions.
And to fall down from C# and JAVA on MFC won't facilitate it.
It's all new for me
|
|
|
|
|
baerten, I apologize if you found my post rude, that was not my intention.
However, I found it strange when you asked about threading a week ago and you were told, rather subtile perhaps, that you had not yet understood the multithreading concept by Michael Dunn, David Crow, myself and others.
The other day you posted again about the same problem suggesting that you did not follow the recommendations you were given and that the concept was still not within your grasp.
Don't get me wrong, we are all children in the beginning and that's allright.
I thought that the response you got earlier was too subtile and that's why I tried to make the message as clear as I could, perhaps I overdid it.
The reason is that I know it can create a lot of unnecessary problems if you go ahead without knowing you're taking the wrong path.
In my opinion I do you a greater favour if I make sure you understand me when I tell you that you're holding the map upside down, instead of telling you to run along and get lost in the forest.:->
At last:
Don't be sorry! Consider it a favour to be able to learn MFC on payed time.
If you're short for time, you cannot spend your precious initial time better than reading the suggested articles on Joe's pages[^].
--
Roger
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"No one remembers a coward!" - Jan Elfström 1998 "...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above
|
|
|
|
|
WM_USER is obsolete so you should use WM_APP instead.
Why dont you use an ON_MESSAGE
#define UWM_TESTMESSAGE (WM_APP + n)
GetParent()->PostMessage(UWM_TESTMESSAGE, WM_GRID_DOWN, lOtherParam);
ON_MESSAGE(UWM_TESTMESSAGE, TestMessage)
afx_msg LRESULT OnTestMessage(WPARAM, LPARAM);
LRESULT CTestView::OnTestMessage(WPARAM wParam, LPARAM lParam)
-- modified at 8:18 Friday 17th November, 2006
|
|
|
|
|
|
baerten wrote:
[...]
Now, i need to send a message from the Grid to the View with a parameter.
I think you can send simple parameters using the third and fourth parameters of PostMessage function. For example:
GetParent()-> PostMessage(WM_COMMAND, WM_GRID_DOWN, (WPARAM)1234, (LPARAM)5678);
In case of longer data, try dynamic allocation:
MyData * data = new MyData(. . .);
GetParent()-> PostMessage(WM_COMMAND, WM_GRID_DOWN, 0, (LPARAM)data);
In this case the receiver should delete the data using delete . Alternatively use SendMessage :
MyData data(. . .);
GetParent()->SendMessage(WM_COMMAND, WM_GRID_DOWN, 0, (LPARAM)&data);
I hope this helps.
|
|
|
|
|
It works already,
thanks nevertheless
|
|
|
|
|