Leif Uneus

Sorry @DavidHeffernan, but in the file posted by @pyscript his proposed function InterlockedCompareExchange128 returns a boolean.

@pyscripter Note that in InterlockedCompareExchange128, the last line (MOVZX EAX,AL) is redundant. The function returns a boolean, one byte in size. And, in InterlockedCompareExchange, should it not be following code for the 32 bit ? Result := InterlockedCompareExchange64(Int64(Dest), Int64(NewValue), Int64(CurrentValue)) = Int64(CurrentValue);

Maybe someone can understand this Q&A at SO: CMPXCHG16B correct? https://stackoverflow.com/q/4825400/576719 Or ask a new question at SO.

It is linked by @pyscripter a few replies above.

A little reference article to the CAS and ABA problem. http://ithare.com/cas-reactor-for-non-blocking-multithreaded-primitives/

The greatest problem with inline variable declarations, are backward compatibility. I don't see any benefit, except for some logical clarifications.

I still don't know why Embarcadero does not implement the FastCode purepascal Pos for win64. https://quality.embarcadero.com/browse/RSP-13687 In the example given, the fastcode win64 version is 8 times faster than System.Pos.

From the introduction: It is fully configurable runtime. There is no need to change conditional defines and recompile to change options. (It is however backward compatible with many of the version 4 conditional defines.) It may be configured runtime to favour speed, memory usage efficiency or a blend of the two via the FastMM_SetOptimizationStrategy call.

Closed as harmless.

Look here for an overview of tools and software sources: http://www.modbus.org/tech.php For a Delphi Modbus TCP implementation (free), see: https://github.com/coassoftwaresystems/delphi-modbus

ExcludeTrailingPathDelimiter http://docwiki.embarcadero.com/Libraries/en/System.SysUtils.ExcludeTrailingPathDelimiter

The Delphi IDE known as Galileo (.NET inspired) has 15+ years on its neck. The tools to build and support the IDE is somewhat outdated and the Rio IDE is the first attempt in years to remove old dependencies.

The code editor works for me. I still use the Wordstar keyboard shortcuts as I did in the beginning of the 80s, programming in CP/M and then the MS-DOS environment. I turn off code completion, since that slows down typing and disrupts my intention more that it helps. My fingers do the typing, while I can concentrate on the code. The form designer is ok for layout. But there is one big shortcoming with how it lures a novice programmer to make a mess of separating the GUI from business logic. I wish a more sophisticated default scheme would be introduced to handle that. The error insight function is best turned off as well, since it introduces more doubts than it really helps. Comparing code is easy with the Beyond Compare plugin. The integration with different types of code repositories could be better. The debugger is fine and with the use of FastMM memory leaks are easy to find and remove. The biggest concern for me is not the state of the IDE. Every new version introduces errors in the compilers and the RTL. Using a new version in a 24/7 application is out of the question. I wish all Embarcaderos efforts could focus on bringing out quality compilers comparable with industry standard C++ compilers and a RTL that can be trusted.

IDE Classic editor key mappings with Smart Surround Keys option disables the ctrl+G (delete key) shortcut. https://quality.embarcadero.com/browse/RSP-24277 "[Regression] Smart Surround Keys disables editor classic shortcut ctrl+G" Annoying, but unchecking the Smart Surround Keys option will make it work again.

Not exactly the same, but https://quality.embarcadero.com/browse/RSP-23466 shows that the threading library in Rio is defect.

Define "weird". Enumerations with defined ordinal values do not have RTTI. See http://docwiki.embarcadero.com/RADStudio/en/Simple_Types_(Delphi)#Enumerated_Types_with_Explicitly_Assigned_Ordinality

There was a race condition in the TRttiContext, causing errors in multi-thread applications. As @David Heffernan says, it is best used as a singleton. Seems to be fixed in Delphi 10.3 Rio. https://quality.embarcadero.com/browse/RSP-9815 https://stackoverflow.com/q/27368556/576719 "TRttiContext Multi-thread issue"

Result := Result or (condition);

@Incus J Using Application.ProcessMessages is not the correct way to test if the GUI is updated in a lengthy process. Put your lengthy operation in a separate thread and add a possibility to cancel it if the GUI detects such a request. Application.ProcessMessages can lead to many hard to find anomalies and program failures.

30+ new reports added today. Until a couple of hotfixes and at least one update, I will use it for testing.

@Stefan Glienke I could not agree more. Releasing software and updates based on a new compiler version is a risky business and tests are very time consuming.

Unfortunately the introduction of custom managed records has been deferred to version 10.4 See http://blog.marcocantu.com/blog/2018-november-deferring-managed records.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+marcocantublog+(marcocantu.blog) Pity, since I can see many important use cases for this language enhancement. Guess I will have to bide my time another year.