On Feb 16, 2014, at 5:27 AM, Kevin Meaney <k...@yvs.eu.com> wrote: > Is the only reason for interoperability with manual retain-release code?
For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. > It seems that it creates an unnecessary complication when thinking about > memory management. Now I'm assuming that any method like: > NSString *expandedPath = [myPath stringByExpandingTildeInPath]; > returns an autoreleased string so I need to know this if I'm doing this with > lots of strings and that I need to put my own autorelease pool in place, > something I wouldn't have to think about if it wasn't an autoreleased object. You don't just need to consider whether methods you call return autoreleased objects (and as Roland pointed out, it's not always clear whether a returned object really has been autoreleased or not.) You also need to consider whether the method you called caused objects to be autoreleased as part of the work it did. That is, you might call "[[FooController alloc] init]", which doesn't return an autoreleased object, but perhaps the -init method did a bunch of work that involved autoreleasing objects. In that case your call to that method would still add a bunch of objects to the autorelease pool. You can't tell by looking at the declaration. In practice, I add @autoreleasepool blocks by considering whether I'm writing a loop that will have a lot of iterations and whose body involves method calls that are likely to allocate memory. Then I also look at memory usage over time in the Instruments app and watch for spikes, and look for issues (on iOS) where the app triggers a low-memory notification during some activity. "Likely to allocate memory" is weaselly, I know. It's an educated guess. But you don't have to guess perfectly. An unnecessary @autoreleasepool is unlikely to add noticeable (unless you go overboard with them), and if you leave one out where you need one, you'll probably notice during testing. It's part of the kind of memory/performance tuning you'll be doing anyway later in development. —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
