David Heffernan

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.

It's plausible that Indy isn't the problem here and that a wholesale library replacement will leave you with the same problems.

Does vtune do code coverage?

That's kind of odd. Does the same happen if you do this with a brand new vcl project?

@Stefan Glienke You could readily tweak this to work with TStrings rather than TStringList and avoid all that hacking at the internals. But it's nice to see you using records for enumerators!

Not all of us do this!

This would be too late to make much difference. The longer you leave bugs the more they cost. And I'm not sure that it would even help much. You'd have to devote significant resource to running the community contributors. Better to use that resource to get the quality right from the off. There's just something rotten in the Emba development model.

Python has enumerate for this which ought to be possible for Emba to implement for Delphi in a similar manner as for in.

The thing is, releasing software that is of low quality means that your engineering team spends large amounts of time addressing this low quality post release when it is much more expensive to do so. If they would use better engineering processes and concentrate on quality from the very start, then they would use far less human resources. They aren't even cutting corners with this approach. It is inefficient in terms of their own times and resource, and obviously really inefficient for every user affected by this low quality.