• 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 (Part I)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Management (Part I)


  • Subject: Re: Memory Management (Part I)
  • From: mathew <email@hidden>
  • Date: Fri, 8 Aug 2003 12:32:47 -0400

On Friday, Aug 8, 2003, at 04:41 US/Eastern, Alastair J.Houghton wrote:
The point that Marcel is trying to make is that if you are returning an object's properties or contained data using your "return [[obj retain] autorelease]" paradigm, in order for objects to have consistent lifetimes you would also need to do the same in other cases (for example for method parameters), which is plainly ridiculous.

I have to say I agree wholeheartedly with what both Marcel and Marco have been saying on this subject. The fact is that religiously writing "return [[obj retain] autorelease]" doesn't gain you a great deal, because it is normally obvious when you need to retain an object in order to prevent it being released

I'd like to amplify this point. I'm catching up on the list, and just waded through this thread. Ignoring all the side-issues, the question seems to boil down to what you expect when you do (in pseudo-code):

get reference R to object B which is a property of object A
explicitly deallocate object A

It seems pretty clear to me that the natural OO thing to expect is that your reference is no longer valid. If an object deallocs itself, it should dealloc all the objects beneath it.

Now, if we were talking about a system with automatic memory management via a reference-counting allocator and garbage collector, the answer would be different. But Objective-C does not have automatic memory management; you're expected to handle reference counting yourself--which means you can end up with invalid references if you're not careful.

So to restate the two basic principles here...

1. If you immediately deallocate something in the object tree, expect everything underneath it to go away immediately as well, unless you take explicit steps to ensure otherwise.

2. If you take a reference to something then deallocate it, expect your reference to be invalid.

Both of those seem obvious and right to me. [[x retain] autorelease] violates those assumptions and increases CPU and RAM use, so it isn't worth doing everywhere just to assist the exceedingly rare case where you want to hard-dealloc part of an object structure while continuing to use the rest of it.


mathew
_______________________________________________
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: Memory Management (Part I)
      • From: j o a r <email@hidden>
References: 
 >Re: Memory Management (Part I) (From: "Alastair J.Houghton" <email@hidden>)

  • Prev by Date: Re: NSApplescript Issue
  • Next by Date: Re: duplicate preference keys
  • Previous by thread: Re: Memory Management (Part I)
  • Next by thread: Re: Memory Management (Part I)
  • Index(es):
    • Date
    • Thread