RAD Studio 12のリリースが間近に迫ってきました！

2023年8月には少し趣向を変えたウェビナーを開催し、C++BuilderとRAD StudioのC++側で取り組んでいる技術の舞台裏を紹介しました。

このウェビナーでプレビューした内容の 1 つは、アップグレードされた Clang ベースの Win64コンパイラでした。ただし、単なるアップグレードではなく、新しい STL、新しいリンカなど、コアとなる部分にいくつかの主要な技術的改善が加えられています。この試みは、品質と寿命のために正しい決断を下すことを強く意識し、ツールチェーン全体を徹底的に作り直すことでした。

新しいClang

C++コンパイラはRAD Studioの基盤であるため、Clang と LLVM作業を通じて、エンバカデロではDelphiからLLVMを利用できるようにしています。そしてもちろん、C++開発者に最高のソース互換性、ライブラリ、アプリのパフォーマンスなどを提供するには、最新の強力なC++コンパイラが必要です。

エンバカデロが目標としている内容は、以下の通りです。

• 非常に高品質かつ堅牢なSTL。そして複雑かつ大規模なファイルも扱えるリンカ
• 例外処理など、あらゆる分野で優れた品質
• 優れた言語規格の互換性
• コンパイル済みコードの高いパフォーマンス。そして最適化されたランタイム
• 可能な限りプラットフォームの標準に適合

エンバカデロはどうやって上記の要件に対応しているのでしょうか？逆の順序を追ってご紹介いたします。

プラットフォーム標準

新しいツールチェーンはClang 15*をベースにしています。以前のツールチェーンは、実際には (長い話ですが) Kylix に関連する歴史的な理由から、主にUnix/Linux形式である ELF オブジェクトファイル形式を使用していました。新しいツールチェーンでは、あらゆるコンパイル言語のWindowsコンパイラの標準オブジェクトファイル形式であるCOFFに移行しています。同様に、やはり標準であるPDBデバッグフォーマットを使用しています。サードパーティのツールは正式にはサポートしていませんが、COFFとPDBを理解する開発者が使用するツールは多数あり、プラットフォームの標準に合わせることで、アプリとC++Builderでさまざまなツールを使用する機会が広がることを期待しています。

[*] RAD Studio 12.0向けのC++コンパイラの改修が開始された時点では Clang 15が最新であり、途中で新しいバージョンのClangがリリースされたとして、それに切り替えることはしません。ですが今後RAD Studioがリリースされる度にClangのバージョンを最新状態にアップデートしていく予定です。

コンパイルされたコードの高いパフォーマンス

エンバカデロでは、コンパイルされたコードが正しく振る舞うだけでなく、高いパフォーマンスも目指しています。新しいツールチェーンのテクノロジーは、より最適化されたコードを生成し、これまで不可能だったさらなる最適化を将来的に可能にします。

ランタイムの最適化

C++ツールチェーンには複数のレイヤーがあります。

• Cランタイム（コンソールへの出力やファイル IO などを提供）
• C++ランタイム（例外処理などを提供）
• STL（標準I/O、アルゴリズム、コレクションなどのC++ライブラリ関数を提供）

エンバカデロのC++ツールチェーンでは、上記3つをすべて置き換えます。

Cレベルのランタイムは、WindowsコンポーネントであるユニバーサルCランタイム（UCRT）を使用しています。UCRTは高度に最適化され、プラットフォーム標準であるためWindowsの一部となっています。Windows 8、7、Vistaへインストール可能（XPはサポートしていません）。もちろん、エンバカデロのランタイムでお馴染みの独自のメソッドも追加しています。もしお客様のコードがプラットホーム標準ではなくエンバカデロのランタイムを使用されている場合も特に心配は必要ありません。

C++ランタイムは新しくMinGWとLLVMの混合をベースとしています。MinGWはオープンソースのツールチェーンですが、エンバカデロでは厳選された部分のみを使用しています。LLVMは多くの主要なランタイム分野を提供しています。LLVM に焦点を当てることで、エンバカデロでは、開発者が期待した動作をする標準的なライブラリに再び専念することができます。

最後に、STLはLLVMの libc++ であり、優れたパフォーマンスのライブラリです。

優れた言語標準の互換性

エンバカデロでは、複数のテストスイートを実行し、新しいランタイムトリオでは、以前のツールチェーンよりもはるかに多くのC++およびSTL適合性テストに合格していることを確認いたしました。この結果は標準への準拠、互換性、品質の証です。そしてこれは初期の内部バージョンでも確認されており、合格するテストの数はさらに増え続けています。

例外処理など、あらゆる分野で優れた品質

10.4.2では、中核となるユースケースの改善に注力し、品質の大幅な向上を目指してきました。特に例外処理には常に重点を置いていました。新しいツールチェーンでは、新しいC++RTLを使用して例外処理も全面的に見直し、この動作のためだけに何百もの新しいテストを行っています。例えば、テストケースには同じモジュールや異なるモジュールでのthrowとcatch、rethrow、Delphiからの例外、C++からのDelphi例外など、さまざまな組み合わせがあります。また、同じフレーム内のthrow/catchを除く全てのテストスイートに合格することを目指しています（ただし、Clang自体がサポートしていません）。

堅牢なSTLと優れたリンカ

STLについては前述しましたが、オブジェクトファイル形式の変更に伴い、リンカも従来のilinkからLLVMのlldに置き換えられます。

lldはilinkとは全く異なるアーキテクチャを持っており、複雑で大規模なアプリを簡単に扱えることを期待しています。

新しいツールチェーンについて

新しいツールチェーンに関する情報は、以下の通りです。

• Clang15を使用
• リンカとしてLLVMのlldを使用
• COFF64 オブジェクトファイルを生成 (これは、Delphi が 12.0 でも COFF64 オブジェクト ファイルを生成できることを意味します。「-JL」または「-JPHN[E]」オプションが指定されている場合、コンパイラ オプション「-jf:coff」がターゲット ファイルによって指定されます) )
• PDBフォーマットのデバッグ情報を出力
• Itanium ABIを使用（Microsoft ABIではない）
• LLVMのlibc++ STLを使用
• CランタイムにUCRTを使用
• C++ランタイムにLLVMとMinGWを混在して使用
• RAD Studio 12.0では、Win64のみ対象
• 新しいコンパイラ名は「 bcc64x」

そしてもちろん、C++の拡張機能（プロパティ、クロージャなど）や、VCLやFMXアプリのためのDelphiリンク（これらの機能はまだ完成していませんが、今後のリリースで対応予定）、さらに自動リンクなど、ツールチェーンに依存しているとは気づかなかったかもしれない拡張機能もあります。

これはつまり、お客様が持つ既存のコードが、この新しく、堅牢で、モダンで、堅実で、パフォーマンスが高く、標準化されたエキサイティングな基盤の上で動作し続けるということです。

状況

このアップグレードに対するエンバカデロのアプローチの重要な要素の1 つは、「正しく行う」ことです。つまり、「強固な基盤」、「綿密な作業」、「非常に高い品質」、そしてあらゆる段階で正しい意思決定を行うことです。正しく行うには、より多くの時間が必要となりますので、完全な新しいツールチェーンの提供は 12.0 リリースに間に合いません。

しかし新しいツールチェーンは多くの点で素晴らしく、エンバカデロが目指している方向性を是非ご覧いただきたいと考え、バージョン12.0では、プロジェクトで引き続き使用できる古いツールチェーンと並行して、今回ご紹介いたしました新しいツールチェーンをプレビューリリースとして提供する予定です。

是非、新しいツールチェーンをお試しください。

ただ、「純粋な C++」に焦点を当てているため、 Delphi VCL/FMX をテストする準備がまだ整っていませんが、

• 高品質のSTL
• COFF オブジェクト形式による生成
• PDBデバッグファイルで出力
• パフォーマンス
• 標準との互換性
• 新しいCランタイム
• 新しいC++ランタイム
• 新しいリンカ

など、様々な新しいものが実際に確認できます。12.0 がリリースされましたら、その使用方法について詳しくブログで紹介する予定です。

12.0では、新しいツールチェーンは技術プレビューです。Delphiランタイムとのリンクのような重要な部分についてはまだ作業中です（プロパティのようなDelphi互換機能は動作していますが）。エンバカデロは、このプレビューが非常に基礎的なものであると十分に理解はしておりますが、その上で皆様が実際にご覧いただくことで、エキサイティングな感想をいただけることを願っています。

バージョン12.0のツールチェーン

C++Builder / RAD Studio 12.0のWin64ツールチェーンはどのようになるのでしょうか？

前述の通り、2つあります。

1. 既存のClang 5ベースの古いツールチェーン(bcc64)を提供しており、従来通り、IDE内でご利用いただけます。
2. 新しいClang 15ベースのツールチェーンのプレビュー版(bcc64x)は、コマンドライン上でのみ実行できます。

移行パスがあれば、どのようなアップグレードであってもより簡単になります。そのため、ツールチェーンの準備ができたとしても、移行とアップグレードを支援するために、少なくとも1つのリリースでは、以前のツールチェーンと新しいツールチェーンを並行して提供する可能性があります。 (新しいツールチェーンはあらゆる点で高品質であり、既存の C++Builder との優れた互換性を考慮して作成されているため、簡単に切り替えることができると考えています。しかし、もう一度申し上げますが、エンバカデロでは、アプローチを「正しく行おう」としていますので、それは、あるリリースから次のリリースへとツールチェーンを突然切り替える必要はないということです)

まとめ

新しいClangツールチェーンは、既存のツールチェーンよりはるかに凌駕する多くの領域を持つ素晴らしいツールです。12.0のプレビューリリースでは、エンバカデロが目指している方向性を具体的に示しています。その上で今後 Clangツールチェーンがリリースされる度に使用いただきたいと考えております。

RAD Studio/Delphi/C++Builder 12.0の詳細について、日本時間11月10日午前1時に開催される “What’s Coming“ウェビナーにご参加ください。

※免責事項：このブログ記事で説明しているRAD Studioの将来のバージョンにおける新機能や改善点は、いずれも開発が完了しGA版がリリースされるまでコミットされません。