macOS Memory Management

[Blakeasd]

Hello,
What is the difference between

[myObject release];

and

self.myObject = nil;

and

[myObject dealloc];

Is it true that they all do the same thing? Is there an appropriate time to use each one?

 

[robbieduncan]

Is it true that they all do the same thing?

No, they all do different things, although if you are operating under the garbage collected runtime at least 2 may have similar effects.

 

[gnasher729]

3. Read the documentation of dealloc. It is very, very clear about when you, and not Cocoa, should call dealloc. Would be nice if you posted exactly when you should call dealloc, so we know you learned it. Once you've read that, it is very obvious whether [myObject dealloc] is the same as the others or not.

2. Seems that myObject is a property for an object. The property can be declared as "assign", "copy", or "retain". Please read the documentation, then you can post _exactly_ what self.myobject = nil will do in each of the three cases.

1. Once you've done this, the answer to your question is very clear, and better yet, you've understood it.

 

[chown33]

Is there an appropriate time to use each one?

The appropriate time to use [myObject dealloc] is never.
http://developer.apple.com/library/...mmRules.html#//apple_ref/doc/uid/20000994-SW2

Important: You should never invoke another object’s dealloc method directly.​

Read the entire Memory Management Guide. The fundamental rule is ownership. If you understand ownership, all the rest flows naturally from that.
http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/MemoryMgmt/

 

[jiminaus]

The fundamental rule is ownership.

I just wanted to add a salient point here which I feel people often look past. I feel when people see ownership, they think in terms of sole ownership (like C++ STL's auto_ptr). But it's actually in terms of shared ownership. Multiple objects can own another object at the same time. It's only after all owners have released their ownership that the runtime will send dealloc to the owned object.

 

[Blakeasd]

Ok, so I understand now when I need to release an object in the
-(void)dealloc: method, and I know now that I don't typically need to call dealloc on an object. I am still fuzzy though on setting an object equal to nil verses calling release on it.

 

[jiminaus]

Ok, so I understand now when I need to release an object in the
-(void)dealloc: method, and I know now that I don't typically need to call dealloc on an object. I am still fuzzy though on setting an object equal to nil verses calling release on it.

Are you confused because of the different ways you've seen of implementing dealloc?

For example, this:

- (void)dealloc
{
   [propA release];
   [propB release];
   [super dealloc];
}

verses:

- (void)dealloc
{
   self.propA = nil;
   self.propB = nil;
   [super dealloc];
}

 

[Blakeasd]

Yes.

 

[Madd the Sane]

If you are using Objective-C 2.0, both will eventually do the same thing.

self.object1 = nil;

will call

- (void)setObject1:(id)value {
if(object1 =! value)
{
[object1 release];
[value retain];
object1 = value
}
}

If you put value as nil, it can't be retained since it's nothing, and the original object will be deallocated.

 

[gnasher729]

If you are using Objective-C 2.0, both will eventually do the same thing.

self.object1 = nil;

will call

- (void)setObject1:(id)value {
if(object1 =! value)
{
[object1 release];
[value retain];
object1 = value
}
}

If you put value as nil, it can't be retained since it's nothing, and the original object will be deallocated.

Is your property declared as assign, retain, or copy? In two out of three cases what you wrote is completely wrong. (In the third case, properties are atomic unless you request otherwise, and your code isn't).

 

[Madd the Sane]

Is your property declared as assign, retain, or copy? In two out of three cases what you wrote is completely wrong. (In the third case, properties are atomic unless you request otherwise, and your code isn't).

The main reason for the code was for demonstration purposes. I didn't take into account the other Objective-C 2.0 declarations.

 

[jiminaus]

@Blakeasd As you now know, properties have (or should have) different behaviours, determined by the property's attributes.

For retain and copy properties, in dealloc, [prop release] and self.prop = nil are equivalent (sort of, more later). This is because, as Madd the Sane pointed out, a side-effect of assigning nil to a property is that the previously assigned object will be sent release.

For assign properties, in dealloc, [prop release] and self.prop = nil are not equivalent. This is because the property is declared to simply assign the pointer and to neither send release to the old object nor retain/copy to the new object.

But for assign properties, it would be dubious to send release. The implied semantics of an assign property is that the relationship is not that of ownership, but of association. Because there's no ownership, no release should be sent.


So why the two styles? There are pros and cons for each, of course, otherwise we'd all do the same.

An advantage of assigning nil via properties is that you can consistently assign nil to all your properties and get the correct memory-management. Retain and copy properties will be correctly released, and assign properties will simply be nilled.

The disadvantage of assigning nil via properties is that there's potential for a lot to happen when setting a property. By the time an object is sent dealloc by the runtime, it is in a potentially semi-dead state. Now consider what else can happen when a property is set. If there are any other objects observing this object, they will be notified of the property change. This causes outside code to be called and that is to be avoided in dealloc. Why? The outside code might send messages to this partially dealloc'ed object. It might retain the object, causing the partially dealloc'ed object it to resurrected.


By the way, I haven't talked about undeclared properties. Undeclared properties (the major of Cocoa) doesn't have @property but simply declares the getter and setter messages. You have to read the class reference to determine if it is equivalent to an assign, retain or copy declared property. Sometimes this information is in the setter, sometimes it's in the getter, sometimes it's in description at the start of the class reference.

 

[chown33]

Fundamentally, properties represent accessor methods.
Objective-C Language Guide : Declared Properties

The Objective-C declared properties feature provides a simple way to declare and implement an object’s accessor methods. [underline added]
​

There's much more about properties, so I recommend reading the entire section.


To understand properties, one must first understand exactly what an instance variable is, in order to distinguish it from a method.
Defining a Class : Class Interface
Again, I recommend reading the entire section.