クロスプラットフォーム C++ アプリケーションの win32 ビルドを MS Visual Studio 2003 から MS Visual Studio 2005 に移行することを検討しています (はい、非常に前向きです ;)
コンパイルして動作させるために、多くのコード変更を期待する必要がありますか?
クロスプラットフォーム C++ アプリケーションの win32 ビルドを MS Visual Studio 2003 から MS Visual Studio 2005 に移行することを検討しています (はい、非常に前向きです ;)
コンパイルして動作させるために、多くのコード変更を期待する必要がありますか?
比較的大きなコードベースを VS2003 から VS2005 経由で VS2008 に移行したところ、見つかった問題の大部分は const char * を返す関数の戻り値を char * に割り当てるなどの const/non-const の問題でした。VS2005 と VS2008 はどちらも、const の正確性に関してはかなりうるさいです。既存のコードベースが少しずさんな場合、申し訳ありませんが、const の正確性に関して古い学校である場合は、これがたくさん表示されます。
非常に歓迎すべき変更は、VS2005 のテンプレート サポートが VS2003 よりも著しく優れていることです (それ自体が以前のバージョンからの大幅な改善です)。 VC++ 4.x の全盛期。
遭遇する可能性が高い問題の 1 つは、特に C 文字列関数を使用している場合に、「非推奨」または「安全でない」関数に関する大量の警告です。これらの多くは「Microsoft によって非推奨」(「Microsoft による」部分が省略されていることのみ) であり、まだ完全に使用可能ですが、バッファ オーバーフローの潜在的な原因として知られています。変換したプロジェクトでは、プリプロセッサ定義 _CRT_SECURE_NO_WARNINGS を設定し、警告 C4996 を無効にして、これらのやや迷惑なメッセージをオフにしました。
私たちが遭遇したもう 1 つの問題は、MS が VS2005 または VS2008 のいずれかで time_t のデフォルト サイズを変更したことです (申し訳ありませんが、覚えていません。間違いなく VS2008 にありますが、既に VS2005 にある可能性があります)。インターフェイスで time_t を使用する従来のライブラリでは、_USE_32BIT_TIME_T を使用して古いコンパイラの動作に戻す必要があります。
ソリューションに複数のプロジェクトが含まれている場合、並列ビルド機能 (既定でオンになっています) によって、不足しているビルドの依存関係が強調表示されることがあります。そのため、プロジェクトは突然間違った順序でビルドされますが、並列ビルドから線形ビルドに戻すと、魔法のように正しくビルドされます。
全体として、私は VS2003 よりも VS2005/8 を好みます。それがオプションである場合は、VS2008 にアップグレードすることをお勧めします。これは、コンパイラが VS2005 よりも「優れている」ためです。MS は、ネイティブ C++ コンパイラの改善に多大な努力を払っているようです。その一部は 2005 年にすでに顕著だったので、2005 年に固執したとしても、少なくともある程度のメリットは得られます。
このプロジェクトに着手するかどうか、およびどのように着手するかを決定する際には、MS の重大な変更のリストを確認する必要があります。
多くの文字列コマンドは、2005年のように、実行中のバッファを停止しようとするセキュリティを強化したように、警告を表示します。
ただし、2003コードは引き続きコンパイルされます。
最近、10 年前の VC6 プログラムを VS2008 に変換しました。ソース コードを変更する必要はなく、プロジェクト ファイルに必要な変更のみがアップグレード ウィザードによって処理されました。
また、チェック済み反復子を無効にすることを検討してください。そうしないと、新しいバージョンへの移植後にパフォーマンスが低下する可能性があります。
ソース コードが C++ 標準に準拠している場合、2005 に移行するために何も変更する必要はありません。
古いバージョンの VS から新しいバージョンに移行する際に人々が抱える主な問題は、新しいバージョンがより標準に準拠していることです。
次のようなもの:
for(i = 0; i < length; ++i)
{
}
when i
is undefined before is undefined VS の以前のバージョンでは正常に機能しますが、2005 年には i が未定義変数として正しくマークされます。
いいえ、それ以上は期待できません。
編集: 最初に vs2005 のデモ版でコードを試す必要があります。