2

I am struggling in iOS (4) with allocating objects in one scope and releasing it in another scope. I am using properties as pointers to the objects. The object is allocated and initialized in one instance class method and I release it in the class’ dealloc method. The properties are declared with retain. Besides having problems with using properties likes this I also find it cumbersome to alloc and initialize the object and set the property. 

NSObject *object = [[NSObject alloc] init];
Self.myProperty = object;
[object release];

I tried 

self.myObject = [[NSObject alloc] init];

However that gave me a memory leak.

My question: Do I have to make this temporary object or is there a more elegant way of doing this?

A followup question: Do I have to both set the property to nil and release the autogenerated ivar?

[self setMyProperty:nil], [myProperty release];

When XCode 4 generates property stubs for you it puts [self setMyProperty:nil] in viewDidUnload and [_myProperty release] in dealloc.

jv42
  • 8,521
  • 5
  • 40
  • 64
Kai Friis
  • 75
  • 1
  • 7
  • assignment to nil is unnecessary. – Dancreek Jun 09 '11 at 14:36
  • Meaning I should just release the ivars and forget about the properties? I don't mean to be hostile or anything; it’s only the way that Apple handles properties is a bit strange to me. Trying to figure out how to handle properties the iOS way. – Kai Friis Jun 09 '11 at 18:45

2 Answers2

2

First question:

autorelease is your friend:

self.myObject = [[[NSObject alloc] init] autorelease];

Second question:

No, it's redundant, but harmless since the second operation will do nothing ([nil release] is safe). I'd advise using the self.XXX = nil; construct, as it's safer and very clear/readable.

jv42
  • 8,521
  • 5
  • 40
  • 64
  • Thanks, I will give autorelease a shot. While programming the iPhone I’ve read numerous posts warning against using autorelease. So many that I’ve almost forgotten it exists. This is probably on place it is fine to use it. Second answer, thought so. – Kai Friis Jun 09 '11 at 18:34
  • Tested autorelease, no leaks. I'm going for this one, it's the one that best fits my use of properties in my other world. – Kai Friis Jun 09 '11 at 19:04
  • be sure that you do your release before assigning nil! If you assign nil first then your release goes to a nil object and not to the object that needs to be released. – Dancreek Jun 09 '11 at 19:20
  • 1
    @Dancreek: not true. If you do `self.property = nil;` if does call release on the member variable. – jv42 Jun 10 '11 at 08:12
1

The self. notation is running through the synthesized setter which does a retain, which is why you need to do the autorelease on the init object. Conversely, you could leave off the self. and just use

myObject = [[NSObject alloc] init;

This line just sets the myObject pointer to the retained object, and you would not have any leak.

Here was my question from a while back along the same lines as yours:

MKReverseGeocoder autorelease/release question in Apple's CurrentAddress sample

Community
  • 1
  • 1
BP.
  • 10,033
  • 4
  • 34
  • 53
  • 1
    I’ve been thinking along the same lines. However as far as I can tell Apple encourage you in its documentation to use properties. In my book, if you use properties, you do not touch the ivars. What’s the point with properties if you bypass the setter? This is exactly what is confusing me. It dos not fit into my former cognitive model. – Kai Friis Jun 09 '11 at 18:29