3

私の会社のメインアプリケーションは主にC++で書かれています（いくつかのDelphiコードとコンポーネントを使用）。RAD Studio 2007から2010にアップグレードして、次のリリースに向けて約1週間で開始します。このアップグレードをスムーズに進めるために知っておくべきことは何ですか？

私がこれまで考えてきたポイントは次のとおりです。

  • Unicode。これは本当に複雑に見えます。私たちのアプリには、std::string-sとAnsiString-sの恐ろしい組み合わせが含まれています。これについては、「wstringはUnicodeStringで可能なすべてのものを保持できるので、検索/置換を行うだけでよいか」、「すべてのC ++文字列タイプを完全に避けてUnicodeStringを使用する必要があるか」、「できますか」など、多くの質問があります。既存の.HPPsイベントハンドラーメソッドのプロトタイプはコンパイラーによってAnsiStringに変換されましたが、すべてのイベントハンドラーを文字列を使用するように変更します。 Unicode文字列」など。これに関する洞察をいただければ幸いです。

    下位互換性も必要です。私たちのアプリは、現在文字列をバイトの配列として格納している独自のバイナリタプル形式を使用しています。これをアップグレードして古いファイルを読み取り、おそらく新しいUnicode文字列も書き込む必要があります。バイナリ形式に埋め込まれたUnicode文字列を処理するにはどうすればよいですか？UnicodeStringをバイトの配列に向けることができる一般的な方法はありますか？それは元々ANSIバイトまたはUnicodeとして記述されていて、それらが何であるかを理解しますか？

  • サードパーティのコンポーネント。主にSpTBXを使用しており、互換性があるようです。

  • プロジェクトのアップグレード。Codegearフォーラムの標準的なアドバイスは、アップグレード時にすべてのプロジェクトファイルを手動で再作成することのようです。これは非常に多くの作業です（メインアプリの7つのプロジェクト（主にlibs）に加えて、半ダースのDLL、多くのファイル）。これを自動化する方法はありますか？

  • リンカーはどのように見えますか？リンカがランダムにクラッシュしたり、リソースが不足したりすることで、従来は多くの問題が発生していましたが、2007年には大幅に改善されました。これが、メインアプリケーションが複数のライブラリに分割される理由の1つです。リンカはできません（うまくいけば、「できませんでした。しかし、今はできますか？）それ以外の方法で処理できます。

  • 新しいタイプライブラリエディタとフォーマットがあることを知っています（IDL、つまりテキストを格納し、TLBを動的に生成しますか？）これは、TLBを使用した既存のCOMプロジェクトのアップグレードをどの程度うまく処理しますか？C++アプリケーションに組み込まれているDelphiコードとTLBがあります。

  • 他に考慮すべき、または知っておくべきことはありますか？

見つけた：

4

4 に答える 4

4

プロジェクトのアップグレード。Codegearフォーラムの標準的なアドバイスは、アップグレード時にすべてのプロジェクトファイルを手動で再作成することのようです。これは非常に多くの作業です（メインアプリの7つのプロジェクト（主にlibs）に加えて、半ダースのDLL、多くのファイル）。これを自動化する方法はありますか？

あります：IDEのプロジェクトインポーターを使用するだけです:)
真剣に、私はプロジェクトをインポートしてみて、それが機能しないように見えるかどうかを調査します。

リンカーはどのように見えますか？リンカがランダムにクラッシュしたり、リソースが不足したりすることで、従来は多くの問題が発生していましたが、2007年には大幅に改善されました。これが、メインアプリケーションが複数のライブラリに分割される理由の1つです。リンカはできません（うまくいけば、「できませんでした。しかし、今はできますか？）それ以外の方法で処理できます。

C ++ Builder 2009以降、ILINKにほとんど問題はありません。他の人がメモリ不足エラーを経験したことを時々読んだことがありますが、ニュースグループの誰かが回避策を発見しました。

https://forums.embarcadero.com/thread.jspa?messageID=140012&tstart=0#140012

また、ここで読むことができるように、コンパイラは、割り当てるメモリの最大量を制御するための新しいオプション（-Cx）を取得しました。

新しいタイプライブラリエディタとフォーマットがあることを知っています（IDL、つまりテキストを格納し、TLBを動的に生成しますか？）これは、TLBを使用した既存のCOMプロジェクトのアップグレードをどの程度うまく処理しますか？

問題なく動作するはずです。

これについては、「wstringはUnicodeStringで可能なすべてのものを保持できるので、検索/置換を行うだけでよいか」など、多くの質問があります。

はい、Windowsプラットフォームでは、wchar_tは通常16ビットの大きさです。つまり、UnicodeStringであるUTF-16を保持するのに十分です。

または「すべてのC++文字列型を完全に避けてUnicodeStringを使用する必要があります」

コードの移植性によって異なります。いずれの場合も、文字列型が必要な場合は、「UnicodeString」ではなく「String」を使用してください。

「既存の.HPPはコンパイラによってAnsiStringに変換されましたが、すべてのイベントハンドラをStringを使用するように変更できますか？」

まず、古いバージョンのDCCで生成された.hppファイルを再利用しないでください。Delphiで文字列型を使用するイベントハンドラの場合は、UnicodeStringを使用する必要があります。上記のように、単に「文字列」を使用すると、コードはC++BuilderのANSIバージョンとUnicodeバージョンの両方で機能します。

「すべての文字列の前にLを付ける必要がありますか、それともUnicode文字列を使用できるようにUnicodeが有効になっているコンパイラは十分に賢いですか」などの基本事項に至るまで

コンパイラは文字列を変換しませんが（言語標準と競合します）、AnsiStringとUnicodeStringの両方に、char*とwchar_t*の両方の文字列リテラルに対してコピーコンストラクタのオーバーロードがあります。つまり、次のように機能します。

AnsiString as = L"foo";
UnicodeString us = "bar";

ただし、このように機能しないのは、printf（）/ scanf（）関数の全体です。AnsiString :: sprintf（）はconst char *を取り、UnicodeString :: sprintf（）はconstwchar_t*を取ります。

sprintf（）を頻繁に使用している場合は、私のCbdeFormatライブラリが役立つことがあります。このテーマに関する私の記事を読んでください。

于 2009-09-08T12:28:32.667 に答える
2

バイナリタプル形式のデータ文字列の目的はわかりません。Unicodeを格納する必要がありますか？D2007からD2009に移行したとき、システムの一部のANSI文字列のみを保持することができました。

Unicodeの保存が必要な場合は、既存のデータがUTF-8などの形式と互換性があるかどうかを確認する必要があります。既存のデータファイルに保存されている値の範囲に問題がある場合は、次のアップグレードで古いデータファイルの1回限りの変換を行い、古いAnsiStringデータを読み込んで、UTF-8として別のデータに書き戻します。ファイル名または拡張子、または適切なファイルヘッダーデータを変更する。この種の処理変更を可能にするために、私は長い間データファイルをバージョン管理してきました。

私はBCB2010プロジェクトを始めたばかりなので、他の質問にコメントすることはできませんが、DelphiプロジェクトをD2007からD2009にアップグレードするのは確かに困難でしたが、XMLだけのプロジェクトファイルを編集することでこれを修正できました。

変換で頑張ってください;-)

于 2009-09-08T09:02:11.013 に答える
2

Unicode。これは本当に複雑に見えます。私たちのアプリには、std::string-sとAnsiString-sの恐ろしい組み合わせが含まれています。これについては、「wstringはUnicodeStringで可能なすべてのものを保持できるので、検索/置換を行うだけでよいか」など、多くの質問があります。

std::wstringwchar_t*と同じように、文字列が含まれますSystem::UnicodeString。

すべてのC++文字列型を完全に避け、UnicodeStringを使用する必要があります

それはあなた次第です。 char*文字列は引き続きサポートされます。すべてをUnicodeに移行する必要はありません。

既存の.HPPはコンパイラによってAnsiStringに変換されましたが、すべてのイベントハンドラを変更してStringを使用できますか？

System::Stringいいえ、エイリアスを使用するように自動管理イベントハンドラーを変更することはできません。すべてのIDEバージョンはそれについて不平を言うでしょう。UnicodeString必要に応じて、パラメーターの代わりにパラメーターを使用するように、イベントハンドラーの宣言と実装を手動で更新する必要がありAnsiStringます。つまり、DFMとUnit .hファイルを複数のIDEバージョン間で共有することもできません（とにかく行うべきではありません）。

すべての文字列の前にLを付ける必要がありますか、それともUnicode文字列を使用できるようにUnicodeが有効になっているコンパイラである必要があります

いいえ。Lプレフィックスなしで文字列定数または文字定数を宣言した場合でも、データはAnsiとして解釈されます。それは変わっていません。ただし、Ansiデータをに渡すことはできますがSystem::UnicodeString（に渡すことはできませんstd::wstring）、Unicodeに自動的に変換されます。ただし、OSのデフォルトのAnsiコードページを使用してデータを解釈するため、注意が必要です。AnsiデータがASCII文字のみを使用している限り、問題はありません。それ以外の場合、非ASCII文字を使用している場合は、正しいコードページが割り当てられているSystem::AnsiStringTまたはSystem::RawByteString（両方ともCB2009で導入された）にデータを入れてから、それをSystem::UnicodeString変数に割り当てることをお勧めします。変換には、OSのデフォルトのコードページの代わりに関連するコードページが使用されます。

下位互換性も必要です。私たちのアプリは、現在文字列をバイトの配列として格納している独自のバイナリタプル形式を使用しています。これをアップグレードして古いファイルを読み取り、おそらく新しいUnicode文字列も書き込む必要があります。バイナリ形式に埋め込まれたUnicode文字列を処理するにはどうすればよいですか？

タプルが8ビット文字を期待している場合は、構造体宣言などが文字charではなく使用されていることを確認する必要がありwchar_tます。Unicode文字列を格納する必要があるが、8ビットの互換性を維持する必要がある場合は、最初にUnicode文字列をUTF-8にエンコードする必要があります（System::UTF8String文字列タイプを使用すると便利です-CB2009以降、これは真のUTFです-8文字列になりました）。非ASCII文字を使用しない限り、ASCII文字はUTF-8でそのままエンコードされるため、古いアプリは違いを認識しません。ただし、生のUnicodeデータを保存する場合は、文字列データがAnsiまたはUnicodeのどちらとして保存されるかを示すフラグがタプルのどこかに必要になり（まだフラグがない場合）、アプリはそのフラグを探す必要があります。 。

UnicodeStringをバイトの配列に向けることができる一般的な方法はありますか？それは元々ANSIバイトまたはUnicodeとして記述されていて、それらが何であるかを理解しますか？

いいえ。バイトの実際のエンコーディングを事前に知っておく必要があります。System::AnsiStringまたはにメモリアドレスを渡すと、 std::stringAnsi文字が想定されます。同じメモリアドレスをSystem::UnicodeStringまたはstd::wstringに渡すと、代わりにUnicode文字が想定されます。

サードパーティのコンポーネント。主にSpTBXを使用しており、互換性があるようです。

以前のすべてのバージョン（2006から2007への移行を除く）と同様に、サードパーティコンポーネントは、手動（ソースコードがある場合）またはそれぞれのコンポーネントによって、2010年に再コンパイルする必要があります。ベンダー。

プロジェクトのアップグレード。Codegearフォーラムの標準的なアドバイスは、アップグレード時にすべてのプロジェクトファイルを手動で再作成することのようです。

はい。それはまだ当てはまります。

新しいタイプライブラリエディタとフォーマットがあることを知っています（IDL、つまりテキストを格納し、TLBを動的に生成しますか？）

.TLBファイルはもう使用されていません。新しいシステムは、.ridl（Reduced IDL）ファイルで動作するようになりました。コンパイル中に、.ridlは実行可能ファイルのバイナリリソースに正しいTypeLibrary情報を直接生成します。.tlbファイルは生成されません。

これは、TLBを使用した既存のCOMプロジェクトのアップグレードをどの程度うまく処理しますか？C++アプリケーションに組み込まれているDelphiコードとTLBがあります。

CB2010（またはCB2009）が既存の.tlbファイルを直接消費できるかどうかは覚えていません。私は彼らができるとは思わない。ただし、tlibimp.exeを介して.tlbファイルを実行すると、.ridlファイルがエクスポートされます。または、過去のバージョンのTLBエディターからIDLテキストをコピーして、新しい.ridlファイルに手動で貼り付けることもできます。どちらの方法でも、その.ridlileをCB2010プロジェクトに追加できます。

2007年と2010年が共存しています。以前に同じマシンで2006年と2007年に問題が発生したことがあるため、この回答を信頼できるかどうかはわかりません。

そのため、同じ物理マシンに複数のIDEバージョンをインストールするときに仮想マシンを使用します。

于 2009-09-08T22:10:27.357 に答える
1

アップグレードのコストはメリットと一致していますか？

新しいプラットフォームで新しいコンポーネントが開発される段階的なアップグレードを開始してみませんか。さまざまな相互運用ヘルパーを介して、新しいコンポーネントを古いバージョンに統合します。

このアプローチはvb6、へのアップグレードを検討している開発者vb.netに提案されました。

于 2009-09-08T07:44:40.847 に答える