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
[1117 byte] By [
NittiLin] at [2007-11-18 18:39:22]
# 1 Re: How to make sure if a pointer is still good
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.
# 2 Re: How to make sure if a pointer is still good
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
# 3 Re: How to make sure if a pointer is still good
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.
GCDEF at 2007-11-11 1:22:24 >
# 4 Re: How to make sure if a pointer is still good
Originally posted by GCDEF
Dereferncing invalid memory causes a crash, not an exception to be thrown.
No. It will throw an exception.
Jeff
jfaust at 2007-11-11 1:23:25 >
# 5 Re: How to make sure if a pointer is still good
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
B * BDlg1;
B * BDlg2;
...etc...
To declare the the 'B' dialogs in 'A'. Then in constructor for 'A' allocate memory for the 'B' dialogs.
BDlg1=new B;
BDlg2=new B;
and in the destructor for 'A' free the memory used by the 'B's.
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
TDM at 2007-11-11 1:24:24 >
# 6 Re: How to make sure if a pointer is still good
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.
GCDEF at 2007-11-11 1:25:29 >
# 7 Re: How to make sure if a pointer is still good
Originally posted by TDM
Why not make the 'B' dialogs members of 'A'. Use
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
# 8 Re: How to make sure if a pointer is still good
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
# 9 Re: How to make sure if a pointer is still good
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
jfaust at 2007-11-11 1:28:33 >
# 10 Re: How to make sure if a pointer is still good
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
# 11 Re: How to make sure if a pointer is still good
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
TDM at 2007-11-11 1:30:37 >
# 12 Re: How to make sure if a pointer is still good
what is with the IsBadStrPtr, IsBadReadPtr and IsBadWritePtr functions?
I always use them to determinate if a pointer is still good or not. :(
NoHero at 2007-11-11 1:31:35 >
# 13 Re: How to make sure if a pointer is still good
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.
# 14 Re: How to make sure if a pointer is still good
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
# 15 Re: How to make sure if a pointer is still good
Originally posted by TheCPUWizard
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.
Yeah, that's what I'm worring about. System might reallocate memory and some pointers might point to an address that is using by other application.
Thanks,
Nitti
# 16 Re: How to make sure if a pointer is still good
When you create your 'B' dialogs, use SetOwner() to set a back pointer to the 'A' dialog, then in the B's OnDestroy() send a message to its owner, passing B's HWND or ID, and have 'A' remove it from its list.
# 17 Re: How to make sure if a pointer is still good
One thought would be to use a linked list. Each "node" in the list would be a a class derived from CDialog ('B' dialog). The "head" of the list would be in the 'A' class. Have a member in the 'B' dialog class that points to the next dialog in the list. Also have some type of identifier in the 'B' class to identify each node in the list (could just be an int). When you create the dialogs add a new node to the list ( a new B dialog) and assign it an identifier. When you destroy the dialog, go through the list and remove node matching the identifier that was destroyed. That way your list would only contain dialogs that are actually visible and would allow as many dialogs as the system resources would allow.
TDM
TDM at 2007-11-11 1:36:36 >
# 18 Re: How to make sure if a pointer is still good
Originally posted by NittiLin
Yeah, that's what I'm worring about. System might reallocate memory and some pointers might point to an address that is using by other application.
Thanks,
Nitti
Well that can not happen. If you are at the application level, then
you can not (in theory) corrupt other applications.
I would use reference counted smart pointers, as has been
mentioned. There are so many ways to handle this problem.
If Dialog A will definitely exist for the life of the modeless dialogs
then just pass a pointer to it into the constructor for the modeless
dialogs, then you don't have to worry about owner/parent etc..
# 19 Re: How to make sure if a pointer is still good
I also would not use a CArray or linked list. I would instead use
a std::map and have dialog A generate keys when modeless
dialogs are created. The modeless dialog can then use this key and the pointer to dialog A to be removed from the map when it
is closed.
# 20 Re: How to make sure if a pointer is still good
Originally posted by NittiLin
I have 'A' dialog, which creates multiple modeless 'B' dialogs. I use GetDesktopWindow() as 'B' dialogs' parent for some reason. Just out of curiosity - what is the reason ?? Why can't the 'A' dialog be the parent? You could still use GetDeskTopWindow() for whatever you need to use it for...
John E at 2007-11-11 1:39:47 >
# 21 Re: How to make sure if a pointer is still good
Originally posted by souldog
Well that can not happen. If you are at the application level, then
you can not (in theory) corrupt other applications.
I would use reference counted smart pointers, as has been
mentioned. There are so many ways to handle this problem.
If Dialog A will definitely exist for the life of the modeless dialogs
then just pass a pointer to it into the constructor for the modeless
dialogs, then you don't have to worry about owner/parent etc..
So far, program still doesn't have any problems although the testing is still going on. Dialog A does exist for the life time of all the modeless dialogs.
Originally posted by souldog
I also would not use a CArray or linked list. I would instead use
a std::map and have dialog A generate keys when modeless
dialogs are created. The modeless dialog can then use this key and the pointer to dialog A to be removed from the map when it
is closed.
Thanks for the advise. I've never thought of this before. I'll do some research on it.
Thanks,
Nitti
# 22 Re: How to make sure if a pointer is still good
Originally posted by John E
Just out of curiosity - what is the reason ?? Why can't the 'A' dialog be the parent? You could still use GetDeskTopWindow() for whatever you need to use it for...
I want dialog A to be top most only. If dialog A is the parent of all the dialog B, when I bring dialog A to topmost, all the dialog B will be on topmost as well. This is the reason that I can't use dialog A to be the parent of dialog B.
Thanks,
Nitti
# 23 Re: How to make sure if a pointer is still good
Originally posted by TDM
One thought would be to use a linked list. Each "node" in the list would be a a class derived from CDialog ('B' dialog). The "head" of the list would be in the 'A' class. Have a member in the 'B' dialog class that points to the next dialog in the list. Also have some type of identifier in the 'B' class to identify each node in the list (could just be an int). When you create the dialogs add a new node to the list ( a new B dialog) and assign it an identifier. When you destroy the dialog, go through the list and remove node matching the identifier that was destroyed. That way your list would only contain dialogs that are actually visible and would allow as many dialogs as the system resources would allow.
TDM
I use CArray to do the similar thing. Since souldog suggested me not to use CArray, I'm gonne check out the way he suggested.
Thanks,
Nitti
# 24 Re: How to make sure if a pointer is still good
Originally posted by VladimirF
When you create your 'B' dialogs, use SetOwner() to set a back pointer to the 'A' dialog, then in the B's OnDestroy() send a message to its owner, passing B's HWND or ID, and have 'A' remove it from its list.
Good ideas. Thanks a lot. I'll check it out.
Thanks,
Nitti
