|
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. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
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
|
|
|
|
|
As Roger indicated, you should read the article by Joseph M. Newcomer. By relying on WM_APP or WM_USER, you run the risk of clashing (trust me when I say it happens all too easy when you start using a number of user defined messages  )
Message Management[^]
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Hi,
I have four threads in my application and want to show some log messages from each of them into a common list box owned by application.
I want that
Thread#1 always show its log message into row #1 of listbox
Thread#2 always show its log message into row #2 of listbox
Thread#3 always show its log message into row #3 of listbox
and so on ...
Is it possible, if yes then how, and if no then what could be the alternate way.
Waiting for your replies.
Best regards.
Cyber Friend
|
|
|
|
|
Cyber Friend wrote: Is it possible
Yes.
Cyber Friend wrote: if yes then how
Not that easy. Better would be to have one list box for each thread, living near each other. That way you do not have to mess up with columns.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
Rage wrote: Not that easy. Better would be to have one list box for each thread, living near each other. That way you do not have to mess up with columns.
Not that easy neither: you cannot update the listbox from another thread. You better send a message to the GUI thread with the string in it. Otherwise, you'll have problems.
|
|
|
|
|
Cedric Moonen wrote: you cannot update the listbox from another thread
Never said you can ! I just realized that he was actually asking for synchronization help rather than simply listbox handling.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
Have each thread Post a WM_USER* message to the main thread. Trap this message and update the list accordingly.
|
|
|
|
|
Hi,
Thanx for reply.
I will try this method.
Best regards.
Cyber Friend
|
|
|
|
|
Have each secondary thread post a message to the primary thread. In that message, set WPARAM to a value indicating which thread the message is from. That way, you can call InsertString() with an appropriate index value.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
