この記事は、Maksim Menshikov氏のブログの抄訳です

RAD Studio が C++23 をサポートしたという事実は、リリースノート上ではたった一行で触れられているだけかもしれません。しかし、その背後には、RAD Studio の近代史においても屈指の規模と複雑さを伴うエンジニアリング作業が存在しています。

C++23 は、単なる言語仕様のアップデートではありません。RAD Studio のように、最先端の C++ 言語機能と、数十年にわたって積み上げられてきたレガシーとの互換性を同時に維持する必要がある開発環境にとって、それは部分的な改修では到底対応できない、大きなパラダイムシフトでした。

この課題に対応するために誕生したのが、RAD Studio における新しいモダン C++ コンパイラ BCC64x です。BCC64x は LLVM/Clang 20 をベースとしつつ、長年にわたって培われてきた Borland／Embarcadero 独自の拡張を取り込んだ、新世代の C++ コンパイラです。

C++23 対応においてコンパイラは重要な要素のひとつですが、それがすべてではありません。本記事では、RAD Studio が C++23 を実現するまでに直面した技術的背景と、その取り組みの全体像を紹介します。

新しい C++Builder コンパイラの利点

LLVM/Clang 20 と同等の最新コンパイラ基盤

BCC64x は、業界をリードする LLVM ベースの Clang 20 と機能面で完全に肩を並べるコンパイラです。LLVM/Clang プロジェクトは、もともと GCC の代替として始まりましたが、現在ではコンパイラ技術の中核とも言える存在へと成長しました。

今日では、数多くの開発ツールやフレームワークが LLVM を基盤としており、今後もその流れは加速していくと考えられます。BCC64x は、そうしたモダンなエコシステムと足並みを揃えるための基盤となっています。

サードパーティライブラリとの高い互換性

BCC64x では、サードパーティ製ライブラリとの互換性が大きく向上しています。多くの場合、既存のコードを修正することなく、そのままコンパイルが可能です。

技術的には、MinGW/Clang に含まれる一部の POSIX ヘッダを使用している場合など、例外的に調整が必要となるケースも存在しますが、そうした問題は可能な限り最小限に抑えられています。

bcc64c と比較して約 2 倍のビルド速度

BCC64x は、従来の Clang ベースの Embarcadero コンパイラである bcc64c と比べて、おおよそ 2 倍のビルド速度を実現しています。

これは単に新しいバージョンの Clang を導入しただけでなく、並列ビルド機能の改善によるものでもあります。パフォーマンスはマルチコア構成、特に 16 コア以上のマルチコア環境では、その効果がより顕著に現れます。最新の x86 (64-bit) プロセッサにおいて、パフォーマンスと機能完全性との完璧なバランスが達成されています。

以下は 16コアのx86 (64-bit) プロセッサでxerces ライブラリのビルド性能のテスト結果です。

処理別のテスト	bcc32 (Classic)	bcc32c (Clang 5)	bcc64 (Clang 5)	bcc64x (Clang 20)
並列処理	00:11.86	00:16.08	00:16.99	00:13.14
逐次処理	00:11.92	02:15.62	02:47.62	01:35.90

BCC64x のさらなる利点

先進的な最適化機能

BCC64x は、ループアンローリングや頻繁に呼び出される関数のインライン展開など、最新の最適化技術を積極的に活用します。その結果、より効率的な算術コードが生成され、アセンブリレベルでも改善が確認できます。

新しい C ランタイムへの対応

C++ アプリケーション開発者は、長年にわたり C ランタイム（CRT）に関する問題に悩まされてきました。Microsoft はこれを改善するため、Windows アプリケーションの移植性や CRT のバージョン管理を向上させる「新しい統合 C ランタイム」を提供しています。

BCC32 は新しい Windows でも低レベル API へ直接コールしますが、BCC64x はこの新しい CRT を活用することで、従来よりも安定性と将来性の高い Windows アプリケーション開発を可能にします。

セキュリティの向上

Clang には、多数の組み込み診断チェックが備わっています。これにより、潜在的な不具合や脆弱性を早期に検出でき、結果としてアプリケーション全体のセキュリティ向上につながります。

分かりやすくなったエラーメッセージ

BCC64x では、エラーメッセージの可読性も大きく改善されています。エラーが発生した箇所の文脈がより詳細に表示され、マクロ展開の結果なども追跡できるため、問題の原因を把握しやすくなっています。

将来のプラットフォーム拡張に向けた基盤

LLVM は、主要なプラットフォームを幅広くサポートするフレームワークです。BCC64x を採用したことで、RAD Studio は将来的にさらに多くのターゲットプラットフォームへ対応するための土台を手に入れました。

技術的な課題

Delphi と C++ の共存

RAD Studio のエコシステムが C++ 開発者にとって独特の価値を持つ理由のひとつは、
C++ と Delphi が同一の IDE、同一のランタイム上で共存できる点にあります。

実際、RAD Studio に含まれる多くの R&D ツールや内部コンポーネントは Delphi で実装されています。
これは、UI フレームワークである VCL に限った話ではなく、IDE やデバッガ、設計時ツールの多くにも当てはまります。
そのため、Embarcadero の C++ コンパイラは、単に「C++ をコンパイルできる」だけでは不十分で、Delphi のランタイムと正確に連携できることが必須条件となります。

Delphi のランタイムは、一般的な C++ 環境とは異なる 独自の ABI（Application Binary Interface） を使用しています。
Win32 環境では複数のコーリング規約が存在し、Win64 環境では単一のコーリング規約に統一されていますが、Delphi の ABI 自体は Win64 において Itanium ABI に準拠しています。

一見すると、これは細かな実装上の違いに過ぎないように思えるかもしれません。
しかし実際には、C++ と Delphi の間でオブジェクトを安全に受け渡し、例外を正しく伝播させ、ランタイム機能を共有するためには、これらの ABI の違いを完全に吸収する必要があります。

このような事情から、Embarcadero の C++ コンパイラは、一般的な Clang ベースのコンパイラとは異なり、Delphi 固有のキーワードや言語拡張（__closure、__published、__classid など）を引き続きサポートしなければなりません。

重要なのは、新しい C++ 機能の導入が、単に「最新の言語仕様に追従するため」だけではないという点です。C++23 の新機能のいくつかは、Delphi の機能を C++ 側からより自然に扱えるようにし、両言語間の相互運用性を改善する可能性を持っています。

この意味で、C++23 対応は Delphi と C++ の距離を広げるものではなく、
むしろ 両者の共存関係を将来にわたって維持・強化するための重要な一歩だと言えます。

デバッガとデバッグ情報

コンパイラの次に、IDE において最も頻繁に使用される機能はデバッガです。
そして RAD Studio のデバッガは、単に C++ コードをデバッグできればよいというものではありません。

RAD Studio のデバッガは、

• Delphi ランタイムを理解し
• Delphi のソースコードに正しくマッピングでき
• C++ と Delphi の両方を同時にデバッグできる

必要があります。

この要件は、コンパイラの刷新に伴い、デバッグ情報の扱いにも大きな影響を与えました。

従来の C++Builder では、オブジェクトファイル形式として OMF（Object Module Format） が使用されていました。
OMF は 16bit / 32bit 時代に設計された形式であり、当時としては十分なものでしたが、
現代の 64bit 環境や大規模なデバッグ情報を扱うには、多くの制約があります。

一方、モダンなツールチェインでは COFF（Common Object File Format） が標準となっています。

COFF は 64-bit アーキテクチャ、CodeView デバッグ情報形式、および LLVM や MSVC など現代的なツールチェーンとの完全な互換性をサポートするため、OMF よりも優れています。COFF はセクションベースの拡張可能な設計を採用しており、大量のデバッグ情報や複雑な再配置情報を効率的に扱うことができます。
この点で、OMF と比較すると、COFF は明らかに現代的で柔軟な形式です。

ただし問題は、RAD Studio が長年にわたってOMF と tds/GIANT 形式のデバッグ情報に依存してきたという点です。これらの形式は CodeView と互換性がなく、そのままでは新しいデバッガ基盤に統合することができません。

そのため Embarcadero は、従来のデバッグ情報形式を維持しつつ、COFF および CodeView ベースの新しいデバッグ情報も同時に扱えるようにするという、非常に手間のかかる対応を行いました。

この移行作業は決して単純なものではありませんでしたが、その結果として、RAD Studio は旧世代の C++Builder プロジェクトと、新しい bcc64x ベースのプロジェクトの双方を扱える柔軟なデバッグ環境を提供できるようになっています。

COFF を理解する新しいリンカ

bcc64x では、従来の ilink32 に代わり、LLVM のリンカである ld.lld が使用されます。このリンカは COFF オブジェクトファイルや拡張された再配置情報、モダンなデバッグ形式を正しく処理できます。

C++Builderは、従来の ilink32 と新しい LLVM リンカを適切に切り替えることで、既存プロジェクトとの互換性も維持しています。

結論と今後の展望

BCC64x は、C++ と Delphi の将来的な相互運用性を支えるための、堅牢な基盤を確立しました。C++23 の新機能、改善された診断機能、そして長期的な互換性を享受するためには、この新しいツールチェインへの移行が強く推奨されます。

今後のC++Builderでは、今回の基盤整備があってこそ実現できる、さらなる機能強化が計画されています。どうぞご期待ください。