我猜我只会在项目中有可能使用该变量的C ++代码时使用UIKIT_EXTERN。
如果是这种情况，用UIKIT_EXTERN声明所有外部可用常量是否安全？
为什么我不能再看到这个？
答案 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可能不会完全符合您的期望/想要，因为它指定：
对于ObjC翻译可见的图书馆符号，这是完美的。
答案 1 :(得分：1)
主要是使一个类在当前库/可执行文件之外可见。除非您正在开发库，否则您可能不需要使用它。
正如您所指出的，使用宏的主要优点是它构建了额外的C ++ extern保护，因此如果您确实正在开发库，这绝对是一个好主意（否则调用者有要注意并添加extern C声明。
这在ADC文档中有所介绍：
在这里得到了很好的回答：