Let say i have an class named as MyTestClass.h.
Class structure is look like
#interface MyTestClass : NSObject {
NSString *testString;
}
#property (nonatomic, retain)NSString * testString;
#end
.m file
#implementation MyTestClass
#synthesize testString;
-(id) init{
[self setTestString:#""];
return self;
}
-(void)dealloc{
[self.testString release];
testString = nil;
[super dealloc];
}
#end
Now i created an object of MyTestClass and assigned testString twice
MyTestClass * myTestClass = [[MyTestClass alloc] init];
[myTestClass setTestString:#"Hi"];
[myTestClass setTestString:#"Hello"];
Now i think, two times my testStrings memory is leaked!! (one through init() and another one through my first setTestString method)
Am i correct? or will #property (nonatomic, retain) handle/release previous allocated memory?
or ,in this kind of cases ,will i need to override the setTestString() in MyTestClass.m like below code
-(void)setTestString:(NSString *)tempString{
[testString release];
testString = nil;
testString = [tempString retain];
}
Any help on this question is appreciated.
Thanks.
Any help on this question is appreciated.
I'll take this as a licence to make sone observations not necessarily directly related to your question.
Firstly, if you declare a retain property (as you have done) and synthesize it, the automatically generated getters and setters handle memory management correctly for you.
If you manually create setter (which you are allowed to do even with an #synthesize existing), you have to do the memory management yourself. Use either of trojanfoe's examples.
The setter in your question contains a bug in that if testString == tempString i.e. you assign the value of the property to itself, you could end up with assigning a dangling pointer to the property because you effectively release tempString and then retain it.
This is an implementation detail that you an safely ignore, but string literals e.g. #"blah" are compiled into the executable and will never be deallocated no matter how many times they are released. So, with your example, even if the setter did not do correct memory management, there will be no leak.
By the way, the normal pattern for an init method is
-(id) init
{
self = [super init];
if (self != nil)
{
// init stuff
}
return self;
}
or logical equivalent.
You should get into the habit of using it because you need to call the super class's init method and it is allowed to change the value of self, even to nil.
Also, while it is very good practice normally to set the object reference to nil after releasing it, in both cases when you do it, it is unnecessary. the first time, the variable is about to go out of scope and the second time you immediately assign it from some other object.
It's not a leak. Synthesized variable are correctly handled.
A synthesized method is implemented in this way (for a retain keyword)
#property (nonatomic, retain) NSString *string;
//backed by variable NSString *_string;
- (void)setString:(NSString*)newString
{
if (newString != _string) {
[_string release];
_string = [newString retain];
}
}
Of course this is a leak:
- (void)aMethod //of my class with string property
{
NSString *aString = [[NSString alloc] initWithString:#"hello"];
self.string = aString; //retain count of 2
self.string = #"hello2"; //retain count of 1 for aString
//now I don't release aString.... leak
}
If you use the auto-generated setter (in your case, setTestString:, which is also called by self.testString = ...;), the previous value of a retain property is released before being set. So no, there is no leak in the code you posted above.
The synthesized setter method should do the right thing. Here's an example of it's implementation:
- (void)setTestString:(NSString *)tempString
{
[tempString retain];
[testString release];
testString = tempString;
}
or:
- (void)setTestString:(NSString *)tempString
{
if (tempString != testString)
{
[testString release];
[tempString retain];
testString = tempString;
}
}
the dealloc is only called when the instance is destructed.
if you do :
[myTestClass setTestString:#"Hi"];
[myTestClass setTestString:#"Hello"];
in the same block, you're juste calling twice the setter. there is no memory leak.
When you use #synthesize on a property that specifies retain, the setter that's generated will handle the retain/release correctly for multiple assignments. As long as you use self. rather than going directly to the backing variable and do a final release in dealloc you should be fine.
Related
So I'm trying to write an initializer for a subclass of NSOperation. This is my first time using NSOperation. My NSOperation subclass looks like this:
.h
#property (nonatomic, copy) NSString *fileName;
.m
#synthesize fileName = _fileName;
- (id)initWitFileName:(NSString *)fileName {
if (self = [super init]) {
_fileName = fileName;
}
return self;
}
- (void)dealloc {
[_fileName release];
[super dealloc];
}
- (void)main {
// do long task
}
So I thought when I create my own initializers, I should just set the ivar myself since the state of the object is undetermined in the init method. So I don't use the accessor in the initializer. When my main method gets run, I get a memory bad access and a crash. However, in my init method, if I do this instead:
- (id)initWitFileName:(NSString *)fileName {
if (self = [super init]) {
_fileName = [fileName retain];
}
return self;
}
I do not get a crash. What is correct? I'd think in this second case that I wouldn't be releasing the memory since the accessor is (copy). Or is it because I don't use the accessor, that my fileName object basically gets dealloc'd only since there is no +1 in the initWithFileName method? Thanks!
The second one is close, but:
- (id)initWitFileName:(NSString *)fileName
{
if (self = [super init]) {
_fileName = [fileName copy];
}
return self;
}
is more usual since NSString* properties are generally defined with (nonatomic, copy).
This is done to avoid problems or unintended consequences if the caller is actually passing a NSMutableString and later changes the value.
When you #synthesize something with a set of properties, you're generating getters and setters for the object. This allows you to use methods like
[self setFilename:#"MyFile.txt"]
or
self.filename = #"MyFile.txt"
Both of the lines above function in exactly the same way, and might be implemented like this:
- (void)setFilename:(NSString *)string {
_filename = [string copy];
// Or, for a retained property:
// _filename = [string retain];
}
This implementation is overly simplified. See idz's comment below for a better understanding of the logic that a real setter would use.
In your example above, you're simply using the = operator, and not a generated function.
_fileName = fileName;
Because of this, you're simply setting the address of _fileName to fileName. None of your synthesize properties matter, and don't make a difference here.
Your explanation:
Is it because I don't use the accessor, that my fileName object basically gets dealloc'd only since there is no +1 in the initWithFileName method?
is exactly correct. To properly replicate the copy property used by your synthesizer, use this:
_fileName = [fileName copy];
Idea 1: Use ARC. In ARC, you'd declare your ivar strong, and then either use the synthesized setter or assign the ivar directly. A retain will be added for you and all will be well.
Idea 2: Use retain. If you're unable to use ARC for some reason, why you don't declare the NSString as retain, instead of copy? It's okay to hold onto the same instance of an immutable thing. (Sharing a mutable thing can be useful, too, as long as both classes understand that they are doing that).
Idea 3: If you must use non-arc and you must use copy, set the ivar with copy. That will fix your crash by doing the copy. As it is now, the code is copying the handle to the passed string, but not it's contents. The passed string is dealloc'd and your class is stuck with a zombie. You can say _filename = [string copy]; as others have suggested.
As a side-note, calling self = [super init]; is correct inside the overridden init method. Since you're making your own init variant, I think it's more proper to call self = [self init];
I have few questions to ask about the following class
#import <Cocoa/Cocoa.h>
#interface SomeObject {
NSString *title;
}
#property (retain) NSString *title;
#end
implementation SomeObject
#synthesize title;
-(id)init {
if (self=[super init])
{
self.title=[NSString stringWithFormat:#"allyouneed"];
}
return self;
}
-(void)testMethod{
self.title=[[NSString alloc] init] ;
}
-(void)dealloc {
self.title=nil;
[super dealloc];
}
In the .h file do we need to declare the title and sub when we add the property. is it not enough to add the #property (retain) NSString *title; line.
2.Do i need to autorelease both assignment to title in the init and testMethod. if So why?
Can some one explain these things to me.
1-
You don't need to declare the iVar in the header. You might also use
#synthesize myVar = _myVar;
if you want to go for a different iVar name
2-
Declaring a property "retain" means that every time you assign the property with a new object, it automatically releases the previous object and retain the new one.
Therefore, if you use a convenience method like stringwithFormat, the property will retain that object for you.
If you want to use alloc-init, for me the best way to do is:
NSString *str = [NSString alloc] init];
self.title = str;
[str release];
Besides, it is right to assign nil to the property in the dealloc because the property will release the object it has, and it calls retain on nil which doesn't do anything
1.No need to declare title in .h, declaring property is enough.
2.when you are using self.title in init, you do not have to autorelease it.But when you initialize it in testMethod, you need to autorelease it because you have declare the property as retain.And do not forget to release title in dealloc.
you don't need to add as it is done automatically (Since Xcode 4 I guess).
in init- you don't as it already returns an autoreleased object..
where as in testMethod you need to since you are allocating it..
you always have to release any object which you create using alloc , copy or new .... AMEN.. :)
Be aware it is not considered a good practice to use accessor methods in initializer methods and dealloc method. Do check out this answer: Why shouldn't I use Objective C 2.0 accessors in init/dealloc?
Also in Apple's memory management guide: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html
I'm new in iPhone development and after reading Apple documentation and several posts here I still have some doubts about memory management. Please, supouse this basic class:
//MyClass.h
#interface MyClass : NSObject {
NSString *varA;
OtherClass *varB;
NSString *varC;
NSString *varD;
}
#property (nonatomic, copy) NSString *varA;
#property (nonatomic, retain) OtherClass *varB;
#property (nonatomic, copy) NSString *varC;
#property (nonatomic, copy) NSString *varD;
+ (id) initClass:(NSString *)desc;
- (void) method1:(NSString *)desc;
#end
With this implementation:
//MyClass.m
#implementation MyClass
#synthesize varA;
#synthesize varB;
#synthesize varC;
#synthesize varD;
+ (id) initClass:(NSString *)desc{
self = [super init];
if( self ){
self.varA = [NSString stringWithString:desc];
self.varB = [OtherClass initClassWithAutorelease:#"a description"]; //this class return an autoreleased object
[varB aMethod:#"something"];
}
return self;
}
- (void) dealloc{
[varB aMethod:#"something"];
[varA release];
[varB release];
[super dealloc];
}
- (void) method1:(NSString *)aString{
self.varC = aString;
self.varA = [NSString stringWithString:#"new value"];
[varB aMethod:#"something"];
}
#end
At this point what I have in mind is that the instance variables with #property have to be use without self. in the init method of the class and release them without self. in the dealloc, in other methods it is convinient to use self. for all cases. So here are my doubts:
First, I suppose that if I use self.varA= in the init method the retain counter increase so I have to release it in the dealloc method, even if the object has not been created with alloc, copy or new. Or I can use only varA= in the init and I will not need to do a release. For other class methods it's better to use the setter/getter so I can use self.varA=, ... appendString:self.varA ... or ...=self.varA without problem. Is all this correct?
Second doubt, what is best in terms of memory management and simplicity, to assign to an instance variable an object in the init method with or without autorelease? If I assign to it one without autorelease I will have to dealloc it but if I use autorelease the variable could be released before I want (like the autoreleased self.varB = [OtherClass... that will be used in the dealloc method whenever the MyClass is released).
Third, do I have to dealloc all my instance variables even if I don't use them in the init method but I could use them (read/write) in other methods of the same class? (Like varC in method1 or varD that is not used).
Fourth, do I need to take care of varA after assigning the new value in method1 if I did it well in the initClass and dealloc methods? In other words, will this generate memory leaks?
Fifth, if I declare with autorelease this class like an instance variable in a ViewController (MyClass *c; ... c = [[[MyClass alloc] initClass:#"description"] autorelease];) and I set the #property, do I have to do a release if I use it with c=... instead of self.c=...? As far as I know the behavior is the same than in my example so I should use the setter/get method in the viewDidLoad or viewWillAppear and released it in the dealloc without self..
Sixth and last one, for a instance variable is varA the same that self->varA?
Thanks...
At this point what I have in mind is that the instance variables with #property have to be use without self in the init method of the class and release them without self in the dealloc
This is completely the opposite of what is true. #property just makes the variable public outside of the class. If you have another class call that object, it will look in the header file (.h file), if it doesn't see a variable by that name, it will throw a warning during compile, and an error during runtime. When using properties with synthesize (btw, your synthesize can be all on one line, doesn't really matter though, ex: #synthesize varA, varB, varC;), using self automatically retains and keeps a retain count.
- (id) initClass:(NSString *)desc{ //Note the "-" instead of the "+" here, this is an instance method, not a class method
self = [super init];
if( self ){
[self setVarA:[NSString stringWithString:desc]];
[self setVarB:[OtherClass initClassWithAutorelease:#"a description"]];
[varB aMethod:#"something"];
}
return self;
}
in other methods it is convinient to use self for all cases.
Very untrue as well. If anything, this adds another call to the call stack and makes the execution slower (by one operation, but still, one more than needed). Consider this example:
[[self varA] doStuff:#"OMG"];
versus
[varA doStuff:#"OMG"];
The 2nd one will only access one pointer, where as the first one will have to access 2 pointers to get to the same result.
First, I suppose that if I use self.varA= in the init method the retain counter increase so I have to release it in the dealloc method, even if the object has not been created with alloc, copy or new.
Untrue. The class handles the first retain, and because of this, it handles a release as well. When your class is released, it sends a release to everything it has a retain on. If you do a release in your dealloc, this will actually decrease its retain count to -1 and create a memory error. If you set the property with self.varA = someObject, then it will give it a release when your class is dealloced. If you did self.varA = [someObject retain], then you would have to do a release in the dealloc.
Or I can use only varA= in the init and I will not need to do a release.
Kinda true, you would not need to do a release because you did not do a retain. But if something else lowers the retain count to 0 on this object, there is nothing in your class that forces the object to stay alive, and it will be freed, and if you reference it, memory error.
For other class methods it's better to use the setter/getter so I can use self.varA=, ... appendString:self.varA ... or ...=self.varA without problem. Is all this correct?
No, see why above. Only use [self setVarA:newValue] if you are changing the instance of the object, the synthesize will handle the rest. Otherwise just use [varA value] to get what ever data you need.
Second doubt, what is best in terms of memory management and simplicity, to assign to an instance variable an object in the init method with or without autorelease? If I assign to it one without autorelease I will have to dealloc it but if I use autorelease the variable could be released before I want (like the autoreleased self.varB = [OtherClass... that will be used in the dealloc method whenever the MyClass is released).
If you are creating a new object in init, autorelease it. You will have to release it in your dealloc if you do just a regular alloc init. The variable will not be released before you want it because of the retain you do on it through the property. EX
-(id) init {
self = [super init];
if(self) {
[self setVarA:[[[NSString alloc] init] autorelease]]; //Sets a new instance of NSString, autoreleased
}
return self;
}
This is correct, you do not need to do anything in your dealloc. You are creating an object with a retain count of 2 (one for the alloc you did here, and 1 for the retain you do when the synthesize sets the value in your class). Now, if it autoreleases, its retain will only go down by 1, and you will still have the retain from your property, so it will not release before your class releases
-(id) init {
self = [super init];
if(self) {
[self setVarA:[[NSString alloc] init]]; //Sets a new instance of NSString
}
return self;
}
Again, you create an object with a retain count of 2. You will need to do a [varA release] in the dealloc to knock the retain count down enough for it to be released when your class is released.
Third, do I have to dealloc all my instance variables even if I don't use them in the init method but I could use them (read/write) in other methods of the same class? (Like varC in method1 or varD that is not used).
No, you do not want to send releases to freed objects. You really should never use a dealloc in my opinion, but if you decide you want to for sure, then the worst case is to check to see if the object is null, and if its not, then release it
if(varD != null)
[[self varD] release];
Fourth, do I need to take care of varA after assigning the new value in method1 if I did it well in the initClass and dealloc methods? In other words, will this generate memory leaks?
No memory leaks from NSString. This method returns an autoreleased object. When you assign a new value to [self varA], it will release the old object, and retain the new object.
Fifth, if I declare with autorelease this class like an instance variable in a ViewController (MyClass *c; ... c = [[[MyClass alloc] initClass:#"description"] autorelease];) and I set the #property, do I have to do a release if I use it with c=... instead of self.c=...? As far as I know the behavior is the same than in my example so I should use the setter/get method in the viewDidLoad or viewWillAppear and released it in the dealloc without self..
You don't need a release in either scenario. The alloc increases the release count by 1, the autorelease will decrease it to 0. If you did self.c, that would increase it to 2, and decrease to 0 (one decrease from autorelease, and one from the property) when your class is released. You do not need to do ANYTHING in dealloc.
Sixth and last one, for a instance variable is varA the same that self->varA?
Yes, they point to the same location in memory.
when ever you write "alloc, retain, copy, new" you are responsible for releasing them in the dealloc method. ex
.h file
NSString * string;
#property (nonatomic, retain)NString * string;
.m file
#synthesize string;
-(void)dealloc{
[string release];
}
hope that helps :D
I wanna ask if I allocated an instance variable for private use in that class, should i release it immediately on site, or i can depend on dealloc function. (because maybe i will need it on other function) ?
//Player.h
#interface Player : NSObject
{
NSMutableArray * objectArray;
}
- (void)awake;
- (void)add;
#end
//Player.m
#implementation Player : NSObject
{
-(id) init {
self = [super init];
if (self != nil ){
[self awake];
[self add];
}
return self;
}
- (void) awake {
objectArray = [[NSMutableArray alloc] init]; //is it cause leakage?
[objectArray addObject:#"foobar"];
}
- (void) add {
[objectArray addObject:#"foobar2"];
}
- (void) dealloc {
[objectArray release];
[super dealloc];
}
}
#end
or should i using property to set the objectArray iVar?
//Player.h
#interface Player : NSObject
{
NSMutableArray * objectArray;
}
#property (nonatomic,retain)NSMutableArray* objectArray;
- (void)awake;
- (void)add;
#end
//Player.m
#implementation Player : NSObject
{
-(id) init {
self = [super init];
if (self != nil ){
[self awake];
[self add];
}
return self;
}
- (void) awake {
self.objectArray = [[NSMutableArray alloc] init autorelease]; //cause leakage?
[objectArray addObject:#"foobar"];
}
- (void) add {
[objectArray addObject:#"foobar2"];
}
- (void) dealloc {
[objectArray release];
[super dealloc];
}
}
#end
if both of them doesn't cause a leakage, what type should i use?
should i always set iVar property, and access iVar value with self even if i only want to use it in this class?
I like to take the stance that if the instance variable should not be visible outside of the class then it should not be implemented as a property. But it's a personal thing that other developers may not agree with.
Either way you would need to release the objectArray in your classes dealloc method - which is what you're currently doing.
However you need to be careful with your awake method - if it's invoked multiple times then objectArray is leaked. This is the downside of not using properties. A use of self.objectArray = [[NSMutableArray alloc] init] here would have released the previous object.
In my opinion, you should only declare properties in your header if other objects are allowed to use them. There is no good reason why you would provide an -add: method (as in your example) that adds something to your array while also providing a getter for your array so other objects can manipulate it directly. It's called encapsulation.
If you do want to have the benefits of generated getters/setters for your implementation file, you can always use a class continuation (a nameless category) inside your implementation file and include your property declarations there. That way you get real, auto-generated properties that are only visible to your class' implementation.
Personally, I wouldn't use any getter or setter methods in your example. Just allocate the NSArray in your -init and release it in -dealloc. If this -awake method of yours might be called multiple times, just add an [objectArray removeAllObjects] call and you're sure to have an empty array without worrying about memory management.
It is very likely that memory will leak in your first example because you are not sending release to the previously set instance variable (if it already existed).
This is why you should use property setters - they handle all of this stuff for you.
Also, since you are obtaining ownership of the instance variable through the property (which is defined with the retain keyword), you will definitely leak memory if you don't send the instance variable the -release message in your -dealloc method.
So the verdict is that you should use the second example, not the first.
I've read a few posts on this, but there's still one thing that's not clear for me. I know this might be rather a n00b question, but I've actually got rather far into development without quite grasping this fundamental issue. A symptom of being self taught I guess.
You declare a variable in your header, like so:
#interface SomeClass : NSObject {
NSMutableArray *anArray;
}
#property (nonatomic, retain) NSMutableArray *anArray;
end
And then in your main file you synthesise it and set it to an initial value:
#implementation SomeClass
#synthesize anArray
- (SomeClass *)init{
if (self = [super init]) {
self.anArray = [[NSMutableArray alloc] initWithCapacity:10];
}
[return self];
And release it when your Class deallocs:
- (void)dealloc {
[anArray release];
[super dealloc];
}
Now, when I run instruments, the line
self.anArray = [[NSMutableArray alloc] initWithCapacity:10];
is identified as a memory leak. Is it a memory leak because when you define the variable anArray in the header it allocates memory? (Because I thought it was a null pointer.) Therefore when you want to initialise it, and you call [[NSMutableArray alloc] initWithCapacity:10], you are reallocating the memory, and losing the pointer to the original allocation?
So instead, I use the convenience class method:
#implementation SomeClass
#synthesize anArray
- (SomeClass *)init{
if (self = [super init]) {
self.anArray = [NSMutableArray arrayWithCapacity:10];
}
[return self];
This is no longer identified as a memory leak in instruments. And since it's a convenience method, anArray is autoreleased. However, if I am to assume that the instance declaration in the header allocates memory, which would explain the previous issue, then should I still release anArray? Does setting the initial values in this way retain it perhaps?
I understand the difference between
NSMutableArray *anArray = [[NSMutableArray alloc] initWithCapacity:10];
and
NSMutableArray *anArray = [NSMutableArray arrayWithCapactiy:10];
but what I'm not sure I understand is when you've declared NSMutableArray *anArray in your header, which of the two approaches you should use and why. And whether or not if you use the second approach, you should still release anArray when you call dealloc.
I might add that I've found the following posts/links useful:
Suggest the best way of initialization of array ( or other objects )
What is the cost of using autorelease in Cocoa?
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
What is the difference between class and instance methods?
alloc'ing an object starts it off with a reference count of 1.
Setting a property that has the 'retain' attribute also increases the reference count.
So, that means this is usually bad:
#property (nonatomic, retain) Object * variable;
...
self.variable = [[Object alloc] init];
Because variable now has a reference count of 2.
When setting a object's member variable, just do this:
variable = [[Object alloc] init];
You should also realize that this works
self.anArray = [NSMutableArray arrayWithCapacity:10];
Because "arrayWithCapacity" (and other similar factor methods) autoreleases the object it returns, so after you set the property, it essentially has a reference count of 1.
It's not the instance that allocates the memory. You're right to assume that in Objective-C (at least on all Apple-based operating systems), newly initialized classes have all their ivars set to 0 (or nil or NULL as appropriate).
The problem you're seeing is that you're using the property, not the ivar in your initialization. Since you declared your property as retain, using the property accessor to set it automatically retains it.
So, when you initialize you either have to take ownership and set the ivar directly, or do like you're doing and use the property accessor to set the property and then relinquish ownership in the init method (by either releasing an object you own or, as you did in your second instance, using the convenience constructor so that you never owned the returned instance).
So just remember, if you ever use the property accessors, even within the class itself, you will get the features you set on the property (e.g., nonatomic, retain, etc.). You use the property accessors whenever you do one of the following:
// in these cases the property takes ownership through the
// retain keyword, so you must not take ownership yourself
self.anArray = something;
[self setAnArray:something];
[self setValue:something forKey:#"anArray"];
You would access your ivar directly like:
anArray = something; // in this case you must take ownership