• 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: returning nil on initialization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: returning nil on initialization


  • Subject: Re: returning nil on initialization
  • From: Ondra Cada <email@hidden>
  • Date: Fri, 2 Apr 2004 03:44:20 +0200

On Friday, Apr 2, 2004, at 02:45 Europe/Prague, Bill Cheeseman wrote:

Thus, when you want to create a new object of class myClass in your code,
you can count on safely doing this:

myClass *myObj = [[myClass alloc] init];
if (myObj) {
// do something here with myObj
[myObj release];
}

If the 'myObj' object is nil because the -init failed and deallocated what
was just allocated with [myClass alloc], you don't need to release the
'myObj' object outside the 'if (myObj)' block because it was already
released in the -init method.

Is this correct?

More or less, yup. Only that the last paragraph is somewhat superfluous, for presumed "the -init failed and deallocated...", you won't get anything but nil into myObj, and thus you can't release it outside the "if (myObj)" block even if you wanted to.

Well, from the practical point of view, you actually _can_ release it without any harm, for [nil release] is an empty operation:

MyClass *myObj=[[MyClass alloc] init]; // note the convention says: use capitalized class names
// do something here, possibly in an "if (myObj)" block
[myObj release]; // if myObj!=nil, all right; if myObj==nil, all right as well!

And, if we are speaking of conventions and convenience, in a *VAST* majority of cases you don't want to use the above code anyway, for it is a possible leaker and what's worse, it is error-prone. The safe equivalent is

MyClass *myObj=[[[MyClass alloc] init] autorelease];
// do something here, possibly in an "if (myObj)" block, possibly with "if (!myObj) return", possibly with exception, no problem in any case!

Of course, the best variant of them all is to do exactly what Cocoa does, i.e., put the alloc/init/autorelease combo into a specific factory method:

MyClass *myObj=[MyClass myClass];
// anything goes, like above...

with the following in MyClass interface/implementation (or in a category, if MyClass happens to be a library code):

@implementation MyClass
...
+(MyClass*)myClass {
return [[[self alloc] init] autorelease];
}
...
---
Ondra Hada
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: 
 >Re: returning nil on initialization (From: Bill Cheeseman <email@hidden>)

  • Prev by Date: Fwd: Are you who I think you are...
  • Next by Date: NSTabView Question
  • Previous by thread: Re: returning nil on initialization
  • Next by thread: Re: returning nil on initialization
  • Index(es):
    • Date
    • Thread