David Heffernan

I use YAML rather than JSON, with my own wrapper of libyaml. And I have written my own library to handle persistence, not RTTI based. I think you are always going to suffer if you let the standard JSON library try to do persistence for you based on RTTI.

Change the way you do JSON persistence then. Fix the real problem.

Ugh. Just use a generic list and scrap most of this duplicated code.

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe. It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state. I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. Doc is here https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

I submitted many QC reports, including one with a detailed document explaining how to make the floating point control word handling threadsafe. These got deleted when QC was killed. I can't be bothered to add them again. Marco and David M know about this.

True. But that's not necessarily less work. By batching a few releases together you reduce the number of context switches. That can easily be significant. If you do maintenence then you need to maintain a greater number of Delphi installations per dev machine if never skip. In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix. And that requires a chunk of work for every distinct version of Delphi. Skipping reduces that overhead. So blanket statements are easily seen to be bogus. It all depends on context.

OK, so you agree with me.

This makes no sense to me. You only deal with breaking changes if you keep current. You present an either or choice that's actually a both or neither!

It costs me time and money to upgrade and for now I'm missing nothing by sticking to XE7. But that's just me. Different users will have different drivers. Nobody can made a blanket statement like

It makes no difference to the operation of the code, its just worth being aware of the difference between THandle, which is a handle to a kernel object, and HWND which is a window handle. The Delphi rtl has been a little sloppy over the years distinguishing different handle types so it's not surprising that some of the rubs off.

Imagine if the Delphi debugger was able to evaluate expressions without generating memory leaks in the debugger?

Sounds like management are right here. Why should they spend money on upgrading? And it's probably less the license costs but mote the time cost of the staff migrating code and tools.

Nope. It's an HWND. A THandle is quite different. Also, https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683

TST, like binary tree, requires there to be an ordering of the key values?

No

Quite possibly depends on the font files as well. Can't imagine this is related to Delphi.

It is easy. And there are open source dictionaries out there. As for whether they are compatible with the GExperts license, I've no idea.

Expand a generic dictionary implementation manually. Just replace the TKey and TValue textually. It would also be very valid to stop developing GExperts for pre generic delphi.

If you don't like the terms, don't buy the product. We all have a right to set the terms of any products that we sell.

Open array of record, using a function or record constructor to populate new instances of that record. Syntax support for initialization is a bit crappy in Delphi sadly.

The question literally asks about intervals less than that which you obtakn with a timer. You'll find that Sleep has the same performance as a timer.

Strange way round. Wouldn't it be normal for you to prove your prime claim?

Try timing Sleep(1) with TStopwatch.

The latter.

I'm not suggesting that you don't preallocate with a sensible capacity if you know it. I would always do that. In multithreaded code especially, minimising heap allocation is always advisable.