iPhone上的弱链接拒绝工作 | iPhone上的弱链接拒绝工作

本文介绍了iPhone上的弱链接拒绝工作的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个主要针对3.0的iPhone应用程序，但是当它们可用时会利用更新的API。代码如下：

I've got an iPhone app that's mainly targetting 3.0, but which takes advantage of newer APIs when they're available. Code goes something like this:

if (UIApplicationDidEnterBackgroundNotification != NULL) {
    [nc
        addObserver: self
        selector:    @selector(irrelevantCallbackName:)
        name:        UIApplicationDidEnterBackgroundNotification
        object:      nil];
}

现在，根据Apple所说的一切，如果相关的API链接很弱，这将正常工作，因为动态链接器将 UIApplicationDidEnterBackgroundNotification 评估为 NULL 。除了它没有。应用程序编译，但一旦它命中 if（UIApplicationDidEnterBackgroundNotification！= NULL）它就会崩溃 EXC_BAD_ACCESS 。

Now, according to everything Apple's ever said, if the relevant APIs are weakly linked, that will work fine because the dynamic linker will evaluate UIApplicationDidEnterBackgroundNotification to NULL. Except that it doesn't. The application compiles, but as soon as it hits if (UIApplicationDidEnterBackgroundNotification != NULL) it crashes with EXC_BAD_ACCESS.

这只是我需要设置的编译器标志的问题吗？或者我是以错误的方式解决这个问题？

Is this simply a matter of a compiler flag I need to set? Or am I going about this the wrong way?

推荐答案

Aaand我想通了。对于非函数的符号（例如， extern const int foobar ），您必须与符号的地址进行比较，而不是符号本身，因此：

Aaand I figured it out. For symbols that are not functions (extern const int foobar, for instance), you have to compare against the address of the symbol, not the symbol itself, so:

if (&UIApplicationWillEnterForegroundNotification != NULL)
    etc;

回想起来有点显而易见，但我仍然对我周围的整个宇宙有所怀疑，因为我从未提及过区别。

Which in retrospect is kind of obvious, but I still fault the entire universe around me for not ever mentioning the distinction.

这篇关于iPhone上的弱链接拒绝工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！