I am just starting out with Objective C trying out a sample program about fractions from the Programming in Objective C book:
#import <Foundation/Foundation.h>
//---- #interface section ----
#interface Fraction: NSObject
-(void) print;
-(void) setNumerator: (int) n;
-(void) setDenominator: (int) d;
#end
//---- #implementation section ----
#implementation Fraction
{
int numerator;
int denominator;
}
-(void) print
{
NSLog (#"%i/%i", numerator, denominator);
}
-(void) setNumerator: (int) n
{
numerator = n;
}
-(void) setDenominator: (int) d
{
denominator = d;
}
#end
//---- program section ----
I keep getting the inconsistent instance variable specification error for the instane variables numerator and denominator.If I move the declarations to the #interface section, the error goes away but I want to know why I am getting this error? I am using Xcode 3.6.2 on Snow Leopard 10.6.8
You're getting an error because ivars needs to be declared in the interface.
By the way, you're using a veeeeery old version of xcode (probably too old to submit to the appstore), so you might want to look into getting xcode 4.6. There's also been many updates to the Objective-C language. In modern objective-c, there is no longer a need to manually declare ivars like this.
If you REALLY would like to keep ivars out of the header file, you can declare them in an empty category interface (also called a "class extension") like this, in the .m file:
#interface YourClass() {
ivars here
}
#end
Instance variables in #implementation blocks are only supported since Xcode 4.2 (LLVM compiler version 3.0). You must upgrade your development tools to take advantage of this feature.
The motivation for this language feature is to achieve better information hiding in your class structure. That means that clients of your interface (your .h file) may not need to be aware of the ivars the class is using, so they are "hidden" in the implementation file.
Another way to hide ivar is to include them in a class extension in your implementation (.m) file:
// Fraction.m
#interface Fraction () {
int numerator;
int denominator;
}
#end
#implementation Fraction
// ...
#end
But it also requires Xcode 4.2+ and a modern runtime environment.
For complete compatibility with old compilers, ivars can only be placed in the interface section of the .h file.
Related
Sometimes I declare an ivar but after a while I am no longer using it. I would like to remove this sort of cruft from my code, but I cannot find a warning that will show me my unused ivars.
Is there a tool or built in feature of Xcode that will allow me to find all of my unused ivars?
I see that the static analyzer has CLANG_ANALYZER_OBJC_UNUSED_IVARS, but it does not seem to do anything.
#implementation AppDelegate
{
#private
BOOL _foo; // Never read or written to
}
Runing the analyzer in Xcode 5 with CLANG_ANALYZER_OBJC_UNUSED_IVARS (unused ivars) set to YES never produces a warning.
Based on the relevant Clang source code and a couple of quick tests, it seems that the analyzer does not look at ivars that are not both declared in the #interface and marked #private.
#interface Igloo : NSObject
{
NSString * address; // No warning
#private
NSInteger radius; // Warning
}
#end
#implementation Igloo
{
NSInteger numWindows; // No warning
#private // Has no real effect, of course; just testing
NSString * doormatText; // No warning
}
#end
I suggest filing a bug/submitting a patch.
It appears that the static analyzer option only works if you declare the ivar in the header file.
This generates the analyzer warning correctly:
// AppDelegate.h
#interface AppDelegate : NSObject <UIApplicationDelegate>
{
BOOL _foo; // never read or written
}
#end
Neither of these generates any sort of analyzer warning:
// AppDelegate.m
#interface AppDelegate ()
{
#private
BOOL _goo; // never read or written
}
#end
#implementation AppDelegate
{
#private
BOOL _hoo; // never read or written
}
#end
So it looks like you cannot use the modern syntax to keep ivars in the .m file if you want to check for unused ivars.
In Xcode from product menu click on analyze... It will show you unused variables. This will also tell you about dead code.
Is there a say to do this without changing every .m file to .mm?
OK. I am trying to implement the answer but having trouble. Take a look at my Objective C++ .h and .mm below
Objective-C++ - IDCaptureTemplateCommand.h:
#include "Template.h"
#interface IDCaptureTemplateCommand : NSObject
#property (nonatomic, strong) IDCaptureTemplateCommand *IDCaptureTemplateCommand;
#end
Objective-C++ - IDCaptureTemplateCommand.mm:
#include "IDCaptureTemplateCommand.h"
#implementation IDCaptureTemplateCommand
- (id)init
{
self = [super init];
if (self) {
self.captureTemplateCommand = [[IDCaptureTemplateCommand alloc] init];
}
return self;
}
#end
Objective-C - IDCameraViewController.h
#import <UIKit/UIKit.h>
#import "IDCaptureTemplateCommand.h"
#interface IDCameraViewController : UIViewController <UINavigationControllerDelegate>
#property (nonatomic) IDCaptureTemplateCommand *captureCommand; //ERROR - Unknown type name 'IDCaptureTemplateCommand'
#end
You can do so in the same way as you can use C++ from C or whatever. You need to be able to declare the interface using pure Objective-C and then the implementation can be written using Objective-C++.
If your header file uses C++, e.g. your class has an std::string instance variable, then to make the functionality accessible from Objective-C you have to write a wrapper or otherwise hide the C++ at the interface, so that your Objective-C files don't need to see any of the C++ declarations.
Ever since starting to work on iOS apps and objective C I've been really puzzled by the different locations where one could be declaring and defining variables. On one hand we have the traditional C approach, on the other we have the new ObjectiveC directives that add OO on top of that. Could you folks helps me understand the best practice and situations where I'd want to use these locations for my variables and perhaps correct my present understanding?
Here's a sample class (.h and .m):
#import <Foundation/Foundation.h>
// 1) What do I declare here?
#interface SampleClass : NSObject
{
// 2) ivar declarations
// Pretty much never used?
}
// 3) class-specific method / property declarations
#end
and
#import "SampleClass.h"
// 4) what goes here?
#interface SampleClass()
// 5) private interface, can define private methods and properties here
#end
#implementation SampleClass
{
// 6) define ivars
}
// 7) define methods and synthesize properties from both public and private
// interfaces
#end
My understanding of 1 and 4 is that those are C-style file-based declarations and definitions that have no understanding whatsoever of the concept of class, and thus have to be used exactly how they would be used in C. I've seen them used for implementing static variable-based singletons before. Are there other convenient uses I'm missing?
My take from working with iOS is that ivars have been alost completely phased out outside of the #synthesize directive and thus can be mostly ignored. Is that the case?
Regarding 5: why would I ever want to declare methods in private interfaces? My private class methods seem to compile just fine without a declaration in the interface. Is it mostly for readability?
Thanks a bunch, folks!
I can understand your confusion. Especially since recent updates to Xcode and the new LLVM compiler changed the way ivars and properties can be declared.
Before "modern" Objective-C (in "old" Obj-C 2.0) you didn't have a lot of choices. Instance variables used to be declared in the header between the curly brackets { }:
// MyClass.h
#interface MyClass : NSObject {
int myVar;
}
#end
You were able to access these variables only in your implementation, but not from other classes. To do that, you had to declare accessor methods, that look something like this:
// MyClass.h
#interface MyClass : NSObject {
int myVar;
}
- (int)myVar;
- (void)setMyVar:(int)newVar;
#end
// MyClass.m
#implementation MyClass
- (int)myVar {
return myVar;
}
- (void)setMyVar:(int)newVar {
if (newVar != myVar) {
myVar = newVar;
}
}
#end
This way you were able to get and set this instance variable from other classes too, using the usual square bracket syntax to send messages (call methods):
// OtherClass.m
int v = [myClass myVar]; // assuming myClass is an object of type MyClass.
[myClass setMyVar:v+1];
Because manually declaring and implementing every accessor method was quite annoying, #property and #synthesize were introduced to automatically generate the accessor methods:
// MyClass.h
#interface MyClass : NSObject {
int myVar;
}
#property (nonatomic) int myVar;
#end
// MyClass.m
#implementation MyClass
#synthesize myVar;
#end
The result is much clearer and shorter code. The accessor methods will be implemented for you and you can still use the bracket syntax as before. But in addition, you can also use the dot syntax to access properties:
// OtherClass.m
int v = myClass.myVar; // assuming myClass is an object of type MyClass.
myClass.myVar = v+1;
Since Xcode 4.4 you don't have to declare an instance variable yourself anymore and you can skip #synthesize too. If you don't declare an ivar, the compiler will add it for you and it will also generate the accessor methods without you having to use #synthesize.
The default name for the automatically generated ivar is the name or your property starting with an underscore. You can change the generated ivar's name by using #synthesize myVar = iVarName;
// MyClass.h
#interface MyClass : NSObject
#property (nonatomic) int myVar;
#end
// MyClass.m
#implementation MyClass
#end
This will work exactly as the code above. For compatibility reasons you can still declare ivars in the header. But because the only reason why you would want to do that (and not declare a property) is to create a private variable, you can now do that in the implementation file as well and this is the preferred way.
An #interface block in the implementation file is actually an Extension and can be used to forward declare methods (not needed anymore) and to (re)declare properties. You could for instance declare a readonly property in your header.
#property (nonatomic, readonly) myReadOnlyVar;
and redeclare it in your implementation file as readwrite to be able to set it using the property syntax and not only via direct access to the ivar.
As for declaring variables completely outside of any #interface or #implementation block, yes those are plain C variables and work exactly the same.
First, read #DrummerB's answer. It a good overview of the whys and what you should generally do. With that in mind, to your specific questions:
#import <Foundation/Foundation.h>
// 1) What do I declare here?
No actual variable definitions go here (it's technically legal to do so if you know exactly what you're doing, but never do this). You may define several other kinds of things:
typdefs
enums
externs
Externs look like variable declarations, but they're just a promise to actually declare it somewhere else. In ObjC, they should only be used to declare constants, and generally only string constants. For instance:
extern NSString * const MYSomethingHappenedNotification;
You would then in your .m file declare the actual constant:
NSString * const MYSomethingHappenedNotification = #"MYSomethingHappenedNotification";
#interface SampleClass : NSObject
{
// 2) ivar declarations
// Pretty much never used?
}
As noted by DrummerB, this is legacy. Don't put anything here.
// 3) class-specific method / property declarations
#end
Yep.
#import "SampleClass.h"
// 4) what goes here?
External constants, as described above. Also file static variables can go here. These are the equivalent of class variables in other languages.
#interface SampleClass()
// 5) private interface, can define private methods and properties here
#end
Yep
#implementation SampleClass
{
// 6) define ivars
}
But very rarely. Almost always you should allow clang (Xcode) to create the variables for you. The exceptions are usually around non-ObjC ivars (like Core Foundation objects, and especially C++ objects if this is an ObjC++ class), or ivars that have weird storage semantics (like ivars that don't match with a property for some reason).
// 7) define methods and synthesize properties from both public and private
// interfaces
Generally you shouldn't #synthesize anymore. Clang (Xcode) will do it for you, and you should let it.
Over the last few years, things have gotten dramatically simpler. The side-effect is that there are now three different eras (Fragile ABI, Non-fragile ABI, Non-fragile ABI + auto-syntheisze). So when you see the older code, it can be a little confusing. Thus confusion arising from simplicity :D
I'm also pretty new, so hopefully I don't screw anything up.
1 & 4: C-style global variables: they have file wide scope. The difference between the two is that, since they're file wide, the first will be available to anyone importing the header while the second is not.
2: instance variables. Most instance variables are synthesized and retrieved/set through accessors using properties because it makes memory management nice and simple, as well as gives you easy-to-understand dot notation.
6: Implementation ivars are somewhat new. It's a good place to put private ivars, since you want to only expose what's needed in the public header, but subclasses don't inherit them AFAIK.
3 & 7: Public method and property declarations, then implementations.
5: Private interface. I always use private interfaces whenever I can to keep things clean and create a kind of black box effect. If they don't need to know about it, put it there. I also do it for readability, don't know if there are any other reasons.
This is an example of all kinds of variables declared in Objective-C. The variable name indicate its access.
File: Animal.h
#interface Animal : NSObject
{
NSObject *iProtected;
#package
NSObject *iPackage;
#private
NSObject *iPrivate;
#protected
NSObject *iProtected2; // default access. Only visible to subclasses.
#public
NSObject *iPublic;
}
#property (nonatomic,strong) NSObject *iPublic2;
#end
File: Animal.m
#import "Animal.h"
// Same behaviour for categories (x) than for class extensions ().
#interface Animal(){
#public
NSString *iNotVisible;
}
#property (nonatomic,strong) NSObject *iNotVisible2;
#end
#implementation Animal {
#public
NSString *iNotVisible3;
}
-(id) init {
self = [super init];
if (self){
iProtected = #"iProtected";
iPackage = #"iPackage";
iPrivate = #"iPrivate";
iProtected2 = #"iProtected2";
iPublic = #"iPublic";
_iPublic2 = #"iPublic2";
iNotVisible = #"iNotVisible";
_iNotVisible2 = #"iNotVisible2";
iNotVisible3 = #"iNotVisible3";
}
return self;
}
#end
Note that the iNotVisible variables are not visible from any other class. This is a visibility issue, so declaring them with #property or #public doesn't change it.
Inside a constructor it's good practice to access variables declared with #property using underscore instead self to avoid side effects.
Let's try to access the variables.
File: Cow.h
#import "Animal.h"
#interface Cow : Animal
#end
File: Cow.m
#import "Cow.h"
#include <objc/runtime.h>
#implementation Cow
-(id)init {
self=[super init];
if (self){
iProtected = #"iProtected";
iPackage = #"iPackage";
//iPrivate = #"iPrivate"; // compiler error: variable is private
iProtected2 = #"iProtected2";
iPublic = #"iPublic";
self.iPublic2 = #"iPublic2"; // using self because the backing ivar is private
//iNotVisible = #"iNotVisible"; // compiler error: undeclared identifier
//_iNotVisible2 = #"iNotVisible2"; // compiler error: undeclared identifier
//iNotVisible3 = #"iNotVisible3"; // compiler error: undeclared identifier
}
return self;
}
#end
We can still access the not visible variables using the runtime.
File: Cow.m (part 2)
#implementation Cow(blindAcess)
- (void) setIvar:(NSString*)name value:(id)value {
Ivar ivar = class_getInstanceVariable([self class], [name UTF8String]);
object_setIvar(self, ivar, value);
}
- (id) getIvar:(NSString*)name {
Ivar ivar = class_getInstanceVariable([self class], [name UTF8String]);
id thing = object_getIvar(self, ivar);
return thing;
}
-(void) blindAccess {
[self setIvar:#"iNotVisible" value:#"iMadeVisible"];
[self setIvar:#"_iNotVisible2" value:#"iMadeVisible2"];
[self setIvar:#"iNotVisible3" value:#"iMadeVisible3"];
NSLog(#"\n%# \n%# \n%#",
[self getIvar:#"iNotVisible"],
[self getIvar:#"_iNotVisible2"],
[self getIvar:#"iNotVisible3"]);
}
#end
Let's try to access the not visible variables.
File: main.m
#import "Cow.h"
#import <Foundation/Foundation.h>
int main(int argc, char *argv[]) {
#autoreleasepool {
Cow *cow = [Cow new];
[cow performSelector:#selector(blindAccess)];
}
}
This prints
iMadeVisible
iMadeVisible2
iMadeVisible3
Note that I was able to access the backing ivar _iNotVisible2 which is private to the subclass. In Objective-C all variables can be read or set, even those that are marked #private, no exceptions.
I didn't include associated objects or C variables as they are different birds. As for C variables, any variable defined outside #interface X{} or #implementation X{} is a C variable with file scope and static storage.
I didn't discuss memory management attributes, or readonly/readwrite, getter/setter attributes.
I recently learned that you can add ivar in a class extension with LLVM2.0. (gcc can't do this)
This is somehow really private iVar because other users don't it's existence since it's not in the header file.
like:
//SomeClass.h
#interface SomeClass : NSObject {
}
#end
//SomeClass.m
#interface SomeClass ()
{
NSString *reallyPrivateString;
}
#end
#implementation SomeClass
#end
But this does rely on the compiler. Is there any other way to declare an ivar that's not in the header file?
The only place to declare instance variables is in the interface or a class extension (which is really an extension of the interface). But you can effectively add instance variables at any time with the modern runtime using the associated object functions.
If you are implementing a library and want to hide your instance variables take a look at what Apple does in the interface for UIWebView. They have an internal webview that does not expose a header file.
#class UIWebViewInternal;
#protocol UIWebViewDelegate;
UIKIT_CLASS_AVAILABLE(2_0) #interface UIWebView : UIView <NSCoding, UIScrollViewDelegate> {
#private
UIWebViewInternal *_internal;
}
If you're just going to be using the ivar internally, and you're using the modern runtime (Snow Leopard 64 bit and iOS 3.0+, I think) then you can just declare properties in a class extension and synthesize them inside the class. No ivars are exposed in your header, no messy id _internal objects, and you get around fragile ivars, too.
// public header
#interface MyClass : NSObject {
// no ivars
}
- (void)someMethod;
#end
// MyClass.m
#interface MyClass ()
#property (nonatomic, retain) NSString *privateString;
#end
#implementation MyClass
#synthesize privateString;
- (void)someMethod {
self.privateString = #"Hello";
NSLog(#"self.privateString = %#", self.privateString);
NSLog(#"privateString (direct variable access) = %#", privateString); // The compiler has synthesized not only the property methods, but also actually created this ivar for you. If you wanted to change the name of the ivar, do #synthesize privateString = m_privateString; or whatever your naming convention is
}
#end
This works with Apple's gcc, in addition to LLVM. (I'm not sure if this works on other platforms, ie not Apple's gcc, but it will certainly work for both iOS and Snow Leopard+).
I have just started learning objective C and am really confused how the .h and .m files interact with each other. This simple program has 3 files:
Fraction.h
#import <Foundation/NSObject.h>
#interface Fraction : NSObject {
int numerator;
int denominator;
}
- (void) print;
- (void) setNumerator: (int) n;
- (void) setDenominator: (int) d;
- (int) numerator;
- (int) denominator;
#end
Fraction.m
#import "Fraction.h"
#import <stdio.h>
#implementation Fraction
-(void) print { printf( "%i/%i", numerator, denominator ); }
-(void) setNumerator: (int) n { numerator = n; }
-(void) setDenominator: (int) d { denominator = d; }
-(int) denominator { return denominator; }
-(int) numerator { return numerator; }
#end
Main.m
#import <stdio.h>
#import "Fraction.h"
int main(int argc, char *argv[]) {
Fraction *frac = [[Fraction alloc] init];
[frac setNumerator: 1];
[frac setDenominator: 3];
printf( "The fraction is: " );
[frac print];
printf( "\n" );
[frac release];
return 0;
}
From what I understand, the program initially starts running the main.m file. I understand the basic C concepts but this whole "class" and "instance" stuff is really confusing. In the Fraction.h file the #interface is defining numerator and denominator as an integer, but what else is it doing below with the (void)? and what is the purpose of re-defining below? I am also quite confused as to what is happening with the (void) and (int) portions of the Fraction.m and how all of this is brought together in the main.m file. I guess what I am trying to say is that this seems like a fairly easy program to learn how the different portions work with each other - could anyone explain in non-tech jargon?
People who come from other environments always seem to belive that something complicated is happening with the .c, .m, and .h files used in C and Objective-C programming.
Actually, its very, VERY simple.
For the purpose of buiding a project Integrated Development Environments - like XCode - ignore all the .h files. What they do do is to take each .c and .m file and compile it. If the programmer (thats you) has used any #include, or #import directives, the compiler inserts the entire text of the included/imported .h file where the directive was.
So, if you had a .h file - insert.h - that said:
in
And a .c file that said:
Alice
#include "insert.h"
Wonderland
The compiler would, after processing the #include & #import directives, see this:
Alice
in
Wonderland
It is this very VERY simple file merging behavior that we use to make complicated programs :)
.h is very simply a convention by which programmers can tell each other that the file is suitable to be merged in - potentially multiple times - using #include or #import.
The .c and .m files are not merged like that. Each .c and .m file is compiled seperately - to produce .o files. Each .o file is a collection of compiled functions. The .o files are then merged - or "linked" - to produce the final program.
The linking step ensures that each function exists only once, and that all functions that are called do in fact exist somewhere.
C & Objctive-C define one special function that must exist somewhere - main(). Again, the language is very relaxed - it doesn't care which .c or .m file the main() function is in. Merely that it exists in some file somewhere.
You need to take a look into Object Oriented Programming and perhaps read a little more into Objective-C development to get a good grasp on the concepts of OOP etc
To answer your question "what is the difference between .h and .m files", .h files contain the declaration for your class, so basically all of attributes and methods that it can utilise. The .m file is the implementation of these methods.
In laymans terms, the header file (.h) is the a way of saying "This is what I can do" and the .m is "This is how I do it". It's a little more complicated then that though.
The files don't interact at all, using them is merely a convention, you could also put everything in the main.m file.
A good starting point for learning Objective-C is the introduction to the Objective-C language.
In a nutshell, an Objective-C class is a C struct. An instance is a reference to such a struct that has been allocated in memory. A class has a name and an instance has a state or value.
The thing that sets an Objective-C class apart from a C struct is the ability to look up method addresses by name. In simplified terms, the struct has a hash table of function pointers keyed by name.
There are lots of other niceties in Objective-C objects, like reference counting, but calling methods by name is the crux of it. A SEL is a C string, but a C string is not a SEL.
As far as header and source files, by convention you declare the interface to a class in header files and define the methods in a source file. Defining things, other than types and constants, in a header file is a bad practice, as is including source files. You are free to declare anything you want in a source file, but it is essentially private to the source file.
A C executable, and thus an Objective-C executable, has an entry point at the main function. By convention main is defined in a file with the same name in Objective-C projects.
The below lines of code in Fraction.h are not nothing but getter methods. They are not redefining the two int variables declared above them.
- (int) numerator;
- (int) denominator;