何时使用UIKIT_EXTERN vs extern

时间:2013-07-16 04:28:45

标签: objective-c visibility declaration extern

我猜我只会在项目中有可能使用该变量的C ++代码时使用UIKIT_EXTERN。

如果是这种情况,用UIKIT_EXTERN声明所有外部可用常量是否安全?

为什么我不能再看到这个?

2 个答案:

答案 0 :(得分:22)

  

我猜我只会在项目中有可能使用变量的C ++代码时使用UIKIT_EXTERN。

右。这是主要原因。这是因为C和C ++符号使用不同的命名约定。

有一个不太常见的原因:UIKIT_EXTERN还指定默认可见性。

注意:更一般地说,“符号” - 不是“变量”,因为extern也可以应用于常量,函数等等。

  

如果是这种情况,用UIKIT_EXTERN声明所有外部可用常量是否安全?

简短回答:使用此表单是一种很好的做法(阅读:'安全'),但通常最好让您的库声明自己的等效UIKIT_EXTERN。< / p>


UIKIT_EXTERN是UIKit声明。 图书馆不应该依赖于这个声明,只是定义他们自己的同义词 - 很多人都这样做,但我发现它在C和C ++中更常见,因为这些程序通常针对更多的平台和很高的比例iOS程序不是为支持其他平台而开发的。否则,不需要UIKit的Objective-C程序可能因为此声明而依赖于UIKit,因此他们必须导入UIKit(以便UIKIT_EXTERN的声明可见)。

此外,UIKit并不适用于可以运行iOS程序的所有平台(即它可以是C,C ++,或依赖于Foundation并可移植到OS X)。因此,即使某人(好奇地)坚持宣称他们自己是个坏主意,选择CF_EXPORT(CoreFoundation的等价物)将是一个更便携的选项,因为它也可以用于C,C ++和OS X.此外,你的图书馆只需要包括CoreFoundation(至少)。

如果你的图书馆依赖于UIKit并且你的图书馆必须导入框架,那么使用它们的同义词极不可能导致你的图书馆出现问题。

但这是一个非常大的条件 - 您的图书馆很容易宣布自己的。简而言之,一个编写良好且可移植的库应该(几乎)永远不会使用'raw'extern,也不应该使用不必要的库依赖(在这种情况下是UIKit)。

使用UIKIT_EXTERN 将是一个糟糕的设计选择,除非您的库与UIKit不可分割 - 例如UIView子类的集合。

如果您的库只处理Foundation类型,那么导入UIKit意味着您的库(在OS X上)将(不必要地)无法使用(直到UIKit导入被删除)。

使用C ++(包括超集)的经验不多的人可能不知道符号名称是不同的,因此他们可能只是直接使用extern。最后,一些程序最初并未设计为在C和/或Objective-C翻译之外使用,因此他们可能只是简单地使用extern而没有条件修饰。

最后,UIKIT_EXTERN可能不会完全符合您的期望/想要,因为它指定:

  • 外部C符号
  • 具有默认可见性

对于ObjC翻译可见的图书馆符号,这是完美的。

答案 1 :(得分:1)

主要是使一个类在当前库/可执行文件之外可见。除非您正在开发库,否则您可能不需要使用它。

正如您所指出的,使用宏的主要优点是它构建了额外的C ++ extern保护,因此如果您确实正在开发库,这绝对是一个好主意(否则调用者有要注意并添加extern C声明。

这在ADC文档中有所介绍:

在这里得到了很好的回答: