インライン（CおよびC++）

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

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

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

inline 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はサポートしていません。ただし、意味論は異なります。どちらの場合も、インライン化を強制するわけではありません。コンパイラは、関数をまったくインライン化しないか、一部の場合にのみインライン化するかを自由に選択できます。コンパイラによって、インライン化できる関数の複雑さが異なります。Microsoft Visual C++やGCCのような主流の C++ コンパイラは、関数としてマークされていない関数であっても、適切な関数を自動的にインライン化できるオプションをサポートしています。ただし、コンパイラにすべてのインライン化の決定を任せるためにキーワードを省略することは不可能です。なぜなら、リンカが異なる翻訳単位に重複した定義があると警告するからです。これは、関数をインライン化する必要があることをコンパイラに示唆するだけでなく、コンパイラが関数の呼び出し可能なアウトオブラインコピーを生成するかどうかにも影響するためです (インライン関数のストレージクラスを参照)。inlineinlineinlineinlineinline

GNU C は、提供する方言 gnu89 の一部として、inlineC89 の拡張機能として をサポートしています。ただし、その意味論は C++ および C99 とは異なります。C90 モードの armcc も、inline非標準の拡張機能として を提供しており、その意味論は gnu89 および C99 とは異なります。

一部の実装では、コンパイラに強制的に関数をインライン化させる手段が提供されており、通常は実装固有の宣言指定子によって行われます。

• Microsoft Visual 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に適用した場合と適用しない場合の効果はinline、C言語の方言^{[ 2 ]}とC++ ^{[ 3 ]で異なります。}

関数のアドレスを取得するには、inlineその関数のインライン化されていないコピーを生成するコードが必ず必要となる。

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

^{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. この関数には、修飾子を省略した「裸」の__declspecマークも付いています。

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

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

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

インライン関数指定子で宣言された関数はインライン関数です 。関数をインライン関数にすると、その関数への呼び出しが可能な限り高速になることを意味します。このような提案がどの程度効果的かは実装依存です（注：たとえば、実装によってはインライン置換を全く行わない場合や、インライン宣言のスコープ内の呼び出しに対してのみインライン置換を行う場合があります） 。

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

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

• GNUコンパイラコレクション（GCC）による関数のインライン化
• LLVM貢献者David Chisnallによる、CおよびC++における「インライン」セマンティクスの概要