0

I have implemented a downloader for iOS projects. It accepts requests and, when download has finished, responds to a target by a delegate. It is asynchronous and the target is (obviously) a weak reference so when the download is complete, if the target is no more allocated, I've got a bad_acces. I've resolved adding a method (called when an object that use it is deallocated) that search for the target in all requests and sets it to nil. This is so far from the behavior I wanted (completly independent from other objects: if a download is no more requested it will be cached: it has no method to stop the download but only a priority queue) There is a safe way to know if a pointer still point to a valid memory address?

Shiner
  • 3
  • 1
  • 3
  • 4
    If the reference is `weak` and you're running in ARC then, in theory, the reference should be set to `nil` when the object is deleted. – Hot Licks Jun 27 '12 at 16:49
  • Thanks for the reply: it is still useful. The downloader is part of a non-arc library, but I include it in ARC projects. – Shiner Jun 27 '12 at 16:57
  • weak references don't mean anything outside of ARC do they? And with ARC they're only supported on OS X 10.7 and above, and iOS 5 and above. – bames53 Jun 27 '12 at 16:58
  • Sorry, my fault. I meant "not retained" instead of weak – Shiner Jun 27 '12 at 17:03

3 Answers3

4

In answer to your question, there isn't a good way of knowing that a pointer is still valid (other than zombies, which isn't a production-environment solution, just a test-environment tool). But rather that worrying about "how do I know if this is a dangling pointer or not", you should just not allow dangling pointers from occurring in the first place.

When your downloader was created, you presumably specified a delegate. When the object that is the delegate is going to disappear (e.g. in its dealloc), it should tell the downloader to set its delegate property to nil, thus eliminating the dangling pointer.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • This is the current behavior. Sorry for the silly question, I already figured this was the correct way, but I would like to be able to completely disjoint objects behaviors. Now I know that this is possible only on ARC, Thank you. – Shiner Jun 28 '12 at 07:42
1

Profile your code. Use the Instruments specifically the one the checks for memory leaks. Also, use Analyze to detect the parts that are potentially problematic. Use the different tools, they help a lot in the development.

yoninja
  • 1,952
  • 2
  • 31
  • 39
-1

Just by looking at the location in memory that the pointer is pointing at, there is no safe way to know if it is still pointing to valid memory (without having written your own memory manager).

Why not retain/release the delegate in your code? This would be the proper way to design this. Also, provide methods for users of your code to remove itself from your list of delegates.

OpenUserX03
  • 1,448
  • 2
  • 14
  • 21
  • Thank you for the suggestion. I thought so but not sure.I'm not retainig the delegate beacause of the queue: if there were many tasks (with higher priority) it could be retained for a long time – Shiner Jun 27 '12 at 17:13
  • Dont retain delegates. the chances are that the delegate already retains the delegating object. therefore you would be able to rid yourself of both objects and they would be maintaining each other. and would not dealloc. – The Lazy Coder Jun 27 '12 at 18:12