• 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: Accessor methods and (auto)release: conclusion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessor methods and (auto)release: conclusion


  • Subject: Re: Accessor methods and (auto)release: conclusion
  • From: Marco Scheurer <email@hidden>
  • Date: Tue, 6 Aug 2002 14:45:37 +0200

On Tuesday, August 6, 2002, at 10:27 am, Marcel Weiher wrote

[...]
(A.ii) normal objects (presumably a majority of classes)

-getter {
return [[object retain] autorelease];
}

Same issue as above: a simple accessor has no business autoreleasing.
[...]

The case for the [[object retain] autorelease] pattern was already put forward by Ali in a previous message:

I am concerned about the more subtle case such as:

str = [myWindow title];
...
[myDocument saveDocument];
...
... use str ...

Assuming myDocument is the document in myWindow, a side effect of the "saveDocument" call might be to release the title you got back in the first line. A retain/autoreleased return from the first line would eliminate this potential issue, which could be hard to debug.

It's also possible to build an example here of why Method 1 (setter does autorelease) could be bad in this situation. Consider, if saveDocument was implemented as:

pool = [[NSAutoreleasePool alloc] init];
...
if (isUntitled) {
...put up save panel, get new name...
[myWindow setRepresentedFilename:newDocumentFileName];
}
...
[pool release];

I am assuming here that setRepresentedFilename: ends up changing the title of the window. In this case, due to the nested autorelease pool, even if the setTitle: method did an autorelease, the value will still be released when "str" is accessed in the outer function.

I do not think that this a very good reason. It is true that the "str" code above could crash if str is freed before it is used, but making NSWindow's title return a retained/autoreleased version of the string is just a hack. It will not, in all probability, correct the code as written, but only remove the symptom (the crash):

- If the programmer wants a copy of the original window's title, he should do just that,
str = [[window title] copy];

- If the programmer wants a reference to the actual window title, he should make sure that this reference is valid. In that case, as explained above, a retain might not be enough if the window's title is changed before str is used.

I don't see what other meaning this code can have, and in both cases the retain/autorelease pattern is useless.

The other reason offered for this pattern ("more thread safe but not quite enough") is also invalid. Using this pattern for that purpose will only make errors harder to detect and correct.

I tend to agree with Marcel that this is an unnecessary obfuscation and performance penalty. Based on the reasons given for its use above, I would even say it's bad practice. Since the apparition of retain/release/autorelease in OPENSTEP I've used the simple accessors methods, with no autorelease in the getter nor the setter (nor dealloc!), and this has never been the source of a problem. Maybe I'm missing something...


Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
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.

  • Follow-Ups:
    • Re: Accessor methods and (auto)release: conclusion
      • From: Marcel Weiher <email@hidden>
References: 
 >Re: Accessor methods and (auto)release: conclusion (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Re: Accessor methods and (auto)release: conclusion
  • Next by Date: Re: Accessor methods and (auto)release: conclusion
  • Previous by thread: Re: Accessor methods and (auto)release: conclusion
  • Next by thread: Re: Accessor methods and (auto)release: conclusion
  • Index(es):
    • Date
    • Thread