Question

Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?

---

Note: For the folks digging around trying to understand this, I figured-out the source of my confusion. In the .h, I had:

...
@interface myClass : parentClass {
className *variableName:
}

@property (strong, nonatomic) className  *variableName;
...

This leads to self.variableName and _variableName being two distinct variables in the .m. What I needed was:

...
@interface myClass : parentClass {
className *_variableName:
}

@property (strong, nonatomic) className  *variableName;
...

Then, in the class’ .m, self.variableName and _variableName are equivalent

---

In brand-new, Xcode 4.5+, with ARC, targeting iOS 5.0+ project, is there a distinct advantage (runtime efficiency, speed, etc.) to using _variableName over self.variableName vs. the old-style @synthesize variableName?

My understanding is that Xcode 4.5+ will create a default accessor _variableName that is equivalent to self.variableName and the only reasons not to use @synthesize variableName is to avoid confusion between iVars and passed-in variables, correct?

To me, just using self.variableName to access an iVar seems the most straightforward and clear as to which variable you’re looking for. Other than typing _ vs. self., is there an advantage to using _variableName?

Answer 1

My understanding is that Xcode 4.5+ will create a default accessor “_variableName” that is equivalent to self.variableName and the only reasons not to use “@synthesize variableName” is to avoid confusion between iVars and passed-in variables, correct?

In this case, _variableName isn’t the accessor, it’s an ivar that is automatically generated by the compiler and used in the automatically @synthesized setters and getters. Generally, it is considered best to use accessors whenever possible (i.e. self.variableName) so that things like key-value observation and bindings work for that property.

When you access an ivar directly, it is accessed via direct memory access, the same way you would access data in a struct. It simply takes the pointer for the object that owns the ivar, offsets the memory address and attempts to read or write to the memory at that location. Using dot notation (self.variableName) calls the accessor methods to set or get that property and can do a number of different things along the way, such as:

1) Locking: If the property is going to be used in multiple threads and is an atomic property, the runtime will automatically do some locking to make sure that the property is not accessed at the same time from multiple threads. If your object is not meant to be used on multiple threads, you can give the nonatomic hint in your property declaration so that the synthesized accessors skip the locking.

2) Key-Value Notifications: The default setters for properties call -willChangeValueForKey: and -didChangeValueForKey:, which sends out notifications when the property is changed. This is necessary for anything to update properly if bindings are used, and for any other key-value observation.

3) Custom accessor behavior: If you end up writing your own setters and getters, any custom stuff that you implement within those.

Technically, accessing the ivar directly is faster than using accessors, but there are very few situations in which it will make a significant performance difference, and would probably be a case of premature optimization. Even if you don’t feel like you would be using the benefits listed above right away, it’s probably better to use the accessors anyway so that if you decide later on you need some of that functionality, you don’t have to change every instance of accessing that variable (and possibly be creating unexpected new bugs in the process).

In addition, if you are accessing ivars directly and end up refactoring your class into categories or subclasses, it gets messy because you usually have to declare the ivar as a @protected variable. You wouldn’t have to do this if you are using the accessors.

Generally, I try to only access the ivars directly in init, dealloc, and the property’s accessor. A lot of engineers go by this rule of thumb because sometimes the custom stuff that happens in accessors can cause unexpected behavior while the object is init‘ing or dealloc‘ing. For example, if anything in the accessors causes something to retain or release your object or even form a zeroing weak reference to it, it will cause a crash if used in dealloc.