19

查看它的定义NS_INLINE似乎使用它的优势static inline是编译器兼容性，对吗？在objective-c项目中应该NS_INLINE总是使用而不是c函数吗？static inline

#if !defined(NS_INLINE)
    #if defined(__GNUC__)
        #define NS_INLINE static __inline__ __attribute__((always_inline))
    #elif defined(__MWERKS__) || defined(__cplusplus)
        #define NS_INLINE static inline
    #elif defined(_MSC_VER)
        #define NS_INLINE static __inline
    #elif TARGET_OS_WIN32
        #define NS_INLINE static __inline__
    #endif
#endif
4

2 回答 2

23

查看 NS_INLINE 的定义，似乎使用它优于静态内联的优点是编译器兼容性，对吗？

只是一部分。您必须评估这里的主要工具链，并问“为什么static inline 没有使用，或者为什么它不充分？”。主要工具链包含属性__attribute__((always_inline))。所以这实际上有两个部分：

  • a) 兼容性因此它增加了对多个编译器的兼容性。

  • b)__attribute__((always_inline))在主要工具链中使用。inline已演变为对inline. 使用always_inline，编译器仍然可以保留不内联函数的权利（出于显而易见的原因）。然而，它也说“相信我，我想要这个内联——编译器，如果可能的话，内联这个”。这个属性恢复了程序员的部分内联能力。这可以用于性能，但我怀疑（在这种情况下）它更多地与减少私有导出函数的数量有关，而不是性能要求。

在 Objective-C 项目中是否应该始终使用 NS_INLINE 而不是静态内联？

不__attribute__((always_inline))应该留给那些在优化程序方面有很多经验并且使用过这个工具的人。此属性可应用于 C 函数、C++ 方法和其他静态调用。它不能应用于 ObjC 类或实例方法（它们是动态的）。我提到这一点是因为编译器、优化器和 LTO 非常擅长它们的工作。同时，内联的不当使用可能会导致（任何）几个性能损失。例外情况（对于没有花费大量时间进行优化的人）当然是当人们花时间衡量它所产生的差异时。

于 2012-04-22T20:47:51.573 回答
13

是的，它是为了编译器的兼容性，但我认为它更多的是为了使用框架而不是你自己的代码。当然，您可以免费使用它，但我不会打扰。

于 2012-04-21T19:49:47.017 回答