In Tokyo Release 1 (otherwise known as 10.2.1) we’ve made a number of improvements to our C++ support: a small but useful change in the IDE, and some significant improvements in the toolchain itself.
Table of Contents
Toolchain: compiler, linker, etc
Debugging and viewing variables, and general compiler
In 10.2.0, we made a lot of changes to the Clang compilers to improve evaluating variables, commonly local or parameter variables, as well as globals. This had a large effect for Win64, but a smaller effect for Win32.
In 10.2.1, we’ve done a lot of additional work and you should see great improvements evaluating and inspecting variables with the Win32 Clang compiler and debugger.
In addition, we’ve solved a number of other bugs. Each of these were small standalone, but collectively we should have significantly improved quality. One third party spoke to me about their own tests for a large library, which showed great results with 10.2.1’s toolchain compared to 10.2. We plan to continue working on this area in future. It’s important to us that we have as good, or better, language and quality in our toolchain as other compilers, and every release we are working to ensure that gets better. If you have maintenance, not only will you see great improvements in 10.2.1, but you’ll continue to see improvements every release.
Exception handling quality for Clang’s O2 and O3
In 10.2.0, we introduced -O3 level optimisations for the Clang compilers. We also solved a number of quality issues related to exception handling on the Clang compilers, solving all known issues.
In 10.2.1, we’ve addressed a further rare exception handling issue, with multiple nested throws. It’s unlikely you’d encounter this issue – it’s a rare scenario and we ran into it in internal tests – but it means that in O2 and O3 mode we have even better quality.
Exception handling quality in the classic bcc32 compiler
Thanks to a customer who provided an excellent test case, we solved another exception handling issue in the classic compiler, again to do with multiple levels of exceptions.
In general, we recommend moving to the Clang family of compilers, for many reasons – language support, performance, etc – but we do continue to work on the classic compiler. One customer asked me recently if we were planning to keep the classic compiler in the product, and the answer is an absolute yes! Many people use it, and no doubt will continue to use it for many years. We do want you to migrate to newer and better toolchains, but the classic one will certainly remain.
Installing Delphi components like Jedi with standalone C++Builder
Many Delphi components come with an installer that invokes the Delphi command-line compiler. Some installers were unable to invoke it successfully when you had C++Builder only, not RAD Studio, and we’ve resolved those issues. You should now be able to install Jedi JCL and JVCL among others.
Linker
In 10.2, we had a lot of improvements in the linker to solve ‘out of memory’ or heap errors. We have ongoing work every release for this, and so there are more improvements in 10.2.1, especially if you’ve found yourself encountering an error with the dwarf_str heap (an error due to large debug info.)
Our end goal is to never see linker errors. In both 10.2 and 10.2.1, you should have a significantly improved linker compared to prior releases. Try it out.
Standards support
One thing that’s really important to us is standards support, as you can see on our roadmap. This is more than just language standards (eg C++11 or C++17), because it includes RTL and library support as well. Some of this is actually specified as part of the standard, of course, but it can be clearer sometimes to speak about language vs library separately.
In 10.2.1, we added a large number of missing C99 methods in <math.h>. This includes:
acosf(f);
acosh(d);
acoshf(f);
acoshl(ld);
asinf(f);
asinh(d);
asinhf(f);
asinhl(ld);
atanf(f);
atanh(d);
atanhf(f);
atanhl(ld);
coshf(f);
fabsf(f);
frexpf(f, &i);
hypotf(f, f);
log10f(f);
log1p(d);
log1pf(f);
log1pl(ld);
nan(str);
nanf(str);
nanl(str);
round(d);
roundf(f);
roundl(ld);
sinhf(f);
tanhf(f);
for the Win32 and Win64 Clang compilers, with the exception of three methods (hypotf, sinhf, and tanhf) for Win32.
If you’re bringing in third party libraries to C++Builder, and those use math, you may find it much easier in 10.2.1. This issue (using libraries built for other compilers) is an area we’re paying close attention to, and you’ll see ongoing improvements in what we provide as a result.
Bug reports here, listing items we need to ensure we support, are always appreciated. You can email me directly (firstname dot lastname at embarcadero.com) with a link to a QP item as well.
IDE
Finally, C++ code completion gets a small tweak, handling & just like * when terminating completion. In the past, not doing this meant that code completion incorrectly inserted items when you didn’t want it to.
At this point, code completion should stop and not insert what it highlighted if:
- You press Enter – it’s already there
- You press Space
- You press * to change the type to a pointer
- You press &, to change the type to a reference
This last one didn’t occur, and meant that when you were typing a reference you would get unwanted items inserted into code unless you manually closed code completion by pressing Escape, or adding the reference with a space or similar.
This is a great example of a small but high-value change. We have more code completion changes and large improvements planned.
Summary
10.2.1 is largely a Quality release, and this is an overview of some of the quality improvements on the C++ side. Many of them are small items, but those small items matter, and collectively have a big effect. I’m particularly happy with some of the feedback we’ve got about compatibility, and pleased to give you a better product.
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
