• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: memory management
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory management


  • Subject: Re: memory management
  • From: Ken Thomases <email@hidden>
  • Date: Sat, 26 Jul 2008 20:00:03 -0500

On Jul 26, 2008, at 6:44 PM, Daniel Richman wrote:

I just finished reading the docs on memory management and want to make sure I got everything right (for non-GC apps):

1) Any object returned by new, alloc, copy or any derivates (mutableCopy, etc.) is 'yours.' You must release/autorelease it yourself.

2) Objects not returned by any of the above methods were previously sent autorelease by their class.

It is not necessarily true that the object has been sent - autorelease. Whether it has or not is an implementation detail that's irrelevant to you as a caller. The only important point is that the object's lifetime is not in your hands. It is not your responsibility to release it (unless of course you retain it). If you need to ensure that the lifetime is longer, you should retain it as in your (b)(ii), below. Beyond that, don't try to think about whether it has been sent autorelease or not. Just think about your responsibilities.


Since autorelease will release the objects after the event loop is finished,

a) you may use the object as a temporary thing for the remainder of the event loop, including returning it to calling methods
b) if you want to use the object sometime after the current event loop, you should either i) copy it (which makes you responsible for the new object, which has a retain count of 1, or ii) send it retain. In both cases, you are responsible for properly releasing/ autoreleasing the objects however many times you retained them. If you used method i), you must also remember to send it release/ autorelease again since it came to you with a retain count of 1.

The above is a pretty good description of the conventions. Keep your eye out for the (few) places in the framework that document exceptions to the conventions.


For example, the objects obtained from collections are not guaranteed to live for the remainder of the event loop. If the collection itself is deallocated, or if the collection is mutable and the object is removed from it, then the object may have a shorter lifetime.


Now let us suppose that I have a class Foo with instance variables V1 and V2 (ints). If I were to create a class method:

+ (Foo *)fooWithV1:(int)a V2:(int)b {

Foo *newFoo = [[Foo alloc] init];
[newFoo setV1:a];
[newFoo setV2:b];

return newFoo;
}

then I should also put, just before [return newFoo];, [newFoo autorelease];.

I know this is convention. Should I not try to meddle with this, or may I not send the message [newFoo autorelease] if I note this clearly in the docs (this is a quite simple class that just stores two variables; it's intended for use only by the app it's in)?

Conventions and guidelines are just that. They aren't hard and fast rules. However, you should generally have good reason to deviate from them. I can't think of why you'd want to in this case. The object being simple doesn't seem to have any bearing, in my mind.


Cheers,
Ken
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >memory management (From: Daniel Richman <email@hidden>)

  • Prev by Date: highlighted table column in nib
  • Next by Date: Binding NSArrayController's objects to an NSTextView
  • Previous by thread: Re: memory management
  • Next by thread: Re: Decoding digital POCSAG / analog 5-tone (=selective call) sounds
  • Index(es):
    • Date
    • Thread