Roger Cigol

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 ?

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

Interesting - I seem when I successfully compile and link my GoogleTests unit tests for this project I get this line in the console output Linking... Target _PerformLink: Target _PerformBCCILink: d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L. < all my google test files are listed here> Build succeeded. 0 Warning(s) 0 Error(s) The fact that the error messages for the main project (previosuly reported) are referring to "ILINK32" makes me wonder if the 11.2 has got mixed up and is trying to call the 32 bit linker....

I don't know if this helps (it looks like more of the same...). The TwineCompile "console output" shows all 354 file compile ok and the resource compilation goes ok. It then reports the following for the linker error.... Done building target "MakeObjs" in project "MyProjectNameHere.cbproj". Linking... Target _PerformLink: Target _PerformBCCILink: d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: The "ILINK32" task failed unexpectedly. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: System.FormatException: Input string was not in a correct format. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.ParseInt64(String value) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.IsDefaultValue(BaseTask task) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.AppendCommandLineSwitch(BaseTask task, CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.AddOptionString(CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.AddOptionString(CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.GetCommandLine() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.GetCommandLine() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.GenerateCommandLineCommands() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Microsoft.Build.Utilities.ToolTask.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult) Done building target "_PerformBCCILink" in project "MyProjectNameHere.cbproj" -- FAILED. Done building target "_PerformLink" in project "MyProjectNameHere.cbproj" -- FAILED. Done building project "MyProjectNameHere.cbproj" -- FAILED. Build FAILED. D:\MyProjectNameHere\C code\Utility classes\Computer.cpp(348,7): C++ warning : 'GetVersionExW' is deprecated [-Wdeprecated-declarations] d:\program files (x86)\embarcadero\studio\22.0\include\windows\sdk\sysinfoapi.h(383): C++ warning : > 'GetVersionExW' has been explicitly marked deprecated here D:\MyProjectNameHere\C code\LabelPrinterPcb Thread\LabelPrinterPcbControl.cpp(967,6): C++ warning : '/*' within block comment [-Wcomment] D:\MyProjectNameHere\C code\LabelPrinterPcb Thread\LabelPrinterPcbControl.cpp(1018,18): C++ warning : '/*' within block comment [-Wcomment] d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: The "ILINK32" task failed unexpectedly. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: System.FormatException: Input string was not in a correct format. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.ParseInt64(String value) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.IsDefaultValue(BaseTask task) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.Metadata.Option.AppendCommandLineSwitch(BaseTask task, CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.AddOptionString(CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.AddOptionString(CommandLineBuilder b) d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.GetCommandLine() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.GetCommandLine() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.GenerateCommandLineCommands() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Microsoft.Build.Utilities.ToolTask.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Common.BaseTask.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Borland.Build.Tasks.Cpp.ILINK32.Execute() d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB4018: at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult) 4 Warning(s) 1 Error(s) Time Elapsed 00:10:07.58 Finished Build.

Beta testers are not magicians (at least none of the ones I've ever met are). If you don't file an RSP it is much less likely that the bug you vaguely describe here ("problems with ctrl+click to open files") will be fixed.....Please do file an RSP.

That's a little lazy.... Here's the link https://quality.embarcadero.com/browse/RSP-38884?jql= It would be interesting to know if the same problem exists on 11.1 - does anyone have time to check this ?

It would be really valuable to everyone if you could file this bug on the Embarcadero Quality Portal https://quality.embarcadero.com/secure/Dashboard.jspa

Can you give a brief sample code of the kind of thing that you think fails sometimes, even though it "works" in your brief sample. This could well be an example of doing something that C++ is allowed to use the "undefined behaviour" get out (undefined behaviour often tends to one of either "a complete crash" or "sometimes works and sometimes doesn't"

A strange question to ask. You are the person who can generate the fault you are trying to describe. So only you can really judge if the same problem exists when the correct set of circumstances are made to exist in another (eg open source) project....

I would be wary here. The field defaults to read only because it is a calculated field. Why would you want to change the value (unless you are trying something very dodgy?) of a calculated field. This strikes me as the sort of thing that should ring an "alarm bell" with the question: "am I designing my code the best way ?"