Patch 1 for RAD Studio 11.2 Now Available

A couple of days ago Embarcadero announced the release of a patch (called “patch 1” for RAD Studio 11.2

Users of RAD Studio 11.2 will probably have noticed the “patch available” note (actually fairly small text) on the Welcome page of the original installed version. This is “patch 1” which is a download for all subscription users. It fixes a small number of key issues with the original release. It is recommended for all 11.2 users. More information about the installation procedure and the issues fixed is at:


RAD Studio 11.2 Now Available

On 7th Sept 2022 Embarcadero announced the release of RAD Studio 11.2

This is a combined “quality update” and “new features update” and includes some small but helpful IDE / editor improvements and an iOS simulator for Delphi development.

More details are at

Special C++ Quality Release for RAD Studio 11.1.

On the 15th July 2022 Embarcadero released a new upgrade for RAD Studio C++ users currently on 11.1 Alexandria. This new upgrade (called 11.1.5) is a C++ quality release and fixes the inoperative code completion functions. Editing C++ files is now back to how it used to be before the recent difficulties. This is great news.

There is a more detailed blog post about this release at

The new upgrade can be downloaded from

A Simple Batch File to Run a Subset of Google Tests.  

In my blog post of 25th March 2022 (Tips For Using GoogleTests with Embarcadero Clang64 for Windows VCL Projects) I gave a simple batch file that is very useful for running all the google tests.

Here’s a closely related batch file – but this adds a filter to only run the tests from a single test suite, rather than running all the tests. This is a real time saver if you are using a test driven development approach and are testing individual tests. Note the * on the end of the test suite name (this selects all the tests in the test suite).

REM The first line is the full path to the unit test console exe generated by your project
"........Unit tests\Win64\Debug\YourUnitTestProject.exe" --gtest_filter=YourTestSuiteNameHere*

Using Google Tests with Classic Compiler Projects.

If you have legacy projects that still use the old Borland C++ “Classic” compiler there may be good reasons to adopt the approach of using the clang32 compiler for running your unit tests using the Google Tests framework, whilst still having the main target project compiled using the “Classic” compiler.

In most cases code written for the “Classic” compiler compiles without problems with the clang32 compiler. This is particularly true for lower level code (which tends to be where most unit testing is concentrated). Using this approach means that unit tests you develop are more likely to be useable in the future (as projects migrate to using clang32 (or clang64 compilers). It also has the advantage that the clang32 compiler gives more warnings about sloppy / non-standard code syntax. Fixing these warnings normally does not affect the ability of the final target code to compile under the “Classic” compiler and invariably improves your code.

Patch 1 for RAD Studio 11.1.  

Last week Embarcadero released a patch for RAD Studio, Delphi, and C++Builder 11.1 Alexandria. The patch addresses a few relevant issues in the most recent release and is available to active update subscription customers in the GetIt Package Manager or on the download site.

You can read more about the small but important issues this fixes at

Comparing Strings in GoogleTests Projects

GoogleTests has lots of ASSERT_xxxx type functions to cover most common (and indeed uncommon) C++ types. But it doesn’t know about the Embarcadero String type.

To make it easy and consistent to do Embarcadero String types I have made a simple C++ unit which I have called ASSERT_STRING_EQ. I simply include ASSERT_STRING_EQ.h at the top of googletest files that require comparisons of String types and make sure ASSERT_STRING_EQ.cpp is added to the project file.

The contents of ASSERT_STRING_EQ are as follows:

void ASSERT_STRING_EQ(String A, String B)
   ASSERT_STREQ(A.c_str(), B.c_str());

void ASSERT_STRING_NE(String A, String B)
   ASSERT_STRNE(A.c_str(), B.c_str());

Tips For Using GoogleTests with Embarcadero Clang64 for Windows VCL Projects.  

In my previous posting (17th March 2021) I covered how to install GoogleTests framework ready for use with Embarcadero C++ version 11.1. Now I am going to offer some advice on how to write simple tests for your own VCL projects using the GoogleTests framework framework. I will assume Clang64 but it all applies equally to Clang32 projects.

Having installed GoogleTests your installed files will be in directory

C:\Users\[your account name here]\Documents\Embarcadero\Studio\22.0\CatalogRepository\GoogleTest-2021.09

We will call this long path ”…GT2021.09” for the rest of this blog.

If you try to use the GoogleTests files where they were installed you end up with very long include paths and you also lose your project independence. It seems much more convenient to create a copy of the key files in a directory local to your project. I suggest:

1. Create a directory in your project called “GoogleTest”.

2. Inside “GoogleTest create a directory “LibWin64”

3. Inside “LibWin64” copy the four files gmock.a, gmock_main.a, gtest.a and gtest_main.a (only gtest.a is actually required to run simple tests) from the lib folder …GT2021.09\cbuilder\lib\Win64\Debug.

4. Inside “GoogleTest create a directory “Include”

5. Inside “Include” copy the directory “gtest” from …GT2021.09\googletest\include\gtest, making sure you include the “Internal” folder and all it’s contents (including further sub-directories).

6. In your project group create a new windows64 bit VCL console application. Set this to use the debug settings (this allows you to debug code that doesn’t pass a unit test).As well as the files you want to test and the files containing the testing code you need to add to the project the library file …GT2021.09\cbuilder\lib\Win64\Debug\gtest.a.

7. In your project options add the include path ….GoogleTest\Include\gtest.

Having configured your project in this way you then need to add the line “#include “gtest.h” at the beginning of each of your *.cpp files that you generate to test your project (convention suggests one test file for each *.cpp unit in your main project). In addition, in your main VCL console cpp file, you need to change the “main()” program entry point so that it becomes:

int _tmain(int argc, _TCHAR* argv[]){
  printf("Running main() from %s\n", __FILE__);
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();

One key point to be aware of is that you must build your test project (you still choose which ever setting you want for projects you ship) using dynamic run time linking of RTL and packages set to true.  If you do not do this your code will compile but will generate lots of unwelcome linker errors. In the project options set both of these to true:

project | options | C++ Linker | Link with dynamic RTL.


project | options | packages | run time packages | Link with run time packages

If you now build and run this console application it will run your google test code and output pass/fail information to the console but the console closes after the last test has run.

It is much more convenient to use a simple batch file to run the tests. This batch file can then be conveniently edited to pass GoogleTest command line options (eg to run the tests more than once or to run only selected tests etc (see GoogleTest documentation)).

An example of a the contents of a suitable batch file is as follows:

REM The first line is the full path to the unit test console exe generated by your project
"........Unit tests\Win64\Debug\YourUnitTestProject.exe"

TwineCompile for C++ Builder 11.1  

Only a couple of days after the release of C++ Builder (and RAD Studio) version 11.1 the compatible version of TwineCompile has appeared in GetIt.

Building C++ clang32 or clang64 projects of any size without TwineCompile is tedious (or worse!). So it’s always good that TwineCompile becomes available very soon after the new version is released.

Well done to the team at Jomitech for their work on this vital RAD Studio plugin.