What’s Coming for C++Builder: An Amazing Preview
A few weeks ago we released RAD Studio and C++Builder 11.3, a quality release that’s been met with wide praise as the best of any recent version. This builds on several releases of 11.x, including our dedicated C++ quality release, 11.1.5. With that quality background, we want to share our plans for the future of C++Builder and C++ within RAD Studio. We see questions around our plans for C++Builder in multiple areas: support for newer C++ standards like C++20 and C++23; improving the debugger; resolving issues linking large projects; STL quality; productivity like code completion, navigation, and refactoring; and support for other platforms, like Android or Linux. We are addressing these with two major steps: Upgrading Clang – but not just ‘upgrading’ Clang, we’re taking a very different approach that we refer to as ‘doing it right’; Integrating key features of Visual Assist into C++Builder This, both what we’re doing and the approach to what we’re doing, is very exciting. Read on – not just for what we’re doing, or why, but even screenshots showing it in progress! Table of Contents Upgrading to Clang 15 Runtimes and STL Release Plans Continually Up To Date Clang Upgrade in Summary Preview Integrating Visual Assist Preview Modern Clang, COFF, and Visual Assist?! Upgrading to Clang 15 C++Builder’s compilers are based on Clang, extended with our language extensions. The language extensions are for interoperability with Delphi: if you did not know, the two languages can be compiled into the same application, and even have classes in C++ inherit from classes defined in Delphi. C++ can also use and refer to Delphi-implemented code through translated headers, as well as use Delphi-isms like properties. In 2018, we upgraded to Clang version 5, which provided C++17 support. Now, we’re upgrading our current Clang, Clang version 5, to Clang 15 – a massive jump in features and C++ compatibility. But this is not an upgrade like our previous upgrade (from 3.3 to 5 in 2018), in many ways. In the past we’ve always had somewhat of our own way of doing things. For example, we use ELF64 (typically a Unix/Linux object file format) as the object file format on Win64 with DWARF as the debug info format, for various reasons. C++Builder has its core differences, which are our benefits: Delphi compatibility; the language extensions; the things that let us develop forms and frames and use the VCL and FireMonkey – and those differences are valuable. But our current Clang implementation contains some custom elements with no inherent value, and is slowly becoming a maintenance cost without adding to the overall amazing benefits of C++Builder. We are different from platform conventions for legacy reasons. But if we were to follow platform conventions, it would mean less customisation in our toolchain for us to maintain, fewer custom tools, and significantly increased compatibility for you. As a result the Clang upgrade is planned not to be an upgrade of our existing compiler with all extra material, but an upgrade of the core key architecture of our compiler. This means we plan to adopt a more platform-standard approach: to emit COFF object files (the ‘native’ or by-convention Windows format); use the PDB format for debugging; use the LLVM linker not ilink; and not only does this mean we can focus on the […]
