CODEWITHSUNDEEP
objective-ccocoa
Jay
Jay

Reputation: 20136

Is releasing memory of Objective-c 2.0 properties required?

Something I have been wondering about properties for a while. When you are using properties, do you need to override the release message to ensure the properties are released properties?

i.e. is the following (fictitious) example sufficient?

@interface MyList : NSObject {
NSString* operation;
NSString* link;
}
@property (retain) NSString* operation;
@property (retain) NSString* link;
@end

@implementation MyList
@synthesize operation,link;
@end

Upvotes: 8

Views: 3371

Answers (6)

nstein
nstein

Reputation: 349

In pre-ARC whenever you see new, alloc, retain and copy, whether it is an instance var or a property you must release. In ARC whenever you have a strong variable you must set it to nil. In either case you have to override dealloc().

Upvotes: 0

Philippe Leybaert
Philippe Leybaert

Reputation: 171734

You should always release the backing variables in dealloc:

- (void) dealloc {
   [operation release];
   [link release];

   [super dealloc];
}

Another way:

- (void) dealloc {
   self.operation = nil;
   self.link = nil;

   [super dealloc];
}

That's not the preferred way of releasing the objects, but in case you're using synthesized backing variables, it's the only way to do it.

NOTE: to make it clear why this works, let's look at the synthesized implementation of the setter for link property, and what happens when it is set to nil:

- (void) setLink:(MyClass *) value {
   [value retain]; // calls [nil retain], which does nothing
   [link release]; // releases the backing variable (ivar)
   link = value;   // sets the backing variable (ivar) to nil
}

So the net effect is that it will release the ivar.

Upvotes: 13

Pierre Bernard
Pierre Bernard

Reputation: 3198

The best way to do this is:

- (void)dealloc {
    [operation release], operation = nil;
    [link release], link = nil;

    [super dealloc];
}

It would indeed be more convenient to use the generated setter methods

self.operation = nil;

but that is frowned upon. You don't always know which thread an object is deallocated on. Thus using an accessor may cause problems by triggering KVO notifications.

The catch here is that you need to adapt your dealloc to match the object management policy defined in your @property. E.g. don't go releasing a iVar backing an (assign) property.

Upvotes: 2

Tom Dalling
Tom Dalling

Reputation: 24125

Synthesizing a property only creates getter and setter methods, and therefor won't release the ivar when the object is deallocated. You need to release the ivar yourself.

Upvotes: 1

cocoafan
cocoafan

Reputation: 4894

In non-GC applications, yes. It is usual to assign nil instead of releasing the ivars. My best experience is to release ivars initialized with init and assign nil to properties with retain and copy mode.

In your case I would assign nil

- (void) dealloc {
   self.operation = nil;
   self.link = nil;
   [super dealloc];
}

Upvotes: 3

Lily Ballard
Lily Ballard

Reputation: 185661

No, you override the -dealloc method. And yes, if you don't release your properties (or rather, the backing ivars), you will leak. So in your @implementation here you should have something like

- (void)dealloc {
    [operation release];
    [link release];
    [super dealloc];
}

Upvotes: 1

Related Questions