提问



根据我的理解,如果ClassA需要包含ClassB头,则应该使用前向声明,而ClassB需要包含ClassA头以避免任何循环包含。我也理解#import是一个简单的ifndef,所以包含只发生一次。


我的询问是这样的:什么时候使用#import什么时候使用@class?有时如果我使用@class声明,我会看到一个常见的编译器警告,如下所示:



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



真的很想理解这一点,而不是仅仅删除@class前向声明并抛出#import来沉默编译器给我的警告。

最佳参考


如果您看到此警告:



  警告:接收者MyCoolClass是一个前向类,相应的@interface可能不存在



你需要#import文件,但你可以在你的实现文件(.m)中执行,并在头文件中使用@class声明。


@class不(通常)不需要#import文件,它只是将需求向下移动到信息有用的地方。


例如


如果你说@class MyCoolClass,编译器知道它可能会看到如下内容:


MyCoolClass *myObject;


它不必担心MyCoolClass以外的任何东西都是一个有效的类,它应该为指针保留空间(实际上,只是一个指针)。因此,在你的标题中,@class足够90%的时间。


但是,如果您需要创建或访问myObject的成员,则需要让编译器知道这些方法是什么。此时(可能在您的实现文件中),您需要#import "MyCoolClass.h",告诉编译器除了这是一个类之外的其他信息。

其它参考1


三个简单的规则:



  • 只有#import超级类和采用的协议,在头文件(.h文件中)。

  • #import所有类和协议,您在实现中发送消息(.m文件)。

  • 其他一切的前瞻声明。



如果你在实现文件中转发声明,那么你可能做错了。

其它参考2


查看ADC [53]上的Objective-C编程语言文档


在定义类一节中类接口它描述了为什么这样做:



  @class指令最小化了编译器和链接器看到的代码量,因此是给出类名前向声明的最简单方法。简单,它避免了导入导入其他文件的文件时可能出现的潜在问题。例如,如果一个类声明另一个类的静态类型实例变量,并且它们的两个接口文件相互导入,则这两个类都不能正确编译。



我希望这有帮助。

其它参考3


如果需要,在头文件中使用前向声明,#import在实现中使用的任何类的头文件。换句话说,你总是#import你在你的文件中使用的文件实现,如果您需要在头文件中引用一个类,也可以使用前向声明。


异常就是你应该#import你在头文件中继承的类或正式协议(在这种情况下你不需要在实现中导入它) 。

其它参考4


常见的做法是在头文件中使用@class(但仍需要#import超类),并在实现文件中使用#import。这将避免任何圆形夹杂物,它只是起作用。

其它参考5


另一个优点:快速编译


如果包含头文件,则其中的任何更改都会导致当前文件也被编译,但如果类名包含在@class name中则不是这种情况。当然,您需要在源文件中包含标头

其它参考6



  我的询问是这样的。什么时候使用#import,什么时候使用@class?



简单回答:当存在物理依赖时,你#import#include。否则,您使用前向声明(@class MONClassstruct MONStruct@protocol MONProtocol)。


以下是身体依赖的一些常见例子:



  • 任何C或C ++值(指针或引用不是物理依赖)。如果你有CGPoint作为ivar或属性,编译器将需要查看CGPoint的声明。

  • 你的超级课程。

  • 您使用的方法。




  有时如果我使用@class声明,我会看到一个常见的编译器警告,如下所示:
     warning:receiverFooController是一个前向类,相应的@interface可能不存在。



编译器在这方面实际上非常宽松。它会丢弃提示(例如上面的提示),但是如果忽略它们并且没有#import正确的话,你可以轻易地丢弃你的堆栈。虽然它应该(IMO),但编译器不会强制执行此操作。在ARC中,编译器更严格,因为它负责引用计数。当遇到您调用的未知方法时,编译器会返回默认值。每个返回值和参数都假定为id。因此,您应该根除代码库中的每个警告,因为这应该被视为物理依赖。这类似于调用未声明的C函数。使用C,假设参数为int


您赞成前向声明的原因是您可以通过因子减少构建时间,因为依赖性最小。使用前向声明,编译器会看到有一个名称,并且可以正确地解析和编译程序,而不会在没有物理依赖性时看到类声明或其所有依赖项。清除构建花费的时间更少。增量构建花费的时间更少。当然,您最终会花费更多的时间来确保所需的所有标题对于每个翻译都是可见的,但这会在缩短的构建时间内得到回报(假设您的项目不是很小)。


如果你改为使用#import#include,那么你在编译器上的工作量就会超出必要的范围。你还会引入复杂的头部依赖关系。您可以将其比作蛮力算法。当你#import时,你会拖拽大量不必要的信息,这需要大量的内存,磁盘I/O和CPU来解析和编译源代码。


对于依赖于C的语言而言,ObjC非常接近理想,因为NSObject类型永远不是值 - NSObject类型总是引用计数指针。因此,如果你可以适当地构建程序的依赖关系并在可能的情况下转发,因为你需要很少的物理依赖,你可以获得非常快的编译时间。你还可以在类扩展中声明属性以进一步减少依赖。这是一个巨大的大型系统的奖励 - 如果您开发了大型C ++代码库,您就会知道它所带来的差异。


因此,我的建议是在可能的情况下使用前锋,然后在#import中使用身体依赖。如果您看到警告或其他暗示身体依赖的警告 - 将其全部修复。修复程序是您的实现文件中的#import


在构建库时,您可能会将某些接口分类为一个组,在这种情况下,您#import会引入物理依赖的库(例如#import <AppKit/AppKit.h>)。这可能会引入依赖性,但库维护人员通常可以根据需要为您处理物理依赖关系 - 如果他们引入了一个功能,他们可以最大限度地减少它对您的构建的影响。

其它参考7


我看到很多这样做,但我没有看到任何答案为什么?


所以:为什么你应该在你的标题中@class和#import只在你的实现中?你必须一直加倍@class 和 #import来加倍你的工作。除非你使用继承。在这种情况下,你将为一个@class多次#importing。然后,如果您突然决定不再需要访问声明,则必须记住从多个不同的文件中删除。


由于#import的性质,多次导入同一文件不是问题。
 编译性能也不是一个问题。如果是这样的话,我们就不会在我们拥有的每个头文件中#importing Cocoa/Cocoa.h等。

其它参考8


如果我们这样做


@interface Class_B : Class_A


表示我们将Class_A继承到Class_B,在Class_B中我们可以访问class_A的所有变量。


如果我们这样做


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


这里我们说我们在程序中使用Class_A,但是如果我们想在Class_B中使用Class_A变量,我们必须在.m文件中#import Class_A(创建一个对象并使用它的函数和变量)。

其它参考9


有关文件依赖性的更多信息& #import& @class检查出来:


http://qualitycoding.org/file-dependencies/
这篇文章很好[54]


文章摘要



  

导入头文件:


  
  

      
  • #import您正在继承的超类,以及您正在实施的协议。

  •   
  • 转发声明其他所有内容(除非它来自框架
      使用主标题)。

  •   
  • 尝试消除所有其他#imports。

  •   
  • 在自己的标头中声明协议以减少依赖关系。

  •   
  • 太多的前瞻性声明?你有一个大班。

  •   

  
  

导入实现文件:


  
  

      
  • 消除未使用的#imports。

  •   
  • 如果方法委托给另一个对象并返回它获得的内容
      回来,尝试向前声明该对象而不是#importing它。

  •   
  • 如果包含模块强制您包含级别后的级别
      连续的依赖关系,你可能有一组想要的类
      成为图书馆。将其构建为具有主服务器的单独库
      标题,所以一切都可以作为一个预先构建的块进行。

  •   
  • #imports太多了?你有一个大班。

  •   


其它参考10


当我发展的时候,我只有三件事情从不会给我带来任何问题。



  1. 导入超类

  2. 导入父类(当您有子和父时)

  3. 导入项目之外的类(如框架和库中)



对于所有其他类(我的项目中的子类和子类),我通过forward-class声明它们。

其它参考11


如果你试图在头文件中声明一个变量或属性,你还没有导入它,你会得到一个错误,说编译器不知道这个类。


你的第一个想法可能是#import它。

在某些情况下,这可能会导致问题。


例如,如果在头文件或结构或类似的东西中实现了一堆C方法,因为它们不应该被多次导入。


因此,您可以使用@class告诉编译器:



  我知道你不会知道那个课程,但它确实存在。它将被导入或在其他地方实施



它基本上告诉编译器关闭和编译,即使它不确定这个类是否会被实现。


您通常会在 .h 文件中的 .m @class中使用#import

其它参考12


正向声明只是为了防止编译器显示错误。


编译器会知道有一个类,你在头文件中使用了要声明的名称。

其它参考13


只有当您打算以编译器需要知道其实现的方式使用该类时,编译器才会抱怨。


例如:



  1. 这可能就像你要从中派生你的课程或

  2. 如果您要将该类的对象作为成员变量(尽管很少见)。



如果您只是将它用作指针,它不会抱怨。当然,您必须在实现文件中#import它(如果您正在实例化该类的对象),因为它需要知道类内容以实例化对象。


注意:#import与#include不同。这意味着没有任何称为循环导入的东西。 import是一种请求编译器查看特定文件以获取某些信息。如果该信息已经可用,则编译器会忽略它。


试试这个,在A.h中导入A.h,在A.h中导入B.h.没有任何问题或投诉,它也会很好。


何时使用@class


只有当你甚至不想在标题中导入标题时才使用@class。这可能是你甚至不知道该课程将会是什么的情况。你甚至可能没有该课程的标题的情况。


这方面的一个例子可能是您正在编写两个库。一个类,我们称之为A,存在于一个库中。该库包含第二个库的标题。该标头可能有一个指针A但可能不需要使用它。如果库1尚不可用,则如果使用@class,则不会阻止库B.但是如果你想导入A.h,则阻止了库2的进度。

其它参考14


想想@class告诉编译器相信我,这是存在的。


将#import视为复制粘贴。


出于多种原因,您希望最大限度地减少导入的数量。没有任何研究,首先想到的是它减少了编译时间。


请注意,当您从类继承时,您不能简单地使用前向声明。您需要导入该文件,以便您声明的类知道它是如何定义的。

其它参考15


这是一个示例场景,我们需要@class。


考虑您是否希望在头文件中创建一个协议,该头文件具有相同类的数据类型的参数,然后您可以使用@class。请记住,你也可以单独声明协议,这只是一个例子。


// DroneSearchField.h

#import <UIKit/UIKit.h>
@class DroneSearchField;
@protocol DroneSearchFieldDelegate<UITextFieldDelegate>
@optional
- (void)DroneTextFieldButtonClicked:(DroneSearchField *)textField;
@end
@interface DroneSearchField : UITextField
@end