David Heffernan

What if the function has side effects?

I don't think it is this simple though

That doesn't make sense. You seldom attempt to write tests that exercise all combinations. That's the art of testing, finding a good set of test cases that are concise enough to verify, yet broad enough to provide comprehensive coverage.

And then proceeds to offer six bullet points of advice! I think that there is a lot more to unit testing than meets the eye. Unit testing is clearly about proving correctness of your code at the time you write it. It's also obviously about ensuring correctness of the code in the future in the face of modifications to code, refactoring etc. But I think what is often overlooked is that unit testing (and indeed other forms of testing) is very much about defining what your code does, pinning down the contract between the code and its clients (fancy word for the things that call the code under test). Well written tests can provide clear documentation of the code under test. This can be extremely useful when you need to remind yourself what a particular piece of code does. The implementation of the code may be hard to read and extensive. The documentation of the code may be sparse or non-existent. But a well-written test can provide the information you need to fully understand what you can expect a function or class to do. Furthermore, I routinely find that when I write tests, especially with this perspective of a test as documenting the contact, that I am unhappy with the original implementation and the contract that is implied. I will then refactor the code to achieve the contract that I want. This implies that testing early is good. Test driven development takes that view to the ultimate of writing tests before the code. But even if you aren't going that far, write tests as early as possible. Then when you discover that the contract isn't ideal, you can change it and reduce the impact of that change. Change to design always has smaller impact the earlier it is done in a design process.

Perhaps the behaviour is caused by the manner in which you create these windows. We don't know that.

You don't need a Delphi specific text to learn about unit testing. In fact I expect that the best texts won't be Delphi specific.

What value does the form's Position property have?

Your Pos statement will find FOR SELECT so will call Open. But you say ExecSql is called. What you describe happening doesn't match the code therefore. I am confused. Also SQL is case insensitive but Pos is not.

Uwe is providing useful information that your problem may have an environmental aspect to it. Your antagonistic response is very counterproductive.

Perhaps this is just the final confirmation of the end of days for Delphi, if Verity Stob isn't producing new Sons of Kahn material, then does Delphi really exist?

Also, Verity Stob!

I think this controversy was well covered at The Register, I'd read their articles if you are interested

Great to see that MS has done the right thing here, although disappointing that it took so much pressure to make it happen. Good on El Reg for their reporting on this. Never ever going to happen for Delphi though!!

Did they return the money that customers paid? If not, what did they do with it?

Didn't they announce a few years ago that they would maintain a number of older versions with important patches, for some time after release of major upgrades, but then never did.

13.98 can't be exactly represented in a binary floating point type like double. What you can do is store the closest representable number to 13.98. However, unfortunately Delphi's library code that converts between decimal text and binary floating point is rather poor and has fallen behind just about every other mainstream language. The documentation you link to is pretty flawed too because it doesn't acknowledge representability. What problem are you trying to solve? Are you working with currency for instance? In which case binary floating point is not what you need.

I doubt you will achieve better than 0.1% improvement though. That said, I do want the compiler to do a better job producing efficient code. It shouldn't be getting in our way.

I guess there are scenarios where the warning is useful. Perhaps what they did wrong was not to make it more discerning.

I find that hard to believe. That operation is disk bound, or if the file is in disk cache then it is memory bound.

Yes you can. After all, CharInSet is implemented using the in operator. Which is why it should give the same performance as the in operator, because of inlining, but the inline engine is failing for 64 bit. For sure you can measure a difference in performance in the micro-benchmark, but can you measure it in the real program?

Unless I missed something, that's not the question in the original post. Is that what you are asking?

Why not suppress the warning? Or would you then be suppressing valuable warnings too?

That the set can't have a full range of char values doesn't mean that the char C can't have any value in the BMP. For sure you aren't ever going to find a C that has ordinal above 255 but the value of C may not be known at compile time. For instance you may be looping through the elements in a string.

function CharInSet(C: WideChar; const CharSet: TSysCharSet): Boolean; Given this declaration, how could it? Note that I assume that you mean UTF-16 surrogate pairs.

I strongly recommend that you identify the problem before trying to solve it.