On 16 Feb, 2014, at 9:27 pm, Kevin Meaney <k...@yvs.eu.com> wrote: > I've realized that my understanding of ARC is not as good as I thought it > was. So I'll be asking couple of questions. > > With ARC I don't understand why autorelease pools are needed anymore except > for with objects passed by reference. What I mean by that is that class > methods like: > > NSString *myString = [NSString stringWithFormat:@"%@", @"my string"]; > > Why do these methods need to return an autoreleased object, why can't they > behave the same as: > > NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String];
Where did you determine that the first of those returns an autoreleased object and does not, in fact, behave as the second? Where is it documented that [ NSString stringWithFormat:.. ] under ARC returns an autoreleased object? > > Is the only reason for interoperability with manual retain-release code? perhaps - the whole document about ARC is here http://clang.llvm.org/docs/AutomaticReferenceCounting.html, it only says that autorelease pools can exist and that the syntax for them has been tightened up into a real scope. It mentioned a couple of conditions in which it may use them and introduces some qualifiers which force objects into them but nowhere do I see anything which says they are definitely used in any given situation. There are several places it says you may not assume that an object is in an autorelease pool. > > 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. > Documentation doesn't provide any information as to which methods return an > autoreleased object or not. before ARC it was pretty much a given a method like that returned an autoreleased object, now it may or may not return one, so you're no worse off than you were before and are possibly better off. The usual advice is to do the simplest thing and if you have memory issues, go hunt them down with Instruments. And also assume that Debug and Release will do entirely different things. > > But since I can't call autorelease myself in ARC code if I have a method > like. > > KMImage *bigImage = [image kmImageByDoublingSize]; > > I'm not returning an autoreleased object so there is a difference in > behaviour between the behaviour of methods in apple frameworks and the ones > outside of those frameworks. I don't think you can know whether or not you are returning an autoreleased object in that case. I'm assuming that method does the obvious thing from the name, creates a double-sized image and returns it. Whether ARC retains it across the return for you or puts it on an autorelease pool, you don't know, how ARC chooses to keep the object valid across the return boundary is not defined by the ARC spec. It might be either but you shouldn't have to care. > > I've read a couple of posts on stackoverflow StackOverflow has a reasonably high noise to signal ratio. I'm pleased you posted here because Greg Parker is going to correct everything I wrote and explain it properly. The usual advice I think still stands. If you create lots of temporary objects in a loop, check for memory issues and put an autorelease pool in there if you have issues. If you don't have issues, let the compiler do the job for you. > > Kevin _______________________________________________ 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
