Quality Release
C++Builder 10.4.2 brings some great features we believe will really help you — the biggest being ‘split DWARF’, a way to reduce memory usage in the linker by removing debug information. If you have projects that push the linker’s limits, check it out: it may solve your problems (see this blog post.) However, RAD Studio 10.4.2 overall was also very much a ‘quality release’. In fact, despite 10.4.1 being the release aimed at quality and 10.4.2 at features you need, we fixed more issues in 10.4.2 than in 10.4.1!
And C++Builder is no exception.
C++ Exception Handling
This wonderful pun introduces the exception handling work we’ve done in 10.4.2. If this is too long, here’s the TLDR: 10.4.2 gives your apps very high stability and more correct behaviour when handling exceptions.
We analyse categories of issue reports we get, and also do a lot of work that helps us find issues internally. Some of that work is through supporting C++ libraries: using external code is a good way to ensure our toolchain is compatible. Because of those analyses, in 10.4.2 we revised much of our exception handling for Windows.
The scenarios we looked at are:
- In-module exceptions, when an exception is thrown and caught in the same binary, such as all within one EXE.
- Cross-module exceptions, when an exception crosses a module boundary, such as being thrown in a DLL but caught in an EXE. This is a more difficult situation to handle, and coding guidelines indicate that no exceptions should leak out of a module into another… but, we see code where this occurs and it’s an important scenario to tackle. It is common with packages, or when multiple DLLs and an EXE are bundled together as an app.
- Cross-language exceptions, when an exception crosses stack frames belonging to both Delphi and C++. Exceptions can be raised in one language and caught in another, or cross the boundary multiple times.
- When all modules (eg both an EXE and DLL) are statically linked, or all modules are dynamically linked (dynamic RTL.)
- OS, C++, and SEH exceptions
- Both Win32 and Win64 platforms.
Many of these scenarios, especially cross-module with different linking, can get complex. One of the main reasons is handling the deallocation of an exception or exception metadata in the RTL. For example, suppose a DLL, which is fully statically linked and has its own copy of the RTL, throws an exception. How can an EXE, which is also statically linked with its own copy of the RTL, or is dynamically linked but therefore still has a different copy of the RTL to the DLL, handle freeing memory associated with the exception?
Yet in 10.4.2 we do handle those scenarios, and support applications where all modules are statically linked, or all are dynamically linked. We do not support cross-module exceptions in mixes of dynamic/static RTL within the one application.
This means that in 10.4.2 you should see significantly improved exception handling behavior and a large number of quality issues resolved for in-module exceptions, cross-module exceptions, where modules are all statically or all dynamically linked, for OS, C++ and SEH exceptions, and across both Win32 and Win64 – a massive test matrix.
With every release we aim to steadily improve C++Builder, and 10.4.2 is – one could say – exceptional.