Re: Do we really need "if((self = [super init]))" in Objective-C anymore?


 


On Aug 17, 2017, at 11:06 AM, dhoerl <dhoerl@...> wrote:

So really, if Swift expects Foundation to always return a real object, why not use the same construct in Objective C:

The Obj-C behavior is historical. Back in the day of NEXTstep it was a realistic expectation that the process could run out of heap space and malloc() would return NULL, meaning +alloc would return nil. So any call to +alloc had to expect this possible error condition. (Yes, even on a 68030 a process had about 2GB of available address space. But back when hard disks topped out at a few hundred MB, there was no way to allocate that much backing store; your disk would fill up first.)

Somewhere along the line, I think prior to 10.0 but I'm not sure, that changed — in the modern era, running out of address space is considered unlikely enough that malloc() never returns NULL, it aborts instead if it can't allocate. And both macOS and iOS try to keep things from reaching that state — macOS will start freezing apps if the disk fills up (I've seen this happen) and iOS of course kills your app if it goes over a few hundred MB.

These days, yeah, it's pretty safe to skip checking the result of [super init], unless of course that method declares a nullable return value. I still do it, though.

—Jens

Join xcode@apple-dev.groups.io to automatically receive all group messages.