Re: retain/release question about Apple docs
Re: retain/release question about Apple docs
- Subject: Re: retain/release question about Apple docs
- From: Julian Cain <email@hidden>
- Date: Mon, 6 Mar 2006 14:51:23 -0500
Right, nice, I will add an assert, that would be the prime thing to
do. Thanks Greg!
~Julian Cain
email@hidden
On Mar 6, 2006, at 12:51 PM, Greg Titus wrote:
Yes, your new macro would be a lot safer. If you know that you
should never set a value to nil, you should add an assertion that b
is non-nil rather than do nothing at all, so you can actually track
it down easily if you should ever set to nil by mistake.
- Greg
On Mar 6, 2006, at 9:34 AM, Julian Cain wrote:
Correct, i am assuming that i never set a value to nil, in which
case i never really need to so far, otherwise i would use a normal
retain/release. I assume changing my macro to #define REPLACE(a,
b) if (b != a) {[b retain]; [a release]; a = b;} might be safer?
~Julian Cain
email@hidden
On Mar 6, 2006, at 12:04 PM, Greg Titus wrote:
Well, one thing wrong with it is that it doesn't actually do the
replacement if you try to set the value to nil.
- Greg
On Mar 6, 2006, at 8:52 AM, Julian Cain wrote:
What is wrong with using a macro such as :
#define REPLACE(a, b) if (b != nil) {[b retain]; [a release]; a
= b;}
This is what I always use for setters.
~Julian Cain
email@hidden
On Mar 6, 2006, at 4:32 AM, Volker Runkel wrote:
Hi James,
the string newValue has to be released since it was retained
before creating a copy to mString .
The usual procedure would be :
if (mString != newValue) {
// don't retain here [newValue retain];
if (mString) [mString release];
mString = [newValue copy];
// so don't release here [newValue release];
}
Volker
_______________________________________________
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40omnigroup.com
This email sent to email@hidden
_______________________________________________
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