On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt <mich...@freepascal.org> wrote:
> Please add overloading using UTF8String. > Backwards compatibility is not an idle word. To be honest, that last sentence does not make sense to me. Before trunk TRegistry used (on Windows) the A-API and string parameters are just AnsiString(CP_ACP). Unicode caharcters were not supported in plain fpc programs using the default 1 byte encoded string type on Windows. Introducing Utf8Encode (and the plain wrong Utf8Decode) in TRegistry is backwards incompatible. Reverting this to using plain String does not introduce any backwards (compared to 3.0.4) incompatibilty AFAICS. (Unicode support in plain fpc programs simply is not there (unless you use the appropriate string type). There is a reason for the Lazarus UTF8-hack.) Introducing UnicodeString overloads does neither introduce regressions AFAICS. If it would have worked with A-API it certainly will work with UnicodeString, because the characters would have been inside the users codepage. It does however add unicode support for plain fpc programmers for those who need that. All would still be completely unicode-proof in Lazarus (with UTF8-hack). Using UTF8String would trigger 3 conversions instead of 1 (plain fpc programs): string->utf8string->unicodestring (the last conversion is inside the methods where we call the W-API). Using UnicodeString would trigger only 1 conversion: String->UnicodeString. For users using Utf8String inside there program calling the UnicodeString overload would also be just 1 conversion (lossless). -- Bart _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel