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!
Does 10.3 address the speed problems with the Clang compilers? (RSP-16827)
Yes, and we're working on fixing a whole bunch of things for the next release.
But the whole point was to provide code completion for the new compiler. The classic 32-bit compiler will not do and is not even C++11 compliant.
I had to change in the project settings, C++ Compiler the 'Use classic Borland compiler' to ALL targets manually.So, be sure that this is set for both:
after that it's working again
Hi David, improvements?Code completion is broken in Rio, the same project is working in Seattle, but in Rio code completion isn't working!!!
You are right. It does not. I have now installed on a clean Windows 10 Pro system and code completion in C++ is indeed broken.
Code completion doesn't work in Rio. It shows 'calculating' and only the templates. I've switched both, also the 'use classic Borland compiler in my C++ project', but nothing !
Hi David: Is it just me or is the Win32 Clang code completion seriously flawed? There is no way to invoke code completion for local variables or any "top level" identifiers. They need to be typed in completely. As a result, I cannot efficiently use the editor and have been trying alternatives. You can imagine what that can lead to once people get a taste of CLion, etc. I hope fixing this shortcoming is a priority.
We don't support or test cquery with other tools, but in principle, yes. LSP is an open protocol. We currently only use a subset. For projects, things like the paths and include location are things you'd need to manage (you might want to look up the rsvars.bat and compiler .cfg files for some defaults.)
We don't have C++-only (ie pure C++) Android Servies yet, but you can create them today making use of Delphi and implementing them in C++. There's a quick blog post on it here: community.idera.com/.../how-to-use-android-service-tandroidservice-in-c-builder
Hi Milen - thankyou! I'm glad you like the improvements. They're a great step forward and we have more to come.You are right with both those comments, and we will improve code completion over the next few releases.
Hi Albert, C++ 17 only on the Win32 clang compiler at the moment. One step at a time...... Hopefully it won't be too long before C++ 17 comes to Win64 as well....
Thank you and Embarcadero for the next big step in the development of C ++ Builder.
Only two notes about new Code Completion:
- I think it will be better if Code Completetion started after some prefix entered too;
- Code Completion now is case sensitive; would be better to be non0case sensitivi or to have option to select case sensitivity.
Thank you for C++17 compatibility too.
I'm confused... so C++17 code only compiles with the Win32 compiler and not the 64-bit compiler?