David Heffernan

Read this closely. Here I say that I believe that XmlDoc is not suitable because you aren't doing library documentation for the library consumer. So we are on the same page. As I expect you know, my work is in the realm of scientific computing. In our case we are simulating the dynamics and loading of pipes and risers. We document the technical aspects outside the code, using LaTeX so that we can present formulae in a readable fashion. We then cross reference to that document from the code. This works fine for us. I think once you decide that you need formatted equations then that takes you to a separate document. Anyway, that's how we've settled on doing it.

Stop even trying to justify this. The two pieces of code are not comparable. You can see the single SetLength call. That's missing for the list. There's nothing more to say.

Actually the defect is in your test code. Set the capacity when you create the list. Just as you do with the array. Obviously you need to compare like with like.

Sometimes it should, sometimes not

Unification is good. Going to cause headaches for anybody with ARC only code. Don't think that's going to be an easy migration path. Such a shame that this happened at all, but good for Emba for having the strength to change direction.

You don't need to explain what your code is doing. The code ready tells you the what. XmlDoc is typically used to document libraries for the benefit of the consumer. But you seem to be talking about internal documention. I don't see what's wrong with judiciously used comments on the key methods. After all, the vast majority of methods need no internal documentation.

If you want your beta testers to find bugs, don't you want lots of testers?

I wasn't suggesting otherwise. I was just saying that my experience is with YAML, but the issues are essentially the same. You can't expect any system to be able to serialise arbitrary classes without some input from the coder.

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.