インライン関数

CおよびC++ プログラミング言語では、インライン関数はキーワード で修飾された関数でありinline、これには 2 つの目的があります。

1. これは、コンパイラがインライン展開を実行して関数本体をインラインで置き換えることを提案する（必須ではない）コンパイラディレクティブとして機能します。つまり、各関数呼び出しのアドレスに関数コードを挿入することで、関数呼び出しのオーバーヘッドを節約します。この点では、同様に最適化のヒントを提供するストレージクラス指定子に類似しています。^[1]register
2. の2つ目の目的はinline、リンケージの動作を変更することです。詳細は複雑です。これは、C/C++の分離コンパイル+リンケージモデルのために必要です。具体的には、関数の定義（本体）は、コンパイル中にインライン化できるようにするために、それが使用されるすべての翻訳単位で複製される必要があり、関数に外部リンケージがある場合、リンク中に衝突が発生します（外部シンボルの一意性に違反します）。CとC++（およびGNU CやVisual C++などの方言）は、これをさまざまな方法で解決します。^[1]

関数inlineは C または C++ で次のように記述できます。

インラインvoid swap ( int * m , int * n ) { int tmp = * m ; * m = * n ; * n = tmp ; }     

       
      
      

次に、次のような文があります。

swap ( & x 、& y ); 

次のように変換される可能性があります (コンパイラがインライン化を行うことを決定した場合、通常は最適化を有効にする必要があります)。

int tmp = x ; x = y ; y = tmp ;   
  
  

大量のスワップを実行するソート アルゴリズムを実装する場合、これにより実行速度が向上します。

C++とC99 は関数をサポートしていますが、その前身であるK&R CとC89 はinlineサポートしていません。どちらの場合も、 はinlineインライン展開を強制しません。コンパイラは関数をまったくインライン化しないことも、場合によってはインライン化することも自由に選択できます。コンパイラによって、インライン化できる関数の複雑さは異なります。Microsoft Visual C++やGCCなどの主流の C++ コンパイラは、関数としてマークされていない関数も含め、適切な関数を自動的にインライン化するオプションをサポートしていますinline。ただし、キーワードを単に省略してinlineコンパイラにすべてのインライン化の決定を行なわせることはできません。そうすると、リンカーが異なる翻訳単位で定義が重複していると文句を言うからです。これは、inline関数をインライン化する必要があるというヒントをコンパイラに与えるだけでなく、関数の呼び出し可能なアウトライン コピーをコンパイラが生成するかどうかにも影響するためです (インライン関数のストレージ クラスを参照)。

GNU C は、それが提供する方言 gnu89 の一部として、inlineC89 の拡張として をサポートしています。ただし、セマンティクスは C++ および C99 の両方とは異なります。C90 モードの armcc も、inlinegnu89 および C99 とは異なるセマンティクスを持つ非標準の拡張として を提供します。

一部の実装では、通常は実装固有の宣言指定子を使用して、コンパイラに関数をインライン化させる手段が提供されています。

• マイクロソフトビジュアルC++:__forceinline
• gcc または clang:__attribute__((always_inline))または__attribute__((__always_inline__))。後者は という名前のユーザー定義マクロとの競合を回避するのに役立ちますalways_inline。

これを無差別に使用すると、コードが大きくなり (実行ファイルが肥大化)、パフォーマンスの向上が最小限またはまったくなくなり、場合によってはパフォーマンスが低下することもあります。さらに、インライン化が強制されている場合でも、コンパイラーはあらゆる状況で関数をインライン化できるわけではありません。この場合、gcc と Visual C++ の両方で警告が生成されます。

インライン化を強制すると、次の場合に役立ちます。

• inlineコンパイラによって尊重されない（コンパイラのコスト/利益アナライザーによって無視される）
• パフォーマンスを向上させるには結果をインライン化する必要がある

コードの移植性のために、次のプリプロセッサ ディレクティブを使用できます。

#ifdef _MSC_VER 
#define forceinline __forceinline #elif defined(__GNUC__) #define forceinline inline __attribute__((__always_inline__)) #elif defined(__CLANG__) #if __has_attribute(__always_inline__) #define forceinline inline __attribute__((__always_inline__)) #else #define forceinline inline #endif #else #define forceinline inline #endif    

    

    
        
    
        
    

    

static inlineすべての C 方言と C++ で同じ効果があります。必要に応じて、ローカルで表示可能な (関数のアウトオブライン コピー) 関数を生成します。

ストレージ クラスに関係なく、コンパイラはinline修飾子を無視し、すべての C 方言と C++ で関数呼び出しを生成できます。

extern関数に適用した場合と適用しなかった場合のストレージクラスの効果は、inlineC方言^[2]とC++ ^{[3]で異なります。}

C99 では、定義された関数は外部から参照可能な関数を決して生成inlineしませんが、定義された関数はextern inline常に外部から参照可能な関数を生成します。C++ とは異なり、翻訳単位間で共有される外部から参照可能な関数を必要な場合にのみ生成するように要求する方法はありません。

inline宣言が 宣言と混在している場合extern inline、または修飾子のない宣言 (inline修飾子やストレージ クラスがない) と混在している場合、翻訳単位には定義 (修飾子がない、、inlineまたは のいずれであってもextern inline) が含まれている必要があり、外部から参照できる関数が生成されます。

定義された関数にはinline、プログラム内のどこかに、定義されているextern inlineか修飾子のない、その名前の関数が 1 つだけ必要です。プログラム全体でそのような定義が複数提供されると、リンカーは重複シンボルについてエラーを出力します。ただし、定義が欠落している場合は、リンカーが必ずしもエラーを出力するわけではありません。これは、すべての使用をインライン化できる場合は必要ないからです。ただし、コンパイラは常にinline修飾子を無視して、代わりに関数の呼び出しを生成できるため、エラーを出力する可能性があります。これは、コードが最適化なしでコンパイルされた場合によく発生します。(関数が必ずどこでもインライン化されることになっている場合、これは望ましい動作である可能性があり、そうでない場合はエラーが生成される必要があります。) 便利な方法は、inlineヘッダー ファイルで関数を定義し、関数ごとに 1 つの .c ファイルを作成し、その関数の宣言を含めextern inline、定義を含むそれぞれのヘッダー ファイルをインクルードすることです。宣言がインクルードの前か後かは関係ありません。

関数の使用がすべてインライン化されている場合に到達不能なコードが最終的な実行可能ファイルに追加されるのを防ぐには^、単一の関数を持つすべての .c ファイルのオブジェクト ファイルを、通常は を使用して静的ライブラリextern inlineファイルに配置し、個々のオブジェクト ファイルではなくそのライブラリにリンクすることが推奨されます [3]。これにより、実際に必要なオブジェクト ファイルのみがリンクされます。一方、オブジェクト ファイルを直接リンクすると、オブジェクト ファイルが常に実行可能ファイルに含まれることになります。ただし、ライブラリ ファイルは、リンカー コマンド ラインで他のすべてのオブジェクト ファイルの後に指定する必要があります。これは、ライブラリ ファイルの後に指定されたオブジェクト ファイルからの関数への呼び出しは、リンカーによって考慮されないためです。関数から他の関数​​への呼び出しは、リンカーによって自動的に解決されます (のオプションによってこれが保証されます)。 ar rcsinlineinlinesar rcs

代替の解決策は、ライブラリの代わりにリンク時の最適化を使用することです。gcc は、-Wl,--gc-sectionsすべての関数が使用されていないセクションを省略するフラグを提供します。これは、単一の未使用関数のコードを含むオブジェクト ファイルに当てはまりますextern inline。ただし、未使用関数に関連するセクションだけでなく、他のすべてのオブジェクト ファイルから、他のすべての未使用セクションも削除されますextern inline。(プログラム自体ではなく、デバッガーからプログラマーによって呼び出される関数を実行ファイルにリンクすることが望ましい場合があります。たとえば、プログラムの内部状態を調べる場合などです。) このアプローチでは、extern inline関数ごとに 1 つの .c ファイルを使用する代わりに、すべての関数を含む単一の .c ファイルを使用することもできます。その後、そのファイルを でコンパイルする必要があります-fdata-sections -ffunction-sections。ただし、gcc のマニュアル ページでは、「これらのオプションは、そうすることで大きなメリットがある場合にのみ使用してください」と警告しています。

全く異なるアプローチを推奨する人もいます。それは、関数をヘッダーファイルでstatic inlineはなく として定義することです。 ^[2]そうすれば、到達不能なコードは生成されません。しかし、このアプローチは逆の場合に欠点があります。関数を複数の翻訳単位でインライン化できなかった場合、重複したコードが生成されます。生成された関数コードは、異なるアドレスを持つ必要があるため、翻訳単位間で共有できません。これはもう 1 つの欠点です。ヘッダーファイルで として定義されたこのような関数のアドレスを取得すると、異なる翻訳単位で異なる値が生成されます。したがって、関数は 1 つの翻訳単位でのみ使用される場合にのみ使用する必要があります。つまり、関数はヘッダーファイルではなく、それぞれの .c ファイルにのみ配置する必要があります。 inlinestatic inlinestatic inline

gnu89 の と のセマンティクスはinline、extern inline本質的に C99 のものと正反対です。 ^[4]ただし、 gnu89 ではextern inline関数を非修飾関数として再定義できるのに対し、C99ではinlineそれが許可されないという例外があります。 ^[5]extern inlineしたがって、再定義のない gnu89 は C99 に似ておりinline、gnu89 はinlineC99 に似ていますextern inline。言い換えると、gnu89 では、 として定義された関数はinline常に になり、extern inlineとして定義された関数は決して外部から見える関数を出力しません。この理由は、 が変数と一致するためです。extern変数は、 として定義された場合はストレージが予約されることはなく、 なしで定義された場合は常に になります。対照的に、C99 の理由は、を使用すると、その名前が示すものとは反対に、常に関数の非インライン バージョンが出力されるという副作用があるとしたら 驚くべきことです。inline

インライン関数に対して外部から参照可能な関数インスタンスを 1 つだけ提供する必要性と、その結果として到達不能なコードが発生する問題に関する C99 の注釈は、必要な変更を加えて gnu89 にも適用されます。

gcc バージョン 4.2 までは、 が明示的に指定されていinlineても gnu89 セマンティクスを使用していました。 ^[6]バージョン 5 では、^[5] gcc は gnu89 から gnu11 方言に切り替わり、事実上デフォルトで C99 セマンティクスが有効になりました。代わりに gnu89 セマンティクスを使用するには、インライン展開にのみ影響するように または を使用するか、すべての宣言に 属性を追加して、明示的に有効にする必要があります。C99 セマンティクスを保証するには、 、、または( なし) を使用できます。^[3]-std=c99inline-std=gnu89-fgnu89-inlinegnu_inlineinline-std=c99-std=c11-std=gnu99-std=gnu11-fgnu89-inline

C++ では、定義された関数はinline、必要に応じて、翻訳単位間で共有される関数を生成します。これは通常、必要なオブジェクト ファイルの共通セクションに関数を配置することによって行われます。関数はどこでも同じ定義を持つ必要があり、常にinline修飾子が付きます。C++ では、はextern inlineと同じですinline。C++ アプローチの根拠は、到達不能なコードを除去するための特別な予防措置を講じる必要がなく、通常の関数と同様に がextern指定されているかどうかは関係ないため、プログラマにとって最も便利な方法であるということです。

修飾子inlineは、クラス定義の一部として定義された関数に自動的に追加されます。

C90 モードの armcc は、C++ と同じセマンティクスextern inlineを提供します。このような定義は、必要に応じて翻訳単位間で共有される関数を生成します。C99 モードでは、常に関数が生成されますが、C++ と同様に、翻訳単位間で共有されます。したがって、同じ関数を異なる翻訳単位で定義できます。^[7]これは、初期化されていないグローバル変数の複数の非定義に対するUnix C コンパイラ^[8]の従来の動作と一致します。 inlineextern inlineextern inlineextern

関数のアドレスを取得するには、inlineいずれの場合でも、その関数の非インライン コピーのコードを生成する必要があります。

C99 では、inlineまたは関数はグローバル変数extern inlineにアクセスしたり、非ローカル変数を定義したりしてはなりません。ローカル変数は、関数がインライン化されたかどうか、または呼び出しが行われたかどうかに応じて、異なる翻訳単位では異なるオブジェクトになる場合とそうでない場合があります。定義のみが、制限なしに内部リンケージを持つ識別子を参照できます。これらは各翻訳単位で異なるオブジェクトになります。C++ では、と 非ローカルの両方が許可され、すべての翻訳単位で同じオブジェクトを参照します。 staticconst staticconst staticstatic inlineconstconst static

gccは関数をインライン化できない^[3]

1. これらは可変長であり、
2. 使用alloca
3. 計算された使用goto
4. 非ローカルを使用するgoto
5. ネストされた関数を使用する
6. 使用setjmp
7. 使用__builtin_longjmp
8. を使用する__builtin_returnか、
9. 使用__builtin_apply_args

MSDNのMicrosoft仕様によると、MS Visual C++はインライン化できません（ を使ってもできません__forceinline）。

1. 関数またはその呼び出し元は、/Ob0 (デバッグ ビルドの既定のオプション) を使用してコンパイルされます。
2. 関数と呼び出し元は、異なるタイプの例外処理を使用します(一方は C++ 例外処理、もう一方は構造化例外処理)。
3. 関数には可変引数リストがあります。
4. /Og、/Ox、/O1、または /O2 でコンパイルされていない限り、関数はインライン アセンブリを使用します。
5. 関数は再帰的であり、 を伴いません#pragma inline_recursion(on)。 プラグマを使用すると、再帰関数はデフォルトの深さ 16 呼び出しまでインライン化されます。 インライン化の深さを減らすには、inline_depthプラグマを使用します。
6. 関数は仮想であり、仮想的に呼び出されます。仮想関数への直接呼び出しはインライン化できます。
7. プログラムは関数のアドレスを取得し、関数へのポインターを介して呼び出しが行われます。アドレスが取得された関数への直接呼び出しはインライン化できます。
8. この関数には naked__declspec修飾子も付けられます。

インライン展開全般に関する問題 (インライン展開 § パフォーマンスへの影響を参照) に加えて、inline言語機能としての関数は、いくつかの理由から、見た目ほど価値がない可能性があります。

• 多くの場合、特定の関数をインライン化するかどうかを決定するには、コンパイラの方が人間よりも優れています。ただし、コンパイラがプログラマーが指定した数の関数をインライン化できない場合もあります。
• 注意すべき重要な点は、(関数の) コードがinlineクライアント (呼び出し元の関数) に公開されることです。
• 関数が進化するにつれて、以前はインライン化に適していなかった場所でインライン化に適したものになったり、以前はインライン化に適していた場所でインライン化に適さなくなったりすることがあります。関数のインライン化またはインライン化解除はマクロへの変換やマクロからの変換よりも簡単ですが、それでも追加のメンテナンスが必要であり、通常は比較的メリットは小さくなります。
• ネイティブ C ベースのコンパイル システムで増殖に使用されるインライン関数は、その本体の中間表現が各呼び出しサイトにコピーされるため、コンパイル時間が長くなる可能性があります。
• C99の の仕様inlineでは、関数がどこかで使用される場合、関数の外部定義が 1 つだけ必要です。プログラマーがそのような定義を提供しなかった場合、リンカー エラーが簡単に発生する可能性があります。これは、通常インライン化を妨げる最適化がオフになっている場合に発生する可能性があります。一方、定義を追加すると、プログラマーがリンク用のライブラリに配置したり、リンク時の最適化を使用したり、 などの方法で慎重に回避しないと、到達不能コードが発生する可能性がありますstatic inline。
• C++ では、関数はそれを使用するすべてのモジュール (翻訳単位) で定義する必要がありますinlineが、通常の関数は 1 つのモジュールでのみ定義する必要があります。そうしないと、1 つのモジュールを他のすべてのモジュールから独立してコンパイルできなくなります。コンパイラによっては、インライン化できない使用法を持つ各モジュールについて、それぞれのオブジェクト ファイルに関数のコードのコピーが含まれる場合があります。
• 組み込みソフトウェアでは、多くの場合、特定の関数を「プラグマ」ステートメントなどの特別なコンパイラ命令を使用して特定のコード セクションに配置する必要があります。 場合によっては、あるメモリ セグメントの関数が別のメモリ セグメントの関数を呼び出す必要があり、呼び出された関数のインライン化が発生すると、呼び出された関数のコードが、本来あるべきではないセグメントに配置される可能性があります。 たとえば、高性能メモリ セグメントのコード空間は非常に限られている場合があり、そのような空間に属する関数が、高性能セクションに配置することを意図していない別の大きな関数を呼び出し、呼び出された関数が不適切にインライン化されると、高性能メモリ セグメントのコード空間が不足する可能性があります。 このため、関数がインライン化されないようにする必要がある場合もあります。

インライン 指定子を持つ関数宣言は、インライン関数を宣言します。インライン指定子は、呼び出し時点での関数本体のインライン置換が通常の関数呼び出しメカニズムよりも優先されることを実装に示します。実装では、呼び出し時点でこのインライン置換を実行する必要はありません。ただし、このインライン置換が省略された場合でも、7.1.2 で定義されているインライン関数のその他のルールは尊重される必要があります。

—  ISO/IEC 14882:2011、現在の C++ 標準、セクション 7.1.2

インライン関数指定子を使用して宣言された関数は、インライン関数です ...関数をインライン関数にすると、関数の呼び出しが可能な限り高速になることが示唆されます。このような提案がどの程度有効であるかは、実装によって定義されます (脚注: たとえば、実装ではインライン置換をまったく実行しないか、インライン宣言のスコープ内の呼び出しに対してのみインライン置換を実行する場合があります) 。

インライン定義は、 関数の外部定義を提供しません。また、別の翻訳単位での外部定義を禁止しません。インライン定義は、外部定義の代替手段を提供します。翻訳者は、これを使用して、同じ翻訳単位内の関数への呼び出しを実装できます。関数の呼び出しでインライン定義が使用されるか、外部定義が使用されるかは指定されていません。

—  ISO 9899:1999(E)、C99規格、セクション6.7.4

• マクロ（コンピュータサイエンス）

• GNU コンパイラ コレクション(GCC)を使用したインライン関数
• LLVM貢献者 David Chisnallによる C および C++ の「インライン」セマンティクスの要約