macOS new, autorelease vs alloc - init, release?

In most cases, +new is functionally equivalent to +alloc / -init, though there has been some debate about whether it should be used (primarily regarding cases where the +allocWithZone: method has been overridden).

The -autotrelease method exists to ease the burden of memory management, allowing the receiver to create and return transient objects that will eventually be disposed of (usually at the end of the run loop, sometimes sooner) but can be used by the sender (caller) for the time being.

If you are creating objects for use within a method, it is probably better to get in the habit of using an explicit -release rather than -autorelease because then the objects will go away immediately, freeing up memory right away.

When writing methods that return an object, it is best to adhere to Apple's method naming convention: assume that any method with "new" or "copy" in its name will return a persistent object that must be explicitly released, whereas other methods should return objects that do not need to be released (or should not be released because the receiving objects wants to keep ownership).

Read Apple's memory management guide here

Torchi12 said:

I am following tutorials who do:

Class *Object = [ [ Class alloc] init];
-some code-
[object release];


But I've seen:
Class *Object = [[Class new] autorelease];

What's the dfference?
Is one better than the other?
Should I continue with the alloc init or change to new autorelease?

Click to expand...

In general, it is good to follow the same patterns as everyone else does; this makes it easier for anyone including yourself to follow your code, and easier for you to follow other people's code. "Class new" is _not_ a common pattern.

You create an object, use it, release it, if that is what you wanted to do.
You create an object and autorelease it if you want to give the caller an autoreleased object.

gnasher729 said:

In general, it is good to follow the same patterns as everyone else does; this makes it easier for anyone including yourself to follow your code, and easier for you to follow other people's code. "Class new" is _not_ a common pattern.

Click to expand...

new is a common pattern in my personal code. You'll have to take it from my cold dead hands.


P.S. I'm sure there is another thread on this exact topic in here somewhere.

gnasher729 said:

In general, it is good to follow the same patterns as everyone else does; this makes it easier for anyone including yourself to follow your code, and easier for you to follow other people's code. "Class new" is _not_ a common pattern.

You create an object, use it, release it, if that is what you wanted to do.
You create an object and autorelease it if you want to give the caller an autoreleased object.

Click to expand...

I wonder how things will change with the inclusion of ARC. Apple recommends using it, do you think people will follow or just disable it and go to the tradition of retaining/releasing objects?

WMuntean said:

I wonder how things will change with the inclusion of ARC. Apple recommends using it, do you think people will follow or just disable it and go to the tradition of retaining/releasing objects?

Click to expand...

I'm sure some people will stubbornly think their code will somehow be more efficient without using ARC, but the majority will definitely adopt it. It is great.

admanimal said:

I'm sure some people will stubbornly think their code will somehow be more efficient without using ARC, but the majority will definitely adopt it. It is great.

Click to expand...

The stubborn ones will very likely be wrong. retain/release/autorelease goes through normal method calls; ARC will have specialised code for this. autorelease pools will be a lot more efficient for the same reason.

gnasher729 said:

The stubborn ones will very likely be wrong. retain/release/autorelease goes through normal method calls; ARC will have specialised code for this. autorelease pools will be a lot more efficient for the same reason.

Click to expand...

Yes, Apple already provided some graphs on this topic in a WWDC talk.

gnasher729 said:

The stubborn ones will very likely be wrong. retain/release/autorelease goes through normal method calls; ARC will have specialised code for this. autorelease pools will be a lot more efficient for the same reason.

Click to expand...

Specialized code? Where do you see this? From what I have skimmed, ARC does not change anything in the system, it is all in the compiler. Programs work the same way, the compiler just tracks objects and quietly adds in the retains and releases needed to prevent memory leaks, dangling-pointer-deallocation crashes, etc., IIUC. This will make coding as easy as working with GC, but with less runtime overhead for the system.

Now, if Apple figures out a way to apply ARC semantics to Core Foundation objects, programmers could get really lazy.

Sydde said:

Specialized code? Where do you see this? From what I have skimmed, ARC does not change anything in the system, it is all in the compiler. Programs work the same way, the compiler just tracks objects and quietly adds in the retains and releases needed to prevent memory leaks, dangling-pointer-deallocation crashes, etc., IIUC. This will make coding as easy as working with GC, but with less runtime overhead for the system.

Now, if Apple figures out a way to apply ARC semantics to Core Foundation objects, programmers could get really lazy.

Click to expand...

This is not quite correct. ARC inserts calls to objc_retain, objc_release, and a few other functions, which in turn *most of the time* call -release, -retain, etc...

In cases similar to return [[x retain] autorelease]; however, the runtime will inspect the calling function's code to determine if it was compiled with ARC, and if it was, bypass the entire operation because it's guaranteed to be retained as soon as the caller assigns it. This speeds things up somewhat, and can reduce autorelease pool pressure.

Catfish_Man said:

This is not quite correct. ARC inserts calls to objc_retain, objc_release, and a few other functions, which in turn *most of the time* call -release, -retain, etc...

In cases similar to return [[x retain] autorelease]; however, the runtime will inspect the calling function's code to determine if it was compiled with ARC, and if it was, bypass the entire operation because it's guaranteed to be retained as soon as the caller assigns it. This speeds things up somewhat, and can reduce autorelease pool pressure.

Click to expand...

I would think that ARC would just no-op explicitly coded memory management and replace it with its own optimizations. The real question I have pertains to the convenience methods: do they still use autorelease or will ARC code map to different methods so that object life is no longer than absolutely necessary? I think of some of the code I have written using NSString's path construction methods (e.g., inserting a number at the end of a filename but before the extension) that creates about five autoreleased strings, that ARC could easily dispose of immediately instead of filling up the pool. Is it likely that alternate methods, skipping autorelease, exist for ARC'd apps?

Sydde said:

I would think that ARC would just no-op explicitly coded memory management and replace it with its own optimizations. The real question I have pertains to the convenience methods: do they still use autorelease or will ARC code map to different methods so that object life is no longer than absolutely necessary? I think of some of the code I have written using NSString's path construction methods (e.g., inserting a number at the end of a filename but before the extension) that creates about five autoreleased strings, that ARC could easily dispose of immediately instead of filling up the pool. Is it likely that alternate methods, skipping autorelease, exist for ARC'd apps?

Click to expand...

You misunderstood what I meant. I'm talking about ARC-inserted [[x retain] autorelease]; (really objc_retainAutorelease(x); ). Explicit memory management calls under ARC are a compile-time error.

Given that, reread what I wrote, because it answers your question.

Sydde said:

Specialized code? Where do you see this? From what I have skimmed, ARC does not change anything in the system, it is all in the compiler. Programs work the same way, the compiler just tracks objects and quietly adds in the retains and releases needed to prevent memory leaks, dangling-pointer-deallocation crashes, etc., IIUC. This will make coding as easy as working with GC, but with less runtime overhead for the system.

Now, if Apple figures out a way to apply ARC semantics to Core Foundation objects, programmers could get really lazy.

Click to expand...

The retain, release and autorelease methods are gone. The functionality is not done via an Objective-C message anymore (with the possibility of overriding the NSObject implementation) but through a faster C function call. The compiler will also be able to do a retain/release instead of retain/autorelease in some cases, which is faster, and do retain/autorelease only once if you use the same accessor multiple times.

Sydde said:

I would think that ARC would just no-op explicitly coded memory management and replace it with its own optimizations. The real question I have pertains to the convenience methods: do they still use autorelease or will ARC code map to different methods so that object life is no longer than absolutely necessary?

Click to expand...

You cannot call release, retain, or autorelease from ARC-managed code. I would recommend checking out the WWDC video on it if you have a developer account.

gnasher729 said:

The retain, release and autorelease methods are gone. The functionality is not done via an Objective-C message anymore (with the possibility of overriding the NSObject implementation) but through a faster C function call. The compiler will also be able to do a retain/release instead of retain/autorelease in some cases, which is faster, and do retain/autorelease only once if you use the same accessor multiple times.

Click to expand...

This is also not strictly true. Try setting a breakpoint on, say, -[NSWindow release] for a program with an ARC-managed NSWindow.