In RAD Studio 10.2.2, we've made a number of great quality improvements for the C++ toolchain and for the debugger for both C++ and Delphi.
Debugger
- Linux: many fixes when evaluating, especially when passing records or arrays
- Android: Android debugging was broken for Android 8.0 (globally, not just for us.) As of Android 8.1 debugging works again, and we have made tweaks to ensure it works smoothly
- iOS: several bugfixes to do with stability and evaluation
- macOS: Several bug fixes to do with evaluating and watching properties
- C++ Win64: applications can now evaluate properties. This is a long-standing request
...plus many others. In other words, the debugging experience should be more powerful and featureful, and more stable, in 10.2.2.
C++ toolchain
Linker
For Windows, linker improvements are something we've been focusing on since 10.2.0. Both 10.2.0 and 10.2.1 have brought significant improvements: a large address aware linker, retuning for large linksets, exposing options in the IDE for you to be able to change settings if your project has unusual characteristics that cause an error with the defaults.
In 10.2.2, we've fixed or changed:
- Out of memory issues for dwarf_str (debugging info)
- Issues linking when building Delphi code in a or as a C++ project
- Issues when linking with delay loads specified
- LME 200 and 202 errors
- Issues linking when not using runtime packages
- Issues using incremental linking
The most common linker issues reported are to do with out of memory or heap errors, and while the 10.2.x linker is far better than past versions, several of the above areas should make 10.2.2's even better.
As a side note, we find that many linker stability reports can be traced back to an antivirus on your system. LME288 is one common one. Antiviruses can insert themselves into apps in all sorts of ways, usually undocumented and fragile, and change the app's environment and behaviour. For something like the linker, that both uses a lot of memory and assembles a PE image in memory, avoiding antivirus interaction is key. We cannot prevent bugs introduced by third party software.
C++ compilers
We have a large number of quality items that, together, greatly improve C++ compatibility for many common libraries, as well as solving unusual compilation problems that can affect complex projects.
These areas include:
- Significant changes in handling explicitly instantiated templates, and export/import behaviour, when using __declspec(package). This declspec does not explicitly note when a definition is exported vs imported. If you have an instantiated template and multiple modules, you normally want only a single copy. Many compilers have different behaviour here, but our Clang compilers were not optimal, and had different behaviour to classic bcc32. For simple situations such as an EXE and a DLL, you should get the same behaviour as classic bcc. For more complicated situations behaviour may still be non-optimal, and we're interested in test cases for the scenarios you use.
- Many areas to do with exception handling, including different behaviour in optimized or release builds, issues throwing from within __try, and throwing and catching exceptions across module boundaries.
- Several key debugging improvements in the Clang-based compilers. If you had issues where variables were not evaluatable or not displayed, or other issues in general debugging, you should see those resolved.
- More <math.h> functions are fully provided
- Stability issues when handling unexpected (often incorrect) code
- Android: fixed an issue that could cause a crash at app startup
plus more.
In addition, we've made a number of significant fixes to code completion in the IDE: we resolved some unusual bugs that could cause AVs when code completing or cause IDE instability. This means that the IDE should be more stable, and if you were experiencing problems using code completion in the IDE, those should be resolved.
Many of these were complex issues that affected customers, and also affected using common libraries. 10.2.2's C++ toolchain support should be much more robust and we hope you throw lots of complex code at it.
https://community.embarcadero.com/blogs/entry/new-in-10-2-2-c-and-debugger-improvements
https://community.embarcadero.com/blogs/blogger/listings/david-millington