5 ms·

"Seriously, it'll be worth it not to learn about manual memory management." This is not true at all and it is a very dangerous suggestion. Automatic Reference

"Seriously, it'll be worth it not to learn about manual memory management." This is not true at all and it is a very dangerous suggestion. Automatic Reference Counting indeed makes memory management an awful lot simpler (often you don't have to do any explicit memory management at all with it) but you still need to learn about it and understand it, otherwise all sorts of bad things will happen like memory leaks due to circular references (delegates come to mind) and crashes due to the autorelease pool high-water mark eating up all the memory on iOS devices.

AshFurrow 15y ago
I think that if you master UIView and MVC as Apple prescribes it, you learn the conventions you need for proper memory management in ARC. Knowing the conventions is going to suffice. My argument wasn't to go and be naive about memory management. It was to not worry about it right now. Memory management makes the already steep learning curve of Objective-C even steeper, and can scare away newcomers.
- Hisoka 15y ago
  I spent the first month struggling with memory management, and kept being paranoid about "autorelease". Now, I ONLY use autorelease (well in 99% of cases). I don't get why so many people say be careful about autorelease. It makes things so much simpler and prevents mistakes from not releasing after allocating. I wish I learned this much earlier.
  - DrJokepu 15y ago
    Well, be careful with that. A lot of properties in Cocoa and Cocoa Touch are not retained automatically (delegates, data sources and so on). If you just autorelease them you will have problems. The other reason people are careful about autoreleases is because, obviously, objects in the autorelease pool won't get deallocated until the pool is drained, which normally happens in the main application loop. Normally, this is not a problem, but if you do memory-intensive things (like dealing with images or other media) in a loop that means that you will consume a lot of memory before the autorelease pool gets drained. This might get other apps killed (on iOS 4+), and ultimately, yours too.
    - danudey 15y ago
      The other problem with autorelease is when you release too many times; the autorelease pool gets drained down the road, and your app crashes in some other situation (inconsistently) at a time unrelated to when you made the mistake.
  - Aqua_Geek 15y ago
    Autorelease isn't a silver bullet for Obj-C memory management. There are a number of cases in which you would NOT want to autorelease objects - tight loops, for example. If you're already in the habit of autoreleasing everything you +alloc, why not just release it when you're done with it instead?
    - Hisoka 15y ago
      because like I said it's easy to forget when to do that. Example UIView* view = [[UIView alloc] init]; ...do a bunch of stuff [view release] <-- you have to remember this vs. UIView* view = [[[UIView alloc] init] autorelease]; Of course I know about the cases where we have tight loops,w hich is why i said 99 of the time.
      - marcomonteiro 15y ago
        Personally I only use autorelease when I create an object I'm not responsible for. For example, if I create a view somewhere for another object to utilize. I also like knowing that as soon as I'm done with an object that it gets killed and the system can reclaim the memory.
  - bignoggins 15y ago
    when you autorelease, the reference goes into an autorelease pool that is drained later. So you will likely end up using much more memory than you need to. Since iOS runs on memory constrained devices, this could mean the difference between running smoothly and crashing due to memory warnings all the time.
SeoxyS 15y ago
Even if you're going to use a technology to avoid dealing with manual memory management, it's critical to learn it anyway. It's such a fundamental and important part of Cocoa development, not only because of how important it is to making efficient apps, and to not crashing, but also because you need to understand concepts and conventions of ownership in Cocoa. You need to know what you're doing when you're casting CoreFoundation and Foundation types. You need to know what a pointer is, know what a dangling pointer is, know how you can pass a pointer to a pointer to get a second return value from a method (`NSError`[1] is a pretty common Cocoa convention). Know what a singleton is. And after you've learned all of this, you can also do some really neat things with Cocoa's dynamic runtime. Things like invocation building using a category and code like this (or similarly, store and queue up actions on the Mac's Undo manager): [[NSInvocation invocationBuilderWithTarget:self] aRandomMethod:arg]; Once you understand memory management, you can start using blocks, and even storing blocks. You need to understand how copying a block retains every object in the stack, and why raw type variables become immutable in a block. Then you can start to really have fun with awesome powerful technologies like Grand Central Dispatch. Also, in Objective-C you should never user the Garbage Collection feature. And Automatic Reference Counting, while awesome, is not production-ready yet. Apple will not approve apps with it yet—I know, I've been rejected for trying to use it in an app. [1]: HN's markdown parsing is a little funky, this is meant to say: NSError**
- AshFurrow 15y ago
  "Also, in Objective-C you should never user the Garbage Collection feature." Why not? On the Mac, the garbage collection process is offloaded to another CPU. Any performance hit is more than made up for the fact that developers probably messed up the retain counts. Memory management is a thing that you have to get perfect or your app will crash. I personally trust ARC or GC more than I trust myself.
  - cpeterso 15y ago
    iOS's Objective-C doesn't support garbage collection. iOS 5 will add support for Automatic Reference Counting, but no real garbage collection. So if you are writing cross-platform Objective-C code that must support iOS devices and Macs, then you can't rely on garbage collection. And if you must support iOS < 5, then you can't rely on Automatic Reference Counting either.
sambeau 15y ago
I think saying "very dangerous" is a bit over the top. The worst that will happen is that you might get a circular reference and leak memory. This may (or may not) cause your app to eventually crash.

AshFurrow 15y ago

I think that if you master UIView and MVC as Apple prescribes it, you learn the conventions you need for proper memory management in ARC. Knowing the conventions is going to suffice. My argument wasn't to go and be naive about memory management. It was to not worry about it right now. Memory management makes the already steep learning curve of Objective-C even steeper, and can scare away newcomers.

Hisoka 15y ago
I spent the first month struggling with memory management, and kept being paranoid about "autorelease". Now, I ONLY use autorelease (well in 99% of cases). I don't get why so many people say be careful about autorelease. It makes things so much simpler and prevents mistakes from not releasing after allocating. I wish I learned this much earlier.
- DrJokepu 15y ago
  Well, be careful with that. A lot of properties in Cocoa and Cocoa Touch are not retained automatically (delegates, data sources and so on). If you just autorelease them you will have problems. The other reason people are careful about autoreleases is because, obviously, objects in the autorelease pool won't get deallocated until the pool is drained, which normally happens in the main application loop. Normally, this is not a problem, but if you do memory-intensive things (like dealing with images or other media) in a loop that means that you will consume a lot of memory before the autorelease pool gets drained. This might get other apps killed (on iOS 4+), and ultimately, yours too.
  - danudey 15y ago
    The other problem with autorelease is when you release too many times; the autorelease pool gets drained down the road, and your app crashes in some other situation (inconsistently) at a time unrelated to when you made the mistake.
- Aqua_Geek 15y ago
  Autorelease isn't a silver bullet for Obj-C memory management. There are a number of cases in which you would NOT want to autorelease objects - tight loops, for example. If you're already in the habit of autoreleasing everything you +alloc, why not just release it when you're done with it instead?
  - Hisoka 15y ago
    because like I said it's easy to forget when to do that. Example UIView* view = [[UIView alloc] init]; ...do a bunch of stuff [view release] <-- you have to remember this vs. UIView* view = [[[UIView alloc] init] autorelease]; Of course I know about the cases where we have tight loops,w hich is why i said 99 of the time.
    - marcomonteiro 15y ago
      Personally I only use autorelease when I create an object I'm not responsible for. For example, if I create a view somewhere for another object to utilize. I also like knowing that as soon as I'm done with an object that it gets killed and the system can reclaim the memory.
- bignoggins 15y ago
  when you autorelease, the reference goes into an autorelease pool that is drained later. So you will likely end up using much more memory than you need to. Since iOS runs on memory constrained devices, this could mean the difference between running smoothly and crashing due to memory warnings all the time.

SeoxyS 15y ago

Even if you're going to use a technology to avoid dealing with manual memory management, it's critical to learn it anyway. It's such a fundamental and important part of Cocoa development, not only because of how important it is to making efficient apps, and to not crashing, but also because you need to understand concepts and conventions of ownership in Cocoa. You need to know what you're doing when you're casting CoreFoundation and Foundation types. You need to know what a pointer is, know what a dangling pointer is, know how you can pass a pointer to a pointer to get a second return value from a method (`NSError`[1] is a pretty common Cocoa convention). Know what a singleton is. And after you've learned all of this, you can also do some really neat things with Cocoa's dynamic runtime. Things like invocation building using a category and code like this (or similarly, store and queue up actions on the Mac's Undo manager): [[NSInvocation invocationBuilderWithTarget:self] aRandomMethod:arg]; Once you understand memory management, you can start using blocks, and even storing blocks. You need to understand how copying a block retains every object in the stack, and why raw type variables become immutable in a block. Then you can start to really have fun with awesome powerful technologies like Grand Central Dispatch. Also, in Objective-C you should never user the Garbage Collection feature. And Automatic Reference Counting, while awesome, is not production-ready yet. Apple will not approve apps with it yet—I know, I've been rejected for trying to use it in an app. [1]: HN's markdown parsing is a little funky, this is meant to say: NSError**

AshFurrow 15y ago
"Also, in Objective-C you should never user the Garbage Collection feature." Why not? On the Mac, the garbage collection process is offloaded to another CPU. Any performance hit is more than made up for the fact that developers probably messed up the retain counts. Memory management is a thing that you have to get perfect or your app will crash. I personally trust ARC or GC more than I trust myself.
- cpeterso 15y ago
  iOS's Objective-C doesn't support garbage collection. iOS 5 will add support for Automatic Reference Counting, but no real garbage collection. So if you are writing cross-platform Objective-C code that must support iOS devices and Macs, then you can't rely on garbage collection. And if you must support iOS < 5, then you can't rely on Automatic Reference Counting either.

sambeau 15y ago

I think saying "very dangerous" is a bit over the top. The worst that will happen is that you might get a circular reference and leak memory. This may (or may not) cause your app to eventually crash.