Difference between _ and self. in Objective-C

Question

Is there a difference between using the underscore and using the self keyword in Objective-C when calling an @property?

Property declaration:

@property (weak, nonatomic) NSString *myString;

Calling @synthesize on the property:

@synthesize myString = _myString;

Is there a difference if I want to use it in my code? When? In the getter/setter?

self.myString = @"test";
_myString = @"test";

Solution 1

self.myString = @"test"; is exactly equivalent to writing [self setMyString:@"test"];. Both of these are calling a method.

You could have written that method yourself. It might look something like this:

- (void)setMyString:(NSString*)newString
{
    _myString = newString;
}

Because you used @synthesize, you don't have to actually bother writing that method, you can just allow the compiler to write it for you.

So, from looking at that method, it looks like calling it will do the exact same thing as just assigning a value to the instance variable, right? Well, it's not so simple.

Firstly, you could write your own setter method. If you do so, your method would get called, and it could do all sorts of additional things as well as setting the variable. In that case, using self.myString = would call your method, but doing _myString = would not, and thus different functionality would be used.

Secondly, if you ever use Key Value Observing, the compiler does some very clever tricks. Behind the scenes, it subclasses your class, and overrides your setter method (whether it's one you wrote yourself or one generated by synthesize), in order to make the calls to willChangeValueForKey: that are needed for Key Value Observing to work. You don't need to know how this works (although it's quite interesting if you want some bedtime reading!), but you do need to know that if you want Key Value Observing to work automatically, you have to use setter methods.

Thirdly, calling the setter method even if you're relying on synthesize to write one gives you flexibility for the future. You might want to do something extra whenever a value is changed, and at the point you discover you want to do that, you can manually write a setter method — if you're in the habit of always using self.myString =, then you won't need to change the rest of your code to start calling the new method!

Fourthly, the same applies to subclasses. If someone else was to subclass your code, if you use the setters then they could override them to adjust the functionality.

Any time you access the instance variable directly, you're explicitly not providing a way for extra functionality to be hooked in at that point. Since you or someone else might want to hook in such functionality in the future, it pays to use the setters all the time, unless there's a good reason not to.

Solution 2

You are correct - the first version (self.myString) calls the synthesized getter/setter and the second version access the private member variable directly.

It looks like you are using ARC, so in that case it doesn't make that much of a difference. However, if you aren't using ARC, it can make a difference as assigning to the private member directly won't trigger the automatic retain/release or copy/release logic that is generated for you by using synthesize.

Solution 3

The _ (underscore) is simply a convention, as explained in this question.

When you don't prefix a property access with self., you are accessing the underlying variable directly, as in a c struct. In general, you should only ever do this in your init methods and in custom property accessors. This allows stuff like computed properties and KVC to work as intended.

Comments

[Hot Licks]

They're two different symbols. One could be "aardvark" and the other "zebra" and still have the variable-setter/getter relationship.

[Eric Petroelje]

@Hot Licks - You are correct that the names are irrelevant, but as I read the question, I think he was wondering what the practical difference is between using the synthesized property vs. just using the member variable backing it.

[Jakub]

@EricPetroelje - yes, that exactly what I asked. Thanks!

[Amy Worrall]

Note that I didn't mention the memory management implications. If you're using ARC, they're a lot less relevant in this case, so I skipped over them.

[Todd Lehman]

By the way, regarding the first sentence... This is true 99% of the time, but if you have a custom setter (specified with setter= in the property declaration), then the two forms are not exactly equivalent.