Re: Memory management question (passing objects to method)
Re: Memory management question (passing objects to method)
- Subject: Re: Memory management question (passing objects to method)
- From: Tim Lucas <email@hidden>
- Date: Thu, 3 Mar 2005 15:23:27 +1100
On 03/03/2005, at 2:43 PM, Jeff Laing wrote:
In the above, its going to end up doing
name = [nil retain];
which strikes me as skating close to the edge of the language
definition.
Its 100% legal, but somewhat counter-intuitive unless you're an
Objective-C
jock.
The apple docs state:
"A message to nil also is valid, as long as the message returns an
object; if it does, a message sent to nil returns nil. If the message
sent to nil returns anything other than an object, the return value is
undefined."
So assuming that people aren't trying to release non-objects (such as
floats, ints etc) which they shouldn't be doing anways, [nil retain] is
perfectly fine.
Other threads have pointed out that whilst its safe to send messages
that
return "values that fit in a single gpr" to nil, messages that return
floating point, or structs, etc are not safe. This is definitely
counter-intuitive, and looks to my eye to be a bug in the objective-C
runtime.
We aren't returning values from these things, we are talking about
memory management (retain/release/init/dealloc).
You don't have to memory manage floats and structs, therefore the issue
of assigning primitives to [nil someMessage] is irrelevant.
(Or worse, whilst its safe to send a message to nil, it may not be
safe to
rely on it returning a value, and its an artifact of the runtime that
"usually" sends back a zero. I have not read a definitive language
spec so
I can't say one way or the other)
You *can* rely on it returning nil, just don't go assigning nil to a
primitive.
I'd hesitate to present the above as a "generic pattern" for all
setAccessors, especially if you are going to encourage the use of [xxx
setValue:nil] for clearing values. I'd rather than the 'aString=nil'
path
were a bit clearer. Just so's the beginners who are reading this
don't get
misled. ie, don't hide the subtlety.
So by your theory beginners should do memory management throughout
their class, while the rest of us keep the memory management of our
instance vars contained within our accessors?
Much of what makes a good objective-c programmer is about subtlety. The
more obvious way is not always the best, and with something like memory
management, it's best to teach good practice whilst at the same time
pointing out those subtleties.
That said, its a personal preference thing and I really don't want to
generate yet another mountain of "this is the best pattern, no this is,
etc". What I'd like people to understand is that blind use of a
pattern is
dangerous, and you need to think long and hard about whether the
pattern
really *really* fits your data types.
Don't make it sound more complicated than it is.
You must clean up after yourself (in your dealloc) if you have instance
variables which are objects.
Use your accessors where possible to ensure memory gets managed
properly.
You can use your accessors in your dealloc to clean up your instance
variables *objects* (and don't forget, there's no need to clean up
floats, ints, etc)
If you can explain why you shouldn't follow the above advice, then
chances are you've learnt sufficient that the original advice has done
its job.
A clear example of where the use of your accessors in your dealloc
ensures consistency is when you have instance vars which aren't
retained.
It would be easy for somebody to return to your code, see that you
haven't released an instance var in your dealloc and add "[delegate
release]; delegate = nil;" which would stuff everything up, because the
delegate was never retained in the first case.
If in fact they used "[self setDelegate:nil]" then your accessor would
handle things correctly, and everybody would be happy.
- tim lucas
_______________________________________________
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