• 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: NSXMLParser frees itself on error?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSXMLParser frees itself on error?


  • Subject: Re: NSXMLParser frees itself on error?
  • From: Marcel Weiher <email@hidden>
  • Date: Wed, 6 May 2009 19:38:44 -0700


On May 6, 2009, at 18:45 , Jeff Johnson wrote:


I think you misunderstand the problem that autorelease is trying to solve, which is to allow ownership transfer from a callee back to its caller, not to just simply delay a release until "later".

Ownership 'transfer' is rare. If you call +alloc or -copy, for example, ownership is transferred to the caller. Otherwise, there's no such thing.

The fact that you think this is a testament to how well -autorelease works :-)


How about +[NSMutableString string] ? Do you think the NSMutableString class keeps ownership of the array you have created?


This is why you can't implement your getters as -(id)myThing { return [_myThing retain]; }. When someone else calls -myThing, you still own the object, which is why you're responsible for balancing out the retain with an autorelease. You call release or autorelease on an instance variable to relinquish ownership of the object, not to 'transfer' ownership.

This is largely incorrect. There is no need for an -autorelease in a getter, just like there is no need for the retain. *If* you do a retain, for whatever reasons, then you need to balance it with a release or an autorelease.



This is not absurdity, this is *precisely* the case.

I know it's the case, which is why I said it. The absurdity is that it would never be safe to use autorelease.

It is perfectly safe to use autorelease for the things it was intended for. It never was safe for the things you seem to want to use it for.


It may be true that there could always be an autorelease pool around the call, but if the callee has to worry about that, then what's the point of even using autorelease at all? Might as well just always release objects, because you have to assume that they're going to get released immediately after the method returns, right?

Nope, wrong.


Thus, the callee never knows whether its own calls to autorelease will be subsequently turned into releases by the drained pool immediately upon returning from the called method. Is the callee never supposed to use autorelease, to be safe?

It should only use autorelease to give the caller the chance to retain the object if it wants to, it cannot be used to "tunnel" the object through the caller.

You indeed should be able to "tunnel" through the caller:

Nope.


http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#/ /apple_ref/doc/uid/20000043-1000580

You need to re-read that document, because it does not say what you think it says.



"When another method gets the array of Sprocket objects, that method can assume that the array will be disposed of when it is no longer needed, but can still be safely used anywhere within its scope (see “Validity of Shared Objects”). It can even return the array to its invoker, since the application object defines the bottom of the call stack for your code. The autorelease method thus allows every object to use other objects without worrying about disposing of them."

This does not say that you (the callee) can tunnel through the caller. It say that the caller can, at its discretion, decide to pass the objects up to its caller. However, it does not have to do this.



http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#/ /apple_ref/doc/uid/20000043-1000922

"Cocoa’s ownership policy specifies that received objects should remain valid throughout the scope of the calling method. It should also be possible to return a received object from the current scope without fear of it being released."

That is: there is nothing that Cocoa does to make the object go away during the scope of the calling method. However, the calling method certainly has the freedom to make the objects go away.



From the callee's perspective, a call to autorelease defers the release until the end of the event loop.

That is completely wrong. Wherever you got that information from, forget it, delete it, purge it, unremember it.

Heh, I can't very well delete Apple's documentation. "The autorelease method, defined by NSObject, marks the receiver for later release."

Yes, but you don't get to say how much later. Your caller does.

Cheers,

Marcel

_______________________________________________

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


  • Follow-Ups:
    • Re: NSXMLParser frees itself on error?
      • From: Jeff Johnson <email@hidden>
References: 
 >NSXMLParser frees itself on error? (From: Mike Manzano <email@hidden>)
 >Re: NSXMLParser frees itself on error? (From: Jesper Storm Bache <email@hidden>)
 >Re: NSXMLParser frees itself on error? (From: "Stephen J. Butler" <email@hidden>)
 >Re: NSXMLParser frees itself on error? (From: Jeff Johnson <email@hidden>)
 >Re: NSXMLParser frees itself on error? (From: Marcel Weiher <email@hidden>)
 >Re: NSXMLParser frees itself on error? (From: Jeff Johnson <email@hidden>)

  • Prev by Date: Re: A tree data structure?
  • Next by Date: Re: UIToolbar setItems:animated: broken?
  • Previous by thread: Re: NSXMLParser frees itself on error?
  • Next by thread: Re: NSXMLParser frees itself on error?
  • Index(es):
    • Date
    • Thread