Does NSAutoreleasePool also covers variables in all the called methods?
If that's the only place where -isNotExpired is called, the auto release pool you've set up will contain objects autoreleased in -isNotExpired (including startDate).
Note that in a normal Cocoa application, NSApplicationMain() called in main() in main.m will create an autorelease pool for you, so this code wouldn't leak anyway. You generally only create your own autorelease pool in cases where you'll be generating lots of temporary objects with a short useful life (in a loop for instance) and want to keep your high water memory usage down.
Related
i have read so many stackoverflow discussion about when to use #autorelease pool some one suggest to write own #autorelease pool when create a secondary thread in your application and some discussion about this describe that you don't need to create #autorelease pool,
Also should i need to create externally #autorealease pool when i am using GCD
So please any one here , correct me about #autorelease for which scenario.
If your block creates more than a few Objective-C objects, you might want to enclose parts of your block’s code in an #autorelease block to handle the memory management for those objects.
Although GCD dispatch queues have their own autorelease pools, they make no guarantees as to when those pools are drained. If your application is memory constrained, creating your own autorelease pool allows you to free up the memory for autoreleased objects at more regular intervals.
So, if you are only allocating a few objects, don't worry about it.However, if you are allocating any significant number of objects (and since you are targeting a memory constrained environment), then you should be creating and draining pools.
I fairly new to Obj-C and am just starting out making little useless programs to help further my knowledge. I wanted to make sure I wasn't making any memory leaks. Does anything in the '#autoreleasepool' automatically release it's memory when the program ends?
Also if there are any bad habits, please let me know!
int main(int argc, const char * argv[])
{
#autoreleasepool {
Fraction* fractionOne = [[Fraction alloc]init];
Fraction* fractionTwo = [[Fraction alloc]init];
Fraction* fractionThree = [[Fraction alloc]init];
[fractionOne setTo:1 over:2];
[fractionTwo setTo:1 over:4];
[fractionThree setTo:1 over:8];
[Fraction numberOfFractions];
return 0;
}
}
See Apple's discussion of Using Autorelease Pool Blocks in the Advanced Memory Management Programming Guide.
In short, no, it is not the case that "anything in the #autoreleasepool automatically release[s] its memory when the program ends" (or at least not as a function of the #autoreleasepool). The purpose in having an autorelease pool is to control when the memory is reclaimed from autorelease items, i.e. when will the pool be drained. But your code sample doesn't appear to employ any autoreleased items, so it is not really applicable here (unless the methods used autorelease objects internally).
The most common usage of autorelease pools is to reduce the memory high-water mark of your app. See Use Local Autorelease Pool Blocks to Reduce Peak Memory Footprint. It used to be used for thread programming, but now that we have operation and dispatch blocks, we don't have to write traditional threaded code anymore, so we don't have as many occasion to need separate autorelease pools in our multithreaded code.
With ARC turned on, code is added at compile time to explicitly release fractionOne, Two and Three, so they'll get released with ARC. Without ARC, the alloc is creating a retained instance of Fraction and your code hasn't either released explicitly (almost always better) or set these as autoreleased (almost always worse).
So without arc, you're leaking during the few milliseconds this program is running.
That's more or less what it does. But don't worry: just rely on ARC. It manages your memory for you!
Using ARC, the only place you'll really see #autoreleasepool is the main function. When you start making apps, you'll write your code elsewhere and will barely ever edit the "default" main function (given to you by the Xcode templates).
So don't worry about it! Your code is fine :)
The autorelease pool object is essentially a container during runtime that holds objects (so-called autoreleased objects) alive in memory until they are released, i.e. when the pool is drained. This will happen at the end of autorelease’s scope.
Autorelease Pool is part of the Manual Reference Counting (MRC) technique in Objective-C to manage an object’s lifecycle. MRC is one of the three memory management models, the other two being Automatic Garbage Collection and ARC (Automatic Reference Counting).
During runtime, we want to avoid having memory leaks. These are blocks of allocated memory (e.g. objects) that were once alive but are not referenced by any process anymore. If we have no way of accessing or releasing them by any other running code, they can create numerous issues, e.g. cluttering and reducing the amount of available memory. The concept of the Autorelease Pool helps to mitigate this risk.
References:
NSAutoreleasePool
Programming in Objective-C, Sixth Edition (2013) by Stephen G. Kochan
I have audio class that sample the buffer and with NSNotification it calls another class and send a data(int).
I get this warning that runs many many times a second:
class __NSCFNumber autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool()
class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
what does it means?
yes I have NSNumber in that class and NSString.
they are not allocated.
do I need another thread?
what's wrong?
It means that, for whatever thread that code is running on, no autorelease pool has been set up before that code runs. For AppKit- or UIKit-based apps, the framework normally managed one for you on the main thread, but you'll still need to create them yourself if you're using other threads. For apps that are not based on AppKit or UIKit, you'll pretty much always need to make sure there's an autorelease pool around when you're running Objective-C code.
Do you use an autorelease pool in your main() function in the application? Do you use the autoreleased instances (yes, I know, you didn't alloc-init them, but [NSNumber numberWith...] returns an alloc-init-autoreleased object) in a thread other than the main thread? If you haven't initially set up an autorelease pool, or you're using multiple threads, you must create an individual NSAutoreleasePool for each thread.
I'm writing my very first steps in Objective-C.
I followed some examples and the official documentation, and am using autoreleased objects* without explicitly declaring an NSAutoReleasePool.
* By autoreleased objects I mean: SomeClass *obj = [SomeClass someClass];
Is it ok to do it this way?
Will it cause a memory problem?
Is declaring a NSAutoReleasePool more efficient?
edit: I made a mistake in the code example, what I meant was getting an object by it's class factory method instead of allocing an instance of it. This factory methods [often|always] return autoreleased objects, right? for example: [NSString stringWithCString:x]
You don't need to create an autorelease pool explicitly usually. When you do normal Mac programming using the AppKit framework, there will be an implicit autorelease pool which is handled by the event loop. You need to concern yourself with autorelease pools mainly on two occasions:
Your code runs in a background thread: If you have a background thread there is no autorelease pool created for you and you will have to do this manually.
You have a tight loop where you create and destroy a lot of objects. If in this loop any objects are autoreleased they will not actually be released until the autorelease pool is drained. This means that your memory consumption will rise, even though you don't reference those objects anymore. In this situation having a local autorelease pool can help with performance, although switching from autoreleasing to explicit retain/release is probably more efficient.
In answer to your question: that's a no-no. You will leak memory if you autorelease an object (or use an autoreleased object) in a scope that has no autorelease pool.
perhaps ignore the following:
With regard to your example, it might be rather confusing the way you've written it, since Class is a typedef of struct objc_class*. So, you're really declaring a pointer-to-a-pointer to a class, and then assigning a pointer to a class to it. Which won't work. Moreover, since Class is not an Objective-C “class-type” per se, you can't send messages to it.
But all this is neither here nor there, since ±class does not return an autoreleased object.
NSAutoreleasePool .. should there be only one? Why would you want to have more then one? Would you ever want to have more than one pool as part of a single class?
If you have multiple pools, which one will contain object that was asked for be [autorelease]d? Is there a way to find out what objects are waiting to be auto-released as part of a pool?
Sorry for 20 questions, please help me understand this better
NSAutoreleasePool .. should there be
only one?
No, not necessarily. You may create as many autorelease pools as you want/need.
Why would you want to have more then
one? Would you ever want to have more
than one pool as part of a single
class?
The idea is to keep your memory "high water mark" as low as possible. Using autorelease is a bit of a cheat to defer releasing your object until "later". Sometimes you know when "later" is -- and in these cases, it's probably smart to make your own autorelease pool.
What do I mean by all this? Well, imagine you had the following loop:
for (...)
{
// 1 MB of objects are added to the autorelease pool by some code...
}
1 MB is a lot! If that code looped 20 times, you'd have 20MB of objects waiting to get released. Even worse, if it ran for an indefinite or indeterminate number of times your application may very well crash. If you know that code is self-contained you can force anything that gets put into an autorelease pool within that block to get released by creating your own autorelease pool manually, like so:
for (...)
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
// 1 MB of objects are added to the autorelease pool by some code...
[pool drain];
}
Now your "high water mark" is only 1MB instead of 20MB (or more!).
If you have multiple pools, which one
will contain object that was asked for
be [autorelease]d?
The most recent one.
Imagine having a global stack. When you init a new AutoreleasePool, it adds itself to this global stack of autorelease pools. When you call [xxx autorelease] on an object, the autorelease method peeks at the autorelease pool on the top of this stack and adds itself to that autorelease pool's list of objects. When you call [pool drain], that pool loops through all of the references that have been added to it and it calls [xxx release] on all of them.
As BJ Homer points out, the stack in the paragraph above isn't actually truly global - there is actually one stack per thread. But I couldn't figure out how to rewrite the above paragraph and keep it easily understandable by using terms like "thread-local"... so... this addendum will have to suffice : )