Roger Cigol

Thanks Remy - as you rightly say, it's not too difficult to get the console interface working. Slightly harder to write a unit test to prove that unicode chars are handled ok. But I got there in the end. Thanks for pointing me in the right direction.

If you want to compile Delphi you have to get RAD Studio 11.1

or is the TEdit bound to the data source by LiveBindings ? (Right click on the TEdit and select BindVisually....)

Frost.Brutal : Thanks for this instant manual on "how to configure tools" ! I had never really looked into this feature of the IDE and I can immediately see how it can be useful !

Has anyone else compared compile times for Embarcadero clang C++ 17 vs other C++ 17 compilers? The compile times between clang and GNU C++ are supposed to be roughly the same (some say clang is often slightly faster) but if you compile a single C++ 17 unit using Clang 64 (Windows 64 bit, VCL) in Rad studio IDE (Alexandria 11.1) it still seems to take a lot longer than a similar length unit in other systems. It's almost as if it is recompiling the VCL headers every time....

Frost.Brutal : how do you get this to work ? I don't have any tortoise git in my Tools menu (RAD Studio 11.1 patch 1 Enterprise)

I use Tortoise Git outside of the IDE. I work with private repositories on GitLab using SSL communications and found that the IDE support for Git would not support this transfer. I reported this https://quality.embarcadero.com/browse/RSP-26560 So I now work on the cycle. 1) develop code using the IDE 2) Close project in the IDE 3) Commit and push using TortoiseGit (or do other actions - create merge request, check out different branch etc) 4) Reopen the project in the IDE 5) go back to item 1.... I find this works well for me. To some extent I can't see the point of Embarcadero trying to replicate the Git interface (in effect all the convenient things that TortoiseGit allows you to do) within the IDE. Unless they do a lot of work (ie handle all that TortoiseGit does) there are still going to be instances where you need to come out of the IDE to do Git related actions. So you might as well always use the cycle I have described.....

It is entirely possible (and maybe advantageous) to write your main (typically legacy) project using the Classic compiler but to write your unit tests using clang32 and the Google Tests framework. See https://wordpress.com/post/cigolblog.wordpress.com/409

I think doing a benchmark test(s) and then taking an informed decision is always a wise approach. Letting other forum users see your results is always helpful.....

Anyone else find that Classic compiler auto complete doesn't work AFTER installation of patch 1 ? https://quality.embarcadero.com/browse/RSP-37665

C++ programmers are always in demand - that's why there is no one replying to this post !

But I also remind everyone about the valid points raised in this discussion a while back....

something like this https://doodle.com/poll/d9hd42sisyemqbyu

Did it compile ok (all files) and then give this message when trying to link ? Can you state with version of C++ Builder you are using (hopefully Alexandria 11.1). ?

Has anyone got Google Tests (unit testing framework) working with Embarcadero C++ clang compiler? if so, using clang32 or clang64 bit? [or, ideally, both?] I can't find any web documentation that tells me if this is currently possible (Embarcadero 10.4.1) or not. (If there is a helpful URL then I would be grateful if anyone can oblige).

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.cpp is 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()); }

Your first point may be to read the posting on Delphipraxis below. Around July 2021 there is a link to my blog about using google tests with 10.4.2. (and later a link to my blog about using it with 11.1). I did get it to work ok with 10.4.2 - be aware that the packages as downloaded by getit come with some of the projects set to clang32 and some set to clang64 (a mess - might have been fixed by now, but unlikely) so before you try to build all the packages downloaded by getit you need to manually set them all to clang32 or clang64 according to which you want to use. I have a licensed version of RAD Studio but I don't see any reason why you can't get it to work with 10.4.2 community edition. Be aware also that it never did work with 11.0 ! - but all is good with 11.1 It's always wise to search DelphiPraxis before posting as you may find (as in this case) that your question has already been answered. Also it's best to post C++ related questions in the C++ section of DelphiPraxis. Hope this helps....

In your unit test project you also need to include the *.cpp "modules" that you are going to test. As soon as you add these to the unit test project the compiler will know where to find the corresponding header file.

OK - For the sake of other forum users <ie so the DUnit discussion is not here under a google test heading> I suggest you post a new posting in Praxis C++ Builder section with a title "can't get DUnit Tests to run with Classic Compiler" or something similar (better!) and then post details of your problem. I will try to help (but make no promises !)

I should add that the DUnit test framework comes as part of C++ Builder

You can't use googletest with the classic compiler. GoogleTest requires at least C++11 support (I think). It definitely will not compile with the classic compiler. For classic compiler you need to use the DUnit test framework. This is a little limited but it works very well and reliably.

I don't know R at all. But looking at your code it's all fairly clear what's going on (<- is the same as delphi := [took me 30s to work this out]). Your key challenge is to make sure you select the correct types for the variables used. I am a strong advocate of writing readable (and hence supportable) code. I would respectfully suggest that you use longer, more meaningful names for the function and for the variables it uses. This would make it much much easier to see what the function does and how it does it.

There were some reported issues with the web install process. Repeat of installation does sometimes solve it. Installing from the iso avoids this problem - download the iso - extract and install. But there is a possible danger: Embarcadero recommend installing 11.1 using the same method as 11.0 (I believe) so if you used the Web Install for 11.0 it may be wise to use web install for 11.1. I own up to using the iso as my preferred install method - you can download the iso whilst doing something useful elsewhere and then once you start the install you know you are free of any internet connection issues causing a problem.

I have now added my further blog that explains how I am actually using googleTests on a working (or at least on going development) clang 64 VCL C++ Builder project (using RAD Studio 11.1) https://cigolblog.wordpress.com/2022/03/25/tips-for-using-googletests-with-embarcadero-clang64-for-windows-vcl-projects-2/

...and the version of CE does tend to lag behind the latest release, too