Re: reasonable way of avoiding using autorelase?
Re: reasonable way of avoiding using autorelase?
- Subject: Re: reasonable way of avoiding using autorelase?
- From: Joe Osborn <email@hidden>
- Date: Fri, 28 Mar 2003 14:27:43 -0600
just learning obj-c/cocoa. on memory management:
A lot of people struggle a bit with memory management-- don't let it
get to you. ^_^
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.
Right, exactly. It should be autoreleased, since that's the
contract--the only methods that confer 'ownership' of an object are
-retain, -copy, +alloc, and +new. (New is a shortcut for alloc]
init].) If you receive an object from any other method, it is not
'yours' until you take ownership of it.
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.
+new is just this shortcut. it's not used much, though. it's not
'noisy' to add the autorelease, most cocoa coders will just scan over
it.
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?
Really, there isn't much of a hit for -autorelease. I can give you a
99.999% guarantee that the bottleneck in your code won't be due to
-autorelease. See
http://www.c2.com/cgi/wiki?OptimizationRules.
I'm pretty sure there's nothing wrong with autoreleasing for
multithreading--see the documentation for +[NSThread
detachNewThreadSelector:toTarget:withObject:]. "...The method[
specified by] aSelector is responsible for setting up an autorelease
pool for the newly detached thread and freeing that pool before it
exits...." using
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
Most of the useful Cocoa methods use autorelease. I don't do much with
multiple threads, but it'd be crippling if autorelease were verboten.
i also get the feeling there must be a problem with this idea, but i'm
not sure what, if there is one? is it just a practical problem of
whichever object requests and gets the object instance needs to know
not to retain it itself, whereas usually it's supposed to?
Yeah, that's it. It doesn't fit the conventions, it 'breaks the
rules', and it confuses people. It violates the "Principle of Least
Astonishment" and causes bad karma. (: Please just stick to the normal
conventions for memory management, it'll make your code easier to read.
Now, I never really got confused on this memory management stuff, but
I'm totally spoiled by Smalltalk's garbage-collection. I love just
being able to reassign stuff and forget about it. But this is
Cocoa-Dev, not Wish-I-Were-Coding-Smalltalk-Dev. ^.^
--joe
"I really hate this damn machine
I wish that they would sell it
It never does quite what I want
But only what I tell it". -- Anonymous
_______________________________________________
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.