[fpc-devel] TRegistry and Unicode

Bart bartjunk64 at gmail.com
Wed Mar 6 15:47:59 CET 2019


On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt
<michael at 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



More information about the fpc-devel mailing list