• 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: basic Obj-C lesson (was runtime error with NSArray no more!)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: basic Obj-C lesson (was runtime error with NSArray no more!)


  • Subject: Re: basic Obj-C lesson (was runtime error with NSArray no more!)
  • From: Sherm Pendley <email@hidden>
  • Date: Fri, 6 Dec 2002 14:28:23 -0500

On Friday, December 6, 2002, at 01:51 PM, Mike McCune wrote:

so are you saying that on my first iteration I should add something like [[myArray objectAtIndex: i] retain]; and then of course release it after the second iteration?

Not quite. When an object is added to a collection (Array, Set, Dictionary - whatever), the collection retains it. What I'm concerned with is whether you've retained the array object itself; if not, then myArray (from the above example) will either be nil, or will point to memory that has been re-used for some other object, when you attempt to access it in some future event.

In the former case, the result will be precisely nothing. Messages sent to nil are not errors in ObjC - but they don't do anything useful, either. In the latter case, the results are difficult to predict - if the memory pointed to by myArray just happens to be used by another array object, it could potentially even successfully respond to the objectAtIndex: message, but return an object from a different array!

In this specific instance I'm not sure I understand how the NSButton object is created and destroyed.

It's created in IB, serialized to the .nib file, reconstituted into your app from the .nib file, and finally destroyed when the .nib is unloaded.

I mean its in my UI but you're saying that that the object is only retained as long as the call is going on?

No, the NSButton object itself isn't going anywhere. (At least, it shouldn't be...)

Shouldn't the pointer in my NSArray still point to the object that exists in the UI?

Yes - but that reference to the NSButton object will only exist for as long as the NSArray container that holds it exists. In short, you don't need to retain objects added to a collection - the collection does that for you. You do, however, need to establish ownership of the collection object itself, if you intend to use it over the lifetime of several events. You can establish ownership either with an explicit "retain" message to an existing object, or by using an init: or copy: method that creates an object that has been implicitly retained on your behalf.

sherm--

If you listen to a UNIX shell, can you hear the C?
_______________________________________________
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: basic Obj-C lesson (was runtime error with NSArray no more!)
      • From: Mike McCune <email@hidden>
References: 
 >Re: basic Obj-C lesson (was runtime error with NSArray no more!) (From: Mike McCune <email@hidden>)

  • Prev by Date: [OT] Re: newbie Perl question
  • Next by Date: RE: basic Obj-C lesson (was runtime error with NSArray no more!)
  • Previous by thread: Re: basic Obj-C lesson (was runtime error with NSArray no more!)
  • Next by thread: Re: basic Obj-C lesson (was runtime error with NSArray no more!)
  • Index(es):
    • Date
    • Thread