VC6 コンパイラで構築された内部ライブラリ (他のチームによって開発された) を使用します。このライブラリには、主に C スタイルの API が含まれています。Visual Studio 9 コンパイラに移行する計画があります。ライブラリを VC9 コンパイラでビルドするように要求する必要がありますか?
より一般的な質問です。Visual Studio コンパイラの 2 つの異なるバージョンでビルドされた DLL は、どの点 (名前マングリング、最適化など) で異なりますか?
VC6 コンパイラで構築された内部ライブラリ (他のチームによって開発された) を使用します。このライブラリには、主に C スタイルの API が含まれています。Visual Studio 9 コンパイラに移行する計画があります。ライブラリを VC9 コンパイラでビルドするように要求する必要がありますか?
より一般的な質問です。Visual Studio コンパイラの 2 つの異なるバージョンでビルドされた DLL は、どの点 (名前マングリング、最適化など) で異なりますか?
通常、競合は C ランタイム ライブラリで発生します。主なアイデアは、メモリが割り当てられたモジュールでメモリの割り当てを解除する必要があるということです。そうすれば、別のバージョンのコンパイラでビルドされたライブラリを安全に使用できます。もう 1 つの問題は構造体のパッキングですが、Visual C++ コンパイラのみを使用する場合は違いはありません。
名前マングリングは、Visual C++ のバージョンごとに異なりますが、C++ ライブラリにのみ適用されます。C スタイルのエクスポートを使用する場合 (たとえば、DEF ファイルがある場合)、心配する必要はありません。
この質問はあなたの完全な複製ではありませんが、役に立つかもしれません.
私の知る限り、Visual C++ の名前マングリングは、リリースごとに安定しています。
主な問題は、1 つのバージョンでコンパイルされたコードをそのバージョンの CRTL にリンクする必要があり、複数のバージョンのコードを同じ DLL または EXE に混在させると、両方のオブジェクト コードが異なる RTL ルーチンを想定するため、機能しないことです。
一方、異なるライブラリを含む個別の DLL をリンクすると、動作するはずです。結局のところ、それが DLL の要点です。
そのシナリオでは、API のみを使用し、(これが 32 ビット コードの場合) 呼び出し規約を明示的に指定することをお勧めしますextern "C"
(__stdcall__
または...)。WINAPI
_cdecl
また、アプリケーションに CRTL の複数のコピーがある場合、微妙な落とし穴があります。つまり、複数のヒープがあります。オブジェクトが 1 つのヒープに割り当てられ、別のヒープに解放されると、ヒープはすぐに破損し、クラッシュします。
全体として、コンパイラで再コンパイルすることができれば、それが最も簡単なことです。