Ben*_*man 14 visibility declaration objective-c extern
我猜我只会使用UIKIT_EXTERN,如果我的项目中有可能使用该变量的C++代码.
如果是这种情况,用UIKIT_EXTERN声明所有外部可用的常量是否安全?
为什么我不再看到这个?
jus*_*tin 22
我猜我只会使用UIKIT_EXTERN,如果我的项目中有可能使用该变量的C++代码.
对.这是主要原因.发生这种情况是因为C和C++符号使用不同的命名约定.
有一个不常见的原因:UIKIT_EXTERN
还指定默认可见性.
注意:更一般地说,"符号" - 不是"变量",因为extern
它也可以应用于常量,函数等.
如果是这种情况,用UIKIT_EXTERN声明所有外部可用的常量是否安全?
简答:使用这个表格是一种很好的做法(读作:'安全'),但通常最好让你的图书馆声明它自己的等价物UIKIT_EXTERN
.
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++和C(包括超集)的经验的人可能不知道符号名称是不同的,所以他们可能只是extern
直接使用.最后,一些程序最初并未设计为在C和/或Objective-C翻译之外使用,因此它们可能仅仅在extern
没有条件修饰的情况下用于翻译.
最后,UIKIT_EXTERN
可能不会完全符合您的期望/想要,因为它指定:
对于ObjC翻译可见的库符号,这是完美的.
归档时间: |
|
查看次数: |
5314 次 |
最近记录: |