This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between #import and #include in Objective-C?
What is the difference between
#include< >
#include" "
#import< >
#import" "
The #import directive is an improved version of #include.
#import ensures that a file is only ever included once so that you never have a problem with recursive includes.
#import "" first check the header in project folder then goes to system library, and the #import<> checks for system headers". In theory the locations are compiler defined and they could be implemented differently on a given platform.
When using #import, the header include guard is unnecessary. Otherwise, it's just like #include.
The header include guard, seen in C and C++ files:
#ifndef HGUARD_MONHeader_h
#define HGUARD_MONHeader_h
...header contents...
#endif
import is super set of include, it make sure file is included only once. this save you from recursive inclusion.
about "" and <>. "" search in local directory and <> is use for system files.
The #import directive was added to Objective-C as an improved version of #include. Whether or not it's improved, however, is still a matter of debate. #import ensures that a file is only ever included once so that you never have a problem with recursive includes. However, most decent header files protect themselves against this anyway, so it's not really that much of a benefit.
What is the difference between #import and #include in Objective-C? :
#include and #import request that the preprocessor* read a file and
add it to its output. The difference between #include and #import is
that
#include allow you to include the same file many times. #import
ensures that the preprocessor only includes a file once. C
programmers tend to use #include. Objective-C programmers tend to use
#import.
* Compiling a file in Objective-C is done in two passes. First,
the preprocessor runs through the file. The output from the
preprocessor goes into the real compiler.
Related
This question already has answers here:
What is the difference between #import and #include in Objective-C?
(10 answers)
Closed 6 years ago.
Why use #import in objective c? if we use #include what happens?
The #import directive was added to Objective-C as an improved version of #include. Whether or not it's improved, however, is still a matter of debate. #import ensures that a file is only ever included once so that you never have a problem with recursive includes. However, most decent header files protect themselves against this anyway, so it's not really that much of a benefit.
Source: #Jason Coco
Where do #import my headers and implementations?
Are there rules regarding what I should do?
Is there a way to import everything in a single header file?
Given "General guidelines for using #import in very large projects.".
Well, Objective-C is much like C and C++ in this regard. Stuffing all your #includes/#imports into your headers will introduce a lot of unnecessary dependency, which adds a lot of time to your build. So further information may also be sought in topics on C and C++ dependencies.
Where do #import my headers and implementations?
Typically, you should write #import only where physical dependency exists. Since every objc object is reference counted and your properties/ivars do not typically need to exist in the header, #imports are far lower than C++.
Robin van Dijke outlined the common cases of physical dependence in his answer (+1).
Are there rules regarding what I should do?
Is there a way to import everything in a single header file?
Well, it depends on the size of your project. Some people add all frameworks they use to the PCH (Pre-Compiled Header). Some people put the most frequent ones in the PCH, and some people don't use PCH files at all. The longer the build times and more complex the project, the less the PCH should include.
If you are working on "Very Large" projects, you should probably not add more than Foundation to your PCH.
Another common mistake is that some people will use the PCH so they need to type less (pretty much). The problem with that is their project's common includes/headers change, and when that happens, the target must be entirely rebuilt.
Also, if you can avoid #importing frameworks/libraries in your headers, you can save a lot of build time.
Adding #imports to headers increases causes dependencies to spread even further. It's easy for tons of unrelated code/frameworks which only need to be visible to a few source files to be actually visible to a high percentage of your source files.
Finally, you should really try to keep headers which change often out of other headers.
The big takeaway is that you should:
separate your programs based on features
favor forward declarations over #import. the compiler must know names, but the import is often needed only when you create/message the object.
try to keep your dependency-heavy implementations in the *.m file.
Every once in a while, it can help to review the preprocessed output of some of your source files -- to see what is actually #imported -- the results can be quite surprising.
Notes:
The PCH must be generated for every language in your project.
Compile sources based on their needs; e.g. If you have C programs, don't compile them as ObjC.
As your project's complexity increases, the gains to be made by dividing by targets (e.g. static libraries, modules, dividing your tests logically...) will increase. Structuring dependent targets correctly with low dependency is a large topic in itself. It can really help you build and test at higher frequencies when structured correctly (also important if you use continuous integration or have several developers). Like header dependencies, if you don't consider this from the start, old problems can take a lot of man-hours to correct (after it's already grown to be unbearably slow).
The following conventions can be used:
Use #import in your header file when
- You subclass the imported class
- You use a protocol from the imported header file
- You use other C datastructures (enum, struct) from the imported header file
Example:
#import "SuperClass.h"
#import "Protocol.h"
#class SomeOtherClass
#interface Subclass : SuperClass <Protocol>
SomeOtherClass _instanceVariableToOtherClass
#end
Otherwise use #class in the header file
For all other cases, use #import in the .m file.
Note: #import "class.h" is in fact the following:
#pragma once
#include "class.h"
So it takes care that every class is only imported once to prevent include cycles/loops.
First read this official site That may be helpful for you.
It is similar like , #include Statement In the C language,
Basically #import statement has two Defination,
1) #import "headerFile.h" // This statement is use for Import any header file in current file (UIController)
2) #import<FramWorkName> // This statement basically use for add any framework in current file (UIController)
For use any file any where in your Project then add your file (#import "fileName.h") in .pch file. It is Prefix headers are compiled and stored in a cache, and then automatically included in every file during compilation. This can speed up compilation, and lets you include a file without adding an import statement to every file using it. They are not required, and actually slow compilation whenever you change them. This file is available in your project with .pch file extension.
Such Like:
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import "MyFile_Name.h"
Your can also use PROTOCOL for to define methods that are to be implemented by other classes.
For More information about, How to create POTOCOL, here is Best example with detail.
Just for kicks - I'm going to add a few "basic tenets" - that although are not as detailed as what has been said already - can sometimes help understand the overall "process".
Implementation.m files are never (as far as I know) #import'ed - that is what the compiler "is doing" when it "compiles".
Any header you want ALL compiled (.m) files to "know about" can go in the .pch file. I usually also stick directives shared across all classes, i.e. #import <Cocoa/Cocoa.h>, etc in there - so I don't have to look at them in every file.
If you are going to reference a previously undeclared class in a header file, i.e. AppDelegate.h
#property (nonatomic, strong) HTTPServer *http;
you can #import "HTTPServer.h" at the top of that file (or even in the.pch`)... but it is usually better to reference the "forward class" as follows...
#class HTTPServer;
#interface AppDelegate : NSObject ➜ ...
and then #import "HTTPServer.h" in AppDelegate's .m file. The main reason that you need access to the header file... is to call methods and work with properties, etc of an instance of that external class within your own class's "scope". This is why you can "get away with" simply "mentioning" the #class in your header - you're not actually doing anything with it yet.
The only other thing to consider - and this probably isn't the case if you're building a standalone application - but when building a framework, or a bundle, etc… in which YOUR classes will be referenced in an "API-kind-of-way"… You would want to add a "Copy Files" phase to your build process which would allow "others" to "know about" your classes, via your "Public Header" files. In such a case... you can simply expose a header file which imports the forward declarations needed for your class, for other people to #import. This is how you are able to access all the classes in an "Umbrella Framework", such as <Foundation/Foundation.h> with a single #import... It has exposed the headers that it "makes available" in that first `.h' file.. á la...
#import <Foundation/NSArray.h>
#import <Foundation/NSAutoreleasePool.h>
If you ever used compiler before Xcode, the way to think about it is that any header you need to import are the same as an "Include" -I directive on the commandline. Given a header file src/headers/header.h and a source code file source.c which has an #include "header.h" statement.. the compile command would be
gcc -Iheaders/ source.c -o executable
You can learn about what is actually happening when you compile something in Xcode by navigating to the "log navigator" and Xcode and checking out all the steps.
I want to #import my custom class in "ProjectName"-Prefix.pch file in Xcode project.
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import "CustomClass.h"
#endif
But, I won't use my custom class in every project file, so I want to know, will it somehow hurt to my app performance or something else?
Is there any problem with that?
Is it not recommended?
#import ensures that a given header file is only ever actually included once, so there'll be performance issue. From Apple's documentation:
When you want to include header files in your source code, you typically use a #import directive. This is like #include, except that it makes sure that the same file is never included more than once. The Objective-C samples and documentation all prefer the use of #import, and your own code should too.
From Learning Objective C: A Primer
Performance for sure will not be affected. It is not a good practice to include header files in there unless they are used very broadly in your application, because it will render the code harder to read for people not familiar with your classes.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between #import and #include in Objective-C?
It seems both can work when I use import or include in Objective-C, what's the difference between those two?
..#include and #import request that the preprocessor read a file and add it to its output.
The difference between #include and #import is that
#include allow you to include the same file many times.
#import ensures that the preprocessor only includes a file once.
C programmers tend to use #include.
Objective-C programmers tend to user #import.
Compiling a file in Objective-C is done in two passes. First, the preprocessor runs through the file. The output from the preprocessor goes into the real compiler.
Preprocessor directives start with #. The three most popular are
-#include
-#import
-#define
For an iPhone app, should I #include or #import , and why?
I've seen it done both ways, e.g., #import & #include.
If the header file has traditional include guards, it really doesn't matter which you use, it's more of a stylistic choice. There might be a tiny performance boost if you use #import instead of #include, but I doubt it will be noticeable, since most compilers these days are smart enough to recognize include guards and optimize accordingly.
If, on the other hand, the header file does not have include guards, then you should always use #import, since #import will ensure that the header will only get included once -- if you accidentally #include such a header twice, you will almost certainly get a deluge of compiler errors about redefinitions etc.
Since most Objective-C headers (especially those coming from the Objective-C runtime or the Cocoa headers) do not have include guards, you should use #import when including those. When including standard C library headers or headers from a third-party library, it doesn't matter which you choose -- pick one style and be consistent.
use #import. the advantage is that it does not "re-include" files if they've already been included.
Always use #import - it will make sure that the same header file is never #include'd twice.