Can you describe the naming convention difference between a method that returns an object it has allocated for the caller (and that the caller should release), and a method that returns an autorelease object?
If you declare a property with a retain attribute, do you need to release the property before you set it to nil?
What does the #synthesize directive do?
From apple documentation
You only release or autorelease objects you own.
You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message.
You use release or autorelease to relinquish ownership of an object. autorelease just means “send a release message in the future” (to understand when this will be, see “Autorelease Pools”).
Your second two questions are related. All that #synthesize does is to generate additional methods for your implementation file. The arguments to #property (nonatomic, retain) NSString* myString; define the behavior of the generated methods. For example, if you declare a property as retain, the setMyString generated method will retain its argument.
Nonatomic is important because properties, by default, are threadsafe. If you don't need thread safety, you can remove a lot of overhead in your accessor methods.
Finally, the implementation of a retain property is
- (void) setMyString:(NSString*)newString {
[newString retain];
[myString release];
myString = newString;
}
So, saying self.myString = nil effectively releases myString for you. Many people advocate using self.property = nil for retained properties, as opposed to [property release], though I think it just comes down to personal preference.
A good source for memory allocation is listed below by Aaron.
Regarding #synthesize:
Say you have a property P, what you will have to do is write a getter and a setter for it. There are a few common approaches, one of which is that you retain that object when you set that property and release the old value. E.g:
- (void)setP:(PClass *)value
{
[value retain];
[_pInstanceVariable release];
_pInstanceVariable = value;
}
Since this is a very common piece of code, the compiler can automate it for you, if you specify the retain keyword in property declaration and then do the #synthesize in you implementation. The compiler will generate the above mentioned code which means your code will be a lot cleaner without tedious repeating parts.
Same holds true for getters, unless you want something more complex than:
- (PClass *)p
{
return _pInstanceVariable;
}
the #synthesize will do the job
memory allocation information and naming can be found here
http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html
synthesize is documented here
http://developer.apple.com/library/ios/documentation/cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW17
The apple website has excellent documentation, I would recommend searching there first.
Related
This question already has answers here:
Property vs. ivar in times of ARC
(2 answers)
Closed 8 years ago.
I've been up and down the Google and the Stack and read many articles if not outright debates over ivars and properties. But still, even after all this reading I remain confused.
I understand ivar's are private and properties are typically used to expose (well) class properties. But I understand properties to be more than that, they contain Getters and Setters and when it comes to memory management (even under ARC) I can see the benefit to using them exclusively.
But my question is; does any of this matter anymore now that we have ARC? (see comment in example code below).
Consider:
#interface MyClass
#property(strong) NSMutableArray *myArray;
#end
#interface MyClass
-(instancetype)init {
if (self = [super init]) {
self.myArray = [NSMutableArray array];
// OR
// Will this NOT call the Setter? Hence, leading
// to possible memory leak issues?
_myArray = [NSMutableArray array];
}
return self;
}
#end
self.myArray = [NSMutableArray array]; is considered bad form in init. You should avoid the use of setters entirely in your initialisation. The risk is that a subclass may override the method, in which case you're calling a method on a class that hasn't been inited yet (because it's got only as far as initing you). See the obligatory Mike Ash citation.
_myArray = ... does not call the setter and is therefore the correct form for an init regardless of whether you also have a property.
ARC makes correct memory-management all but a none issue. The debate is exclusively what you want technically to expose and how adaptable you want your internal code to be. I tend to prefer explicit instance variables because that shouts 'private implementation detail'.
Back in the old days of Objective-C, you had ivars, and if you wanted to let some other class set or read them then you had to define a getter and a setter.
As I explained to you, with properties you get the setter and getter for free (almost!) along with an instance variable. So when you define a property, you can set the atomicity as well as assign/retain/copy memory management semantics.
Most people leave the ivar name the same as the property name, but it can be made to be something else when you write your #synthesize statement (i.e., #synthesize foo=_foo; means make an ivar named _foo for the property foo).
Note that as of Xcode 4.6, you do not need to use the #synthesize statement - by default will the compiler prepend the ivar's name with _. So #synthesize is no longer recommended by Apple for new code.
In both cases the assigned value will be retained, since you are assigning it to a strong variable. (Strong is the default for variables that reference object instances)
In the first example the method -setMyArray: will be called, which in the case of a generated setter will store the value to _myArray. In the second case, -setMyArray: will not be called.
For the given code the object already assigned to _myArray will have its reference count properly decremented when the _myArray is set again. (The existing strong reference to the object will be deleted.)
That first call will call the setter while the second will not, however both calls will overwrite the ivar _myArray. For example, if you did self.myArray = #[#"Hello"]; and then _myArray = #[#"World"], printing out both self.myArray or _myArray will print #[#"World"].
If you instead write your own method -(void)setMyArray;, It could possibly do different things, but then you also won't get the private ivar _myArray without declaring it yourself.
I have this in my .h file:
#property (nonatomic,retain) CCTexture2D *tempScreenshot;
Since it says "retain", I'm assuming that whatever value is stored in tempScreenshot is retained.
Do I have to release tempScreenshot in the dealloc method of my class?
Also, if I use the set method to give a new value to tempScreenshot, this new value will be retained, right? What happens to the old value?
Since you're saying "retain" I am assuming this is manual memory management code. If at all possible, you should switch to automatic reference counting (ARC). It dramatically simplifies this work and is faster than the equivalent manual code. Other than support for older OSes, there is almost never a reason to do manual memory management anymore.
Since it says "retain", I'm assuming that whatever value is stored in tempScreenshot is retained.
Whenever you call [self setTempScreenshot:], the accessor will retain the parameter and release the old value. Assigning the ivar directly will not give you any of this. You should always use the accessor except in init and dealloc.
Do I have to release tempScreenshot in the dealloc method of my class?
Yes.
Also, if I use the set method to give a new value to tempScreenshot, this new value will be retained, right? What happens to the old value?
It will be released as long as you use the accessor.
The retain keyword marks the property as retain upon assignment, meaning that on a set, retain will be called on the new value, and release will be called on the old value.
You will need to release the object on dealloc.
In your dealloc method, do: self.tempScreenshot = nil;
This will cause the object to be released. It will then be deallocated assuming nothing else has retained it.
If you were to write your own setter method to retain an object it would look like this.
//Assume an instance variabled name obj for this example
- (void)setAndRetainObjectExample:(NSObject *)newObj {
[obj release];
obj = newObj;
[obj retain];
}
Using the synthesized methods is much cleaner, but looking at it this way may clear up any confusion.
I know this has been answered before (sort of) but I've been reading conflicting answers on exactly when or when not to release an object that has not been specifically subclassed via an allocation.
For example, if I do the following:
#property (..., retain) NSMutableArray *myArray;
or in general,
#property (some retain attribute - strong, weak, retain) type myObject;
After synthesization, If I do nothing else to myObject (no allocation or even forget to use it), are there any cases in which I'm still responsible to release it?
There are two totally different answers depending on whether or not you're using ARC. Since the ARC environment is pretty straight forward, I'll just answer from a pre-ARC perspective. The main thing to understand is that all of the talk around property retain semantics is just a distraction from the main point: If you take ownership, you must relinquish it. Relinquishing ownership is done via -release. So, what you need to understand is "What counts as taking ownership?"
By convention, any time you send a message to class that contains any of [new, alloc, retain, copy], you now own that object. The compiler generates setter methods for Objective C Properties depending on the ownership policies you specify. For example...
#property (..., retain) NSMutableArray *myArray;
#synthesize myArray = _myArray;
This generates a method that looks like this1:
- (void)setMyArray:(NSMutableArray *)myArray
{
// This is oversimplified, just to illustrate the important point.
// Again, this is NOT the way a setter would actually be synthesized.
[_myArray release];
_myArray = [myArray retain];
}
So now, when you say something like self.myArray = someArray, you know you've sent a retain message to someArray, and you're responsible for releasing it later. The ideal way to do that is to say self.myArray = nil, because it releases the old value before retaining nil. Note that it's also perfectly safe to send that message, even if you never set anything to the myArray property, because sending messages to nil is okay. That's why it's common to always set owned properties to nil when you're done with them, regardless of how they're being used.
1 For a study on how accessors should actually work, see this article.
I'm declaring an ivar of type NSString on a class. To initialize the value of this ivar I use the following code:
NSString *myVar;
-(void)inAnyMethod
{
myVar = [NSString stringWithFormat:#"%#",theValue];
}
Do I have to release this ivar? According to my understanding, it is not my responsibility. But in most cases, strings that I use in this manner cause leaks.
What am I missing?
You do not have to release it, because that is a convenience method that returns an autoreleased object.
The way to know if you are getting something with a retain count of 1 that you will need to release is using the Cocoa naming conventions which say that anything that starts with new, alloc or contains copy in the method name will return a retain 1 object, the others will return autoreleased objects like in this case.
In addition to Oscar Gomez answer, note that when you use class methods (those methods with plus sign that you can find in the documentation and are not included in Oscar Gomez list, e.g. stringWithFormat is one of them), you have not to worry about memory management. If you create your own class method, you should do the same: return an autorelease object.
Regarding your code, it cannot work if you simply assign your ivar to the NSString object (returned from that method). In fact, at some point of your application cycle, the object will be released (it has been put in a pool) and your ivar will not reference any object anymore.
The trick: create a #property with a copy policy or send a copy message like the following:
myVar = [[NSString stringWithFormat:#"%#",theValue] copy];
Copy is normally used when a class has subclasses of mutable type. Otherwise use retain. Once done, you have the possession for that object and you have to remember to release it. If you don't do it you cause a leak.
[myVar release];
P.S. Since Xcode 4.2 there is a new compiler feature called ARC.
Hope it helps.
When is self needed for class properties? For example:
self.MyProperty = #"hi there";
vs
MyProperty = #"hi there";
MyProperty is an NSString set as (nonatomic, copy). Is there any difference in memory management for the above two?
What about when there is no property and the variable MyProperty is declared in the header file? Is a property needed if it is never referenced outside of the class? Does it make a difference to memory management?
Yes, there is a difference for both memory and performance.
MyProperty = #"hi there";
This is considered a direct assignment. There is practically no memory or performance impact. Of course, that's not to say it's best practice - that's a different question :)
#property(nonatomic, copy) NSString *MyProperty;
// ...
self.MyProperty = #"hi there";
This statement has a significant impact on memory and performance. This is essentially equivalent to:
-(void)setMyProperty(NSString *)newValue {
if (MyProperty != newValue) {
[MyProperty release];
MyProperty = [newValue copy];
}
}
The old value is released and the new value is copied into MyProperty. This is acceptable and especially typical when dealing with strings when the string your assigning is mutable (ie, it could change later).
If, as in your example, you're simply assigning a static string (#"hi there"), there is nothing wrong with directly assigning the string value; it's more efficient however the difference in performance is trivial.
You can declare a property with #property as retain, copy, or assign (default is assign). You can then generate "accessor" (getter/setter) methods by using #synthesize. Here is what the setter methods look like that are generated when you do so:
// #property(nonatomic, assign)
-(void)setMyProperty(NSString *)newValue {
MyProperty = newValue;
}
// #property(nonatomic, retain)
-(void)setMyProperty(NSString *)newValue {
if (property != newValue) {
[property release];
property = [newValue retain];
}
// #property(nonatomic, copy)
-(void)setMyProperty(NSString *)newValue {
if (property != newValue) {
[property release];
property = [newValue copy];
}
}
More information on ObjectiveC Declared Properties.
"You can use the #synthesize and #dynamic directives in #implementation blocks to trigger specific compiler actions. Note that neither is required for any given #property declaration.
Important: If you do not specify either #synthesize or #dynamic for a particular property, you must provide a getter and setter (or just a getter in the case of a readonly property) method implementation for that property."
In other words, if you declare a property but don't synthesize the property, you won't be able to use [self MyProperty] or self.MyProperty unless you define 'MyProperty' and 'setMyProperty' methods. If you don't declare a property then you simply have an instance variable.
Note: #dynamic doesn't generate the accessors. It's really used if you're dynamically (ie, magically) resolving accessor methods via loading code or dynamic method resolution.
The difference is that
self.MyProperty = #"hi there"
is dot-notation call that will call the generated accessor, which will handle the retain counts correctly (equivalent to [self setMyProperty:#"hi there"]), whereas
MyProperty = #"hi there"
is a direct assignment to your member variable, which doesn't release the old value, retain the new one, or do anything else your accessor does (e.g., if you have a custom setter that does extra work).
So yes, there is a big difference in memory management and in behavior in general between the two. The latter form is almost always wrong, unless you know specifically why you are doing it and that you are handling the retain counts correctly yourself.
If you use automatic Key-Value Observing (or any Cocoa technology that builds on it - like bindings, ...), it is also important use the setter. The observer would not receive any notification if you assign to the ivar.
If you bind "MyProperty" to a NSTextfield and you change your "MyProperty" ivar via code, the bound textfield would still display the old value as it did not receive any change notification.
To access a variable, there is often no need to use the dot notation. Thus, in code generated by the XCode templates, you will see things like:
[flipsideViewController viewWillAppear:YES];
There is no need to write self.flipsideViewController here, because the accessor method typically does nothing except handing you the variable.
So a good rule of thumb is to use dot notation when you are setting a variable (absolutely necessary unless you want to do your own retaining and releasing), but not when you're accessing it:
self.aString = #"Text text text";
NSLog (aString); // No need for self.aString here
NSString* tmpString = aString; // Here neither
When you're using non-object types, like int or float or many others, you can get away with not using the dot notation/setter method. In these cases, there is nothing to retain, so the setter method will do little apart from just assigning the value.
However, synthesized getters and setters do more than just retaining and releasing. As others have mentioned, they are also the engine that keeps the KVO system running. Thus, you should use the proper setters even on ints, floats and the rest.
What about the accessors then? In more advanced contexts, a class might respond to a request for a variable's value even when the variable doesn't exist. To quote the exalted Objective-C manual, classes might provide "method implementations directly or at runtime using other mechanisms [than simple accessor methods] such as dynamic loading of code or dynamic method resolution."
(One way of implementing this sort of on-the-fly response to messages is by overriding NSObject methods like methodSignatureForSelector: and forwardInvocation: .)
For this reason, using properly declared interfaces (whether synthesized or not) is always a good idea when you're working on something big. But it's completely ok to access ivars directly, as long as you set them using the proper API.
(Note: I'm not a Cocoa guru, so corrections are more than welcome.)
For the second part of the question, property definition is not needed, it is a help to us . The #synthesize directive on property generates accessor methods for properties so we don't have to do it manually, and because:
This code instructs the compiler to
generate, or synthesize, the accessor
methods. The compiler will generate
the accessor methods using
well-tested, fast algorithms that are
ready for multi-core and
multi-threaded environments, including
locking variables in setter methods.
Not only does using properties reduce
the amount of code that you have to
write, it replaces that code with the
best possible accessors for today's
modern multi-core systems. Later, if
you need to provide an alternative
implementation for a property
accessor, you can simply add the
appropriate code to your class.
http://developer.apple.com/leopard/overview/objectivec2.html
The nonatomic will avoid use of locking when accessing variables, if you don't specify anything then default is atomic. Locking is useful on multithreaded systems. The copy specifies what code should be generated for accessors, copy will copy the object, retain will retain new object and release old one, assign is good for simple variables like int to just plain assign values.
So when you define your property as you did above (nonatomic,copy) and then use self.MyProperty = #"Hey" you're actually calling generated accessor that will make a copy of the new variable as opposed to just assigning it. You can override accessor and add checking to it.
Because of the above I would say that defining property has benefits even when the variable is not used outside of the class.
I believe to access properties you should use self.MyProperty instead of just MyProperty but I can't point you to explanation why.
Might be something to do with the fact that compiler will generate from
self.MyProperty = #"Hey";
this:
[self setMyProperty: #"Hey"];
But I'm only speculating here.
Whether you call self.MyProperty or MyProperty it should not affect memory management (I would still prefer the first - self.MyProperty).
See Objective-C 2.0 Overview for some high level description from Apple.
As a supplement to the other answers, try to think of it this way:
self.MyProperty = #"hi there";
or
[self setMyProperty:#"hi there"];
(which are equivalent) both call a method, whereas
MyProperty = #"hi there";
Simply sets a variable.
This is an old question, though it used to be "When do I write [self setMyProperty:#"hi there"]?" (Note that self.MyProperty = #"hi there" is exactly equivalent to this.)
The answer I've always heard (and which makes good sense) is always use the accessor; never write MyProperty = #"hi there". There are several reasons:
Memory management is handled for you; you don't have to worry about proper retaining/releasing/copying.
It's easier to modify your code in the future; if at some point you realize that changing MyProperty needs to have a particular side effect, you can add to the setter method without finding every time you set MyProperty.
If you ever have problems with MyProperty, it's easy to add logging code to the setter (or even getter) to find out every time it's changed (or even accessed).
Summary: it's safest and most flexible to always use [self setMyProperty:#"hi there"] or self.MyProperty = #"hi there", and never use MyProperty = #"hi there".
Still not clear on when to use the accessors and when to do direct assignment on ivars ? I have seen lot of Apple examples which directly access the ivars. So using properties for all ivars seems pedantic overkill.
It seems only significant ivars which need to be around longer and are accessed outside tend to use the properties.
Would appreciate some Cocoa gurus to step in and clarify.