• 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
real authority on what needs to be released
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

real authority on what needs to be released


  • Subject: real authority on what needs to be released
  • From: James DiPalma <email@hidden>
  • Date: Wed, 11 Sep 2002 12:43:21 -0400

I'm glad I learned Cocoa before this list was available, because reading documentation has made learning Cocoa much easier than trying to divine truth from what gets said on this list.

From: Dean Davis <email@hidden>

Cocoa is nice but fustrating that doesn't seem to be
any real authority on what needs to be released and
when.

What is frustrating is trying to explain to people that they are making it more difficult than it really is. Apple doesn't need to document every single method that returns an object and state, "this method is neither an init method nor a copy method, so it returns an object that is not retained."

If you count real authorities as someone with a legitimate, proven claim to knowing anything about Cocoa, then release/auto-release is clear, has been clear for years, and can be made clear to you too if you read one of these (an incomplete list) "real" authorities:

Apple's Programming Topic: "Memory Management"
Apple's Concepts (within Memory Management): "Object Ownership and Disposoal"
Stepwise's starting point -- http://www.stepwise.com/StartingPoint/Cocoa.html
Memory Management with Cocoa/WebObjects - Manu Iyengar
Very simple rules for memory management in Cocoa - mmalcolm crawford
Hold Me, Use Me, Free Me - Don Yacktman
Books
Cocoa Programming for Mac OS X - Aaron Hillegass
Learning Cocoa - Apple Computer, Inc.
Cocoa Programming - Scott Anguish, Erik M. Buck, Donald A. Yacktman


This statement is in Apple's documentation titled "Object Ownership and Disposal":

"Cocoa ... sets this policy: If you create an object (using alloc or allocWithZone:) or copy an object (using copy, copyWithZone:, mutableCopy, or mutableCopyWithZone:), you alone are responsible for releasing it. If you did not directly create or copy the object, you do not own it and should not release it."

This statement is in Apple's documentation for NSObject look at its release method:

"You send release messages only to objects that you "own." By definition, you own objects that you create using one of the alloc... or copy... methods. These methods return objects with an implicit reference count of one. You also own (or perhaps share ownership in) an object that you send a retain message to because retain increments the object's reference count. Each retain message you send an object should be balanced eventually with a release or autorelease message, so the object can be deallocated."

Please don't blame Cocoa or Apple when people on this list can't get it right. All of the real authorities consistently and simply explain object ownership. No one has an excuse for not understanding it.


From: Dietrich Epp <email@hidden>

Autorelease pools are to free things from methods other than those made with alloc/init.

NSAutoreleasePools do _not_ free anything and they do way more than release objects that where not "made with alloc/init" *. When they are dealloced, they simply send release to objects that received an autorelease message. NSObject's release method will decrement its retainCount by 1; if this objects retainCount now equals 0, this object will call dealloc on itself. NSObject's dealloc method will free its own memory.

* All objects are made with an alloc/init... method somewhere, so by your statement, NSAutoreleasePool does nothing. Good thing Apple has clearly defined what NSAutoreleasePool does by writing documentation (the first paragraph):

"The NSAutoreleasePool class is used to implement Foundation's autorelease mechanism. An NSAutoreleasePool object simply contains objects that have received an autorelease message, and when deallocated sends a release message to each of those objects. An object can be put into the same pool several times, and receives a release message for each time it was put into the pool. Thus, sending autorelease instead of release to an object extends the lifetime of that object until the pool itself is released or longer if the object is retained."


-jim
_______________________________________________
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: real authority on what needs to be released
      • From: Dietrich Epp <email@hidden>
    • Re: real authority on what needs to be released
      • From: Dean Davis <email@hidden>
References: 
 >Re: [newbie] NSString code so it won't leak (From: Dean Davis <email@hidden>)

  • Prev by Date: Formatter Trouble
  • Next by Date: Re: argh...linking problems with AppleShare client lib
  • Previous by thread: Re: [newbie] NSString code so it won't leak
  • Next by thread: Re: real authority on what needs to be released
  • Index(es):
    • Date
    • Thread