Re: Does retain not work on ids?
Re: Does retain not work on ids?
- Subject: Re: Does retain not work on ids?
- From: Ken Tozier <email@hidden>
- Date: Mon, 23 May 2005 22:33:45 -0400
On May 23, 2005, at 10:01 PM, Andy Lee wrote:
On May 23, 2005, at 9:40 PM, Ken Tozier wrote:
I have a struct in which one field (type = id) serves as a generic
"data" object. In my initialization method, i've tried several
different ways to retain the field, but when a later method goes
to access it, it's always nil.
Let me see if I understand correctly. You have a C struct (as
opposed to a class? And the struct has a member of type "id"? And
you assign a non-nil value to that member? And when you check
later, the value of the member has become nil?
Exactly
If this is what you're asking, then it has nothing to do with -
retain. Sending -retain to an object does not prevent references
to the object from becoming nil. Either something else is clearing
the struct member, or you didn't correctly set it in the first place.
I sent a code snippet in reply to Pandaa's reply
By the way, you should be careful where you put the -retain,
because it has to be properly balanced by a -release or -
autorelease (assuming you eventually do want to dealloc the
object). If you make copies of the struct and keep them around,
you don't want them to contain references to an object that was
dealloc'ed.
The struct is used by all my custom GUI object classes to allow for a
simple way to store various properties.
Unless there's a compelling reason not to (and I can't think of one
offhand), you might want to consider using an object rather than a
struct.
The problem with an object was that it introduced a lot of extra
steps inside the code calling accessor methods for NSNumbers,
converting the numbers to floats etc it is much easier to just
extract all this stiff at initialization and access them using
properties.xxx format. None of the fields are visible outside the
class so it just seems like a waste of time to do all that accessor/
conversion stuff.
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden