• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: autorelease problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autorelease problem


  • Subject: Re: autorelease problem
  • From: Ondra Cada <email@hidden>
  • Date: Wed, 10 Jul 2002 13:27:55 +0200

On Wednesday, July 10, 2002, at 05:25 , Hok Chun So wrote:

However, I encounter some problem about autorelease.

Strangely enough, there seems to be no problem with autorelease. Its usage is somewhat weird (see comments below), but so far as I can see, it should work all right. So I infer some other part of the code causes the crash (some guess which one it might be is below, too).

- (IBAction)showInfo:(id)sender
{
NSString *filePath;
int i = 0;
// create a text string
myStr = [[MyString alloc] init];

You should autorelease it immediately, ie. [[[MyString alloc] init] autorelease]. Perhaps you might want to implement "constructor" (not in the C++ sense) class methods, so as you can use simply [MyString string]; the implementation would be straighforward:

+(MyString*)string { return [[[self alloc] init] autorelease]; }

// save string into a file under current user's home directory
filePath = [NSHomeDirectory() stringByAppendingPathComponent:@"testfile"];
if ( [NSArchiver archiveRootObject:myStr toFile:filePath] == YES )

Don't check for equivalency when the value is already boolean. Plain

if ([NSArchiver ... filePath]) ...

is better readable, and more robust in case the original method writer happened (slightly incorrectly) to exploit the fact that int is bool in C,
and anything nonzero means YES.

i = 1;

The strange thing I see here is that you don't use the i anymore?

// read back the file
[myStr autorelease]; // ************ problem occurs here

Should be autoreleased immediately when created, lest an exception happens to be raised meantime and the object leaks.

Nevertheless, I see no potential crash-causer here: it is perfectly right to (auto)release once any object which you have made by alloc/init.

My *guess* is that your archiving code is not quite proper, for it stores the object's address (or an address of something the object contains) somewhere, to be used later. Therefore, if you (properly) release the object, this "later usage" would crash. On the other hand, if you comment out the autorelease, objects leaks, and thus, when this "later usage" comes, it is still available.

myStr = [NSUnarchiver unarchiveObjectWithFile:filePath];
[myStr retain];

Absolutely no harm here, but for the sake of easy and not-error-prone code maintaining you should rather use the pattern of

myStr=[[NSUnarchiver ... filePath] retain];

The way you used there's some possibility you insert some code between later, which might cause problems.

// display the string onto text panel
[textPanel setString:[[myArchiveStr getDate] description]];

Did you not wanted to display myStr here, perchance? Incidentally, since I don't know your design I can't be sure at all, but it seems sorta suspicious that something named "MyString" contains a date ;)

}
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >autorelease problem (From: Hok Chun So <email@hidden>)

  • Prev by Date: Re: Application architecture question
  • Next by Date: Re: "Morphing" Sheets
  • Previous by thread: autorelease problem
  • Next by thread: Application architecture question
  • Index(es):
    • Date
    • Thread