什么时候使用UIKIT_EXTERN vs只是extern [英] When to use UIKIT_EXTERN vs just extern

问题描述

我想如果我的项目中可能有使用变量的C ++代码，我只会使用UIKIT_EXTERN.

I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable.

如果是这种情况，那么使用UIKIT_EXTERN声明所有外部可用的常量不是安全的吗?

If this is the case wouldn't it just be safe to declare all your externally available constants with UIKIT_EXTERN?

为什么我看不到更多?

推荐答案

我想如果我的项目中可能有使用变量的C ++代码，我只会使用UIKIT_EXTERN.

I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable.

对.这是主要原因.发生这种情况是因为C和C ++符号使用不同的命名约定.

Right. This is the primary reason. This happens because C and C++ symbols use different naming conventions.

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

There is a less common reason: UIKIT_EXTERN also specifies default visibility.

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

Note: More generally, "symbol" -- not "variable" since extern could also be applied to constants, functions, et cetera.

如果是这种情况，那么使用UIKIT_EXTERN声明所有外部可用的常量不是安全的吗?

If this is the case wouldn't it just be safe to declare all your externally available constants with UIKIT_EXTERN?

简短答案:使用这种形式是一种很好的做法(阅读:安全")，但是通常最好是让您的库声明其自己的UIKIT_EXTERN等效项.

Short Answer: It would be good practice (read: 'safe') to use this form, but it's usually best for your library to declare its own equivalent of UIKIT_EXTERN.

UIKIT_EXTERN是UIKit声明. 库不应该依赖于此声明，而应该定义它们自己的同义词，并且很多人都这样做，但是我发现它在C和C ++中更为常见，因为这些程序通常针对更多平台，并且iOS程序未开发为支持其他平台.否则，由于此声明，不需要UIKit的Objective-C程序可能依赖UIKit，因此它们必须导入UIKit(这样UIKIT_EXTERN的声明是可见的).

UIKIT_EXTERN is a UIKit declaration. Libraries should not depend on this declaration, and just define their own synonym -- and many do, but I find it is more common in C and C++ because these programs often target more platforms and a good percentage of iOS programs are not developed to support other platforms. Otherwise, Objective-C programs which do not require UIKit could depend on UIKit because of this declaration, so they would have to import UIKit (so that UIKIT_EXTERN's declaration is visible).

此外，UIKit并非在所有可以运行iOS程序的平台上都可用(即，它可以是C，C ++，或者取决于Foundation并可以移植到OS X).因此，即使有人(好奇地)坚持宣称自己的想法不是一个好主意，选择CF_EXPORT(与CoreFoundation等效)也是一个更可移植的选择，因为它也可以用于C，C ++和OSX.此外，您的库只需包含CoreFoundation(至少).

Furthermore, UIKit is not available on all platforms where iOS programs could be run (i.e. it could be C, C++, or depend on Foundation and portable to OS X). So even if somebody (curiously) insisted declaring their own were a bad idea, choosing CF_EXPORT (CoreFoundation's equivalent) would be a more portable option because it could also be used for C, C++, and on OS X. Furthermore, your library would only need to include CoreFoundation (at minimum).

如果您的库依赖于UIKit，并且必须由您的库导入框架的框架，那么使用它们的同义词就不太可能对您的库造成问题.

If your library depends on UIKit and the framework's must be imported by your library, then it is highly unlikely that using their synonym would cause a problem for your library.

但这是一组相当大的条件-您的库很容易声明自己的.简而言之，一个编写良好且可移植的库应该(几乎)永远不要使用"raw" extern，也不应该使不必要的库依赖关系成为一件好事(在这种情况下为UIKit).

But this is a pretty big set of conditions -- it's very easy for your library to simply declare its own. In short, a well written and portable library should (almost) never use 'raw' extern, nor should unnecessary library dependencies be a good thing (UIKit in this case).

使用UIKIT_EXTERN 除非您的库与UIKit是分不开的，例如UIView子类的集合，这将是一个糟糕的设计选择.

It would be a bad design choice to use UIKIT_EXTERN unless your library were inseparable from UIKit -- such as a collection of UIView subclasses.

如果您的库仅处理Foundation类型，则导入UIKit意味着您的库将(不必要)在OS X上无法使用(直到删除UIKit导入).

If your library just deals with Foundation types, then importing UIKit means that your library will be (unnecessarily) unusable on OS X (until that UIKit import is removed).

在将C ++与C(包括超集)结合使用方面经验不多的人们可能不知道符号名称是不同的，因此他们可以直接使用extern.最后，某些程序最初并未设计为在C和/或Objective-C转换之外使用，因此它们可能只是使用extern，而没有条件修饰.

People who haven't much experience using C++ with C (including supersets) may not know that symbol names are different, so they may just use extern directly. Finally, some programs were not initially designed to be used outside of C and/or Objective-C translations, so they may have simply used extern without conditional decoration for the translation.

最后，由于UIKIT_EXTERN指定了以下内容，因此它可能无法完全满足您的期望/要求:

Finally, UIKIT_EXTERN may not do exactly what you expect/want since it specifies:

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

对于ObjC翻译可见的库符号，这是完美的.

For library symbols visible to ObjC translations, this is perfect.

这篇关于什么时候使用UIKIT_EXTERN vs只是extern的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！