[nickm]

I'm just learning Cocoa, so this is a simple question. If I have an object whose intended lifetime in the length of a method I'm writing, can I initialize it with code like in the subject?

I realize that the preferred style is to explicitly release the object when it is no longer needed, since I am not intending on returning it, but for various reasons I want to use a construct like the one I specified in some cases.

[smeger]

Yep, perfectly fine - do it all the time.

That said, if the object you're trying to create has a factory class method (like [NSArray array], for example), you can make your code a bit cleaner by using that instead. It's essentially the same thing as saying [[[NSArray alloc] init] autorelease].

[Rickster]

Well, I'm not a rabbi, but I think you're safe.

Some ObjC conventions vary from person to person and case to case. Generally, this pattern is okay... we use it around here fairly often. Though it's probably best to make changes in object ownership explicit. For example, if you're creating an autoreleased object just so you can "transform" it, like with NSString and its various -stringByDoingSuchAndSuch methods, autoreleasing at the outset is probably good. But if you're, say, creating an NSMenu and then attaching it to an NSPopUpButton, it'll probably make your code clearer to others if you release or autorelease the object only once you hand it off to its new owner. But that's just my $1/50.

[Detrius]

The only thing that came to my mind is that anything that has been autoreleased is deallocated the next time through the event loop. I started thinking that if you had a multithreaded application that this might cause some problems... but then I realized that each thread has an autorelease pool. So, assuming that this works the way I think it would work, you should be fine even in this situation. As would naturally follow then would be that readability would be the only issue.

I may have to start using this method too.