-
April 2nd, 2004, 12:09 PM
#1
How to make sure if a pointer is still good
Guys,
I have 'A' dialog, which creates multiple modeless 'B' dialogs. I use GetDesktopWindow() as 'B' dialogs' parent for some reason.
'A' dialog saves pointers of 'B' dialogs to a CArray in order to do something when user closes 'A' dialog.
User can delete 'B' dialogs at any time before closing 'A' dialog. Since 'A' is not B's parent, I don't know how to notify 'A' dialog to remove the pointer from CArray if user deletes any of the 'B' dialogs.
However, so far, program works fine without any problems.
My question is
1) If user deleted a 'B' dialog, but its pointer still exists in 'A' dialogs' CArray. When 'A' dialog loops though CArray and got that pointer and use that to call some functions on B dialogs, will it cause any problems?
2) How do I make sure if the pointers on CArray are still good to use?
Any suggestions or comments are welcome,
Thanks,
Nitti
-
April 2nd, 2004, 12:14 PM
#2
1) Yes it will cause problems
2) You can not "Make sure a pointer is still good"
Look at approaches such as smart pointers, reference counted objects, notifications...There are dozens of ways to approach this issue.
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
2008, 2009,2010
In theory, there is no difference between theory and practice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
-
April 2nd, 2004, 01:09 PM
#3
Originally posted by TheCPUWizard
Look at approaches such as smart pointers, reference counted objects, notifications...There are dozens of ways to approach this issue.
Thank you very much for your reply. I'll do some research on those subjects you listed.
If I use TRY CATCH to wrap around the code when 'A' dialog loop through those pointers and simply just ignore any pointers that raises an exception, will it work? If yes, what exception should I catch?
Thanks,
Nitti
-
April 2nd, 2004, 01:30 PM
#4
Originally posted by NittiLin
Thank you very much for your reply. I'll do some research on those subjects you listed.
If I use TRY CATCH to wrap around the code when 'A' dialog loop through those pointers and simply just ignore any pointers that raises an exception, will it work? If yes, what exception should I catch?
Thanks,
Nitti
Dereferncing invalid memory causes a crash, not an exception to be thrown.
If A creates the Bs, it ought to be trivial to let the Bs know about A, then call A from inside their EndDialog function to let A know they're not valid any more.
-
April 2nd, 2004, 01:38 PM
#5
Originally posted by GCDEF
Dereferncing invalid memory causes a crash, not an exception to be thrown.
No. It will throw an exception.
Jeff
-
April 2nd, 2004, 01:50 PM
#6
Originally quoted by NittiLin
I have 'A' dialog, which creates multiple modeless 'B' dialogs. I use GetDesktopWindow() as 'B' dialogs' parent for some reason.
Why not make the 'B' dialogs members of 'A'. Use
Code:
B * BDlg1;
B * BDlg2;
...etc...
To declare the the 'B' dialogs in 'A'. Then in constructor for 'A' allocate memory for the 'B' dialogs.
Code:
BDlg1=new B;
BDlg2=new B;
and in the destructor for 'A' free the memory used by the 'B's.
Code:
delete BDlg1;
delete BDlg2;
That way whenever 'A' is a valid dialog all of the pointers to the 'B's are valid. Use Create to display the 'B' dialogs and DestroyWindow when you want to close them. The result would be that the data members in all 'B' dialogs will always be available after 'A's constructor has been called and before 'A's destructor is called. The pointers to 'B' would be valid whether the 'B' dialog was visible or not.
Just an alternative to trying to keep track of the pointers in an array. It uses a little bit more memory but is less likely to crash.
TDM
-
April 2nd, 2004, 02:24 PM
#7
Originally posted by jfaust
No. It will throw an exception.
Jeff
You're correct. I was thinking of catching a CException, which doesn't work. Catching ... does.
-
April 2nd, 2004, 03:43 PM
#8
Originally posted by TDM
Why not make the 'B' dialogs members of 'A'. Use
Code:
B * BDlg1;
B * BDlg2;
...etc...
I can't do it that way because I don't know how many B dialogs user will create. That's why I save the pointers to a CArray.
Thanks,
Nitti
-
April 2nd, 2004, 03:47 PM
#9
Originally posted by jfaust
No. It will throw an exception.
I'll add TRY CATCH code block to make sure if any pointers are no longer available.
Thanks,
Nitti
-
April 2nd, 2004, 03:51 PM
#10
No. This is a bad choice and a serious misuse of exception handling. This is not the right answer. Have pity on all the future maintainers of your code and do the right thing--a little research.
Jeff
-
April 2nd, 2004, 04:11 PM
#11
Originally posted by NittiLin
I'll add TRY CATCH code block to make sure if any pointers are no longer available.
Thanks,
Nitti
What you're saying is "my code is messed up, but I'll let the exception handling bail me out". This is definitely an abuse of exception handling.
Regards,
Paul McKenzie
-
April 2nd, 2004, 04:21 PM
#12
Originally quoted by
I can't do it that way because I don't know how many B dialogs user will create.
That sounds like a strange design. Have you considered an MDI application?
TDM
-
April 2nd, 2004, 04:22 PM
#13
what is with the IsBadStrPtr, IsBadReadPtr and IsBadWritePtr functions?
I always use them to determinate if a pointer is still good or not.
-
April 2nd, 2004, 04:33 PM
#14
They only check to see if the pointer is invalid. Consider the following simple case.
Allocate 10000 objects of the same type.
Get a pointer to item number 1234.
Delete the array of objects.
Create a new array of 3000 objects
[making some BIG assumptions on memory allocation]
Your pointer is still "valid" but now it points into the newly created array, not at the original object.
IMPORTANT: DO NOT EVERY COUNT ON THIS. IT IS MERELY TO EXPLAIN A POINT.
Most of the (is valid pointers) simply check if the pointer points to:
1) A valid memory location
2) The start of a memory allocation unit
3) The start of a memory allocation unit of the correct size.
Which of the above it does depends on the function, see the docs.
There is ABSOLUTELY no way to (generically) tell if a (raw) pointer still points to the actual instance of a certain object that is was originally assigned to.
TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
2008, 2009,2010
In theory, there is no difference between theory and practice; in practice there is.
* Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
* How NOT to post a question here
* Of course you read this carefully before you posted
* Need homework help? Read this first
-
April 2nd, 2004, 05:46 PM
#15
Originally posted by jfaust
No. This is a bad choice and a serious misuse of exception handling. This is not the right answer. Have pity on all the future maintainers of your code and do the right thing--a little research.
Yes, I'm testing the program with and without catch exception. In the same time, I am doing research on "smart pointers, reference counted objects, notifications" like TheCPUWizard suggested.
Originally posted by Paul McKenzie
What you're saying is "my code is messed up, but I'll let the exception handling bail me out". This is definitely an abuse of exception handling.
Thank you Paul. I'm still doing research on how to solve my problems.
Originally posted by TDM
That sounds like a strange design. Have you considered an MDI application?
MDI doesn't fit in this project because B dialogs should be able to be visible even if 'A' dialog is hidden and stays in System Tray.
Thank you very much. You guys are so nice giving me so many suggestions. I'm still doing research on this issue.
Nitti
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|