Re: reasonable way of avoiding using autorelase?
Re: reasonable way of avoiding using autorelase?
- Subject: Re: reasonable way of avoiding using autorelase?
- From: Nicholas Riley <email@hidden>
- Date: Fri, 28 Mar 2003 09:14:30 -0600
- Mail-followup-to: Ben Dougall <email@hidden>, email@hidden
On Fri, Mar 28, 2003 at 02:30:18PM +0000, Ben Dougall wrote:
>
just learning obj-c/cocoa. on memory management:
>
>
this example that's given as an incorrect way of setting up a method to
>
return a reference to an object:
>
>
-(NSObject *)eCancer
>
{
>
NSObject *result = [[NSObject alloc] init];
>
return result;
>
}
>
>
i understand what the problem is here. you're initialising and
>
allocating an object (retain count=1), then you're returning it's
>
reference/pointer to another object (retain count will now be 2, if
>
that object retains it as it should if it's going to use it) but only
>
one object needs the new object instance. and autorelease is the way to
>
handle this as it's a temporary way for the above method to retain the
>
object pointed to by result.
Exactly. And often, the callee won't retain the object either, if it
only needs to use it briefly. If it doesn't, then it doesn't need to
do anything explicitly beyond simply using the object.
>
alternatively to autoreleasing, would having the object that asks for
>
and recieves this object reference, just not retain it, be a way of
>
doing it? and use the above object's retain for/in the calling object?
>
seems like a simple, possible short cut to me. i get the feeling that
>
using an autorelease is slightly more inefficient than not using an
>
autorelease. also autoreleases are not to be used if multithreading
>
right?
CF uses this technique, as do a lot of non-garbage-collecting object
systems. It's just more inconvenient, cumbersome, and potentially
buggy, because you have to remember to explicitly release the object
later. C++'s ability to declare objects statically helps a lot,
because they'll automatically be deleted when they go out of scope,
but Objective-C has no such thing and you'd have to carefully make
sure that the object would be released on every path (including
exceptions) out of your code. Of course I guess you could use some
kind of smart pointer with Objective-C++ to do this, but that'd be
additional overhead every time you tried to access the object, as
opposed to the additional overhead on autorelease and (typically)
every time through the runloop with NSAutoreleasePool. There is no
free lunch.
In some cases you may want to do the above, but normal accessors don't
behave this way by convention. Some methods are named 'retainedXXX'
to indicate that the object they're returning is already retained, for
efficiency.
--
=Nicholas Riley <email@hidden> | <
http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.