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

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

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

  2. #17
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,553
    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.
    Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
    Convenience and productivity tools for Microsoft Visual Studio:
    FeinViewer - an integrated GDI objects viewer for Visual C++ Debugger, and more...

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

  4. #19
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    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..
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  5. #20
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    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.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  6. #21
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,262

    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...
    "A problem well stated is a problem half solved. - Charles F. Kettering

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

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

    Re: 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

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

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

Page 2 of 2 FirstFirst 12

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