Is it necessary to use autoreleasepool in a Swift program?
On page 17 of this WWDC14 presentation, it says
Working with Objective-C? Still have to manage autorelease pools
autoreleasepool { /* code */ }
What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {}
is unnecessary?
In an answer of a related question, there is an example where autoreleasepool
can be useful:
- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}
If the code above gets translated into Swift with autoreleasepool
dropped, will Swift be smart enough to know that the number
variable should be released after the first }
(like some other languages does)?
memory-management swift
add a comment |
On page 17 of this WWDC14 presentation, it says
Working with Objective-C? Still have to manage autorelease pools
autoreleasepool { /* code */ }
What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {}
is unnecessary?
In an answer of a related question, there is an example where autoreleasepool
can be useful:
- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}
If the code above gets translated into Swift with autoreleasepool
dropped, will Swift be smart enough to know that the number
variable should be released after the first }
(like some other languages does)?
memory-management swift
1
There appears to be no documentation onautoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.
– Aaron Brager
Sep 16 '14 at 7:32
add a comment |
On page 17 of this WWDC14 presentation, it says
Working with Objective-C? Still have to manage autorelease pools
autoreleasepool { /* code */ }
What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {}
is unnecessary?
In an answer of a related question, there is an example where autoreleasepool
can be useful:
- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}
If the code above gets translated into Swift with autoreleasepool
dropped, will Swift be smart enough to know that the number
variable should be released after the first }
(like some other languages does)?
memory-management swift
On page 17 of this WWDC14 presentation, it says
Working with Objective-C? Still have to manage autorelease pools
autoreleasepool { /* code */ }
What does that mean? Does it mean that if my code base doesn't have any Objective-C files, autoreleasepool {}
is unnecessary?
In an answer of a related question, there is an example where autoreleasepool
can be useful:
- (void)useALoadOfNumbers {
for (int j = 0; j < 10000; ++j) {
@autoreleasepool {
for (int i = 0; i < 10000; ++i) {
NSNumber *number = [NSNumber numberWithInt:(i+j)];
NSLog(@"number = %p", number);
}
}
}
}
If the code above gets translated into Swift with autoreleasepool
dropped, will Swift be smart enough to know that the number
variable should be released after the first }
(like some other languages does)?
memory-management swift
memory-management swift
edited May 23 '17 at 11:47
Community♦
11
11
asked Sep 16 '14 at 4:55
EthanEthan
13.6k124262
13.6k124262
1
There appears to be no documentation onautoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.
– Aaron Brager
Sep 16 '14 at 7:32
add a comment |
1
There appears to be no documentation onautoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.
– Aaron Brager
Sep 16 '14 at 7:32
1
1
There appears to be no documentation on
autoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.– Aaron Brager
Sep 16 '14 at 7:32
There appears to be no documentation on
autoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.– Aaron Brager
Sep 16 '14 at 7:32
add a comment |
2 Answers
2
active
oldest
votes
The autoreleasepool
pattern is used in Swift when returning autorelease
objects (created by either your Objective-C code or using Cocoa classes). The autorelease
pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage
/UIImage
objects):
func useManyImages() {
let filename = pathForResourceInBundle
for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}
If you run this in Instruments, you'll see an allocations graph like the following:
But if you do it without the autorelease pool, you'll see that peak memory usage is higher:
The autoreleasepool
allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.
Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool
pattern is still useful.
2
On all of these questions, you can write your own class, and have it do aprintln
indeinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).
– Rob
Sep 17 '14 at 20:49
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
@matt Yeah, I saw similar behavior. So I repeated my exercise withNSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.
– Rob
Feb 7 '15 at 20:23
1
I found an example that works! Just call NSBundle'spathForResource:ofType:
repeatedly.
– matt
Feb 8 '15 at 2:00
1
MypathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)
– matt
Feb 13 '15 at 20:03
|
show 9 more comments
If you would use it in the equivalent Objective-C code, then you would use it in Swift.
will Swift be smart enough to know that the number variable should be
released after the first }
Only if Objective-C does. Both operate along the Cocoa memory management rules.
Of course ARC knows that number
goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:]
may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:]
.
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
@Ethan It would appear that native Swift objects are not autorelease objects, and theautoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus theautoreleasepool
construct becomes useful.
– Rob
Sep 17 '14 at 3:46
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25860942%2fis-it-necessary-to-use-autoreleasepool-in-a-swift-program%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The autoreleasepool
pattern is used in Swift when returning autorelease
objects (created by either your Objective-C code or using Cocoa classes). The autorelease
pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage
/UIImage
objects):
func useManyImages() {
let filename = pathForResourceInBundle
for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}
If you run this in Instruments, you'll see an allocations graph like the following:
But if you do it without the autorelease pool, you'll see that peak memory usage is higher:
The autoreleasepool
allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.
Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool
pattern is still useful.
2
On all of these questions, you can write your own class, and have it do aprintln
indeinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).
– Rob
Sep 17 '14 at 20:49
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
@matt Yeah, I saw similar behavior. So I repeated my exercise withNSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.
– Rob
Feb 7 '15 at 20:23
1
I found an example that works! Just call NSBundle'spathForResource:ofType:
repeatedly.
– matt
Feb 8 '15 at 2:00
1
MypathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)
– matt
Feb 13 '15 at 20:03
|
show 9 more comments
The autoreleasepool
pattern is used in Swift when returning autorelease
objects (created by either your Objective-C code or using Cocoa classes). The autorelease
pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage
/UIImage
objects):
func useManyImages() {
let filename = pathForResourceInBundle
for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}
If you run this in Instruments, you'll see an allocations graph like the following:
But if you do it without the autorelease pool, you'll see that peak memory usage is higher:
The autoreleasepool
allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.
Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool
pattern is still useful.
2
On all of these questions, you can write your own class, and have it do aprintln
indeinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).
– Rob
Sep 17 '14 at 20:49
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
@matt Yeah, I saw similar behavior. So I repeated my exercise withNSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.
– Rob
Feb 7 '15 at 20:23
1
I found an example that works! Just call NSBundle'spathForResource:ofType:
repeatedly.
– matt
Feb 8 '15 at 2:00
1
MypathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)
– matt
Feb 13 '15 at 20:03
|
show 9 more comments
The autoreleasepool
pattern is used in Swift when returning autorelease
objects (created by either your Objective-C code or using Cocoa classes). The autorelease
pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage
/UIImage
objects):
func useManyImages() {
let filename = pathForResourceInBundle
for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}
If you run this in Instruments, you'll see an allocations graph like the following:
But if you do it without the autorelease pool, you'll see that peak memory usage is higher:
The autoreleasepool
allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.
Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool
pattern is still useful.
The autoreleasepool
pattern is used in Swift when returning autorelease
objects (created by either your Objective-C code or using Cocoa classes). The autorelease
pattern in Swift functions much like it does in Objective-C. For example, consider this Swift rendition of your method (instantiating NSImage
/UIImage
objects):
func useManyImages() {
let filename = pathForResourceInBundle
for _ in 0 ..< 5 {
autoreleasepool {
for _ in 0 ..< 1000 {
let image = NSImage(contentsOfFile: filename)
}
}
}
}
If you run this in Instruments, you'll see an allocations graph like the following:
But if you do it without the autorelease pool, you'll see that peak memory usage is higher:
The autoreleasepool
allows you to explicitly manage when autorelease objects are deallocated in Swift, just like you were able to in Objective-C.
Note: When dealing with Swift native objects, you generally will not receive autorelease objects. This is why the presentation mentioned the caveat about only needing this when "working with Objective-C", though I wish Apple was more clear on this point. But if you're dealing with Objective-C objects (including Cocoa classes), they may be autorelease objects, in which case this Swift rendition of the Objective-C @autoreleasepool
pattern is still useful.
edited Sep 19 '15 at 0:16
answered Sep 16 '14 at 23:43
RobRob
304k50573739
304k50573739
2
On all of these questions, you can write your own class, and have it do aprintln
indeinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).
– Rob
Sep 17 '14 at 20:49
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
@matt Yeah, I saw similar behavior. So I repeated my exercise withNSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.
– Rob
Feb 7 '15 at 20:23
1
I found an example that works! Just call NSBundle'spathForResource:ofType:
repeatedly.
– matt
Feb 8 '15 at 2:00
1
MypathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)
– matt
Feb 13 '15 at 20:03
|
show 9 more comments
2
On all of these questions, you can write your own class, and have it do aprintln
indeinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).
– Rob
Sep 17 '14 at 20:49
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
@matt Yeah, I saw similar behavior. So I repeated my exercise withNSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.
– Rob
Feb 7 '15 at 20:23
1
I found an example that works! Just call NSBundle'spathForResource:ofType:
repeatedly.
– matt
Feb 8 '15 at 2:00
1
MypathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)
– matt
Feb 13 '15 at 20:03
2
2
On all of these questions, you can write your own class, and have it do a
println
in deinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).– Rob
Sep 17 '14 at 20:49
On all of these questions, you can write your own class, and have it do a
println
in deinit
, and it becomes quite easy to verify precisely when objects are deallocated. Or observe it in Instruments. In answer to your question, it appears that Swift objects are returned from functions with +1 retain count (not autorelease objects), and the caller will seamlessly manage ownership from that point (e.g., if and when the returned object falls out of scope, it is immediately deallocated, not placed in an autoreleasepool).– Rob
Sep 17 '14 at 20:49
3
3
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
@StevenHernandez An autorelease pool has very little to do with leaks. A leak is caused by unreleased object. Autorelease pool, on the other hand, is just a collection of objects for which the release is deferred until the pool is drained. Pools don't control whether something is deallocated or not, but rather merely the timing of such deallocation. Re map view, you can't control what caching it does (uses memory, but not true leak) nor do anything if there was a real leak (and I'm not aware of any significant map view leaks, though historically there have been random, modest leaks in UIKit).
– Rob
Oct 27 '14 at 14:46
1
1
@matt Yeah, I saw similar behavior. So I repeated my exercise with
NSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.– Rob
Feb 7 '15 at 20:23
@matt Yeah, I saw similar behavior. So I repeated my exercise with
NSImage
/UIImage
objects and manifested the problem more consistently (and, frankly, this is a more common example of the problem, as peak memory usage is often only problematic when dealing with larger objects; a practical example of this might be a routine resizing a bunch of images). I also reproduced the behavior calling Objective-C code that explicitly created autorelease objects. Don't get me wrong: I think we need autorelease pools in Swift less often than in Objective-C, but it still has a role to play.– Rob
Feb 7 '15 at 20:23
1
1
I found an example that works! Just call NSBundle's
pathForResource:ofType:
repeatedly.– matt
Feb 8 '15 at 2:00
I found an example that works! Just call NSBundle's
pathForResource:ofType:
repeatedly.– matt
Feb 8 '15 at 2:00
1
1
My
pathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)– matt
Feb 13 '15 at 20:03
My
pathForResource:ofType:
example no longer works in Xcode 6.3 / Swift 1.2. :)– matt
Feb 13 '15 at 20:03
|
show 9 more comments
If you would use it in the equivalent Objective-C code, then you would use it in Swift.
will Swift be smart enough to know that the number variable should be
released after the first }
Only if Objective-C does. Both operate along the Cocoa memory management rules.
Of course ARC knows that number
goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:]
may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:]
.
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
@Ethan It would appear that native Swift objects are not autorelease objects, and theautoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus theautoreleasepool
construct becomes useful.
– Rob
Sep 17 '14 at 3:46
add a comment |
If you would use it in the equivalent Objective-C code, then you would use it in Swift.
will Swift be smart enough to know that the number variable should be
released after the first }
Only if Objective-C does. Both operate along the Cocoa memory management rules.
Of course ARC knows that number
goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:]
may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:]
.
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
@Ethan It would appear that native Swift objects are not autorelease objects, and theautoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus theautoreleasepool
construct becomes useful.
– Rob
Sep 17 '14 at 3:46
add a comment |
If you would use it in the equivalent Objective-C code, then you would use it in Swift.
will Swift be smart enough to know that the number variable should be
released after the first }
Only if Objective-C does. Both operate along the Cocoa memory management rules.
Of course ARC knows that number
goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:]
may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:]
.
If you would use it in the equivalent Objective-C code, then you would use it in Swift.
will Swift be smart enough to know that the number variable should be
released after the first }
Only if Objective-C does. Both operate along the Cocoa memory management rules.
Of course ARC knows that number
goes out of scope at the end of that iteration of the loop, and if it retained it, it will release it there. However, that does not tell you whether the object was autoreleased, because -[NSNumber numberWithInt:]
may or may not have returned an autoreleased instance. There is no way you can know, because you don't have access to the source of -[NSNumber numberWithInt:]
.
answered Sep 16 '14 at 20:19
newacctnewacct
95.7k23134196
95.7k23134196
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
@Ethan It would appear that native Swift objects are not autorelease objects, and theautoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus theautoreleasepool
construct becomes useful.
– Rob
Sep 17 '14 at 3:46
add a comment |
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
@Ethan It would appear that native Swift objects are not autorelease objects, and theautoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus theautoreleasepool
construct becomes useful.
– Rob
Sep 17 '14 at 3:46
1
1
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
If Swift behaves the same as Objective-C for this, why the presentation mentioned "Working with Objective-C?" specifically?
– Ethan
Sep 16 '14 at 23:19
8
8
@Ethan It would appear that native Swift objects are not autorelease objects, and the
autoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool
construct becomes useful.– Rob
Sep 17 '14 at 3:46
@Ethan It would appear that native Swift objects are not autorelease objects, and the
autoreleasepool
construct is entirely unnecessary. But if your Swift code is handling Objective-C objects (including Cocoa objects), those do follow autorelease patterns, and thus the autoreleasepool
construct becomes useful.– Rob
Sep 17 '14 at 3:46
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25860942%2fis-it-necessary-to-use-autoreleasepool-in-a-swift-program%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
There appears to be no documentation on
autoreleasepool
in Swift. I expanded on your question and asked it in the dev forums.– Aaron Brager
Sep 16 '14 at 7:32