没有 ivars ->我缺少什么?

发布于 2024-12-05 03:17:48 字数 653 浏览 1 评论 0原文

我从不使用ivars。我只使用属性——有时用原始类型分配属性,有时在 “私有”类扩展。我已经看到了在切换到 ARC 时不使用 ivars 的优势——我有一些借用的代码,其中有很多 ivars,但我仍然无法“ARC”,因为我不知道需要保留什么。所以我知道使用ivars的一些优点,但是使用ivars而不是属性有什么优点呢?

注意:我完全依赖于属性声明(由编译器?)自动添加的 ivars。

不要标记为关闭:我已经研究了其他一些问题,例如这个这个都没有击中要害。 标题看起来不错,但就像 SO 上的许多问题一样,这些问题是一堆奇怪的疑问和其他东西。

I never use ivars. I only use properties -- sometimes assign properties with primitive types, and sometimes on a "private" class extension. I've seen the advantages of not using ivars in switching to ARC -- I have some borrowed code with lots of ivars that I still can't "ARC", since I don't know what needs to be retained. So I know some advantages of not using ivars, but what are the advantages of using ivars instead of properties?

Note: I depend exclusively on the ivars that are automagically added in (by the compiler?) for the property declaration.

Don't mark to close: I've looked at some of the other questions, like this and this and none hit the spot. The titles look good, but like so many questions on SO, the questions are a mess of strange doubts and other stuff.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

小嗷兮 2024-12-12 03:17:48

声明的属性不能以与 @protected ivar 相同的方式处理。您可以在类扩展中声明该属性以使其对任何其他类保持私有,或者在标头接口中声明它以使其可公开访问,但是无法使其仅可由子类访问。这需要 ivar 声明。

编辑

只是另一个简短的想法。我最近写了很多框架类,我认为使用 iVars 作为文档可能有一些话要说。

例如,假设您正在紧密循环中调用某些代码,并且希望确保其高性能。在这个紧密循环中,您想要访问类的属性,但需要知道每次调用它时返回值是即时计算还是存储在 iVar 中。在标头中查看 iVar 是确保您无需太多开销即可恢复该变量的快速方法。

Declared properties cannot be treated in the same manner as an @protected ivar. You can declare the property in a class extension to keep it private from any other class, or declare it in the header interface to make it publicly accessible, however there is no way to make it accessible only to subclasses. This would require the ivar declaration.

EDIT

Just another brief thought. I have recently been writing a lot of framework classes, and I think there might be something to be said for using iVars as documentation.

For example, let's say you are calling some code in a tight loop and you want to ensure that it is performant. Inside that tight loop you want to access a property of a class, but need to know whether each time you call it the return value is calculated on-the-fly or stored in an iVar. Seeing the iVar in the header is a quick way to ensure that you'll get that variable back without much overhead.

清风不识月 2024-12-12 03:17:48

如果没有必要,我认为没有任何理由使用 iVar。如果苹果和编译器想为你工作,我说就让他们吧。您将拥有更高效且更易于维护的代码。此时 iVar 是遗留代码。

I don't see any reason to use iVars if you don't have to. If Apple and the compiler want to do work for you, I say let them. You'll have code that more efficient and easier to maintain. At this point iVars are legacy code.

野味少女 2024-12-12 03:17:48

对我来说有一个很好的理由:一个恼人的 GCC 错误,请参阅 这个其他问题以获取描述。

如果您使用 Clang/LVVM,那么您不必担心这个错误。

One good reason for me: an annoying GCC bug, see this other question for a description.

If you're using Clang/LVVM, then you don't have to worry about this bug.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文