CODEWITHSUNDEEP
objective-cios
user953175
user953175

Reputation: 205

IOS objective-C instance vars -- what's the difference

What is the difference between declaring variables in the interface section vs. in the implementation section outside of a method.

Upvotes: 0

Views: 400

Answers (3)

CRD
CRD

Reputation: 53010

A variable declared in the @interface is an instance variable. In more recent compilers instance variables can also be declared in a block in the @implementation in a similar way to doing so in the @interface - this effects their visibility but not their lifetime.

A variable declared "outside of a method" in the implementation, as in:

@implementation

static int CallCount = 0;

is the closest thing Objective-C has to a class variable - a variable which all instances of a class share, as opposed to instance variables where each object instance has its own variable.

Such a variable has execution lifetime - it exists throughout a single execution of the whole application - just as typical class variables do in other languages. (The lifetime of instance variables is that of the object instance they belong to.)

The use of static further limits the visibility (not its lifetime) of the variable name to just the file containing the declaration - like a private class variable in other languages. Note that, unlike most languages class variables, variables declared in an @implementation without a static qualifier are added to the global namespace and thus increase the opportunities for name collisions - this is why they are not real class variables.

Such class variables are often initialized using the class method + initialize, just as instance variables are initialized using the instance method - init.

Upvotes: 2

justin
justin

Reputation: 104708

Declaring them in a class extension is often used in attempt to hide the instance variables and associated accessors from the client. Neither approach truly hides them, but hiding them is usually an improvement, and is available only if all compilers you need support it.

Upvotes: 1

Lily Ballard
Lily Ballard

Reputation: 185821

Do you mean in the ivar block in the implementation, as in

@implementation MyClass {
    id someIvar;
}
// methods go here
@end

If so, then the only difference is visibility to other code. At runtime, the ivar will be indistinguishable from one declared in the @interface section. However, code outside the class can see ivars declared in @interfaces, and unless those ivars are marked with @protected or @private, then the other classes can reach in and twiddle the ivars. But ivars declared in the @implementation are not even visible to code outside, so they cannot touch the ivars.

For the most part, this is just a code cleanliness issue. Nothing should go in the header file unless it's meant to be public. So why put ivars there?

As Josh Caswell noted, ivars declared in this fashion require a recent version of Clang.

The alternative interpretation of your question is you have code like

@implementation MyClass

- (void)someMethod { /* ... */ }

NSString *var;

- (void)otherMethod { /* ... */ }
@end

If this is what you meant, then the answer is, don't do that. In this code snippet we've declared a global variable named var rather than an instance variable. The location of the variable inside the @implementation block is irrelevant, it's exactly identical to a global variable in C (because that's what it is).

Upvotes: 7

Related Questions