//creates memory leak
self.editMyObject = [[MyObject alloc] init];
//does not create memory leak
MyObject *temp = [[MyObject alloc] init];
self.editMyObject = temp;
[temp release];
The first line of code creates a memory leak, even if you do [self.editMyObject release] in the class's dealloc method. self.editMyObject is of type MyObject. The second line incurs no memory leak. Is the first line just incorrect or is there a way to free the memory?
The correct behavior depends on the declaration of the editMyObject @property. Assuming it is delcared as
@property (retain) id editMyObject; //id may be replaced by a more specific type
or
@property (copy) id editMyObject;
then assignment via self.editMyObject =
retains or copies the assigned object. Since [[MyObject alloc] init]
returns a retained object, that you as the caller own, you have an extra retain of the MyObject instance and it will therefore leak unless it there is a matching release (as in the second block). I would suggest you read the Memory Management Programming Guide[2].
Your second code block is correct, assuming the property is declared as described above.
p.s. You should not use [self.editMyObject release]
in a -dealloc
method. You should call [editMyObject release]
(assuming the ivar backing the @property is called editMyObject
). Calling the accessor (via self.editMyObject
is safe for @synthesized accessors, but if an overriden accessor relies on object state (which may not be valid at the calling location in -dealloc
or causes other side-effects, you have a bug by calling the accessor.
[2] Object ownership rules in Cocoa are very simple: if you call a method that has alloc
, or copy
in its signature (or use +[NSObject new]
which is basically equivalent to [[NSObject alloc] init]
), then you "own" the object that is returned and you must balance your acquisition of ownership with a release
. In all other cases, you do not own the object returned from a method. If you want to keep it, you must take ownership with a retain
, and later release ownership with a release
.
Your property is declared "retain" meaning that it the passed in object is automatically retained.
Because your object already had a reference count of one from alloc/init there's then two references and I'm assuming only one release (in your destructor).
Basically the call to self.editMyObject is really doing this;
-(void) setEditMyObject:(MyObject*)obj
{
if (editMyObject)
{
[editMyObject release];
editMyObject = nil;
}
editMyObject = [obj retain];
}
By convention in Cocoa and Cocoa-touch, any object created using [[SomeClass alloc] initX]
or [SomeClass newX]
is created with a retain count of one. You are responsible for calling [someClassInstance release]
when you're done with your new instance, typically in your dealloc
method.
Where this gets tricky is when you assign your new object to a property instead of an instance variable. Most properties are defined as retain
or copy
, which means they either increment the object's retain count when set, or make a copy of the object, leaving the original untouched.
In your example, you probably have this in your .h
file:
@property (retain) MyObject *editMyObject;
So in your first example:
// (2) property setter increments retain count to 2
self.editMyObject =
// (1) new object created with retain count of 1
[[MyObject alloc] init];
// oops! retain count is now 2
When you create your new instance of MyObject
using alloc
/init
, it has a retain count of one. When you assign the new instance to self.editMyObject
, you're actually calling the -setEditMyObject:
method that the compiler creates for you when you @synthesize editMyObject
. When the compiler sees self.editMyObject = x
, it replaces it with [self setEditMyObject: x]
.
In your second example:
MyObject *temp = [[MyObject alloc] init];
// (1) new object created with retain count of 1
self.editMyObject = temp;
// (2) equivalent to [self setEditMyObject: temp];
// increments retain count to 2
[temp release];
// (3) decrements retain count to 1
you hold on to your new object long enough to release it, so the retain count is balanced (assuming you release it in your dealloc
method).
See also Cocoa strategy for pointer/memory management
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With