Re: Should objects returned by indirection be autoreleased
Re: Should objects returned by indirection be autoreleased
- Subject: Re: Should objects returned by indirection be autoreleased
- From: Lon Giese <email@hidden>
- Date: Fri, 12 May 2006 22:32:20 -0700
you know Bill, you might be assuming that nscell will retain the
object... the docs do not say that... unless the docs specifically
promise to retain an object then dont count on it... it might or it
might not... thats the whole idea of encapsulation we dont care what
happens inside a class as long as its interface is well defined. for
instance the docs for NSArray explicitly says it retains object added
to it and releases those removed... so you can depend on that... you
can not depend on nscell retaining a represented object... maybe it
does and maybe it doesnt and maybe apple might change whether it does
or not... again thats the idea of encapsulation and oop... It not
really that big a deal because it easy enough to retain an object you
want to keep around...
On May 12, 2006, at 9:28 PM, Bill Bumgarner wrote:
On May 12, 2006, at 8:23 PM, Lon Giese wrote:
No don't assume that... the doc for setRepresentedObject: does not
say that NSCell will retain it... so it wont... if you dont
explicitly release the it you will have a memory leak... things
like targets, delegates and such are not retained by the object you
pass it to... The hard and fast rule is if you create it ( any init
method or any copy method ) or retain it then you have to release
it... If you didn't create it or retain it then you MUST NOT release
it. NSArray for example will retain objects added to it, but the
rule still holds...
What makes you think that the Cell won't retain/release the object?
... or that it even matters?
The documentation indicates that
setRepresentedObject:/representedObject are used to link an object to
the cell. Given that the expectation is representedObject will
always return whatever was passed to setRepresentedObject at some
previous time, the cell better had retain the object or NSCell is
violating the retain/release semantics of Cocoa (or the documentation
is wrong -- which it isn't).
However NSCell does not retain the object so if you release the
object while NSCell still has it's id you'll likely get a stern
warning or crash when NSCell tries to send a message to it... clear
as mud? you'll figure it it after you track down several crashes in
the autorelease pool... when the autorelease pool crashes you know an
object was released too many times...
Actually, the Cell does retain the object. As it should.
Now, the crash you are describing is universal. If you send release
to any random object that you didn't retain, your app is going to
crash eventually.
Now, back to the original question....
On May 12, 2006, at 6:42 PM, Eric wrote:
NSCell has the property "representedObject". If I subclass NSCell
and set
and use the property from within my subclass (by calling
setRepresentedObject:), then can I assume it will be automatically
deallocated in [super dealloc]? In other words, I can just use this
property without doing anything.
You can assume that NSCell will do the appropriate retain/release
dance.
However, unless you are using represented object for its intended
purpose, I would suggest not using the pattern you suggest. In
particular, it would mean that anything else that uses your subclass
that expects normal NSCell representedObject behavior is going to
break.
Assuming you need something outside of the representedObject kind of
mechanism, go ahead and create an iVar and manage the state through
that; retaining, releasing, etc... as you normally would.
b.bum
_______________________________________________
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