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

Question

看看NS_INLINE它的定义似乎使用它的优点static inline是编译器兼容性,这是正确的吗？在objective-c项目中应该NS_INLINE总是使用而不是static inlinec函数吗？

#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

是的,这是为了兼容编译器,但我认为它更适合使用框架而不是自己的代码.当然,你可以自由使用它,但我不会打扰.