@class vs. #import

Question

It is to my understanding that one should use a forward-class declaration in the event ClassA needs to include a ClassB header, and ClassB needs to include a ClassA header to avoid any circular inclusions. I also understand that an #import is a simple ifndef so that an include only happens once.

My inquiry is this: When does one use #import and when does one use @class? Sometimes if I use a @class declaration, I see a common compiler warning such as the following:

warning: receiver 'FooController' is a forward class and corresponding @interface may not exist.

Would really love to understand this, versus just removing the @class forward-declaration and throwing an #import in to silence the warnings the compiler is giving me.

Answer 1

if we do this

@interface Class_B : Class_A

mean we are inheriting the Class_A into Class_B, in Class_B we can access all the variables of class_A.

if we are doing this

#import ....
@class Class_A
@interface Class_B

here we saying that we are using the Class_A in our program, but if we want to use the Class_A variables in Class_B we have to #import Class_A in .m file(make a object and use it's function and variables).

Answer 2

If you try to declare a variable, or a property in your header file, which you didn't import yet, your gonna get an error saying that the compiler doesn't know this class.

Your first thought is probably #import it.
This may cause problems in some cases.

For example if you implement a bunch of C-methods in the header file, or structs, or something similar, because they shouldn't be imported multiple times.

Therefore you can tell the compiler with @class:

I know you don't know that class, but it exists. It's going to be imported or implemented elsewhere

It basically tells the compiler to shut up and compile, even though it's not sure if this class is ever going to be implemented.

You will usually use #import in the .m and @class in the .h files.

Answer 3

Compiler will complain only if you are going to use that class in such a way that the compiler needs to know its implementation.

Ex:

1. This could be like if you are going to derive your class from it or
2. If you are going to have an object of that class as a member variable (though rare).

It will not complain if you are just going to use it as a pointer. Of course, you will have to #import it in the implementation file (if you are instantiating an object of that class) since it needs to know the class contents to instantiate an object.

NOTE: #import is not same as #include. This means there is nothing called circular import. import is kind of a request for the compiler to look into a particular file for some information. If that information is already available, compiler ignores it.

Just try this, import A.h in B.h and B.h in A.h. There will be no problems or complaints and it will work fine too.

When to use @class

You use @class only if you don't even want to import a header in your header. This could be a case where you don't even care to know what that class will be. Cases where you may not even have a header for that class yet.

An example of this could be that you are writing two libraries. One class, lets call it A, exists in one library. This library includes a header from the second library. That header might have a pointer of A but again might not need to use it. If library 1 is not yet available, library B will not be blocked if you use @class. But if you are looking to import A.h, then library 2's progress is blocked.

Answer 4

I see a lot of "Do it this way" but I don't see any answers to "Why?"

So: Why should you @class in your header and #import only in your implementation? You're doubling your work by having to @class and #import all the time. Unless you make use of inheritance. In which case you'll be #importing multiple times for a single @class. Then you have to remember to remove from multiple different files if you suddenly decide you don't need access to a declaration anymore.

Importing the same file multiple times isn't an issue because of the nature of #import. Compiling performance isn't really an issue either. If it were, we wouldn't be #importing Cocoa/Cocoa.h or the like in pretty much every header file we have.

Answer 5

When I develop, I have only three things in mind that never cause me any problems.

1. Import super classes
2. Import parent classes (when you have children and parents)
3. Import classes outside your project (like in frameworks and libraries)

For all other classes (subclasses and child classes in my project self), I declare them via forward-class.

Answer 6

Three simple rules:

• Only #import the super class, and adopted protocols, in header files (.h files).
• #import all classes, and protocols, you send messages to in implementation (.m files).
• Forward declarations for everything else.

If you do forward declaration in the implementation files, then you probably do something wrong.