How exactly getter and setter methods body looks like after they have been automatically synthesized ?
From official documentation I found so far only recommended implementation techniques, however no word about which of them used by compiler during synthesizing process: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAccessorMethods.html#//apple_ref/doc/uid/TP40003539-SW5
Some techniques recommends implementations containing autorelease message, which is not quite secure for multithreaded programming. I'm just wonder if auto-generated code follows to some of the proposed implementations.
For example:
.h
#interface AClass: NSObject{}
#property (nonatomic, retain) AnotherClass *aProp;
#end
.m
#implementation AClass
#synthesize aProp
-(id) init {
if ((self = [super init])) {
self.aProp = [[AnotherClass alloc] init]; // setter invocation
}
return self;
}
-(AnotherClass *) aMethod {
return self.aProp; // getter invocation
}
#end
What are equivalent accessors code snippets for aProp generated by compiler ?
-(AnotherClass *) aProp {
// getter body
}
-(void) setAProp: (AnotherClass *) {
// setter body
}
When declaring a property as nonatomic, you'll get the following:
// .h
#property (nonatomic, retain) id ivar;
// .m
- (id)ivar {
return ivar;
}
- (void)setIvar:(id)newValue {
if (ivar != newValue) { // this check is mandatory
[ivar release];
ivar = [newValue retain];
}
}
Note the check ivar != newValue. If it was absent, ivar could be dealloc'ed after release, and the following retain would cause a memory access error.
When you declare your property with copy, the code will look almost the same, with retain replaced by copy.
For assign, it is even simpler:
- (void)setIvar:(id)newValue {
ivar = newValue;
}
Now, when you declare your property as atomic (this one is the default), things get slightly more complicated. A snippet similar to the one below was posted by one of Apple's engineers on the development forums:
- (id)ivar {
#synchronized (self) {
return [[self->ivar retain] autorelease];
}
}
- (void)setIvar:(id)newValue {
#synchronized (self) {
if (newValue != self->ivar) {
[self->ivar release];
self->ivar = newValue;
[self->ivar retain];
}
}
}
Note the #synchronized block in both methods and additional retain-autorelease in the getter. Both those things ensure that you will either get the previous value (retained and autoreleased) or a new one in the case the value is changed by some thread while you are trying to read it.
It depends on the attributes you set, for instance with a RETAIN attribute...
- (void)setAProp:(AnotherClass *)value {
[aProp release];
aProp = value;
[aProp retain];
}
For ASSIGN attribute....
- (void)setAProp:(AnotherClass *)value {
aProp = value;
}
For COPY attribute (used with NSString)...
- (void)setAProp:(AnotherClass *)value {
aProp = [value copy];
}
Related
Here's a little example of using weak arguments:
#interface MYTestObject : NSObject
#end
#implementation MYTestObject {
void(^_block)(void);
}
- (void)dealloc {
NSLog(#"DEALLOC!");
}
- (id)init {
if (self = [super init]) {
[self doSomethingWithObject:self];
}
return self;
}
- (void)doSomethingWithObject:(id __weak /* <- weak argument! */)obj {
_block = ^{
NSLog(#"%p", obj);
};
}
#end
And it works: -dealloc is called!
Also, if you remove __weak you'll get a retain-cycle and it's absolutely correct.
Wonder, if that's just a side-effect and it's completely unsafe to use weak arguments? Or is it a specified behavior and I'm just a bad google-user?
Two observations:
I'd be inclined to make a local __weak reference within doSomethingWithObject, rather than make it a __weak argument as illustrated in Avoid Strong Reference Cycles when Capturing self.
I don't think that it is, as you asked, "completely unsafe to use weak arguments." But if nothing else, it's the more common pattern to have a local __weak variable and strikes me as more appropriate as an implementation detail of doSomethingWithObject rather than part of the method's public interface.
I'd also make block a property with the copy memory qualifier. As the docs say
You should specify copy as the property attribute, because a block needs to be copied to keep track of its captured state outside of the original scope. This isn’t something you need to worry about when using Automatic Reference Counting, as it will happen automatically, but it's best practice for the property attribute to show the resultant behavior.
Thus:
#interface MYTestObject : NSObject
#property (nonatomic, copy) void(^block)(void);
#end
#implementation MYTestObject
- (void)dealloc {
NSLog(#"DEALLOC!");
}
- (id)init {
if (self = [super init]) {
[self doSomethingWithObject:self];
}
return self;
}
- (void)doSomethingWithObject:(MYTestObject *)obj {
typeof(obj) __weak weakObj = obj;
self.block = ^{
NSLog(#"%p", weakObj);
};
}
#end
Here is how I used to write a custom retained setter before:
- (void)setMyObject:(MyObject *)anObject
{
[_myObject release], _myObject = nil;
_myObject = [anObject retain];
// Other stuff
}
How can I achieve this with ARC when the property is set to strong.
How can I make sure that the variable has strong pointer?
The strong takes care of itself on the ivar level, so you can merely do
- (void)setMyObject:(MyObject *)anObject
{
_myObject = anObject;
// other stuff
}
and that's it.
Note: if you're doing this without automatic properties, the ivar would be
MyObject *_myObject;
and then ARC takes cares of the retains and releases for you (thankfully). __strong is the qualifier by default.
Just to sum up the answer
.h file
//If you are doing this without the ivar
#property (nonatomic, strong) MyObject *myObject;
.m file
#synthesize myObject = _myObject;
- (void)setMyObject:(MyObject *)anObject
{
if (_myObject != anObject)
{
_myObject = nil;
_myObject = anObject;
}
// other stuff
}
I have read a lot of topics about getters and setters. I know what they are and why are useful. Different source claim's different ways to release the ivars. Here begins my confusion
#interface CoolClass : NSObject
{
NSString *name;
}
#property (nonatomic, copy) NSString *name;
#end
#implementation CoolClass
#synthesize name = _name;
-(id)init
{
if(super = [self super])
{
self.name = #"Jo";
}
return self;
}
-(void)dealloc
{
[self.name release], self.name = nil;
}
#end
Is that the correct way to release/free ivars ?
You'll want to use accessors most of the time, but not in partially constructed states because they can have negative side-effects. Here's how it's done:
- (id)init
{
if((self = [super init])) {
// self.name = #"Jo"; << don't use accessors in initializer
_name = [#"Jo" copy]; << good
}
return self;
}
// added for another variation:
- (id)initWithName:(NSString *)inName
{
if((self = [super init])) {
_name = [inName copy];
}
return self;
}
- (void)dealloc
{
// don't use accessors in dealloc
// don't release the result of a getter (release the result of the retained or copied result)
// [self.name release], self.name = nil;
// instead:
[_name release], _name = nil;
[super dealloc]; << compiler should have warned you about this one
}
Note: In the case of init, the string literal is an immortal and it won't matter if you copy it because the copy just returns itself. My preference is to just 'copy' the immortal for clarity, although it's unnecessary.
Here is what I would advise:
#interface CoolClass : NSObject
#property (nonatomic, copy) NSString *name;
#end
#implementation CoolClass
#synthesize name = _name;
-(id)init
{
if(super = [self super])
{
self.name = #"Jo";
}
return self;
}
-(void)dealloc
{
[_name release];
[super dealloc];
}
#end
Notes:
There is no need to explicitly declare ivars inside { ... } in your header. They will be created automatically when you synthesise your property. Explicit ivars are a legacy concept that are no longer needed since about iOS 3.
You should not use self.name in the dealloc as this calls the getter method, which may do additional work beyond merely fetching the ivar. Normally it's good practice to use the getter method, but in the dealloc you should release the ivar directly
It is good practice to set ivars to nil after releasing them, but again in the dealloc this in not necessary because no code is ever executed after dealloc, so the pointer won't be referenced again.
Normally (outside of the dealloc), if you wish to release an ivar you should set it to nil using the setter like this: self.name = nil; that will automatically release it and set it to nil. This is equivalent to [_name release], _name = nil;
#interface CoolClass : NSObject
{
NSString *name;
}
You declared here an instance variable 'name'; Nowadays there is no need to declare ivars in the header file. Just use properties and make the compiler to synthesize ivar for you.
#property (nonatomic, copy) NSString *name;
Here we have a property declaration that specifies that a copy of the object should be used for assignment and that a previous value is sent a release message.
In implementation you want to synthesize your property:
#synthesize name = _name;
This code tells the compiler to generate a getter and setter for property called 'name' and use instance variable called '_name' to store value. So you have now two ivars - 'name' and '_name'.
That how init method should like like:
-(id)init
{
if(self = [super init])
{
name = #"This is ivar declared between {}";
_name = #"synthesized ivar";
}
return self;
}
And the dealloc:
-(void)dealloc
{
[name release];
[_name release];
[super dealloc];
}
How exactly getter and setter methods body looks like after they have been automatically synthesized ?
From official documentation I found so far only recommended implementation techniques, however no word about which of them used by compiler during synthesizing process: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAccessorMethods.html#//apple_ref/doc/uid/TP40003539-SW5
Some techniques recommends implementations containing autorelease message, which is not quite secure for multithreaded programming. I'm just wonder if auto-generated code follows to some of the proposed implementations.
For example:
.h
#interface AClass: NSObject{}
#property (nonatomic, retain) AnotherClass *aProp;
#end
.m
#implementation AClass
#synthesize aProp
-(id) init {
if ((self = [super init])) {
self.aProp = [[AnotherClass alloc] init]; // setter invocation
}
return self;
}
-(AnotherClass *) aMethod {
return self.aProp; // getter invocation
}
#end
What are equivalent accessors code snippets for aProp generated by compiler ?
-(AnotherClass *) aProp {
// getter body
}
-(void) setAProp: (AnotherClass *) {
// setter body
}
When declaring a property as nonatomic, you'll get the following:
// .h
#property (nonatomic, retain) id ivar;
// .m
- (id)ivar {
return ivar;
}
- (void)setIvar:(id)newValue {
if (ivar != newValue) { // this check is mandatory
[ivar release];
ivar = [newValue retain];
}
}
Note the check ivar != newValue. If it was absent, ivar could be dealloc'ed after release, and the following retain would cause a memory access error.
When you declare your property with copy, the code will look almost the same, with retain replaced by copy.
For assign, it is even simpler:
- (void)setIvar:(id)newValue {
ivar = newValue;
}
Now, when you declare your property as atomic (this one is the default), things get slightly more complicated. A snippet similar to the one below was posted by one of Apple's engineers on the development forums:
- (id)ivar {
#synchronized (self) {
return [[self->ivar retain] autorelease];
}
}
- (void)setIvar:(id)newValue {
#synchronized (self) {
if (newValue != self->ivar) {
[self->ivar release];
self->ivar = newValue;
[self->ivar retain];
}
}
}
Note the #synchronized block in both methods and additional retain-autorelease in the getter. Both those things ensure that you will either get the previous value (retained and autoreleased) or a new one in the case the value is changed by some thread while you are trying to read it.
It depends on the attributes you set, for instance with a RETAIN attribute...
- (void)setAProp:(AnotherClass *)value {
[aProp release];
aProp = value;
[aProp retain];
}
For ASSIGN attribute....
- (void)setAProp:(AnotherClass *)value {
aProp = value;
}
For COPY attribute (used with NSString)...
- (void)setAProp:(AnotherClass *)value {
aProp = [value copy];
}
Is it safe to say that if a class member does not need getter or setter functions then there's no point in making them properties and synthesizing them?
Well, yes, but often properties can be helpful in the implementation itself even if the properties won't be set outside of the implementation.
For example, suppose you had
#interface SomeObject : NSObject {
NSThing *thing;
}
#end
#implementation SomeObject
- (id)init {
if((self = [super init]))
thing = [[NSThing someThing] retain];
return self;
}
- (void)someMethod {
if(thing)
[thing release];
thing = [[NSThing someOtherThing] retain];
}
// etc etc
#end
Why would you want to bother having to check if thing had been allocated, release thing, set it to something else, and then retain it again, when you could simply do:
- (id)init {
if((self = [super init]))
[self setThing:[NSThing someThing]];
return self;
}
- (void)someMethod {
[self setThing:[NSThing someOtherThing]];
}
If you don't want to make these properties accessible outside of your class, you can use a category
#interface SomeObject ()
#property (retain) NSThing *thing;
#end
in your .m file.