Importing header in objective c

Question

In Objective-c when we using object of one class into another class by convention we should forward declare the class in .h file, i.e. @class classname;. And should import the header file in .m file, i.e. #import "header.h". But if we import the header file in .h then we don't have to import it again in .m file . So what is the reason behind this convention? Which is efficient way?

Heger

Answer 1

So what is the reason behind this convention?

You should favor forward declarations (@class MONClass;) where possible because the compiler needs to know a typename is an objc class before it is used, and because an #import can drag in a ton of other headers (e.g. entire frameworks/libraries), seriously expanding and complicating your dependencies and increasing your build times.

Which is efficient way?

Forward declarations. Your builds, rebuilds, and indexing will be much faster if you do this correctly.

Fornication

So to clarify, if i'm declaring a type in .h file I forward declare using @classname, then in the .m file where I send messages to the object I import the actual header file "classname.h" ? – Solly

@conor correct. although, there are a few more details: https://mcmap.net/q/63427/-class-vs-import/… over the past few years, compiler advancements and language changes (in ObjC) have made it easier to keep your class' dependencies out of the header -- it can all go in the *.m in many cases. so you will need your superclass and any protocols you adopt publicly. your ivars and properties can often stay out of the header -- no import or forward required in those cases. – Fornication

Answer 2

You are correct that importing the header in the .h makes like easier (in the short run). The reason not to do this and import it in the implementation file (.m) is to prevent name pollution, where all the names in the imported header are available when someone imports your header. Instead, by importing your header only your functions/classes shuld be imported and the rest at the implementation

Also, if you import the header in the .h, that means every code that imported your header will have to be recompiled when the 3rd-party header changes, even if nothing has changed in your header explicitly. Forward declaration avoids this problem and forces only those implementation (.m) files to be recompiled that actually make use of the 3rd-party header

Veinstone

Answer 3

Though import of files in .m makes it easier to get away with few lines of code but it is general thinking that importing may affect the load time and response time , yes it does affect and does not.Because according to documentation by apple :-

If you are worried that including a master header file may cause your program to bloat, don’t worry. Because Mac OS X interfaces are implemented using frameworks, the code for those interfaces resides in a dynamic shared library and not in your executable. In addition, only the code used by your program is ever loaded into memory at runtime, so your in-memory footprint similarly stays small.

As for including a large number of header files during compilation, once again, don’t worry. Xcode provides a precompiled header facility to speed up compile times. By compiling all the framework headers at once, there is no need to recompile the headers unless you add a new framework. In the meantime, you can use any interface from the included frameworks with little or no performance penalty.

Thus Response and load times are affected for the first time only , But anyways forward referencing should be favoured to maintain coding standards and avoid overheads however small :).

Swafford

Answer 4

#import is a pre-processor directive that operates on the file before the compiler sees it. Whenever you get confused, conceptually think of it as like a copy-and-paste: when you see #import foo, the means the contents of file foo are inserted at that point. (It's a bit more clever than that, as it also guards against duplicate includes).

So you #import Foo.h in Bar.h if there are declarations in Bar.h that reference Foo.h. If there is nothing in Bar.h that uses Foo, but there is Bar.m, then the import goes in Bar.m. Keep the declarations only where they're need.

Tyrolienne

Answer 5

This just to say compiler we have a class with name xx if you use @class xx;

Because you don't need its properties/method right now.

And in the next case, you also need the property and methods because you will have to access them. That's the issue if you use @class xx in your .h file and don't import xx.h. Then declaring an object of xx will not generate and error but accessing it's method will generate warning and accessing property generate an error

Erase

I hate to be harsh, but your answer would be much easier to read (and thus to vote on) if you used capitals at the beginning of sentences and didn't use nonstandard abbreviations/spellings like 'becz', 'cz', and 'rite'. – Timelag