Roger Cigol

I just use an TFDQuery with the SQL statement set to SQL CreateTable statement (created either at design time or at run time as suits your needs) and then call Execute() method of the TFDQuery

I have a C++ Builder application that is in two parts - a dll and a main exe. This has all been working fine with version XEn ... 10.0... 10.1... 10.4.... etc (and maybe 11.1 too). But when I compiled it with 11.2 patch 1 I found it compiled without errors but didn't run. I traced the problem to DllMain() not being called when the dll is "attached" as the exe file loads. When I changed this from DllMain() to DllEntryPoint() it all started working again. (Phew!). This page: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Creating_DLLs_in_C%2B%2BBuilder Suggests that there is an option (check box) called VC++ which selects either DllMain() or DllEntryPoint(). But I can't find this option ! anyone know where this is for version 11.2 patch 1 ?

Hi Remy, Well that would explain why I can't find it ! But it doesn't explain why I've suddenly had to change a working using MainDLL() project to having to use DllEntryPoint() in order to get it to work. My own notes suggest that the last time I rebuilt this project was 11.1.5 - so I suspect the change has happened just with 11.2 Any way thanks for your help. As I have solved the problem it's probably not worth further chasing !

Certainly not my intention to do that. Of course there are other source control solutions too. My intention was to point out that trying to do version control / source control manually is rarely (if ever) a sensible use of someone's time these days. Sorry if I sent out wrong "messages" here....

Solving all this versioning issues is exactly what git was invented for and exactly what it does so well and so easily (espeically if you install tortoise git into windows). It's all out there for free and takes a day or two (max) to get the hang of.

You can only do this if you have RAD studio - ie the version with both Delphi and C++. It may be possible to build a separate library with a separate build system (eg GCC or MSC++) and then call this from Delphi - but I would expect lots of effort required to get the naming and parameter passing all working ok. I would be wary about going down this route......

You can purchase RAD Studio - which gives you both Delphi and C++ Builder. Be careful with the statement " most c++ libraries do not compile with c++ builder" - Some do, some don't - "most" is an unhelpful adjective here. If the ones you want to use compile that's what you want..... C++ multi-platform is weaker than Delphi - not having Android is a real shame. Going back to your original question "Do you think Embarcadero would let me switch my license from Delphi to C++ builder?" - This is probably a very unusual request (and I am sure they would try to sell you an "upgrade to RAD Studio (ie add C++ builder)" rather than a straight switch. What would happen to all your current delphi projects?

I am grateful to Glenn Dufke for pointing out the following video - long but worthwhile ! I add my youtube comment here as a way of starting a discussion: A great presentation (especially liked a guru like you failing to get the gcc to run!). Very ambitious vision - but it's good to "aim high". Could a compromise be to have a Cpp release that prohibits (not just deprecates!) the "unsafe" historic features (eg union, pointer arrithmetic, new/delete etc etc), forces use of bounds checking and std::span but without introducing the new syntax? Might not be so elegant and would not reduce your "teaching load" so much but might get through the inevitably cumbersome standards committee? Or do you realistically see Cpp2 as a fork away from the standards committee (sorry to be so heretic!)?

I live in that world ! But tell me what GUI you would use with Rust that comes close to VCL or FMX ?

Anyone out there who is an Embarcadero C++ Programmer based in the UK (ideally SW England) with interest in engineering applications ? We could do with working with one (full time?)

It is true that C++ has evolved greatly. Actually in almost all cases it is backward compatible (and the few cases it isn't are often particularly flakey coding edge cases). There are some serious brains greatly improving the concepts behind writing sound code working on C++. It's fascinating (but time consuming) learning (and understanding) about the thinking behind some of the additions. The thinking behind sticking to C++ is a) access to a lot of third party libraries. b) not tied to one particular vendor's compiler (there are three compilers still very active out there: MSC++, GCC and Clang). c) There are many more C++ programmers out there than delphi. Of course b) is a great self deception: the extensive use of the (still beautiful after all these years) VCL framework does tie me to Embarcadero - although much of my more recent (in the last 10 yrs) code has good separation between the GUI and the "nitty gritty business" code the GUI is still an area that takes a lot of time to get right (ie how the customer likes it) so it would be very painful to swap to one of the competitors <but not impossible>. Of course c) is a great self deception as all the good C++ programmers have good jobs ! and actually a) is true but as yet I don't use a great many 3rd party libraries. ...... so perhaps you are right !

I don't see an Embarcadero Rust VCL/FMX appearing any time soon.....

A very valuable posting has appeared on Stack Overflow regarding using Google Tests with Embarcadero C++ clang compilers. Thank you to T. Herzke for sharing this. More useful info on C++ google tests unit test

.... And am still looking ....

I have to point out that the upgrade to 11.2, installing over 11.1.5 went without any issue for me (installed from ISO image). It's true that I did have an issue discussed (and resolved) in the link below but the installation went without any issue.

I have a 350+ file project that built just fine with 11.0, 11.1 and 11.1.5. Its a windows 64 bit VCL project. It has a set of unit tests (googletest) that builds under 11.2 ok. It has a small "test utlititly" that is also Win64 VCL and that too builds ok under 11.2 But when I try to compile the main project all the files compile ok but the linker fails. I get the following output which I am having trouble interpreting. Any ideas about what might cause this ? [MSBuild Error] CodeGear.Cpp.Targets(3984, 5): MSB4018 The "ILINK32" task failed unexpectedly. System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) at Borland.Build.Tasks.Common.Metadata.Option.ParseInt64(String value) at Borland.Build.Tasks.Common.Metadata.Option.IsDefaultValue(BaseTask task) at Borland.Build.Tasks.Common.Metadata.Option.AppendCommandLineSwitch(BaseTask task, CommandLineBuilder b) at Borland.Build.Tasks.Common.BaseTask.AddOptionString(CommandLineBuilder b) at Borland.Build.Tasks.Cpp.ILINK32.AddOptionString(CommandLineBuilder b) at Borland.Build.Tasks.Common.BaseTask.GetCommandLine() at Borland.Build.Tasks.Cpp.ILINK32.GetCommandLine() at Borland.Build.Tasks.Common.BaseTask.GenerateCommandLineCommands() at Microsoft.Build.Utilities.ToolTask.Execute() at Borland.Build.Tasks.Common.BaseTask.Execute() at Borland.Build.Tasks.Cpp.ILINK32.Execute() at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult)

An update: it seems the real problem with my linker options was that one of the heap size settings had been entered (by me) with a leading space. It seems the MSBuild process doesn't like this. By deleting and then re-entering the numbers I removed the leading space and hence it all "sprung into life".

This problem is solved! I found that if I cleared the linker heap settings (in project | options | linker) and then tried a build the correct linker did run (so the can't create task ILINK32 error message is a bit of a red herring - the task called ILINK32 creates a call of ilink64) but it gave an "out of memory error". Entering heap sizes back in again (as per the embarcadero documentation on "linker out of memory" issues) gave me a project that links ok. OK : so not actually sure why I had to do this - but it has solved the problem.

I get the same problem with and without TwineCompile. I use TwineCompile for all C++ projects - for the clang compilers any reasonable project without TwineCompile becomes unmanageable because of the compile times.....

I have just created a new trivial Clang64 VCL project (one form, two buttons). This compiles and links ok with 11.2. When I look at the section of the build output text related to the linker it begins as follows: Linking... Target _PerformLink: Target _PerformBCCILink: d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L.\Win64\Debug;"d:\program files ie it is using the ilink64 linker. So I am pretty sure that my problem is that 11.2 is for some reason trying to link my large project using the wrong linker.... Anyone know why this might be or how I can force this to use ilink64 ?

Hi David P, Really appreciate your suggestion. Have tried doing a manual delete of all temporary folders - no different. I already use a different tempororary file for each build option (for this VCL Win64 project I only have a debug build and a release build as the two targets). You don't mention my note about "shouldn't it be using ILINK64".... Do you agree with this statement or am I wrong here?

It is true: you cannot use the Classic compiler to compile GoogleTests. But there is nothing (or at least normally very little) to stop you using the Classic compiler for your main project but to use Clang32 for your unit testing project

My mistake ! sorry for confusion. The correct link is.... https://cigolblog.wordpress.com/2022/05/12/using-google-tests-with-classic-compiler-projects/

Hi Camilo, 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://cigolblog.wordpress.com/2022/05/12/using-google-tests-with-classic-compiler-projects/ The big advantages of using GoogleTests over DUnit are a) There is good documentation provided by Google out on the web b) it supports all commonly used unit testing techniques (including building mocks) c) if/when you move your Classic based project to Clang32 your unit tests will all still be valid / useful I've ditched DUnit completely in favour of using GoogleTests - even though many of my existing projects for customers are still based on the Classic compiler

Hi David P - can you remind me how to switch off the Code insight indexing in 11.2 - I can't find the check box " Index for C++ Insights" that is referred to on this help page: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Code_Insight_Reference#Error_Insight