Re: Memory management question
Re: Memory management question
- Subject: Re: Memory management question
- From: Alastair Houghton <email@hidden>
- Date: Wed, 24 Mar 2004 19:14:55 +0000
On 24 Mar 2004, at 17:40, Randall Meadows wrote:
>
I need to see if I "get" ObjC's memory management scheme yet:
>
>
I have a method that returns an autoreleased NSString*; in an instance
>
of a class I store that returned value in an ivar; I then store that
>
class instance in an NSArray.
>
>
Putting the class instance into the array increases its (the class
>
instance) refcount, right? What about the refcount of the NSString
>
ivar contained in that class? Not touched, right? I have to
>
explicitly retain/release that, correct? What's the easiest way to
>
managed that--"retain" in my setter method and override "-dealloc" in
>
my class and release the NSString* ivar there?
Yes, although you need to be careful in your setter to remember to
-release the existing ivar---remember, BTW, that it's harmless sending
messages to nil, so something simple like:
- (void)setStringValue:(NSString *)string
{
[string retain];
[myString release];
myString = string;
}
will work just fine (although it obviously isn't thread-safe).
Incidentally, for strings and other objects with mutable forms, you
might consider whether you really want
- (void)setStringValue:(NSString *)string
{
string = [string copy];
[myString release];
myString = string;
}
For immutable objects, -copy tends to be implemented as a -retain, but
for mutable objects it will ensure that you get a snapshot of the
object's value, rather than something that might be changed outside the
control of your object.
The other thing to note is that it's possible to slip-up if you don't
think carefully about the order of your -retain and -release; consider
the case where someone writes
[myObject setStringValue:[myObject stringValue]];
if we had written
- (void)setStringValue:(NSString *)string
{
[myString release];
myString = [string retain];
}
then the call above would cause a crash because the object in "string"
has been released (by the [myString release]) more times than it has
been retained and has therefore been deallocated.
(You might think that nobody will ever write a call like the one above,
but remember that the pointer to your string might be stored by other
objects, especially as -copy just does a -retain for immutable string
objects. It's actually quite easy for you to end-up being passed the
same pointer you've already got.)
>
What about something like:
>
>
line = [line stringByTrimmingCharactersInSet:...];
>
>
where line is also an autoreleased NSString*? Since the "line" on the
>
RHS is already in an autorelease pool, it'll get released when the
>
pool does its thing, right? And then the new value assigned to the
>
lvalue "line" gets autoreleased (eventually), right?
If the object in line is already autoreleased, then yes, there is no
leak here.
>
At 12:40 PM -0500 3/24/04, Randall Meadows wrote:
>
>
> line = [line stringByTrimmingCharactersInSet:...];
>
>
I now notice that NSMutableString has setString: available. Would it
>
be more efficient to do
>
>
[[line setString:[line stringByTrimmingCharactersInSet:...];
>
>
instead of creating a new object each time?
No. You're still creating just as many objects, but now you've got a
string copy operation as well. If you're worried about too many
objects floating around, you can always use additional autorelease
pools to clean them up as and when necessary. Alternatively, you can
immediately release any individual autoreleased object by doing
[[someObject retain] release];
(The -retain increments the reference count, removing it from the
autorelease pool, then the -release triggers the deallocation of the
object.)
BTW, if I were you, I'd write your program before worrying that you're
creating too many objects; unless there's some really obvious area
where it's going to cause trouble (e.g. you have a loop that goes
around ten million times, creating four autoreleased strings per
iteration), then you shouldn't worry about creating temporary objects
too much until you get to the optimisation stage.
Take a look at my FAQ if you haven't already, as it gives a few hints
on memory allocation. It's here:
http://www.alastairs-place.net/cocoa/faq.txt
It does sound like you've grasped the basics, though.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.