In C++Builder 10.3, we have some great news for C++ developers. We’re very pleased to announce our first C++17 compiler. This is combined with an updated C++17 standard library, and a completely new code completion technology, and - yes, there’s more - a new feature, Error Insight for C++.
Let’s dig into what’s new in C++ for RAD Studio 10.3!
C++Builder 10.3 with a sample C++17 project open
C++Builder has been using a customised, enhanced version of Clang for several years. Originally, we brought Clang 3.1 to Windows, followed by 3.3, the version used for Win32, Win64, iOS32, iOS64, and Android. However, as time went past v3.3 was out of date, especially in that it supported only C++11. We’ve had an internal project to upgrade our compiler to bring our language enhancements to a much newer version of Clang for some time.
In 10.3, we are releasing this new toolchain for Windows 32-bit targets. It is based around Clang 5.0 (we chose a stable version to build from when adding our enhancements). It brings full support for C++17.
This new compiler will allow you to:
C++17 is the current language standard and one many people and libraries are using and taking advantage of. In 10.3, you’ll be able to use these language features and the broader C++ ecosystem compatibility that comes with it.
There are some great features in C++14 and C++17 you can now use. There are some great overviews of C++17, including:
Because we are moving straight from C++11 to C++17, we also now support C++14:
Structured bindings in C++17. This has a method returning a tuple (a number of variables) which are bound to two individual local variables in the calling method. A beautiful code snippet.
The compiler can understand C++14, 11, and 98/03 (as C++17 is with some small exceptions, a superset of features.) If you are already using the Clang-enhanced compiler this should be very smooth or outright unnoticeable, simply that you can now use new features.
If you are using the classic compiler, you can remain doing so - it is still present in C++Builder 10.3. However, we do encourage you to upgrade, and upgrading from classic to Clang should be easier in 10.3. The most common issue we see when updating from the classic compiler are missing RTL functions (commonly seen as linker errors, with a method not found) and in 10.3, we have an overhauled RTL integration with many previously missing methods provided.
There are a few other nice tweaks we’ve made in the toolchain as well. For example, in the past, when you enabled debug info, the compiler would automatically fall back to optimisation level 0. Often you want to do this, in order to see your assembly code as simply as possible or to prevent optimisations that prevent inspecting variables or placing breakpoints, such as code being optimised out. However, debugging the actual release-optimised code is also useful and that is now enabled.
C++Builder 10.3 provides a very recent edition of the Dinkumware STL (v8.03a) which at the time of writing is only a couple of weeks old. Dinkumware provides our version of the standard library, and has been integrated into our own RTL.
This version of the standard library is C++17-capable, so pairs with the C++17 compiler. However, we also use this recent version on the Win64 platform. On that platform, while C++17-specific features requiring new language features aren’t available yet, you can still use many headers from the C++17 standard (you may want to try string_view, for example.)
We also provide updated implementations for many math functions, which means that math on Win64 may be up to two times faster than it was before 10.3.
An updated compiler, new standard library, revised and wider set of RTL methods, faster math performance and more are not all that we are delivering in 10.3! We’ve also focused on code completion.
In the past, code completion for C++ had some issues. It was often slow, or did not provide good predictions. It also calculated results blocking the main thread, meaning you could not type while it was generating results (though you could press Escape.) Especially for large codebases, or codebases with complex header inclusions, this was not ideal.
In RAD Studio 10.3, we have added support for a completely new code completion technology. It provides significantly better quality completion results, and does so faster; and it is asynchronous, meaning that you can keep typing as it calculates results, and is based around clang tooling.
Code completion in C++Builder 10.3. Here, there is a new feature: completing header #include-s.
It uses the Language Server Protocol, an open JSON-RPC-based protocol for running code tooling out of process. The IDE now starts a second process (we use cquery, an open source clang-based LSP server) and communicates with it as you interact with your code and project. When code completion is invoked, that process calculates the results while you continue typing. This allows fast, async, high quality completion.
There are some items to be aware of with the new code completion.
The new code completion will take effect when using the Win32 or Win64 Clang compilers. Before using Code Completion with the Clang enhanced compilers in 10.3, you will need to first save the project after creating it (so it exists on disk, even if its files are modified in the IDE) to be able to complete within the file. Of course, the code completion results always reflect the current state of the file, whether it is saved or not.
This is a common 'gotcha' if you try code completion out: create a new project and save it first before testing it. The server also needs to process files before it can complete; this happens in the background, with the open files prioritised. You may see a few seconds after opening or creating a project for the first time before completion is available in a file. Information is cached, so will be instantaneous from then onwards.
Cquery, the LSP server we use, is a 64-bit process only, so you will need to be developing on a Win64 machine. This is also the case if you are targeting Win32. The vast majority of our customers develop on 64-bit editions of Windows.
Note: Currently, code completion support requires that your project’s file path does not include a space. Code completion also needs to be invoked without a preexisting prefix (eg if you want all the get* methods, invoke on the dot (.) or arrow (->)) and type "get". We plan to make code completion more flexible in the future, and intend to include support for parameter completion within a method along with the two items listed beforehand.
The key I would like to emphasise here is our new technical underpinnings, and that we are closely looking at great improvements both now and in future releases. Code completion for all languages has been something we've had good feedback to focus on, and in 10.3 you are seeing the first cut of a set of great improvements. This is an area we will be working on in future releases.
One really nice thing to note is that not only is does replacement for the old code completion solve a number of problems around speed and accuracy, but it also adds new features. You can, for example, now complete heading inclusion. Try typing #include < and invoking completion: you will get a list of headers. Select one to use it.
This is an entirely new direction for the RAD Studio IDE, and a very exciting one. Code tooling (including code completion) is an area of significant interest for us, in both C++ and Delphi.
Error Insight is a feature that shows code errors before you compile, drawing a red squiggly underline under problematic code. The Delphi side of RAD Studio has had this feature for many years, but C++ never has. In 10.3, we have added it for C++.
In 10.3, for Win32 and Win64 using the Clang compiler (ie the same time you can use the new code completion), you will also be able to see code errors underlined. This also uses the LSP server, and so occurs in the background and asynchronously. It functions in the same set of situations where the new code completion is enabled. You can mouse over one of the red underlines to see a hint with more information.
RAD Studio 10.3 is a large release in many areas. C++ sees a very large amount of upgrades and improvements, some of which have important and exciting implications for the direction we’re looking for Delphi and the IDE as a whole. In 10.3, we have:
This allows you to use a newer and faster compiler; to build code that optimizes to run faster giving your users faster apps, and is better to debug; to pull in more third-party code and libraries and make use of the wider C++ ecosystem. Then, as a developer, you can code faster and have better productivity with the new code completion, which is faster, more accurate and asynchronous so you can invoke it and keep working; and see errors inline before you compile through Error Insight, allowing you to fix code without a compile-fix cycle.
These are some huge improvements to our C++ tooling and we are very excited to provide them to you -- coming soon, in RAD Studio 10.3 Rio!
I'm confused... so C++17 code only compiles with the Win32 compiler and not the 64-bit compiler?
It will be possible in this new version to create Android Services in C++Builder that for now can only be created from Delphi? Or use the iOS Simulator?
Having C++17 support and clang based code completion and other tools will be great!
I would have one question, would the cquery and other clang tooling be available to be used from other editors and scripts? I mean it would be great if C++Builder would generate the needed configuration (includes, point to correct compilers etc.) and then it could be also used from scripts and other tools.