macOS new, autorelease vs alloc - init, release?

[Torchi12]

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?

 

[Sydde]

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

 

[gnasher729]

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?

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.

 

[xStep]

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.

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.

 

[WMuntean]

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.

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?

 

[admanimal]

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?

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.

 

[gnasher729]

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.

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.

 

[admanimal]

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.

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

 

[Sydde]

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.

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.

 

[Catfish_Man]

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.

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.

 

[Sydde]

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.

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?

 

[Catfish_Man]

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?

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.

 

[gnasher729]

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.

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.

 

[admanimal]

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?

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.

 

[Catfish_Man]

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.

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