Kryvich

1. You cannot extend a set of constants if they are defined in a record type in a third party library. There is no record inheritance. 2. An enumeration give us more type safety than a set of integer constants. 3. Scoped enumerations. 4. I like prefixes. But if not, see 3. I use enums with 100 or more members. If instead of them I used named integer constants, adding and subtracting them, there would be many hard-to-find errors.

I know, now it is not fashionable to use prefixes, and they prefer to write TCommandType.NA, or even CommandType.NA like in C#.

@Mike Torrettinni I would use different prefixes if possible.

The best test bench is your program. Try both variants on real data and compare results.

Embarcadero announced DelphiCon 2020 for November 17th. So I think a new version (10.5 or 10.4.x) is coming soon.

@Mike Torrettinni What version of Delphi are you using and what compiler directives are set? I ran your test in Delphi 10.3 CE and I got the same assembler code for both cases. TestStringHelper.dpr.23: if (vSearchValue = '') and (vItemValue <> '') or (vItemValue = vSearchValue ) 004E9AA1 837DFC00 cmp dword ptr [ebp-$04],$00 004E9AA5 7506 jnz $004e9aad 004E9AA7 837DF800 cmp dword ptr [ebp-$08],$00 004E9AAB 750B jnz $004e9ab8 004E9AAD 8B45F8 mov eax,[ebp-$08] 004E9AB0 8B55FC mov edx,[ebp-$04] 004E9AB3 E8301CF2FF call @UStrEqual ... TestStringHelper.dpr.29: if IsSearchByValueFound_Inlined(vSearchValue, vItemValue) 004E9B49 837DFC00 cmp dword ptr [ebp-$04],$00 004E9B4D 7506 jnz $004e9b55 004E9B4F 837DF800 cmp dword ptr [ebp-$08],$00 004E9B53 750B jnz $004e9b60 004E9B55 8B45F8 mov eax,[ebp-$08] 004E9B58 8B55FC mov edx,[ebp-$04] 004E9B5B E8881BF2FF call @UStrEqual

Several years ago, I suggested adding the ability to call global functions and procedures as if they were class members of their first const parameter. For example, the standard function Trim could be used like this: Result := ' ABCD '.Trim; // equals to Result := Trim(' ABCD '); Unfortunately, they came up with the concept of non-extensible helpers.

Yes, I can now export my data to XML. The resulting XML looks similar to what I get with SimpleXML. I will test it further. Thank you!

Very interesting library! I am used to use SimpleXML, but if your library is really that fast, I will definitely switch to it. SimpleXML supports ANSI encoding to reduce memory usage, but I think it will not be too difficult to add ANSI to Neslib.Xml. Converting one of my program from SimpleXML to Neslib.Xml was not difficult, but I ran into an exception EIntOverflow in the procedure TXmlPointerMap.Map. Call stack is: I was able to make a truncated test project to demonstrate the exception, please look at the attachment. P.S. And thank you for the insightful article. I like this type of optimizations! Test Export To XML.zip

This "sugar" is too expensive.

Marco Cantù has a comprehensive guide to Unicode, ANSI, RawByteStrings etc.

@A.M. Hoornweg It depends on Windows ANSI codepage. I have CP-1251. The compiler also issues a lot of warnings: Ansistring28591.dpr

We need a real RawByteString without ANY implicit conversions. Just show a compiler error when trying to implicitly convert a string. Or improved TBytes with copy-on-write and all manipulation routines.

@A.M. Hoornweg Why duplicate what the standard library already does for strings, including byte manipulation and copy-on-write?

1) Recommendations can change over time. 2) Look at Microsoft: they used UTF-16 as the default string for Unicode Windows in the beginning, and now they trying to use UTF-8 instead.

I would use RawByteString in this case, despite the warning in the manual. (Actually, that's what I do in such cases.) I don't think these strings will be thrown out of the RTL in the future. Use raw byte strings inside the module, explicitly converting them to Unicode strings in the output.

Very impressive!

Try remove const in the header of function Login.

@WillH Actually the project is maintained 17 years by these people: Now they can legally open their changes to everyone.

Announcement from Marco Cantù: Bold for Delphi is Open Source

I really hope for the release before 11/28/2020. Because after that date, my Community Edition will turn into a pumpkin.

@Carlo Barazzetta Thank you! Your components are a must-have for High-DPI enabled applications. I would say High-DPI is a second revolution in Delphi desktop development after Unicode.

https://github.com/Kryuski/AnsiToUtf8

Rather hope for 10.5. They are unlikely to break DCU compatibility in 10.4.1.

Well I would prefer the short form for other record operators too: typeName = record operator conversionOp: resultType; operator unaryOp: resultType; operator comparisonOp(b: type): Boolean; operator binaryOp(b: type): resultType; end;