How to make sure if a pointer is still good
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 25

Thread: How to make sure if a pointer is still good

  1. #1
    Join Date
    Mar 2004
    Location
    Phoenix, AZ
    Posts
    15

    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

  2. #2
    Join Date
    Mar 2002
    Location
    NY, USA
    Posts
    12,097
    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
    In theory, there is no difference between theory and paractice; 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

  3. #3
    Join Date
    Mar 2004
    Location
    Phoenix, AZ
    Posts
    15
    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

  4. #4
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,131
    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.

  5. #5
    Join Date
    Mar 2002
    Location
    California
    Posts
    1,582
    Originally posted by GCDEF
    Dereferncing invalid memory causes a crash, not an exception to be thrown.
    No. It will throw an exception.

    Jeff

  6. #6
    Join Date
    Jan 2004
    Location
    Earth
    Posts
    567
    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

  7. #7
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,131
    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.

  8. #8
    Join Date
    Mar 2004
    Location
    Phoenix, AZ
    Posts
    15
    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

  9. #9
    Join Date
    Mar 2004
    Location
    Phoenix, AZ
    Posts
    15
    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

  10. #10
    Join Date
    Mar 2002
    Location
    California
    Posts
    1,582
    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

  11. #11
    Join Date
    Apr 1999
    Posts
    27,434
    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

  12. #12
    Join Date
    Jan 2004
    Location
    Earth
    Posts
    567
    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

  13. #13
    Join Date
    Mar 2004
    Location
    (Upper-) Austria
    Posts
    2,899
    what is with the IsBadStrPtr, IsBadReadPtr and IsBadWritePtr functions?
    I always use them to determinate if a pointer is still good or not.
    I am not offering technical guidiance via email or IM
    Come on share your photo with us! CG members photo album!
    Use the Code Tags!

  14. #14
    Join Date
    Mar 2002
    Location
    NY, USA
    Posts
    12,097
    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
    In theory, there is no difference between theory and paractice; 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

  15. #15
    Join Date
    Mar 2004
    Location
    Phoenix, AZ
    Posts
    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

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center