NS_INLINE比静态内联有什么优势？

看看NS_INLINE的定义，似乎使用它的优势在于编译器的兼容性，是否正确？应该使用NS_INLINE而不是static inline在Objective-C项目的c函数中使用吗？NS_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

来源

2012-04-21 keegan3d

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

来源

2012-04-21 19:49:47

如果代码是针对其他人使用的库，那么您会推荐使用'NS_INLINE'吗？ – keegan3d 2012-04-21 20:22:44

它会在除Apple之外的平台上使用吗？用GnuStep之类的？如果不是，那么不。对于Mac OS X或iOS进行开发将无法与“静态内联”兼容，几乎没有机会。 – 2012-04-21 20:29:11

看看NS_INLINE的定义，它似乎使用静态内联的优点是编译器兼容性，是否正确？

只有部分。您必须在此处评估主导工具链，并询问“为什么使用static inline而不是，或者为什么它不够？”。主导工具链包含属性__attribute__((always_inline))。所以这里有两个部分：

a）兼容性因此它增加了对多个编译器的兼容性。
b）在主导工具链中使用__attribute__((always_inline))。 inline已下放为inline的简单请求。由于always_inline，编译器仍然可以保留不内联函数的权利（出于显而易见的原因）。但是，它也表示“相信我，我希望这个内联编译器，如果可能的话，内联”。这个属性恢复了内联程序员的一些能力。这可以用于性能，但我怀疑（在这种情况下）它更多地与减少私有导出函数的数量有关，而不是性能要求。

应该NS_INLINE总是被用来代替静态内嵌在Objective-C的项目？

第__attribute__((always_inline))应该保留给那些在优化程序方面有很多经验的人，并且使用这个工具。该属性可以应用于C函数，C++方法和其他静态调用。它不能应用于ObjC类或实例方法（这是动态的）。我提到这是因为编译器，优化器和LTO非常善于处理它们的工作。同时，不恰当地使用内联可能会有（几种）性能损失。对于那些没有花费大量时间进行优化的人来说，这是一个例外，当然需要花时间来衡量它的差异。

来源

2012-04-22 20:47:51 justin

非常感谢，非常深入！我已经更新了我的问题清单，以清楚地说明我正在谈论一个Objective-C项目中的c函数。 – keegan3d 2012-04-22 21:31:05

@ keegan3d不用客气。事实上，我假定你正在将它应用到正确的符号。我提到objc方法作为附注（例如，对于任何读者）。然而，我试图做的更大的一点是，工具链中有很好的优化器，以及相当近期的优化（例如clang的LTO），这些优化允许对许多C和C++符号进行非常积极的优化 - 即使定义对编译器不可见。这些进步进一步增加了手动调整的难度（例如'__attribute __（（always_inline））'）的使用。 – justin 2012-04-22 21:50:20

新的'FOUNDATION_STATIC_INLINE'宏如何？这只是定义为'static __inline__'。我可以使用它，即“static __inline__”与“static inline”相同吗？ – ma11hew28 2012-12-20 17:04:29

NS_INLINE比静态内联有什么优势？

回答

相关问题