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.

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.

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

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

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

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.

Unless performance is impacted

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

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?

No

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.