Roger Cigol

Count me in as a volunteer too, if needed.

This problem is always going to be with us. But we do need to keep the forum open. New members = new blood = new ideas. Without new members the forum has signed it's own death warrant (even if it is a slow death).

Writing a compiler is VERY complex. Speaking as someone who doesn't write compilers, I myself would be cautious about criticising my colleagues in the industry who do, particularly when given an explanation that does make some kind of sense (as in this discussion). I certainly agree with @Dalija Prasnikar there is nothing worse than a compiler warning that is wrong. It is hard to make them "go away" and they definitely can "hide" other useful warnings.

The use of a 64 bit application talking to a 64 bit database is the one time I've found where the IDE being a 32bit app is a real pain. What it means is you can't use the same database settings for design time as you use for run time (and doing so is a really convenient feature when you develop 32 bit apps). I work on a large PostgreSQL project and PostgreSQL is only available as a 64bit database (and has been so for a long while - you have to go back several versions to get a 32 bit version). I just accept that I can't use the design time connectivity of FireDAC and just do all my debugging at runtime. It's not so convenient but I've got used to it!. Be sympathetic to the Embarcadero Team - changing the IDE to 64bit must happen but they need to make sure that there are 64bit versions (or equivalents ) for all the sub components (which come from many many places : just look at the IDE menu item: Help | About | Acknowledgements). It's not quite as straightforward job as you think. You also have the issue that it "breaks" all the design time features for the folk out there using FireDAC with 32 bit apps talking to 32 bit databases. These may well be used to seeing all the design time connection functionality.

I've just noticed that there is no mention of the Delphi Coding Boot Camp 2023 on this Forum. Seems strange that no one else is aware of this! Delphi Code Boot Camp 2023

That's interesting ! I haven't had a single e-mail about it. Sorry if you feel I have just added to the "swamping".

Am I blowing my own trumpet too much to let people know that I am presenting "Introduction to XML Mapper" in this bootcamp today at 20:00 hrs UK time = 14:00 hrs USA CST ? If the answer is "yes" than I apologise

In the unlikely but not impossible event that you have field names in your paradox tables that include the # symbol I point you to this posting: Upgrading paradox field names containing # symbol

I too migrated a system away from Paradox a long long time ago. Paradox was good in it's time but it's limitations (particularly for a multi-user interface to the database) are very significant. I would definitely migrate to a modern and supported database (there are several open-source type solutions that are only a free of charge download away....)

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++ ?