19

それの定義を見ると、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
4

2 に答える 2

23

NS_INLINE の定義を見ると、静的インラインよりもそれを使用する利点はコンパイラの互換性にあるようですが、それは正しいですか?

一部のみ。ここで主要なツールチェーンを評価し、「なぜ使用されstatic inline なかったのか、またはなぜ不十分だったのか」を尋ねる必要があります。支配的なツールチェーンには、属性が含まれています__attribute__((always_inline))。したがって、これには実際には 2 つの部分があります。

  • a) 互換性 したがって、複数のコンパイラの互換性が追加されます。

  • b)__attribute__((always_inline))支配的なツールチェーンでの使用。inlineへの単純な要求に発展しましたinline。を使用always_inlineすると、コンパイラは関数をインライン化しない権利を留保できます (明らかな理由により)。ただし、「信頼してください。これをインライン化したいです -- コンパイラ、可能であればこれをインライン化してください」とも書かれています。この属性は、インライン化機能の一部をプログラマーに復元します。これはパフォーマンスのために使用できますが、(この場合) パフォーマンス要件よりも、プライベート エクスポート関数の数の削減に関係していると思われます。

Objective-C プロジェクトでは静的インラインの代わりに NS_INLINE を常に使用する必要がありますか?

No.__attribute__((always_inline))は、プログラムの最適化の経験が豊富で、この機能を使用した経験のある人のために予約する必要があります。この属性は、C 関数、C++ メソッド、およびその他の静的呼び出しに適用できます。ObjC クラスまたはインスタンス メソッド (動的) には適用できません。コンパイラ、オプティマイザ、および LTO の機能は非常に優れているためです。一方、インライン展開を不適切に使用すると、(いずれかの) いくつかのパフォーマンス ペナルティが発生する可能性があります。例外 (最適化にかなりの時間を費やしたことのない人) は、もちろん、時間をかけてその違いを測定する場合です。

于 2012-04-22T20:47:51.573 に答える
13

はい、コンパイラの互換性のためですが、独自のコードよりもフレームワークを使用するためのものだと思います。もちろんご自由にお使いいただけますが、私は気にしません。

于 2012-04-21T19:49:47.017 に答える