Clang has new feature called ARC. Concept looks cool. Is this feature support detecting cycles?
ARC has support for weak references. If one of the references in a cycle is a weak reference, this will allow the cycle to be properly released. See this post by Chris Lattner from Apple:
[ARC introduces] zeroing weak references, which are like assign properties in their cycle breaking ability but a lot safer since they can't dangle.
Nope... ARC is only for automating retain and release - nothing else... I'm pretty sure Instruments has a tool for this - at least in 4.1/4.2
Related
I'm re-reading "Transitioning to ARC Release Notes" now.
In the beginning, it says
ARC is supported in Xcode 4.2 for OS X v10.6 and v10.7 (64-bit
applications) and for iOS 4 and iOS 5. Weak references are not
supported in OS X v10.6 and iOS 4.
Why is this? Is implementing weak reference require deep down platform/OS support?
I thought, weak reference is not that special (considering C++ raw pointer usages).
Could it be not a technical reason? (weak reference support is dropped because it failed a few test cases and they don't have enough time?)
Weak references are self-zeroing. They are set to nil immediately before the object pointed to starts its dealloc and any attempt to assign an object that is in the middle of deallocating to a weak reference raises an exception. The runtime therefore needs to be able to store an addition mapping: from objects to any weak references to that object. iOS 4 did not implement that table.
The main implementation difference between them and C++'s weak_ptr is that there's no conversion step, as per the conversion to a shared_ptr. The niling is pushed, not pulled. The references can just be loaded as regular pointers at the machine level.
Part of the reason that the Objective-C runtime had to be extended to handle this is that Objective-C objects generally can't live on the stack. So tracking them automatically requires greater conspiracy between compiler and runtime. Unlike the STL, you wouldn't have seen ARC appear first as a third-party solution.
In practice it's just a few extra C calls that aren't implemented. The compiler support being in place, you can implement them yourself if you really want and support weak references under iOS 4 and earlier. Mike Ash did. Apple's decision was likely as much to do with its general attitude towards backward support for development technologies: it'd rather everyone use the latest.
Weak properties are 'Zeroing Weak References', meaning that when the object is deallocated, all weak references to that object are automatically nil. The changes to the Objective C runtime necessary to make this work were not introduced until iOS5. ARC was allowed to work in iOS4 using unsafe_unretained in place of weak, which can become dangling pointers if the object they are pointing at is ever released.
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.
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
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).
Supposedly weak is like assign or unsafe_unretained, except that a weak variable is "zeroed" when the object that it points to is dealloc'ed. But ARC is handled by the compiler, so why is weak not supported on iOS 4 and Mac OS X 10.6?
(for this question please don't give a guess as an answer, but something more supported by facts/reference/docs)
Since __weak requires zeroing out one or more pointers in places other than the current object, additional data structures are required to keep track of weak references. This is in contrast to __strong, __unsafe_unretained, and __autoreleasing, which do not require additional tracking. The tracking structures and programs for manipulating them are built into the OS; the compiler inserts the code to perform the calls, but the OS support needs to be there in order for the compiled code to work.
__weak references require runtime support which isn't available on the older iOS versions.
There is no technical reason why 10.6 could not support weak references, and indeed there is at least one third-party implementation available (e.g. this one). Apple decided to support ARC but without weak references. I doubt anybody who knows the actual reason Apple made that choice is allowed to post it on stackoverflow... so all you can do is speculate.
my app is developed with ARC disabled from the beginning, now i decided to take advantage of ARC techniques, when i try to convert the project to ARC i keep getting errors wherever release autorelease methods are exist, does that mean i have to dig into my project and get rid of any methods related to memory management? thanks
Yes, you are not allowed to use release, retain, or autorelease in ARC code. If it's too much of a hassle, you can disable ARC on a per-file basis as described here: How can I disable ARC for a single file in a project?
There are a lot of good references on the web that deal with automatic reference counting, e.g.
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
or
http://www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
According to Apple's ARC Documentation, there are a fairly significant number of changes to the way that one develops software when using ARC.
As a complete beginner to Objective-C, would it be better to start off with ARC disabled, with the idea that it would give me a better low-level understanding of what is going on behind the scenes? Or has ARC essentially deprecated the 'old way' of doing things, to the point that it's not really worth spending time learning?
This is basically an opinion question, and is therefore fairly dangerous.
My Opinion is a qualified yes. It is worth learning basic memory management. The qualification being don't get bogged down in it. Learn what ARC is doing for you under the hood with some very simple projects. Once you have a basic understanding of how to handle memory management, i.e. how to avoid retain cycles(as jemmons alluded to they can still be a problem with ARC).
Once you have a basic grasp of memory management. Start using ARC.
Also as Jason Coco pointed out ARC handles memory management for (to put it simply) NSObject subclasses. So all of the CF Objects you will still be handling yourself, if you need to use them.
An excellent explanation about what ARC is doing for you under the hood can be found in the WWDC2011 Session 323 - Introducing Automatic Reference Counting.
But there are some other considerations that might steer your decision.
What devices do you need to target?
If you plan to target iOS 4.3 and up ARC effectively handles memory management for you.(of NSObject subclasses)
If you plan to target iOS 4.2 then you will not be able to use weak references(you will use unsafe_unretained). iPhone 3g? & iPod touch 2nd gen are stuck at this OS level, because there are many of these devices still in service many developers are still targeting them.
If you plan to target iOSs earlier than 4.2(This would be rare) you will definitely need to learn MRC(Manual Reference Counting).
If you plan to build Mac Apps, there is a garbage collector available on that platform. ARC is also an option(full ARC 10.7, no weak support 10.6).
It's worth noting that ARC is checked by default when you start a new project in Xcode. This is as good a sign as any that the old retain/release way of doing things is deprecated and Apple sees ARC as the future. Your first lesson as a new ObjC developer might be that it never pays to swim up-stream against Apple.
Also, while it's fairly easy to convert old retain/release samples to ARC (for the most part, just drop any retains, releases, and autoreleases), the inverse is not true. And I've already seen a lot of sample code cropping up that's written ARC-style. So as someone just starting out, it'd pay more to learn the ARC way.
Note this doesn't mean you don't have to understand reference counting. It's still an important part of an object's life cycle and you still need to be aware of such things (if only to know when to use weak or strong references). But when it comes time to write code, write it with ARC on.
The "old" style is simply just reference counting to manage your object's lifetime. There's not really all that much too it, but it can be error-prone and cause all kinds of grief. If you're just starting, I'd personally suggest you just learn to program using ARC. You'll still get to deal with reference counting when you need to use the C-library objects, like CoreFoundation or CoreGraphics.
Apple itself recommends ARC for new projects.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html#//apple_ref/doc/uid/10000011i
read point 2 in At a Glance
There is sooo much more interesting to learn in Objective C & iOS apart from the memory management.
My advice : Don't bother about MRR
It would be a great idea just to go over it and understand what's going on, but for development it's not essential, and as you can see most if not all developers have moved their deployment targets to iOS 5.0+, so you are likely not to develop under manual reference counting.
However if you plan to use non ROP -retainable object pointers- in your code like CFStringRef, you might want to really look at non ARC so you can understand things like bridge, because you can combine ARC and non ARC code in one project.