• 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: Memory Management
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory Management


  • Subject: Re: Memory Management
  • From: "seaside.ki" <email@hidden>
  • Date: Mon, 28 Jul 2003 00:20:32 +0200

You wrote:

> Question: Is there a preferred method? And does one method cause
> problems is used? The release in the last method is set in the
> dealloc.

John,

Case 1 and 2 are both fine.

Case 1 is best, if you have to do with the old object something after
you autoreleased it.
As long as you are in the method context - [NSApplication run:] has
not released object
in it's autorelease pool - you still can't access the old object.

Case 2 is as good as case 1, if you no longer need access the old
object.

In case 3, your should skip the retain, since alloc allready retains
it's returned object:

companyRecords = [[NSMutableArray alloc] init]

is ok. Furthermore, overriding the old instance variable companyRecords
without
an release/autorelease results in memory-leaks!

Although messages send to nil will be simply ignored, I personally
prefer to test
always against nil pointers, like this:

- (NSString*) someMethod: (id) parameter 1 anWithThis: (id) parameter2 {

NSString *returnString;

// Step 1 - assert correct parameter range
assert( nil != parameter1 );
assert( nil != parameter2 );

// Step 2 - resign, if odd parameters
if ( ( nil == parameter1 ) || (nil == parameter2 ) )
return nil;

// Step 3 - process your code.
...
returnString = ...;
...

// Step 4 - assert your code worked ok
assert( nil != returnString );

return returnString;
}

And furthermore, I prefer to compare values always in such a case, that
constant
values are at the left side of comparison operators, since

( 2 = someVar )

delivers a compile time error. And

(someVar = 2 ) // typo! Intendet: ( someVar == 2 )

is simply evaluated.

Stefan

Am Sonntag, 27.07.03 um 23:37 Uhr schrieb John MacMullin:

> I have been reading in Cocoa in a Nutshell, at page 9 and 14, the use
> of memory management using the following pattern:
>
> interface {
> id title;
> }
>
> - (id)title {
> return title;
> }
>
> - (void)setTitle:(id)aTitle {
> [title autorelease];
> title = [aTitle retain];
> }
>
> I have also seen the following method from Objective-C services:
>
>
> interface {
>
> NSMutableArray *companyRecords;
>
> }
>
>
> - (NSMutableArray *)companyRecords
> {
> return companyRecords;
> }
> - (void)setCompanyRecords:(NSMutableArray *)newCompanyRecords
> {
> [newCompanyRecords retain];
> [companyRecords release];
> companyRecords = newCompanyRecords;
> }
>
> An finally a third method:
>
> interface {
>
> NSMutableArray *companyRecords;
>
> }
>
> - (NSMutableArray *)companyArray
> {
> if (!companyRecords) {
> companyRecords = [[[NSMutableArray alloc] init] retain];
> }
> return companyRecords;
> }
>
>
> Question: Is there a preferred method? And does one method cause
> problems is used? The release in the last method is set in the
> dealloc.
>
> John
> _______________________________________________
> 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.
_______________________________________________
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: 
 >Memory Management (From: John MacMullin <email@hidden>)

  • Prev by Date: Public, private and protected variables
  • Next by Date: Re: Public, private and protected variables
  • Previous by thread: Memory Management
  • Next by thread: Re: Memory Management
  • Index(es):
    • Date
    • Thread