Why do the iOS main.m templates include a return statement and an autorelease pool?

I was re-reading UIApplicati开发者_如何学JAVAonMain documentation and wondered, if UIApplicationMain never returns, why:

• is there a return at the end?
• is there an NSAutoreleasePool?

I even ask myself: why int main(int argc, char *argv[]) on an iPhone? Can we launch apps with a command line? What are argc and argv for? Are they used or just legacy C?

Some comments on Twitter from honorable fellows are that:

• return is here for the compiler
• the NSAutoreleasePool is useless.
• the run loop needs an autorelease pool to be allocated (contradicts #2)

1) The return statement is probably just there because the compiler doesn't know that the function can never return (it is not marked up in any special way, after all). So the compiler's code flow analysis would warn that it had a missing return statement. That still doesn't explain why UIApplicationMain() has a return value, though. Maybe there is an error situation where it actually can return, who knows.

2) I think having an autorelease pool in main() around UIApplicationMain is wrong, as any object released without a pool will end up in this autorelease pool, which persists for the entire duration of the application. So effectively the object is still leaked.

Usually, if there is no autorelease pool in place, the runtime logs an error message about the missing pool and tells the developer to set a breakpoint on _NSAutoreleaseNoPool to find where the pool-less autorelease happens. The top-level NSAutoreleasePool as found in the templates thus actually hides this leak from the users.

UIApplicationMain() should build its own autorelease pool as needed (It has to create and tear down a pool once through the event loop anyway, otherwise objects would just add up in the outer pool, consuming all memory). If someone thinks they really need to run ObjC code before calling UIApplicationMain() (and they can't do the same work in applicationDidFinishLaunching: or the likes), they can always create a pool before UIApplicationMain(). Since UIApplicationMain() is documented to never return (like exit()), there is no point in having commands following it anyway. The pool would never get released.

If you look at the Mac templates, they actually do not have the pool.

3) The parameters are used even if you double-click an application on the Mac. The OS passes certain information to the application that way. The first parameter is the path to the executable when it was launched, which is necessary to find files in the bundle, I presume. On the Mac, the PSN (process serial number) is also passed to an application as a parameter when launched from the Finder:

05.07.11 22:18:54,129 [0x0-0x21e21e].com.thevoidsoftware.MacTestApp: 0: /Volumes/RamDisk/MacTestApp-fdcuwfrzopalmgaufwujijhqhvjc/Build/Products/Debug/MacTestApp.app/Contents/MacOS/MacTestApp
05.07.11 22:18:54,129 [0x0-0x21e21e].com.thevoidsoftware.MacTestApp: 1: -psn_0_2220574

On the arguments part, on iOS, if you launch directly the app you only get one argument, the app path

2011-07-05 22:38:15.004 iCyril[2326:707] There are 1 args
Argument 1 : /var/mobile/Applications/7D58CC99-89C3-4F86-93D9-5FAF0756B706/iCyril.app/iCyril

Given that you can open files, read urls etc from the UIApplication delegate methods, the other info must be handled by the same mechanism.