Roger Cigol

A respectful suggestion: It would be more useful to other users of this forum if you posted this new question as a separate question with an appropriate title....

The use of COFF format is coming - how soon is unspecified but David Millington has announced this in his post here: David's What's coming in C++ Builder

If you are displaying message boxes in your code, you are presumably displaying text inside them. So if you are worried about the language of the buttons you presumably have a strategy for handling different languages for the text that you are displaying in the box. Surely you can use the same strategy to translate the button captions? I frequently use my own dialog boxes and ShowModal() rather than the OS message boxes. One advantage I find is that when users ask for support over the phone it is much easier to determine if the message box is generated by my code (because I give it a red or blue background (for error or warning)) or if the message box is generated by the OS (in which case it is in the standard OS colours). I haven't found any problems with this approach.

But you said originally that in your case argc was equal to zero (ie it is NOT > 0).

I've gone back to an old Skype Text conversation I had about this issue. The PA Server for remote debugging did not work for 11.1 but did work for 11.2.

AI is a big problem. Anyone who tries to limit it's use to intelligent purposes gets my support. I've signed.

.... and I'd knock this out very quickly using Embarcadero C++ and VCL. You could use radio buttons as you say (the correct native choice) and you would use the same form and just populate the text next to each radio button with the multiple choice answer. A Delphi fan would be equally at home doing the same with Delphi and VCL. Or use Firemonkey if you want to target mobile devices. Actually there is very little code required here - it's mostly visual layout stuff. So the choice of language is not a major decision. Pick the one you are most familiar with (if you want to get it done quickly) or pick the one you want to learn if getting new skills is what you are after....

Which version are you using? there's a known issue with Linux remote (ie PA Server) debugging with some versions around 10.x (I can't recall exactly when this was fixed but it's ok with 11.2 / 11.3

Twenty five or so years ago I took on maintenance / on going development of a large C++ project based on MS Visual C++ and MFC (version 6). I got the customer's main issues sorted out over a couple of years and in doing so got to know the ins and outs of Visual C++ /MFC 6.0. The customer got confidence in me then and I suggested migrating to Borland C++ Builder / VCL version 6.0 . This took another year to get done. I am still supporting and developing this product for the same customer and it's now on Embarcadero C++ 11 and we are about to change to a 64bit based version of the software..... This is (one of the reasons) why I am really excited and pleased about David Millington's recent blog about the Embarcadero future direction for clang C++....

Same advice as the string integer posting. Use String rather than AnsiString(). You only need to use AnsiString variables if you specifically want to represent text using only 8 bit Ansi encoding. These days that is a rare occurrence.

Also for simple conversions from String types to integer types you may like to use the ToIntDef() String member function. Pass this a default value which is the value returned if the String variable does not contain a valid integer. (The ToInt() function throws an exception if the String cannot be converted to an integer).

"It worked" does not mean that the code is sensible or ideal. You don't need / want to convert the int value called sum to an AnsiiString. you actually want to convert it to a C++ Builder String type (whichi is actually a UnicodeString). So you would be better to have used Label3->Caption = String("The sum is ") + String(sum);

This is also a useful link: https://stackoverflow.com/questions/73879934/cbuilder11-how-to-unit-test-with-googletest

I have blogged a bit about google test / C++ Builder - which may help. Start here: https://cigolblog.wordpress.com/2022/03/17/using-googletests-with-embarcadero-clang64-for-windows-vcl-projects-c-builder-11-1/

template<class A>class TThreadDataInterface_TS { private: std::mutex DataMutex; A ThreadSafeCopyOfData; A &operator=(A RHS); // declared private - not defined - prevents use of = operator public: void Read_TS(A &Data) // read (copy) Data out, thread safe, no handshake of data { try { const std::lock_guard<std::mutex> Lock(DataMutex); Data = ThreadSafeCopyOfData; } catch (...) { A UninitialisedData; Data = UninitialisedData; } } void Write_TS(const A &Data) // write (copy) Data in, thread safe, no handshake of data { try { const std::lock_guard<std::mutex> Lock(DataMutex); ThreadSafeCopyOfData = Data; } catch (...) { } } TThreadDataInterface_TS(void){} TThreadDataInterface_TS(const A &InitialValue){ ThreadSafeCopyOfData = InitialValue;} } I have ported the above template class from a GNU / Linux working code base to an Emabarcadero Clang 64 bit Windows console program. It's a template class for use communicating data (type A) between two threads. The GNU/Linux code did not have any try / catch statements in and worked fine. When I ran this code using Embarcadero Clang64 I found that most of the time the locking worked fine but sometimes the line "const std::lock_guard<std::mutex> Lock(DataMutex);" caused an exception to be thrown (and since this was not caught anywhere the program abnormally terminated). I added the try /catch that you see above and now the program runs without aborting - but as you can see from the code on the rare times that an exception is caught the data transfer doesn't work smoothly. The bottom of this page: CPP ref lock_guard constructor seems to state that "if m is not currently locked by the calling thread, the constructor never throws exceptions (no-throw guarantee)." I am sure that my thread has not previously locked the mutex so I am puzzled as to why I am sometimes (1 in a 100?) getting this exception. Has anyone got any thoughts on this ?

For anyone interested I have solved my problem. I have an abstract base class (called TThreadStateMachine) that I use to derive classes for code units that run in their own threads and are state machine based control. The base class has a virtual function that forms the basic periodic tick of the derived class state machine. The TThreadDataInterface_TS template class is used to provide thread safe communications to / from the state machine. The problem comes when the derived classes, based on TThreadStateMachine are destroyed. The C++ standard ensures that the derived class destructor is called BEFORE the base class destructor. But because the base class was still running it's own thread it was (sometimes) causing the derived class state machine to "Tick" even when parts of it have been destroyed. My solution to this was to create a new base class function AbortThread() and make sure I call this in the derived class destructor before doing any further destruction. Now it passes many many iterations of a unit test creating and destroying without an error. I believe all is good now. One mystery may never be solved.:Why dic my poor original implementation never seem to cause a problem on Linux / GNU C++ ?

I have just tried sequence 1. 2. 3 but for me when I drag the form corner to change the size everything expands ok : I can put buttons on the area that has been "expanded" ok. I am using RAD Studio 11.2 (patch 1) and I created a new VCL Win32 C++ (clang32) project for this test.

Yes: Classic compiler has no support for any modern C++ language features. Once you use Clang it is hard to go back to Classic limitations.

I changed one line of code and suddenly one of my important (ie live development for customer) projects won't link: giving "out of memory". It's a clang64 windows VCL building on 11.2. I normally have to fiddle with the heap settings when this happens. But this time the "Tools | Options | Compiling and Running | Verbosity -> set to "diagnostic" doesn't seem to give me any different output from the normal (just "out of memory") so I can't see which heap values are causing the problem. Is this a known regression? It seems as if this Verbosity setting doesn't have any effect on the output given by the linker. I have tried with and without TwineCompile enabled. I am still on 11.2 (patch 1). There seems little to gain by changing to 11.3 for us C++ users. Unless someone can tell me that this "Verbosity" setting does work on 11.3.......

Well this is strange (and still puzzling and worrying). I was working on a different project yesterday and earlier today (a 32 bit VCL C++ clang project). And I've just gone back to this "problem" project and now it links ok. What can be going on here?

I am puzzled / worried. I've just checked out (of Git) the previous version sent to the customer as a compiled and working *.exe file and this now won't link - giving the same out of memory error. What can change that causes the linker to work with the source code at some point and then later not work ? where should I be looking to solve this problem ?

Hi Hans, Sorry about wrong word in my original question: I have edited this to read "diagnostic". Sometimes I have seen TwincCompile catch these messages, but sometimes not. For testing, once you have all the files compiled (takes 10 mins with twine compile) I turn Twine Compile off, Set verbosity to diagnostic and do a "make" again. This checks all object code is still ok (it is) and then jumps straight to doing the linking. The output I get is as follows (edited to save space and maintain customer confidentiality): Done building target "_CheckLinkDependencies" in project "MYPROJECTNAME.cbproj". Target "_PerformLink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets": Task "CallTarget" Target "_PerformBCCILink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets": Using "ILINK32" task from assembly "d:\program files (x86)\embarcadero\studio\22.0\bin\Borland.Build.Tasks.Cpp.dll". Task "ILINK32" d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L.\Win64\Release;"BIG LONG LIST OF OBJECT CODE FILES HERE", .\Win64\Release\MYPROJECTNAME_resources.res .\Win64\Release\MYPROJECTNAME.res Turbo Incremental Link64 6.97 Copyright (c) 1997-2022 Embarcadero Technologies, Inc. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2. Done executing task "ILINK32" -- FAILED. Done building target "_PerformBCCILink" in project "MYPROJECTNAME.cbproj" -- FAILED. Done executing task "CallTarget" -- FAILED. Done building target "_PerformLink" in project "MYPROJECTNAME.cbproj" -- FAILED. Done building project "MYPROJECTNAME.cbproj" -- FAILED. Build FAILED. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2. 1 Warning(s) 1 Error(s) As you see: I do NOT get any indication of which heap size has caused the memory overflow. If I repeat the make with Vertosity set to "Normal" I do get slightly less information in the output - so the setting is having some effect. But no sign of any heap information.....

I find the same with the clang code completion - it sometimes works and sometimes doesn't. I know Embarcadero are aware of this and are trying to make it better. However I think the new approach that is coming (as per David Milington's recent blog) promises to get this properly sorted. It's an essential feature in the world of modern C++ IDEs. If you haven't read David's blog - here's the link: David's c++ the future blog

My experience is that for legacy projects, unless you have a really good reason to change (ie a major new requirement where you'd like to use modern C++ code constructs) then stick with Classic. I still use Classic for significant (to my customers) projects. It does build much faster than the clang compiler. I most definitely wouldn't dream of using clang without the benefit of TwineCompile because the build times would become unmanagable. I wonder why you can't get TwineCompile to work with your classic compiler? I use TwineCompile for all projects and wouldn't want to be without it. I've never had a problem with a classic compiled project working/not working with TwineCompile. {too many negatives: I mean: Classic compiler projects always work with TwineCompile for me).

... try renaming the file back to .jpg and then try to open it with a photo viewer app and see !