Re: Autorelease Question
Re: Autorelease Question
- Subject: Re: Autorelease Question
- From: Filip van der Meeren <email@hidden>
- Date: Fri, 21 Nov 2008 08:27:25 +0100
On 21 Nov 2008, at 04:55, Adam Leonard wrote:
See the Cocoa Fundamentals Guide:
"Class factory methods are implemented by a class as a convenience
for clients. They combine allocation and initialization in one step
and return the created object autoreleased. These methods are of
the form + (type)className... (where className excludes any prefix)."
"autoreleased" !
Someone correct me if I am wrong about this, but the statement that
convenience methods always return an autoreleased object is a
generalization that is implementation specific and not always true.
As far as I can tell, it is not true in the case of [NSString
string] on 10.5.
For example, try running this code:
NSString *string1 = [NSString string];
NSString *string2 = [[[NSString alloc]init]autorelease];
NSString *string3 = [NSString stringWithFormat:@"hello"];
NSString *string4 = [[[NSString
alloc]initWithFormat:@"hello"]autorelease];
NSLog(@"string1: %p, string2: %p, string3: %p, string4:
%p",string1,string2,string3,string4);
On my computer, string1 and string2 always point to the same address
and string3 and string4 point to different addresses.
That is because all empty strings point to the same singleton.
Next, look at the retain counts of each. string1 and string2 return
INT_MAX, while string3 and string4 return 1.
And if you really want, try:
int i;
for(i=0; i<1000; i++)
[string1 release]; //no crash
for(i=0; i<1000; i++)
[string3 release]; //CRASH
You should never release an object when you didn't retain it first.
The fact that the [NSString string] has such a high retaincount is to
make sure it will never get released; every program needs an empty
string at some point...
All of this would leave me to believe that [NSString string] is NOT
"combining allocation and initialization in one step and returning
the created object autoreleased". Instead, it is likely implemented
like this:
+ (id)string
{
return @"";
}
I would think of something like the following:
+ (NSString*)string
{
static NSString *result = nil;
if(!result)
{
// Go freaky...
// Something like this
result = [[NSConcreteString alloc] initWithBytes:nil];
[result setThisRetainCountToMax];
}
return result;
}
(i.e., returning an empty constant NSString)
Again, this makes sense. Why waste memory by having more than one
empty string instance?
These are all implementation details, so I'm not suggesting that it
is ok to ignore the memory management rules , but it is also an
implementation detail as to when NSString decides to fulfill its end
of the memory management agreement.
Another case where a class factory method that does call autorelease
will not "return the created object autoreleased" is when its call
to -init.... returns nil
There is no reason to assume that no autoreleasemessage was sent...
Messages to nil objects may happen according to the Objective-C
language, will not call the method and automatically return nil, 0.0f,
0...
For instance, One example given, +dataWithBytes:length:, is
documented to return nil in cases when "the data object could not be
created"
I think this is a bug in the documentation. I am curious to know
what others think.
That isn't a bug, Objective-C reserves exceptions for extreme
situations, that is in big contrast to other languages like C++ or C#
that require more try-catch-blocks than actual code...
If it can't create the object for some reason, then it returns nil.
And you the programmer have to check for the returnvalue not to be nil.
This method of working is much easier, just imagine that you would
have to try-catch all these factorymethods/singletons !
Adam Leonard
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Filip van der Meeren
http://www.sourceforge.net/projects/xlinterpreter
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden