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

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

Originally posted by GCDEF
Dereferncing invalid memory causes a crash, not an exception to be thrown.

---

No. It will throw an exception.

Jeff

Quote:

---

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

Quote:

---

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.

Quote:

---

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

Quote:

---

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

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

Quote:

---

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

Quote:

---

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

what is with the IsBadStrPtr, IsBadReadPtr and IsBadWritePtr functions?
I always use them to determinate if a pointer is still good or not. :(

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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