NS_INLINE优于静态内联的优势是什么？

Question

查看NS_INLINE的定义似乎使用static inline的优势是编译器兼容性，这是正确的吗？对于objective-c项目中的c函数，是否应始终使用NS_INLINE而不是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

Answer 1

  

看一下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非常擅长他们的工作。同时，不正确使用内联可能会导致（任何）性能损失。例外（对于没有花费大量时间进行优化的人）当然是在花时间来衡量它所产生的差异时。

Answer 2

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