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.
Related
This question already has answers here:
To ARC or not to ARC? What are the pros and cons? [closed]
(6 answers)
Closed 8 years ago.
As a newbie to the iOS, i need to know the main differences between ARC and Non-ARC.
Am using X-Code 3.2, so need to know the main feature of ARC that distinguishes against non-ARC ?
any help is appreciated.
Thank you.
Automatic reference counting (ARC) was introduced in the iOS 5 sdk to free Objective-C programmers from having to handle memory management by making memory management the job of the compiler.
When using ARC there is no need for retain and release calls, and not only that in many cases ARC can provide a significant performance increase.
ARC is a feature of the new LLVM 3.0 compiler and it completely does away with the manual memory management that all iOS developers love to hate.
Using ARC in your own projects is extremely simple. You keep programming as usual, except that you no longer call retain, release and autorelease. That’s basically all there is to it.
My suggestion is to use ARC.
For your reference you can read this:-
http://clang.llvm.org/docs/AutomaticReferenceCounting.html
What are the pros and cons of using the ARC in an iOS project?
An ARC program's execution is nearly identical to well written MRC. That is, the behavioral differences are often undetectable because both the order of operations and performance are very close.
If you already know how to implement OS X or iOS apps with manual reference counting (MRC), ARC doesn't really add functionality -- it just allows you to remove reference counting operations from your sources.
If you don't want to learn MRC, then you may want to first try ARC. A lot of people struggle with, or try to ignore common practices of MRC (example: I've introduced a number of objc devs to the static analyzer). If you want to avoid those issues, ARC will allow you to postpone your understanding; you cannot write nontrivial objc programs without understanding reference counting and object lifetimes and relationships, whether MRC, ARC, or GC. ARC and GC simply remove the implementation from your sources and do the right thing in most cases. With ARC and GC, you will still need to give some guidance.
If the program you're developing has rather loose usage of reference counting (e.g. a typical amount of autoreleases), switching to ARC could really improve your program's execution times and peak memory usage.
The simple answer is that in non-ARC projects you have to control almost all memory operations (ownership, release time and etc.) by yourself. On the other hand, in ARC enabled projects most work done by system. More you can read via links that given in comments. If you are newbie then probably you should omit non-ARC projects by now and return later.
I'm reading a book on Objective C, and I was wondering about 2 things:
1.Should I take the time currently to read a whole chapter on memory management since we mostly use ARC?(only asking this question to make sure im managing time properly)
2.If you are doing a really good job on manual management, can you get to better performance than using ARC? (like that your app will work faster)
tnx
You should at least familiarize yourself with the basic concepts of the manual memory management, because ARC uses it under the hood. You need to learn at least about three things: retain, release, and autorelease. This will help you understand discussions about ARC's inner working.
ARC is mostly a compiler trick (with some support from the runtime). You can write less code, but you cannot get better performance from it. Essentially, ARC lets you deal with memory management declaratively, while the manual management uses imperative style. However, both systems call the same methods from the runtime.
1、Of course you should.ARC is based on the same memory management,just let the compiler do the same work.If you want to master a kind of technology，try to know how does it work is a faster way.
2、Actually,they do the same performance.Just let the compiler do what did you do before.For when you retain an object(which is a property) in the class, we always release in the dealloc.you alloc an object in a method,assign to local pointer,it will be release when the stack memory of this method clean up;if you retain it in the method to the method's local variable you release it in the same place.Then you will be find they are all predictable.why not let the machine do it?
I am a new cocoa developer coming from a C#/Java background. I had been introduced to memory management patterns which objective-c language uses and I just find them very helpful for code-conscious development.
Why does Apple now want us to use ARC (Automatic Reference Counting) instead of MRR (Manual Retain-Release) and what advantages other than time saving does ARC offer?
I see such a transition negatively affecting good-citizen habits that developers gain from the obj-c ecosystem.
Nick
It's unfortunate that making it easier for competent developers to be correct has a side effect of making it easier for new developers to not learn, but it seems like it's probably worth it.
ARC is less forgiving than a tracing collector like C# or Java use though. If you don't have a clear object ownership model you will almost certainly create cycles and leak tons of memory. My hope would be that this is made obvious enough (via Instruments? That still requires seeking it out... not sure what could be done here) that new developers will quickly learn to keep their object graph clear and acyclic.
ARC allows me to concentrate on writing useful code instead of boilerplate dealloc methods.
Most people I know have used autorelease behind every alloc anyway, because it saved you a release later and you couldn't forget to actually put it. So the object was around until the autorelease pool was drained, and with ARC the object gets deallocated when it isn't needed anymore. I think in those cases the ARC-compiled program will even use less memory.
And, shame on me, it helps me to make my apps crashing less often too.
That premature release that happens every 10.000 launches. The one that I could never track down completely, hopefully with ARC this is a thing of the past.
I see such a transition negatively affecting good-citizen habits that developers gain from the obj-c ecosystem.
probably in the same way an embedded developer who started with assembler thinks people that start with C and have never used assembler get into bad habits.
In my opinion the MRR vs ARC discussion is similar.
ARC and C both allow to write more maintainable code in a shorter time.
And both of them can lead to a larger memory and cpu footprint.
If I remember correctly Apple announced that they did add a little speed up to retain and release to compensate that impact on cpu usage. And because of that there is no real reason that MMR is still around.
I, for one, welcome our new ARC overlords.
i've actually rather enjoyed moving to ARC - it's one less thing to think about. on top of that, i think newcomers would often be tripped up by the significance of naming conventions (+alloc, -copy etc vs [NSString stringWith....]). the only tricky bit is when you start dealing with CoreFoundation etc (the C APIs) where you still have to keep in mind just who is owning what.
Looking at the release notes of OS 10.7, there's some stuff about using Automatic Reference counting (ARC) to make memory management simple. I'm about to embark on a new Cocoa project soon and wondered whether it would be worth using the model (the way I understand it, you can't mix between using ARC and not using it)?
The dilemma seems to be using something new versus using something that could potentially save lots of debugging time later. But is that the case? Has anyone played around with it and found no real-world benefit?
Without a doubt you should use ARC. ARC injects the retain release calls at the most appropriate times, so you may actually see lower average memory use than you would if you didn't use ARC.
I have used ARC and it is immensely powerful. You stop having random crashes and your app just feels more responsive. As they said at WWDC, there is no reason not to use Automatic Reference Counting.
Also, you can use non-ARC files in the same project as ARC files.
I agree with FreeAsInBeer about using ARC. However, it should also be made clear that garbage collection (GC) should not be used. It looks like Apple is henceforth going to focus their efforts ARC, while letting GC die a slow death. This is wonderful because ARC is clearly a far superior technology, whereas GC is slow and extremly buggy.
So yes. Use ARC. Stay away from GC.
I've long considered myself a garbage collection snob – despite a secret love for C++, I find myself sneering at developers who actively choose to use languages without (read: missing) garbage collection when they're given the option.
And then I met Objective-C. Wow! Its system of reference counting seems brilliantly simple – I'd even go so far as to say elegant. When developing for OSX, developers are given the option to use a snazzy GC; when developing for iOS, developers are stuck with reference counting.
My question is:
If I am developing an OSX application that could potentially be ported to iOS, is Objective-C's reference counting system time-consuming enough (development-wise and bug-fixing-wise) to warrant ignoring it for the application's first version?
What problems am I likely to run into if I rely on reference counting*, assuming I'm not clever enough to construct any diabolically complex cyclical data structures? With features like autorelease, it all seems so easy, but I know that Apple wouldn't have invested the effort into creating a garbage collector if this were really the case. What should I be on the lookout for?
* I am aware that I can use the garbage collector even if I am throwing around retains and releases (they'll be ignored). However, considering non-GC applications often use RAII, I don't understand how that would work if a generational GC were to "replace" calls to retain and release. Wouldn't resources potentially be released late?
My experience with developing code to port to iOS is that taking GC only code and back porting it to reference counting is a bit tedious and time consuming and potentially error prone. Having said that, as long as you use properties (make them retain even though it makes no difference in GC) as much as possible and you enable the static analyser build phase, it's not too bad. The static analyser will catch most failures to observe the memory management rules. It won't notice if you fail to release an ivar in dealloc, but you can go through and systematically add all the dealloc methods.
Bear in mind that you can't directly port a Mac application to the iPhone, the VC part of MVC has to be completely rewritten, so you could take the approach of writing the Mac UI solely for garbage collection and only make the model classes compatible with both GC and reference counting.