• 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: More memory allocation questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More memory allocation questions


  • Subject: Re: More memory allocation questions
  • From: Marcel Weiher <email@hidden>
  • Date: Sun, 28 Jul 2002 22:43:46 +0200

On Sunday, July 28, 2002, at 10:02 Uhr, Terry Simons wrote:

What exactly is the Apple runtime?

The stuff that has headers in /usr/include/objc/.

They way I see it now:

Most (all?) of the time an NSAutoreleasePool object is set up for you every time your program handles an event.

This is simply part of the Cocoa frameworks.

Autoreleasing an object ( [someObject autorelease] ) does nothing other than add that object to the NSAutoreleasePool object.

Yes.

At the end of the event loop,

Sort of yes, but only because of the above, and only if you don't have any nested pools. It is not a general feature of autorelease pools, just that Cocoa sets up some autorelease pools that way.

any objects in the NSAutoreleasePool object get a "release" message, which decrements their count, and if the count is equal to 0, they are dealloc'd.

Yup. This happens whenever an autorelease pool is deallocated, and Cocoa sets one up for you.

A "retain" to an object will increment the count of an object,

Yes.

so that if they are in the autorelease pool when you get access to them, you can make sure they stay around until you're done with them.

This has nothing to do with autorelease pools. Please don't make it more complicated than necessary.

You want to keep it, you send it retain. That's it.

(Unless someone mistakenly sends more release/autorelease messages than they should to that object).

Yup. That condition is known as a bug ;-)

If you retain an object, then you should release/autorelease it.

You should release it at some time. (Autoreleasing is nothing more than releasing a little later).

It seems that you should always use autorelease,

No.

unless you are 100% certain that nobody else is using a specified object, then release may be preferable because it will free up resources immediately.

No. If someone else is using that object, they should have retained it. Autorellease doesn't come into play. There are two levels that are getting mixed up here:

Level 1:

retain / releave -> dealloc

Level 2:

autorelease -> a later release


The first level turns a global problem (when can this object be deallocated / when does it have no more references ) into a local one ( do *I* reference this object ).

The second level deals with the "transfer ownership to another object without losing the object in transit"-problem.


If you don't alloc/init an object, you shouldn't release it.

If you don't: +alloc, -copy, -retain an object. -init doesn't play a part.

If you don't autorelease/release objects that you create with alloc/init then you'll leak memory.

If you don't release. Autorelease is just a release that happens later.

How's that?

Better :-)

Marcel

--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: More memory allocation questions
      • From: Terry Simons <email@hidden>
    • Re: More memory allocation questions
      • From: Shawn Erickson <email@hidden>
References: 
 >More memory allocation questions (From: Terry Simons <email@hidden>)

  • Prev by Date: Re: More memory allocation questions
  • Next by Date: Re: More memory allocation questions
  • Previous by thread: Re: More memory allocation questions
  • Next by thread: Re: More memory allocation questions
  • Index(es):
    • Date
    • Thread