これは、「No question's too dum」部門からの 1 つです。
さて、主題が言うように: 影響はありますか? もしそうなら、いくらですか？コードと DFM リソースに含まれるすべての文字列リテラルは、コンパイルされたバイナリ内で 2 倍のスペースを占めるようになりますか? コンパイルされたアプリケーションの実行時のメモリ使用量はどうですか? すべての文字列変数が 2 倍の RAM を占有するようになりましたか? 私も気にする必要がありますか？
初期のプレリリース Web キャストの 1 つで、このような質問があったことを覚えていますが、答えを思い出せません。また、試用版は 14 日間しかないため、必要なサードパーティ ライブラリが更新される前 (おそらく約 1 か月後) に自分で試すつもりはありません。
D2009は、デフォルトの文字列タイプにUTF-16を使用しますが、必要に応じて変数UTF-8を作成できます。
Jan Goyvaertsは、優れたブログ投稿でサイズと速度のトレードオフについて説明しています。
DFMの文字列リテラルは、少なくともD7以降UTF-8になっています。したがって、D2009を使用したDFMの文字列によるサイズの増加はありません。
ようやく Delphi 2009 を手に入れることができました。必要な調整を行った後、プロジェクトをコンパイルして問題なく実行できるようになりました。:)
結果をすばやく取得するために、最初はアプリのもう少し複雑なモジュールを 1 つコメント アウトする必要があったため、まだ 100% 比較できるわけではありませんが、ソース コードに大量の文字列リテラルが含まれているにもかかわらず (過剰なデバッグ ログ メッセージ) Delphi 2009 でコンパイルされたバイナリのサイズは、おそらく以前とほぼ同じになります。
Delphi コンパイラは、実際にバイナリまたは少なくともそのリソース セクションに対して何らかの圧縮を実行するのでしょうか。UTF-16 文字列リテラルへの変更が、この特定のアプリに大きな影響を与えることを本当に期待していたでしょう。リテラルは本当に (圧縮されていない) UTF-16 としてバイナリ内に格納されていますか?
メモリ フットプリントの違いをまだ調査する時間がありませんでした。
編集:{$STRINGCHECKS}直接 Unicode 関連ではありませんが、確実に関連しています: Andreas Hausladen は最近、コンパイル済みの実行可能ファイルのサイズに対するコンパイラ オプション (BTW: デフォルトでオン) の (重大な) 影響について興味深いビットを投稿しました: http://andy.jgknet.de /ブログ/?p=487
私は何年も Unicode VCL を待ち望んでいましたが、ついに登場しました。とにかく多くの文字列リテラルを持たないか、大量のデータをメモリに保存しないため、ほとんどのアプリケーションはサイズの問題について心配する必要はないと思います。
ユーザビリティの問題は、Unicode の使用を可能な限り正当化するために、より重視されています。
一部の開発者が小さな exe を作成したい場合は、AnsiString を使用して手作業で最適化できます (i18n が問題にならない場合)。
私は何年もDelphiを使用していませんが、おそらく使用するUnicodeエンコーディングに依存します。UTF8は、通常のASCII文字セットとまったく同じです（エキゾチックな文字を使用する場合は、複数のバイトのみを使用します）。UTF16は少し肥大化している可能性があります。