Re: Initializing an Array
Re: Initializing an Array
- Subject: Re: Initializing an Array
- From: Ondra Cada <email@hidden>
- Date: Tue, 22 Jan 2002 21:11:39 +0100
Jeff,
unimportant parts edited out:
>
>>>>> Jeff Galyan (JG) wrote at Tue, 22 Jan 2002 11:57:56 -0700:
JG> @interface AppCrasher : NSObject {
JG> NSString *myString;
JG> }
JG> @end
JG> @implementation AppCrasher
JG> - (id)initWithString:(NSString *)aString
JG> {
if (!(self=[super init]) return nil; // or at the very least "[super init]"!
JG> myString = [aString copy];
JG> [myString retain];
No need to retain -- would leak
JG> return self;
JG> }
JG> - (NSString *)methodOne
JG> {
JG> // create a char* and send [myString getCString] with it
JG> // do something with the C string
JG> // return a new NSString
JG> }
Kinda imprecise. There can be any kind of problem inside, which cause any
kind of strange bugs.
JG> @implementation SomeClass
JG> - (void)getCrashed:(NSString *)someString
JG> {
JG> AppCrasher *myCrasher;
JG> NSString *strOne, *strTwo, *strThree, *strFour, *strFive, *strSix;
JG>
JG> myCrasher = [[AppCrasher alloc] initWithString:someString];
This again would leak -- you should autorelease it immediately.
JG> strOne = [myCrasher methodOne];
.... see above, nobody this side of the list knows what methodAnyNumber might do.
Actually, if you really can see mysterious changing of variable contents
(like "myString" stopping to contain a decent value and lo! it contains nil
for no apparent reason) it looks like you access uninitialized pointers or
so, and have bad luck enough that they happen to point to your data instead
of some nonsense address which would cause SIGBUS.
JG> ....If you step
JG> through in the debugger (and remember, this is with optimization turned
JG> off), you'll see a new instance of myCrasher get created, then while you
JG> step through the calls to you'll see myString get initialized properly,
JG> then somewhere between the call to methodFour and methodSix (it varies),
JG> myString suddenly becomes nil
Try NSLog or the ol' plain printf:
NSLog(@"line %d, myString %x",__LINE__,myString);
to be sure of the value even for the (*very* unlikely, but possible) case
there is some problem of displaying values between gcc and gdb.
JG> even though myCrasher has not been
JG> deallocated yet, so therefore, the ivar myString should not be getting
JG> sent a release message.
First, it would not go nil even if yourCrasher is deallocated -- at least
not immediately. Later -- when the place in memory gets reallocated to
another object -- it could get any value.
Besides, not getting release message would never mean crash; the result
would be just a leak.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc