David Heffernan

Seems odd to replicate a function that already exists in the RTL. Also to implement it by potentially assigning the result variable twice. And the default parameters are very odd. It would never make any sense to omit these parameters.

A generic IfThen is trivial to write. I know I have one in my code base.

This is probably a mis-feature. I'd far rather such ambiguities resulted in errors unless you fully qualified the names. In fact it would be far better if units didn't have to be imported in full. If you could import classes, names paces etc. rather than having to pull an entire unit into the importing unit's namespace. Have you decided to reimplement other rtl functions, and if not why not? What is special about IfThen that you insist on reimplementing them?

The point is not that it doesn't behave as designed. It's that the design is poor. What is needed is a conditional operator built into the language, like in almost all other languages.

Well, now you've got to fully qualify function calls left right and centre, so it's hard to see this as a clean up.

That's a poor idea in my view.

This seems odd. Why would you need another implementation of IfThen for Integer and string? Why would you need more than one?

What types are the parameters for the functions that are ambiguous?

Not for every type. It's not helpful making these assumptions.

Sometimes reference types are best, and sometimes value types are best. That's why we have both. You cannot know that a class is right here.

You can't know that. It is easy to imagine scenarios where a value type is essential for performance reasons.

Use an open array parameter. http://rvelthuis.de/articles/articles-openarr.html

In that case why convert to bytes? Not sure why we are guessing. Perhaps @karl Jonson might like to contribute.

If it's a byte array, why don't you just write that to file? Why do you need to convert it to a string variable?

Submit a report to QualityPortal

When you do this, you find that your code is around more than 10 times slower than even the slowest versions in the benchmark, and that's before we've added code to handle errors which is currently missing from your code.

This is not something we should be happy about though. The compiler should be doing this for us.

Define "best". Starting with deciding which encoding to use.

Measure your program and find out. If all you do is micro benchmarks then likely all you will achieve is to make your code harder to read and develop, and your program runs no faster. Do you know where the bottlenecks are in your program?

Is this code a bottleneck in your program? If not write it in the way that is easiest to read. How many times have I said that to you? Why would you choose to make your code hard to read for no benefit?

DeepBlue is old news. Things have moved on. Stockfish is king these days.

You can extend my benchmark program in earlier posts to see how it performs.

This code is very easy to verify that it is safe. For more complex code, that may not be the case, and so pointers could be risky. I was using pointers here for performance reasons. Copy a bunch of characters in one go rather than character by character. Others showed much better ways to do it than my initial attempt.

Blitz ELO of <1500 suggests that no, it does not play good chess CCRL Blitz - Index (computerchess.org.uk)

Can it play chess well? Or is it interesting because it's Pascal?