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: Jeff Laing <email@hidden>
- Date: Thu, 3 Mar 2005 14:43:10 +1100
> For example, if you have something like the following:
>
> - (void)setName:(NSString*)aString
> {
> if(aString != name)
> {
> [name release];
> name = [aString retain]; // (or copy if you want)
> }
> }
Hmmm, perhaps I shouldn't say this, I have this feeling that people have
discussed this to death already.
But...
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.
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.
(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)
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.
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.
_______________________________________________
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