Memory Management

Discussion in 'Mac Programming' started by Blakeasd, Jul 9, 2011.

  1. Blakeasd macrumors 6502a

    Joined:
    Dec 29, 2009
    #1
    Hello,
    What is the difference between
    Code:
    [myObject release];
    
    and

    Code:
    self.myObject = nil;
    
    and

    Code:
    [myObject dealloc];
    
    Is it true that they all do the same thing? Is there an appropriate time to use each one?
     
  2. robbieduncan Moderator emeritus

    robbieduncan

    Joined:
    Jul 24, 2002
    Location:
    London
    #2
    No, they all do different things, although if you are operating under the garbage collected runtime at least 2 may have similar effects.
     
  3. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #3
    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.
     
  4. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    Location:
    Brobdingnag
    #4
    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/
     
  5. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #5
    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.
     
  6. Blakeasd thread starter macrumors 6502a

    Joined:
    Dec 29, 2009
    #6
    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.
     
  7. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #7
    Are you confused because of the different ways you've seen of implementing dealloc?

    For example, this:
    Code:
    - (void)dealloc
    {
       [propA release];
       [propB release];
       [super dealloc];
    }
    verses:
    Code:
    - (void)dealloc
    {
       self.propA = nil;
       self.propB = nil;
       [super dealloc];
    }
     
  8. Blakeasd thread starter macrumors 6502a

    Joined:
    Dec 29, 2009
  9. Madd the Sane macrumors 6502a

    Madd the Sane

    Joined:
    Nov 8, 2010
    Location:
    Utah
    #9
    If you are using Objective-C 2.0, both will eventually do the same thing.
    Code:
    self.object1 = nil;
    will call
    Code:
    - (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.
     
  10. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #10
    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).
     
  11. Madd the Sane macrumors 6502a

    Madd the Sane

    Joined:
    Nov 8, 2010
    Location:
    Utah
    #11
    The main reason for the code was for demonstration purposes. I didn't take into account the other Objective-C 2.0 declarations.
     
  12. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #12
    @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.
     
  13. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    Location:
    Brobdingnag
    #13
    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.
     

Share This Page