Re: Looping worker threads - NSString vs sprintf
Re: Looping worker threads - NSString vs sprintf
- Subject: Re: Looping worker threads - NSString vs sprintf
- From: Brendan Younger <email@hidden>
- Date: Wed, 1 Aug 2001 13:55:58 -0500
On Wednesday, August 1, 2001, at 06:59 AM, Ondra Cada wrote:
>
Brendan,
>
>
>>>>>> Brendan Younger (BY) wrote at Tue, 31 Jul 2001 13:42:04 -0500:
>
BY> NSExeceptions are indeed implemented using setjmp/longjmp however,
>
they
>
BY> cause memory leaks since (I believe) calling longjmp causes your
>
BY> function to fall through which means any classes you've
>
instantiated and
>
>
I generally instantiate objects, not classes, but I believe you meant
>
it the way.
>
>
BY> were planning on releasing since setjmp will be dangling there.
>
>
They will not! It's another nice autorelease pool feature. Shortly,
>
when you
>
create a new pool, it is stored into the current one. Therefore, in this
>
setup
>
>
for (;;) {
>
id pool=[NSAutoreleasePool new];
>
NS_DURING // or explicit setjmp
>
for (;;) {
>
id p2=[NSAutoreleasePool new];
>
for (;;) {
>
id p3=[NSAutoreleasePool new];
>
for (;;) {
>
id p4=[NSAutoreleasePool new];
>
...
>
[NSException raise...]; // or explicit longjmp
>
...
>
}
>
...
>
}
>
...
>
}
>
NS_HANDLER ... NS_ENDHANDLER
>
...
>
[pool release]; // ALL the objects (including p2-p4 and their
>
contents)
>
released here!
>
}
>
>
BY> often not so bad when raising an exception since your program will
>
BY> probably quit itself soon anyway,
>
>
Nope. Exception DO NOT mean that the program's bound to quit ASAP. They
>
can
>
be -- and often are -- used as part of a perfectly normal behaviour,
>
like
>
>
...
>
NS_DURING
>
some_very_complicated_code_which_can_exit_from_many_places
>
NS_HANDLER
>
if (![[localException name] isEqualToString:@"justExitedCleanly"])
>
[localException raise];
>
NS_ENDHANDLER
>
...
>
>
and, of course, whenever you want to exit from anywhere in the
>
"some_very_complicated_code", you just use "[NSException
>
raise:@"justExitedCleanly" format:@""]".
>
>
BY> but Christian Mike implied that he
>
BY> used them to stay away from things like endless recursion and
>
BY> overflowing the stack. That's fine if all you have are stack-based
>
BY> variables
>
>
Thanks to the fact that the guys who designed the OpenStep were nobody's
>
fools it's fine for normal (malloc-ed) objects as well, provided you
>
use the
>
autorelease pools properly.
>
>
BY> but will cause memory leaks if you've malloc'd something or
>
>
This it would, so you should never use explicit malloc -- always wrap it
>
into an object (which can be autoreleased).
>
>
BY> instantiated a class.
>
>
It will not, see above.
>
---
>
Ondra Cada
>
OCSoftware: email@hidden http://www.ocs.cz
>
private email@hidden http://www.ocs.cz/oc
>
Ondra, I'm getting the distinct impression that you are, in fact, not
actually *reading* my emails. May I suggest that you do so before
replying with contradictory statements. Read the following again.
BY> but will cause memory leaks if you've malloc'd something or
This it would, so you should never use explicit malloc -- always wrap it
into an object (which can be autoreleased).
BY> instantiated a class.
It will not, see above.
One last time. Instanciating an object: [[SomeObj alloc] init].
Autoreleasing an object: [[[SomeObj alloc] init] autorelease]. First,
bad; second, good. See? We agree on the correct way to handle the
situation, only you seem to have assumed that I am always wrong and have
hence not even tried to understand what I'm saying.
Brendan Younger