CODEWITHSUNDEEP
iphoneobjective-cipad
Slee
Slee

Reputation: 28248

#import statements in .m or .h in objective-c?

I ended up having these in both of my .h and .m files, this is my first Objective-C program so I'd like some clarification so I can clean thins thing up.

Upvotes: 3

Views: 2476

Answers (5)

Pablo Santa Cruz
Pablo Santa Cruz

Reputation: 181280

These are the rules I follow:

  1. If in your header file, you only need to use pointers to classes declared in the header file you are including, then I would just use a class sentence on the header file (.h) and full import on the definition (.m) file.
  2. If you need to use full definition of some stuff on the header file you are including, then the full import goes into the header file.

For the examples, consider files MyClass.m, MyClass.h and MyInclude.h:

Example, scenario #1:

// MyClass.h
@class MyInclude;

@interface MyClass : NSObject {
    MyInclude *myIncludeObj;
}

// MyClass.m
#import "MyClass.h"
#import "MyInclude.h"

Exaple, scenario #2:

// MyClass.h
#import "MyInclude.h"
@interface MyClass : NSObject {
    MyInclude myIncludeObj; // MyInclude could be a plain C structure
}

// MyClass.m
#import "MyClass.h"

Upvotes: 4

Daniel Dickison
Daniel Dickison

Reputation: 21882

I have just one rule: Import at the top of the .h file for the superclass and protocols of any classes you declare in the .h file. This is because any file that imports your .h file also needs the declarations for the superclass and protocols. This is also why the default Xcode template has #import <UIKit/UIKit.h> in the .h file rather than the .m file.

For everything else (e.g. types used for ivars and method parameters), use forward-declarations and put the #import in the .m file

Another way to put this is: never use forward declarations for superclasses and protocols.

Upvotes: 1

Stephen Darlington
Stephen Darlington

Reputation: 52565

Unless it affects the interface definition you should put it in the .m file.

If you just use a class, use a forward declaration:

@class AClass;

@interface Bob : NSObject {
  AClass* a;
}

If you implement something, then import it:

#import "SomeProtocol.h"

@interface Bob : NSObject<SomeProtocol> {
}

These kinds of thing are really "best practice" rather than absolutely essential. Objective C's #import directive means that you can't get errors because you include a file multiple times, so it's not technically a problem, but it will increase compile times.

Upvotes: 11

mikecsh
mikecsh

Reputation: 862

The #import directive is an improvement over the #include directive in that instead of blindly copying the file in place, it will not include it if it has already been included. Therefore you shouldn't experience any problems with #import-ing the same file multiple times.

As far as best practice goes, IMHO it's best to keep the scope as narrow as possible. Therefore I'd suggest putting your #imports in you implementation files (.m). If you require the class definition in your interface file (.h) then you can use the

@class MyClass;

construct to inform the compiler that it will be able to find the relevant header in the implementation file.

Hope this helps.

Upvotes: 1

Sam Ritchie
Sam Ritchie

Reputation: 11038

Best practices is to put #import statements in .m files. If you need access to a class inside the header file, for a property declaration or a function parameter, use a forward declaration, like this:

@class Cocos2DController;

@interface HoppersAppDelegate : NSObject <UIApplicationDelegate> {
Cocos2DController*  controller;
}

A forward declaration lets the system know that the class exists, though it's not yet fully defined. With this pattern, you'll keep your headers lean, and guarantee that you're only importing the headers that you want for a specific class, not chaining #imports all through the application.

For a specific problem you might run into: If you include #import statements in a header file, you run the risk of an #import loop if two classes import each other's header files.

Upvotes: 0

Related Questions