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
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:
- C runtime – this provides the basic C language-style methods, C-style file IO, etc
- C++ runtime – this provides the core C++ magic, such as exception handling
- 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.
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!
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.
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?!
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.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
That’s the news I was waiting for….
Fantastic, this looks like a major step in the right direction. Is refactoring is part of it? Also, it would be useful to me to have a Linux IDE creating windows programs. Is that possible? (hint ask crossover linux to help).
So cool. That was expected since 2018!
This is a major step forward, and one we’ve all been waiting for, for a long time.
I can’t wait to get my hands on a beta.
This direction and upgrade look wonderful. I can’t wait to get it. The compatibility to the Window’s way is a great thing and makes it much easier to work with profiler and coverage tools and other static libraries. The clang compiler has various sanitizers (address, memory, thread. I hope that we could get some of that goodness in the future. All in all you got me really excited for the future of C++ Builder.
Thanks for your kind comments Eran. We’re very excited too – we think the plans bring a lot of wonderful extra things to the product and will make plenty of people happy as well as us!
I’m curious. That all sounds very, very good. One can expect some of the mentioned innovations in the next release? Is there a new roadmap?
This is the best news ever.
For years we have waiting for this.
Many thanks, the future for C++ is bright.
Will we be able to target LLVM Instruction set with C++ and Delphi Code? This would allow using the entire LLVM backend to target basically anything.
Okay, but please further maintain the classic compilers, as they are orders of magnitude smaller and faster.
Windows ARM64 platform support with VCL should also be added in the future.
Thanks Guido. I’ll make sure the PMs get to read your comments.
I think prividing the new target plateforme is more important! Without new LLVM 15, we can still doing everything, excepting using the new syntaxe. But without the compiler for Android64/macOS/Linux64, how can we solve this problem ourself???
This is GREAT NEWS! We have been a Delphi shop for 20 years. Though, a year ago we decided to start our nextgen in C++Builder (with frontends in C#) as its very difficult to find Delphi developers in our area.
These changes make me have hope – as we’ve had to write quite a bit of stuff from scratch as “off the shelf” CBuilder doesn’t play nice with many off the shelf C++ libraries. Sounds like C++ framework compatibility will increase as well – which is very nice!! Like a previous poster stated, concentrate on smaller, faster code as well (just because hard drives/ram are bigger/cheaper doesn’t mean builds need to be bigger/slower). And fix cquery from crashing all the time! Also, how about a nice convenient/fast methods for String std::string etc. And while I’m at it.. how about more community support instead of a single section on PRAXIS.
I just renewed (happily) our subscription for over a dozen RAD Studio licenses.. I’d be VERY happy to move all my C# people to CBuilder as well (about 18!).
This all sounds very good, this is what we have all needed for a long time. I only hope for a quick implementation. What is the plan here? Q4/2023 or Q1/2024?
Android x64 for C++ ?
MacOS for C++?
Without android 64bits support Cbiolder will be relegated to durst.
Today people have options like maui, uno, avalonia to develop for a wide range of plataforms like, windows, linux, macos, ios and android. Why they will use cbuilder if cbuilder doenst support multiplatafor development?
We need full multiplatform support in C++ Builder. Android 64, macOS64: identical as for Delphi. ASAP. Otherwise the mumbo-jumbo with CLANG versions will be pointless.
Sounds great… as long as it works and isn’t too slow… and by works I mean I can build my app and it will compile, link, and run without any new issues/bugs. 🙂
Hi David, I think you guys have done a good job on the latest version of C++Builder, finally stable enough to move our applications forward, so now you have an excellent opportunity to provide a better experience for your customers by securing the most important features and necessary for us, such as the cross-platform target, in addition to the interesting things that you mention. The information is appreciated.
Does the switch to Clang 15 and newer also mean that C++23 is coming as soon as Clang has it? If so, then having new features like float128_t (e.g. P1467R9) is a huge win!!! Will importing DLLs and/or EXEs like mso.dll, vislib.dll, excel.exe, etc. produce language compliant header files?