David Heffernan

Why is OTL overkill, and PPL is not? 

http://hunspell.github.io/

Imagine how fast it would be if you wrote code that didn't stress the heap allocator. That's the real route to performance. 

Real world benchmarks are the only ones that matter. 

They all do different things. Rather than have us explain this, did you read the documentation? 

I don't think that item 3 is very widely used. However meta classes, item 2, is widely used. Classic example is the streaming framework. It is used when you need to instantiate a class whose identity is only known at runtime. When streaming properties the framework reads the class name, looks it up using RTTI and then uses meta classes to instantiate the instance if that dynamically determined type. Always seen with virtual constructors. 

4 hours ago, RDP1974 said:

should be cool to have a lock-free allocator using threadvar and/or TLS API

Threadvar is implemented on top of TLS on Windows. 

How is lock free going to handle deallocations made from a different thread from that which allocated the memory? 

But hey, if you want to write this code, go for it. 

All UI happens from the UI thread. So if you want an exception from another thread to result in UI, you need to marshal it into the main thread.

Having madExcept in your process is great. But there are a class of exceptions that you don't want to trouble the user with a bug report. I call these expected exceptions. You need to decide on a policy for those exceptions. 

GetIt, I just don't get it. Surely you are better off pulling from the repo? 

This is one of the reasons why the cool cats don't use RTL collections

Cross process window parenting relationships never end well. Don't try this. 

https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683

Cross process UI is fraught with complications. I wouldn't dream of trying to parent a window from one process into another process. 

People for sure would rather have an error message than incorrect results. You are just kidding yourself if you say otherwise. It's simple human denial. 

Suppressing errors will result in a program with more defects. We all know this to be true. And yet people still choose the path with more defects. 

What happens when you access an array out of bounds with range checking disabled? Perhaps the memory is valid and so the program continues running. But now it's behaviour is unpredictable. Often you will corrupt memory which leads to obscure errors later that you can't tie back to the original defect. Or quite often it's a straight AV which is hardly preferable to a range check error, since it isn't reproducible.

8 minutes ago, Vandrovnik said:

Of course I cannot guarentee it. But you wrote "Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded.", so I gave you an example, where error message would be worse than ignoring the error.

Yes, but since you don't know that the error will be inconsequential, it's kinda pointless looking at the impact. 

16 minutes ago, Sherlock said:

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not? Why not log into some %APPDATA% folder every bug, that occurs and try to keep the application running. When a bug does manage to get reported ask someone to send you the (doubtlessly numerous) log files.

Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

Better hope that the incorrect information that you show to the user is inconsequential. 

13 minutes ago, Vandrovnik said:

Not always... In an application drawing 3D scene, a small error in object displayed somewhere far away from the observer does not metter, probably nobody notices. Of course in a book-keeping application the situation is quite different.

I'm amazed that you can guarantee that the error will be far away from the observer. How did you do that? 

32 minutes ago, Mike Torrettinni said:

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer.

No you wouldn't. Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded. 

I agree with this. If it doesn't impact performance, then for sure include it in release builds. However, sometimes it really does. It does in my numerical code, but obviously that type of code is probably in the minority amongst Delphi code.

You can change viewer. You don't need to change the test framework in order to use a different viewer. 

1 hour ago, Dany Marmur said:

Range checking ON for ALL builds.

Unless performance is impacted 

Irrespective of what any poll says, opt off, range & overflow checks on is the correct thing to do 

31 minutes ago, Lars Fosdal said:

Integrity control. 

I don't understand that. 

Certainly I'd do all the work to prepare the resource from the source file as a pre build step, properly automated. 

I'd question the choice to use compression. What is the point of that? 

9 minutes ago, PeterPanettone said:

Are there any other considerations worth mentioning when deciding which Windows version to use for Delphi?

No

3 hours ago, PeterPanettone said:

Is Windows 10 Home 64-bit good enough to run Delphi 10.3.3+ without problems

Yes

@Arnaud Bouchez How do you handle a line longer than your buffer? 

Often it's not how much memory you use, but how you use the address space. 

But if you can, just switch to 64 bit and move on.