2

I am working on a ARC based project. My project is targeted IOS 4.3. Since there is no weak pointer for the version < IOS 5.0, I have to use unsafe_unretained which may cause dangling pointers.

Now I am thinking, is it really, good option to use ARC with unsafe_unretained? Or should I switch back to manual memory management since my project is targeted IOS 4.3.?

If it is a good option to use ARC in my case, where should I set the unsafe_unretained properties to nil? I have seen people doing it in viewDidUnload, but viewDidUnload is never called in normal scenario. Any help is greatly appreciated.

Nikolai Ruhe
  • 81,520
  • 17
  • 180
  • 200
Raj
  • 1,119
  • 1
  • 15
  • 32

2 Answers2

1

I have to use unsafe_unretained which may cause dangling pointers.

Yes, but in pre-ARC, you also used unretained pointers for weak references, so it is no worse than what you are doing right now anyway.

I will also add that you can use weak while targeting iOS 4.3 if you use the PLWeakCompatibility library: https://github.com/plausiblelabs/PLWeakCompatibility

user102008
  • 30,736
  • 10
  • 83
  • 104
0

Is it really a good option to use ARC [without support for weak]?

Yes. ARC is commonly considered a big advantage in code brevity, readability and reduces the number of memory related bugs. My personal opinion is that this is the main benefit of ARC.

Support for weak is nice and another advantage of ARC (on iOS 5). But sometimes __weak can hide bugs that would pop up immediately with __unsafe_unretained.

In my code whenever I use weak properties or variables I have to think about the consequences. The rest of ARC's memory management on the other hand requires me to think less (which is nice).

Nikolai Ruhe
  • 81,520
  • 17
  • 180
  • 200
  • But as unsafe_unretained may cause dangling pointers , I should set it to nil.I have seen people doing it in viewDidUnload , but viewDidUnload is never called in normal scenario. Where should I set these to nil ? – Raj Nov 07 '12 at 09:24
  • 1
    @Raj That depends very much on what the properties contain and the lifecycle of these contents. It's not possible to answer this in one sentence. But there's not really a change compared to MRC code where you have to care about `assign` properties in the same way. When in doubt, just use `strong` properties. – Nikolai Ruhe Nov 07 '12 at 09:31
  • will unsafe_unretained cause dangling pointers in all the cases ? – Raj Nov 07 '12 at 09:34
  • @Raj Yes, when using `unsafe_unretained` on a property or ivar and the object it points to is deallocated the pointer dangles (which is not necessarily a bad thing). – Nikolai Ruhe Nov 07 '12 at 09:36
  • @Raj No. They carry potential for a crash but they don't leak memory. – Nikolai Ruhe Nov 07 '12 at 11:21
  • is it a good idea to set all the unsafe_unretained pointers to nil in viewDidDisappear? – Raj Nov 08 '12 at 06:23