Leaderboard

https://delphisorcery.blogspot.com/2021/06/introducing-springbenchmark-port-of.html

Good question - probably because I did not look into the implementation as the API does not tell it automatically does UTF8 conversion which it usually does not. But as far as I can see GetHashString encodes as hex and not as base64

I can save you 70 minutes there. The key point of Chandlers Efficiency talk is "Cache locality is very important". The remaining 60 minutes are just circus IMO.

Excellent work! Well written article and kudos for the links to expand on the subject. I am going to watch the videos and read the links now. 🙂

The quick solution is to replace DirExists with SysUtils.DirectoryExists which is available in Unicode compilers, and which is already used in OverbyteUtils for IcsDirExistsW. I'll fix this in SVN shortly. Angus

Hi, Well, logic, yes. Depending on the REST API server function. On another side a TListview (livebinded) for only 10 records a VerticalScrollbox filled by code should be a good alternative, IMO getting previous page and next page (30 records) during thread process should be better

Hi, Exactly that.. if you offer your software as a download then SmartScreen will be a real PITA for your users unless your software was signed with an EV certificate. About 3 times a user gets asked if they really want to do this. First deny the download, then popup a "not often installed" warning with cancel as default choice, then another warning of which I forgot the details. Sorry, can't test that now as Microsoft has finally started accepting my normal certificate again (after 5 months of pain) There I was just coming to the conclusion that one of these days I have to accept that the certificate I had bought for 3 years is worthless and that only an EV code signing certificate is going to offer a painless installation for end users. (pffff... ) edit: you asked for a link: https://www.ssl.com/faqs/which-code-signing-certificate-do-i-need-ev-ov/ I have lost so much time (and sales) on this that when the next renewal comes I will not doubt and buy an EV certificate instead of the -much cheaper- OV one.

Am I the only person who treats out params as "write-only" vars? I get that the compiler doesn't always handle them properly when you abuse them. IRL code, I use them when I need to return more than one value from a method. Saying you can pass in an initial value to an out param is like saying you can pass in a default return value (result) to a function -- and there's probably a way to do that where the compiler won't complain about it either. You can also call a method with no parameters at all and the compiler won't complain. And even when you do that, it's possible to pass in values for those parameters! This is to maintain backward compatibility with ancient syntactic crap in very very old versions of TurboPascal that probably have their roots in even older compilers (USCD Pascal, perhaps?). This is what Pascal Analyzer was created for -- to show you crappy code expressions that, while legal, should not be used. I seem to recall that PA's list of stuff is around 3x bigger than Delphi's. PA does for Delphi as what lint does for 'c'. Speaking of which ... who remembers the ads in programming mags by the guys who published a sooper-dooper version of lint (maybe lint++), under a heading like, "Can you find the bug?"

https://en.wikipedia.org/wiki/ISO/IEC_8859-1 there are 65 undefined characters

Many ANSI charsets DON'T have all 256 bytes mapped.

Try https://en.wikipedia.org/wiki/Windows-1251 one character is undefined hex 98. https://en.wikipedia.org/wiki/Windows-1250 there 5 undefined characters.

Yes, quite lucky. Most ANSI locales use 1 byte per character, and UTF-16 uses 1 codeunit per character for most Western languages. So, you usually end up with 1 byte -> 2 bytes -> 1 byte conversion, hence why the final size was the same byte size, but may or may not be the same bytes as the original. There is more involved than just nul-padding, which typically only applies for bytes in the $00..$7F (ASCII) range. For non-ASCII characters, it is not a matter of simply padding '<HH>' to '<HH>#0', there is an actual mapping process involved. For example, if Windows-1252 were the locale used for the conversion, and byte $80 (Euro) were encountered, it would be converted to the Unicode character U+20AC, which is bytes $AC $20 in UTF-16LE, not $80 $00 like you are thinking. But yes, the individual bytes of the EXE data would mostly get doubled when converted to Unicode, and then truncated to single bytes when converted back to ANSI. But that does not necessarily mean that you will end up with the same bytes that you started with. For example, using Windows-1252 again, byte $81 (amongst a few others) would end up converted to either Unicode character U+FFFD (Replacement Character) or U+003F (ASCII '?') depending on the converter's implementation, which would thus be bytes $FD $FF or $3F $00 in UTF-16LE respectively, and then converted back to ANSI as byte $3F, which is clearly not the same as the original. If you absolutely need a charset that ensures no data loss when round-tripping bytes from ANSI to Unicode to ANSI, you can use codepage 437 for that, see Is there a code page that matches ASCII and can round trip arbitrary bytes through Unicode? The Unicode won't have the same character values as the original bytes in the ranges of $00..$1F and $7F..$FF, but the result of converting the Unicode back to codepage 437 will produce the original bytes. Nul-padding is not guaranteed, but yes, the String data inside the stream can get messed up. Do not use a TStringStream for binary data. Use TMemoryStream or TBytesStream instead.

Most likely, that code predated the shift to Unicode in Delphi 2009. No, it doesn't. It has the potential to corrupt the data. This is exactly why you SHOULD NOT put binary data into a UnicodeString. Doesn't work. It fills only 1/2 of the UnicodeString's memory with the non-textual binary (because SizeOf(WideChar) is 2, so the SetLength() is allocating twice the number of bytes as were read in), then converts the entire UnicodeString (including the unused bytes) from UTF-16 to ANSI producing complete garbage, and then writes that garbage as-is to file. So yes, the same number of bytes MAY be written as were read in (but that is not guaranteed), but those bytes are useless. That code is copying the binary as-is into an AnsiString of equal byte size, converting that AnsiString to a UTF-16 UnicodeString using the user's default locale, then converting that UnicodeString from UTF-16 back to ANSI using the same locale. Depending on the particular locale used, that MAY be a lossy conversion, you MIGHT end up with the same bytes that you started with, or you MIGHT NOT. This has nothing to do with pointers. You are simply performing 2 separate data conversions (binary/ANSI -> UTF-16 -> binary/ANSI ) that just HAPPEN to produce the same results as the input IN YOUR ENVIRONMENT.