On Feb 16, 2014, at 10:22, Kevin Meaney <k...@yvs.eu.com> wrote: > > On 16 Feb 2014, at 17:06, Jens Alfke <j...@mooseyard.com> wrote: > >> 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. > > I didn't say take them out. I said why do they need to return an autoreleased > object.
Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code. > Why can't they just return an object like alloc init... does. It can, if both the implementation and the caller are ARC > I think Roland's main point is to ask do they return an autoreleased object. > I foolishly assumed they did because a modified version of autorelease was > kept with the transition to ARC and my most common experience of dealing with > autoreleased objects was via the behaviour of the class methods that create > objects. So yes a foolish assumption on my behalf. > >>> 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. > > You're missing the question I was trying to ask. Why is autorelease needed at > all? If we don't have autorelease then it is precisely clear whether a > returned object is autoreleased or not. Something we don't even have to > consider. We don't have to worry about whether further down the stack > autoreleased objects have been created or not and that in certain situations > up the stack we need to add in a autorelease pool. > > I've read through some of the clang documentation Roland referred to, much of > it over my head. I did note that there was some discussion over making sure > that objects remain alive over the return boundary and in some cases > autorelease was used for this purpose. But I'm still failing to grasp why, if > autorelease is being used in some cases for making sure an object remains > alive over a return boundary that means there are other ways of dealing with > making sure an object remains alive over the return boundary, do we need > autorelease? If both sides of the boundary are ARC, and the calling code immediately retains the returned value (as is usually the case), then the autorelease can be skipped (and actually is at runtime; the runtime is smart enough to actually inspect the stack to see whether or not the autorelease is necessary, and if it isnt, it actually skips the autorelease and the following retain). > I just feel like I'm missing something. The people at Apple or Clang have > decided that keeping autorelease is necessary and I'm struggling to > understand why when it seems to me it adds unnecessary complexity. Not major > but just another thing that can go wrong if you dont think about it, and so > you have to think about it and that takes mental resources away from the job > at hand. Keeping autorelease is necessary because without it, there would be no way of maintaining the memory management contract across both ARC and non-ARC code. _______________________________________________ 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
