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:

1. Upgrading Clang – but not just ‘upgrading’ Clang, we’re taking a very different approach that we refer to as ‘doing it right’;
2. 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!

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 differences that for us really are key, and we can re-use open source tools and projects, like the LLVM linker. In other words, we are modifying Clang to add our benefits, not moving forward legacy tech into modern Clang.

The bonuses for you are huge: compatibility with many more tools, making it easier to use (for example) other debuggers or analyse core dumps, new technology improving the effectiveness of our linker, and more. You get the high value language and integration technology – the things that make C++Builder C++Builder – with the overall product much more robust, compatible, and modern.

Runtimes and STL

A C++ toolchain’s runtime has three layers:

1. C runtime – this provides the basic C language-style methods, C-style file IO, etc
2. C++ runtime – this provides the core C++ magic, such as exception handling
3. STL – this uses both the above

Historically we’ve had our own C and C++ runtime. We also provide more than the standard methods for a Windows C runtime, including some POSIX methods. However, these days a C runtime is a standard Windows component built-in to the operating system, so we are investigating using the UCRT – universal C runtime – and adding our custom or extended methods on top of it.

Our C++ runtime will most likely remain the same, though we are investigating some options in some areas.

Work on the Clang upgrade is in progress today, and has been for some time. Some areas are still in flux, and that includes the STL that we’ll use. 

Release Plans

The upgrade is planned initially for Windows 64-bit. This is to target the platform many developers are moving to (64-bit), and to do one Windows platform at a time (tight scope lets us focus on doing one thing well). We plan to move the same technology and approach to Windows 32-bit in a future release.

What about other platforms? Moving to other platforms with an older version of Clang, version 5, was not an ideal situation. But moving using a modern, recent version of Clang is much more ideal, and once we have completed the upgrade for Windows we will have the ability to roll out the new compiler to other platforms.

Continually Up To Date

As well as rolling out to Windows 32-bit and other platforms over the next releases, we also plan to keep Clang up to date. We intend to continually stay up to date and ship a new version of Clang even with every point release.

Clang and LLVM move fast, and after we release this upgrade, we plan to continually integrate changes from the remote repositories into ours. Unlike Delphi, C++Builder does not try to retain ABI compatibility across point releases, ie we require that you rebuild C++ object files and binaries that you link in each point release (note that Delphi-generated C++-style object files and libraries are stable, it’s just anything created by a C++ compiler.) This gives us freedom to move fast, and in this case moving fast means staying up to date.

We plan to ship a new version of Clang every single release.

You will always be using the close-to-leading-edge version of the compiler and toolchain.

Clang Upgrade in Summary

We’re upgrading Clang to version 15. Rather than bringing legacy tech forward, we’re using platform-standard formats like COFF and PDB; that includes MS-style mangling not Itanium, we’re all-in on ‘What’s normal on Windows is what is normal for C++Builder.’ This lets us use tools like the LLVM linker, replacing ilink completely. This may also let you use other tools, like profilers, which are written to understand formats like PDB. We’re also revising our runtimes; and using a new STL which is much more reliable. Approximate language level support will be C++20 and a lot of C++23. We’re releasing for Win64 first, with Win32 and others to follow. Compatibility with our previous RTLs and toolchains is key. And finally, we’re continually upgrading so you will be able to use a toolchain (compiler, STL, and more) that’s close to the leading edge, modern and high quality, with every version and upgrade of C++Builder.

This is a hugely exciting move for C++Builder, a solid foundation and approach. Internally, it’s referred to as ‘doing it right’, and it is: we are doing C++Builder right. We hope you’re as excited by these plans and the approach as we are!

Preview

This work is in-progress, but here are some preview screenshots. We’ve been working on adding the C++Builder language extensions: properties, declspecs, Delphi-style classes and inheritance, closures, and so forth.

We should caution that this work is early: we have an internal stage we call the ‘one-button app’, which is where you can create and run a VCL application with a button, and click it: at this point you have all the key elements working. We have not got to that stage yet: these screenshots are of command-line applications. However, they are apps using our C++Builder extensions, built with COFF and PDB, and linking against the Delphi runtime. As time progresses we’ll share more, eventually getting to a point where we seek beta testing and feedback!

Here’s a property test that’s compiled with the our in-progress Clang upgrade:

Note that it’s generating a PDB file.

Here’s another screenshot, this time of debugging inside the IDE:

Here you can see some key C++Builder-isms being tested: __classid (returning the metaclass), published properties, and Delphi-style classes.

At the bottom in the Events view, you can see the version of LLDB we’re using, version 15. And above that, you can see an internal build of our IDE debugging this C++ code, compiled with a modern Clang, using modern LLDB, in source code using our extensions, with debug info loaded from PDB format.

Integrating Visual Assist

The Clang upgrade on its own would be amazing news for C++Builder, but there’s more.

Several years ago, Idera acquired Visual Assist, a very well-known productivity tool for C++ and C# developers. It provides code completions, refactorings, navigation, and many more features, and is billed as filling in the gaps in Visual Studio: it is very, very fair to say that Visual Assist provides a better C++ experience than using Visual C++. It would be natural, therefore, for us to use it to fill in the gaps in C++Builder too.

Visual Assist is a vast product, but there are some key areas that we would like to bring to C++Builder: assisting code completion, adding refactorings, and providing navigation around your code, such as finding references. There are multiple steps for this: Visual Assist has support for C++Builder’s language extensions for (the build that ships to Visual Studio customers does not have this turned on) and we are now working on integrating key VA features. We’re currently working on integration into the RAD Studio IDE itself.

We plan a rollout that brings the highest value features to you first. The initial release will likely contain just one or two refactorings and navigation – plus, of course, code completion. Over each subsequent release, we’ll integrate more.

Preview

Visual Assist in C++Builder! View full-size animated GIF

In this screen recording, you can see our internal IDE build using our first Visual Assist feature, Find Symbol. This lets you search your codebase, including code like VCL headers outside of your code, and quickly navigate to a symbol’s location. This is a good first feature, because it allows us to test our support for C++ extensions like properties (which are symbols that should show up in this dialog.)

Note how when typing ‘grid row’ it’s searching through the FMX headers too, and out of 172 matches it selects TCustomGrid.Row as the most likely. When searching only in the current project group, it chooses Grid.Rows. Searching through all 226,236 FireMonkey and local project symbols combined to find the first result takes only 0.7 seconds.

Modern Clang, COFF, and Visual Assist?!

Upgrading Clang.

A new, up to date Clang every single release.

An entirely new linker.

A new STL.

COFF and PDB and the interoperability that brings.

New code completion.

Visual Assist C++ navigation and refactoring.

It’s impossible to overstate how excited we are, and how much we’re looking forward to delivering this to you. It’s exciting times to be a C++Builder developer!

Disclaimer: All new features and improvements discussed in this blog post for future versions of RAD Studio are not committed until completed, and GA released.

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---