3

質問の動機: 64 ビット コードと 32 ビット コードを生成するには、2 つの個別のフル プログラム コンパイルが必要です。ビジュアル スタジオを使用する場合 (以下で詳しく説明します)、リリース ビルドとデバッグ ビルドには互換性がないため、さらに 2 つのフル プログラム コンパイルが必要になるようです (合計で 4 つになります）。2 つの完全なプログラム コンパイルに固執したいのですが、混乱しています。

デバッグ時に気になるのは、クラッシュの原因となったコードのグローバル状態、スタック フレーム、および行番号/ファイルです。また、査読済みの非常に安定したオープンソース ライブラリからのデバッグ情報も気にしません。したがって、これらのライブラリのデバッグ情報は必要なく、このライブラリのリリース ビルドで十分です。

証拠: VS では、アプリケーションのデバッグ バージョンをコンパイルし、それを Google Protocol Buffers のリリース バージョンとリンクすると、リリース タイプとデバッグ タイプが混在する副作用により、生成されたコードが失敗することがわかっています。

これが Visual Studio を使用することの副作用であるかどうかを知りたいのですが、特定のコンパイラ スイッチのセットがそうなっています。

次に、オープンソース プロジェクトのビルド スクリプト/プロセスを調べると、デバッグ モードで生成されたコードとリリースで生成されたコード (たとえばmumble ) を混在させても問題ないようです。これは、 release と ReleaseWithDebugInfo の違いと関係があると思います (cmake から借用した用語ですが、これは Visual Studio 内で明らかに表現可能です)。ReleaseWithDebugInfo は、バイナリの最適化されたバージョンであり、デバッグ情報も生成されるため、リリースに適しています。

質問 ：

  1. どのスイッチがコードを非互換にするかについて、誰かが説明するか、参照を提供してください。
  2. Visual Studio でコンパイルする ReleaseWithDebugInfo スタイルは、デバッグとリリースの両方のユースケースに十分ですか (上記で説明したように、私の基準によると)? --つまり、コンパイラがデバッグモードで生成するものは何でもやり過ぎですか、それとも冗長ですか?
  3. ReleaseWithDebugInfo モード (私のアプリケーション用) で、リリース モード (デバッグ情報なし) で外部依存関係をコンパイルし、未定義の動作を持たないようにすることはできますか?
4

1 に答える 1

4

デバッグモード（最適化されていないことを意味すると思います）コードが「やり過ぎ」であるかどうかは、それで何をしたいかによって異なります。

デバッガーを使用して、行を非常に正確にステップ実行し、遭遇した変数を調べたい場合は、最適化をオフにする必要があります。それについてあまり気にしない場合は、オンのままにして、デバッガーでの奇妙な動作に耐えることができます。

エディット コンティニュ用にコンパイルする場合、部分的なコンパイル/リンクを可能にするために、その場所に多くのパディングが配置されます。

そのため、最適化されていないコードには多くの「やり過ぎ」や「冗長性」がありますが、それでも価値があるかもしれません。

異なる構成をリンクする際の通常の問題は、実行時ライブラリの異なるバージョン/構成によって割り当てられたオブジェクトを共有している場合です。ライブラリ間で Win32 スタイルの 'C' スタイルのインターフェイスを使用している場合、デバッグとリリースのどちらを行うかはほとんど気にしません。あるバージョンのランタイムで CString をヒープに割り当て、それを別のランタイムで割り当てを解除するコードに渡すと、多くの場合問題が発生します。

ここで考えなければならないことが 3 つあります。

  • デバッグ シンボルは必要ですか? - これらは任意のデバッグ/リリース構成で作成できます
  • 優れたデバッグ機能が必要ですか、それとも優れたコード最適化が必要ですか?
  • みんなが使っているCRT/STL/バージョンは?

完璧にするために本当に必要なのは最後の1つだけです。残りの 2 つは個人的な好みです。

于 2010-11-09T12:56:17.243 に答える