Re: [[object autorelease] release]
Re: [[object autorelease] release]
- Subject: Re: [[object autorelease] release]
- From: Markus Hitter <email@hidden>
- Date: Tue, 2 Oct 2001 13:29:52 +0200
Am Montag, 1. Oktober 2001 um 22:33 schrieb Finlay Dobbie:
On Monday, October 1, 2001, at 08:29 PM, Markus Hitter wrote:
Something like:
for (i=0; i<100000; i++) {
myString = [NSString stringWithString:@"Hello"];
[myString doSomething];
[myString release]; // not allowed btw. crashes
}
Well don't use a convenience constructor.
This requires quite a lot of extra code in some cases. Like the
example in the thread "Does cocoa just leak?"
(stupid anyway, why not just use @"Hello directly? :-))
Because it's a snippet to illustrate the idea ;-)
Am Dienstag, 2. Oktober 2001 um 00:24 schrieb Sven A. Schmidt:
-(void) setNumber: (NSNumber)value {
[ number release ];
number = [ value retain ];
}
Or does it crash when the autorelease tries to delete the now
already manually released object?
Chances are good for a crash, at least you must not do it.
Am Dienstag, 2. Oktober 2001 um 00:43 schrieb Ondra Cada:
In my experience (as long as OpenStep exists) those situations are rare
enough not to be worth complicate the api and implementation.
The situations might be rare, I agree. But as ...release] would
find out itsself wether the object is already autoreleased, this
wouldn't require an addition to the API .
myString = [[NSString alloc] initWithString:@"Hello"];
[myString doSomething];
[myString release];
if you are willing to accept the problems (like leaks if doSomething
triggers an exception).
Yet another reason to allow ..autorelease] release] I didn't
think of. Thanks.
Some other person replied off-list:
The overhead occurs in placing the object in the autorelease
pool. There really isn't any overhead in emptying the
autorelease pool since it simply calls -release on all the
objects it holds. Were they not placed in the autorelease pool
-release would have to have been called for all of them anyway
so the only difference is when -release is called not how many
times.
Hmm - this probably explains, why ..autorelease] release] makes
few sense. Thanks a lot, B.
So, to avoid huge collections of autoreleased and no longer
needed objects, it might make sense to add a "flush" method to
NSAutoreleasePool which would free all objects with retain count
already zero but would NOT decrement the retain count. This
would avoid easily these nested pools, which appear a little
ugly (at least to me).
Cheers,
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/