ヘッダーファイルのインライン関数の定義を（少なくとも、指定されたコンパイル単位で関数をインライン展開するときにインプリメンテーションに表示される）何らかの形で提供する理由は、C++標準の要件です。
しかし、標準は、プリプロセッサ、コンパイラ、リンカなどのツールチェーンやその一部などの実装が少しスマートにならないようにするためのものではありません。
いくつかの特定の実装では、少しスマートな作業が行われるため、実際にはコンパイラには表示されない状況でも関数をインライン展開できます。たとえば、基本的な「すべてのソースファイルをコンパイルしてリンクする」ツールチェーンでは、スマートリンカは関数が小さく、数回しか呼び出されないことを認識し、インライン展開するポイント（例えば、関数を呼び出す文が別のコンパイル単位にあるため、関数自体は別のコンパイル単位にあります）コンパイラはインライン展開を行いません。
実際には、標準で実装されていることを防ぐことはできません。これは、単にすべての実装の動作のための最低限の要件のセットを述べています。
本質的に、コンパイラがインライン化される関数の可視性を持つという要件は、標準からの最小要件です。プログラムがそのように記述されている場合（例えば、インライン化されるすべての関数がヘッダファイルで定義されている場合）、標準ではすべての（標準に準拠した）実装で動作することが保証されます。
しかし、これはわれわれのスマートなツールチェーンにとってどういう意味ですか？よりスマートなツール連鎖は、適切な形式のプログラム（これらの関数を使用するすべてのコンパイル単位でインライン関数を定義するプログラムを含む）から正しい結果を生成する必要があります。私たちのツールチェーンは、よりスマートな操作（例えば、コンパイルユニット間の覗き見）を許可されていますが、コードが別のツールチェーンによって拒否されるようなスマートな動作（コンパイラ間でのコンパイラの覗き見など）
最終的に、C++実装のすべて（ツールチェーン、標準ライブラリなど）は、C++標準の要件に準拠する必要があります。逆のことは真実ではありません。一つの実装は、標準よりもスマートなことを行うかもしれませんが、他の実装が互換性のある方法で動作するという要件を生成しません。
技術的には、インライン化はコンパイラの機能に限定されません。コンパイラまたはリンカで発生する可能性があります。実行時にも発生する可能性があります。たとえば、「ジャストインタイム」テクノロジは、後続のパフォーマンスを向上させるために、実行可能コードを数回実行した後に再構成することができます[通常、仮想マシン環境で発生します自己修正実行可能ファイルに関連する問題を回避しながら、そのような技術の利点]。
"対応するcppファイル"はありません。関数定義は、任意のソースファイル、または後でプログラムにリンクされる任意のオブジェクトファイルまたはライブラリに含めることができます。言い換えれば、このケースは全く与えられていない。 – molbdnilo
@molbdniloわかりました、申し訳ありませんが、私は "対応するcppファイル"と言って間違っていました。私はまだコンパイラがインラインキーワードを持たずにどのように機能をインライン化できるのか不思議です。たとえば、MSDNは次のように言っています： "/ Ob2。デフォルト値。インライン、__inline、または__forceinline、およびコンパイラが選択する他の関数としてマークされた関数の展開を許可します。"これはリンカ段階ではなく推測している段階です。 – Zebrafish