Visual Studio には __forceinline のサポートが含まれています。Microsoft Visual Studio 2005 のドキュメントには、次のように記載されています。
__forceinline キーワードは、費用対効果の分析を上書きし、代わりにプログラマーの判断に依存します。
ここで疑問が生じます: コンパイラの費用対効果の分析が間違っているのはいつですか? そして、それが間違っていることをどのように知ることができますか?
この問題について、私が自分のコンパイラよりもよく知っていると想定されるのは、どのようなシナリオですか?
プロファイリング データがそうする場合にのみ、コンパイラよりもよく知っています。
私が使用している 1 つの場所は、ライセンスの検証です。
easy* クラッキングから保護するための重要な要素の 1 つは、1 つの場所だけでなく複数の場所でライセンスが付与されていることを確認することです。これらの場所が同じ関数呼び出しになることは望ましくありません。
*) すべてがクラックされる可能性があるという議論にこれを回さないでください - 私は知っています. また、これだけではあまり役に立ちません。
コンパイラは静的コード分析に基づいて決定を下していますが、don が言うようにプロファイリングすると、はるかに広範囲に及ぶ可能性のある動的分析が実行されます。特定のコードの呼び出し回数は、多くの場合、それが使用されるコンテキスト (データなど) によって大きく左右されます。ユースケースの典型的なセットをプロファイリングすると、これが行われます。個人的には、自動回帰テストでプロファイリングを有効にして、この情報を収集しています。インラインを強制することに加えて、ループをアンロールし、そのようなデータに基づいて他の手動の最適化を実行して、効果を上げました。また、最善の努力が実際にはパフォーマンスの低下につながる場合があるため、後で再度プロファイリングすることも不可欠です。繰り返しますが、自動化により、これが大幅に軽減されます。
ただし、多くの場合、私の経験では、アルゴリズムを微調整すると、そのままコードを最適化するよりもはるかに優れた結果が得られます。
私はリソースが限られているデバイス向けのソフトウェアを 9 年ほど開発してきましたが、使用する必要があったのは、カメラ ドライバーがキャプチャ バッファーからデバイス画面にピクセル データをコピーする必要があるタイト ループでのみでした。__forceinlineそこでは、特定の関数呼び出しのコストがオーバーレイ描画のパフォーマンスを大幅に圧迫していることがはっきりとわかりました。
確実にする唯一の方法は、ある場合とない場合のパフォーマンスを測定することです。パフォーマンスが非常に重要なコードを記述していない限り、これは通常不要です。
インラインディレクティブは、次のような関数に使用するとまったく役に立ちません。
再帰的で長く、ループで構成され、
__forceinlineを使用してこの決定を強制したい場合
実際には、__forceinlineキーワードを使用しても。Visual C ++は、コードをインライン化しないことを選択する場合があります。（ソース：結果のアセンブリソースコード。）
速度が重要な場合（各フレームで実行する必要のあるタイトな内部ループなど）、結果のアセンブリコードを常に確認してください。
インラインの代わりに#defineを使用するとうまくいく場合があります。（もちろん、＃defineを使用すると多くのチェックが失われるため、本当に重要な場合と場所でのみ使用してください）。
関数をインライン展開することが適切かどうか、または有益かどうかをコンパイラが明確に判断できない状況がいくつかあります。インライン化には、コンパイラが望んでいないトレードオフが含まれる場合がありますが、実際にはそうです (たとえば、コードの肥大化)。
一般に、最近のコンパイラは、この決定を下すのに非常に優れています。
複雑な計算のために関数が 1 か所で数回呼び出されることがわかっている場合は、__forceinline を使用することをお勧めします。たとえば、アニメーションの行列乗算は、関数の呼び出しがプロファイラーによって認識されるようになるまで、何度も呼び出す必要がある場合があります。他の人が言ったように、特にコンパイル時にコードの実行が不明な動的な状況では、コンパイラはそれについて本当に知ることができません。