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.

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.


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:















frexpf(f, &i);

hypotf(f, 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 with a link to a QP item as well.


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.


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.


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

Start Free Trial   Free Delphi Community Edition   Free C++Builder Community Edition   Upgrade Today  

  • Thank you for your prompt reply David. Best regards, Milen
  • Sure - on a command line, type "bcc64 --version" (or any of the Clang-based compilers.) You will get output like, > bcc64 --version Embarcadero C++ 7.30 for Win64 Copyright (c) 2012-2017 Embarcadero Technologies, Inc. Embarcadero Technologies Inc. bcc64 version 3.3.1 (36116.3475b03.2ebda99) (based on LLVM 3.3.1) Target: x86_64-pc-win32-elf Thread model: posix The second line there mentions the Clang/LLVM version (3.3.1.)
  • Hi David, Appreciations for your great work in Embarcadero for C++ Builder to continue to be state of the art instrument. Could you tell me please how to check the Clang version used in C++ Builder 10.2.1 Installation? Thank you
  • Thank you for your answer, David. I saw indeed in a comment from another developer that previous linker can be used but for once I did uninstall the previous version neatly. I rolled back and stayed with 10.2 so far. I will come again to 10.2.1 with the fix you have. As for the export of the destructor of template instantiations, I never reported the problem because I had two other blocking issues that prevented me from going further with Clang. It was with Berlin 10.1. Johnny Willemsen answered my comment in RSP-18762 telling that it (dtor export) is fixed with Tokyo. I took time to search and finally found the origin of the two other bugs and also a workaround, in both cases. These are issues RSP-18959 and RSP-18968. I can compile all my projects now with Clang and, indeed, the destructor mentioned above is properly exported with Tokyo 10.2. I'll email you soon. Philippe
  • Hi Philippe, We're tracking that bug and can actually give you a possible fix now, if you want to email me? firstname dot lastname at Otherwise, the linker alone from 10.2 will work, you don't need to roll back the entire installation. Exporting destructors of template instantiations: we're working on a number of issues related to import and export. Is there a specific QP for this, please?
  • I did try out the linker, as you suggest, David. No, in fact, it just run as part of the build process. It is unfortunately broken. It does not support anymore the delay-load mechanism (linker crash). Please see RSP-18765 and you will understand how bad it is. No way to workaround found so far but roll back to 10.2. This feature is mandatory in my projects. Besides that, the Clang compiler is far from being perfect. I cannot get all my modules compiled with it (compiler crash) and it does not export the destructors of template instantiations. These are also mandatory features, of course. All this has been running for years, compiled with the 'old' BCB2009 compiler and linker. To me, this release is just a big disappointment, like the others before in fact. For ten minor improvements that you (I mean Embarcadero, not you personally) mention, I may have interest in one of them BUT there is also one more broken feature, THE feature that I cannot miss nor work around! With 10.2.1, it is one of the master pieces of the framework that is broken! Your end goal is to never see linker errors (anymore). So is my deepest wish too! The question is when will it be reality? Philippe
  • David Despite all these wonderful improvements, you have still notaddressed the fact that you have broken the useof Boost with the 10.2 Tokyo release. Because you have linked the pre-built Boost libraries to the memory manager for Berlin, lots of nasty things happend if you dynamically link to Boost. It is NOT an option to switch to static linking of you use the Boost Threads library (which we do) because CLANG does not support auto-tss cleanup. So we cannot use Tokyo as shipped. Please would you get someone within Embarcadero to rebuild and reissue to Boost libraries, linked against the correct memory manager. See RSP-18123 in your database. Major bug report in May 2017 still unresolved despite being clearly described. Andrew
  • David, we can currently not recommend moving to the Clang family of compilers because the debugger (10.2 Tokyo Release 1) is still not ready to use. Period. Of course there are improvements from release to release. But we do not need improvements, we need a product with a debugger which is simply doing what it has to to. With the current release it is still not possible to inspect all variables. This is simply a missing basic feature. With each new release we can observe improvements (which are in fact just steps to a usable product) but with each improvement there are also side-effects. From Berlin to Tokyo the problem with wrongly displayed values was solved but the problem with missing breakpoints was introduced. From Tokyo RTM to Release 1 there seems to be an improvement regarding the missing variables. But at the same time other variables visible in 10.2 are no longer visible in 10.2.1 (we have an example where the variables are visible until the debugger reaches a specific code line - the project is too large to share).
  • And don't forget CodeGuard, which works now on 10.2.1 with Windows 8 and Windows 10
  • Not much here for the Marketing team, but we appreciate it. Makes our day easier. It may be time for a State Of The Nation address on C++ DataSnap and Android Services and other areas where we have fell behind. Encourage us a little.