autorelease

I understand you need to be careful with autorelease on iOS. I have a method that is returning an object it alloc s which is needed by the caller, so in this situation -- as I understand it -- I need to send autorelease to the object in the callee before it returns. This is fine, but once control returns to the phone (i.e. after my button click has been processed) it seems that the autorelease pool is released. I suspect this is how it is supposed to be, but I am wondering what is the best practice for this situation. I have resorted to sending a retain message from the caller so that the

I've noticed that there is a different way in Xcode 4.2 to start the main function: int main(int argc, char *argv[]) { @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([PlistAppDelegate class])); } } and int main(int argc, char *argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; int retVal = UIApplicationMain(argc, argv, nil, nil); [pool release]; return retVal; } Does anybody know the difference between those two? Ignacio Inglese The first one is using ARC, which is implemented in iOS5 and above to handle memory management for you. On the

I have a task that takes a rather long time and should run in the background. According to the documentation, this can be done using an NSOperationQueue . However, I do not want to keep a class-global copy of the NSOperationQueue since I really only use it for that one task. Hence, I just set it to autorelease and hope that it won't get released before the task is done. It works. like this: NSInvocationOperation *theTask = [NSInvocationOperation alloc]; theTask = [theTask initWithTarget:self selector:@selector(doTask:) object:nil]; NSOperationQueue *operationQueue = [[NSOperationQueue new]

In many Books and on many Sites I see -drain. Well, for an Autorelease Pool that sounds cool. But does it do anything other than an release? I would guess -drain just makes the Pool to -release all it's objects, without releasing the Pool itself. Just a guess. Note that the comments on oxigen's answer saying that -drain does not release the NSAutoreleasePool are not correct. The documentation for NSAutoreleasePool clearly says that -drain releases (and thus destroys) the NSAutoreleasePool. -drain is a replacement for using -release for NSAutoreleasePool objects, the only difference being that

I am carrying out a number of calculations using NSDecimal and am creating each NSDecimal struct using the following technique: [[NSNumber numberWithFloat:kFloatConstant] decimalValue] I am using NSDecimal to avoid using autoreleased NSDecimalNumber objects (if the NSDecimalNumber approach to accurate calculations is used). However it seems that the NSNumber creation mechanism also returns an autoreleased NSNumber from which the decimal value is extracted. Is there a way to create an NSDecimal without using NSNumber and creating autoreleased objects? Unfortunately, Apple does not provide any

Given this code: // Initialize string NSString *name = @"Franzi"; @"" macro creates a NSString with given text (here the name Franzi) and a RETAIN COUNT OF 1? So @"" gives an NSString with have to be released or not? Am I responsible for this object? Second code example then confuses me, even though I am using it that way: NSSting *message; message = [NSString stringWithFormat:@"Hello @%!",name]; //message = [NSString stringWithFormat:@"Hello Girl!"]; So message gets released in next run loop, k. But what is with the NSString given as argument for stringWithFormat? Does the class object

I'm looking for a primary source (or a really good explanation) to back up the claim that the use of autorelease is dangerous or overly expensive when writing software for the iPhone. Several developers make this claim, and I have even heard that Apple does not recommend it, but I have not been able to turn up any concrete sources to back it up. SO references: autorelease-iphone Why does this create a memory leak (iPhone)? Note: I can see, from a conceptual point of view, that autorelease is slightly more expensive than a simple call to release , but I don't think that small penalty is enough