Cocoa: Point local variable to object property (double)

Question

Every few months I try to re-learn Cocoa because I have no real use for programming iOS other than as a hobby. I'm going back over the basics and looking at what's different with the dot notations; for instance, seeing how the API has been updated to do common tasks by default.

There is plenty of documentation, which is good, but can also be a bad thing when you want to get up and running quickly. While it is slowly coming back, I consider myself a born-again neophyte on the subject, so any help is appreciated.

---

header file:

@interface FooClass : NSObject
{
@private
    double foo;
}
@property (nonatomic) double foo;
@end

implementation file:

@implementation FooClass
@synthesize foo = _foo;
- (void) doSomething
{

}
@end

Inside the doSomething implementation, is it possible to have a local variable (e.g. bar) that is a pointer to the class's foo, such that when bar is get/set foo is updated (local alias)? I've tried variations of:

double bar = *self.foo;
double *bar = self.foo;
double *bar = *self.foo;
double *bar = &self.foo;

bar=5;

If so, what's the right syntax? Also, something is telling me this is a bad idea, so why might it be?

---

Edit: It looks like after some more searching I found something similar: objective-c: double pointers to property not allowed? Now, I'll try to make sense of it.

Answer 1

Your example contains a mistake:

@interface FooClass : NSObject
{
@private
    double foo;
}
@property (nonatomic) double foo;
@end

This declares a property foo. It also declares an ivar (instance variable) foo, which one might assume was the ivar associated with the property of the same name.

@implementation FooClass
@synthesize foo = _foo;
@end

Unfortunately, the @synthesize statement says "synthesize the foo property and create an ivar called _foo for it." So, you now have two ivars, foo (which you created between the {} in the @interface), and _foo, which you just synthesized as the ivar associated with the foo property. That's not good that that you have the foo ivar floating out there, which was explicitly declared, leading the reader to assume that it would be associated with the property of the same name, but it's not, because _foo is.

Long ago, you would have been advised to fix your explicit ivar declaration, e.g.

@interface FooClass : NSObject
{
@private
    double _foo;
}
@property (nonatomic) double foo;
@end

But even better now, it's advised that you omit the explicit ivar definition for a property altogether, and let the @synthesize statement create that ivar for you, eliminating any possibility of the problems we describe above, e.g., simply:

@interface FooClass : NSObject
@property (nonatomic) double foo;
@end

Furthermore, the @synthesize statement is now optional, and if omitted, it will end up doing precisely what you suggested @synthesize foo = _foo;.

And in answer to your question about about having a variable to access your property, that's what the _foo instance variable is. Why do you need another variable? And, besides, you should generally use the getter.

It's generally advisable to not use the ivar for setting the property, but rather use the property's accessor. This counsel would apply to any attempts to change the value of the property through a local variable, too. The only time you absolutely should be using the ivar is in your initializer and dealloc methods.

By the way, that reference to "Use Accessor Methods to Set Property Values" is a roundabout answer to your main question (at least if you were ever tempted to use that local variable to change the value of the property). You should only be using the object setter accessor for changing a property's value. The setter does important stuff that it would be unwise to bypass. To answer your final question would be, in effect, instructing you how to do the wrong thing in a way that doesn't generate a compiler warning, and thus I hesitate to go there.

Some relevant references include:

• Programming with Objective-C

• Practical Memory Management in the Advanced Memory Management Programming Guide.