[fpc-devel] TRegistry and Unicode

Bart bartjunk64 at gmail.com
Wed Mar 6 12:48:28 CET 2019


On Mon, Mar 4, 2019 at 12:16 PM Marco van de Voort
<core at pascalprogramming.org> wrote:

> There is no need to further change interfaces to provide yet another
> option which does yet another option which is useful for only a limited
> time.

So, where to go now from here?

1. Leave all method signatures unchanged (use plain string variables)
and cut out all the Utf8Encode(). Then wait for the time that
string=unicodestring?
2. Cut out Utf8Encode(), overload all methods with ansistring
parameters to accept either UTF8String or UnicodeString parameters?
3. Do nothing at all?

Option 1:
+ easiest fix.
+ consistent with most other "interfaces" (for lack of a beter word).
+ no data los with Lazarus unicode hack. No dataloss on any system
that has CP_UTF8 as it's sytem codepage (most *nix).
+ at least one person is willing to provide such a solution.
- possible data loss on Windows in plain pascal programs.

Option 2:
+ solves the issue of possible data loss cross-platform
+ makes no difference for Lazarus users.
+ at least one person is willing to provide such a solution.
- clutters the interface
- when string becomes unicodestring  (like Delphi) (if ever?), the
ansistring methods need to be removed (or parameters must explicitely
typed as AnsiString)

Option 3:
+ no change required
- no problem solved
- leaves inconsistent interface

>From my previous posts on this topic (here and in bugtracker) it will
be clear that I am strongly opposed to solution 3.

We should at least do something.
As it is now, the registry has bugs and regressions (as compared to 3.0.4)
If nothing is done, then most likely Lazarus will fork the TRegistry
to at least be able to fix current issues.
This is a situiation that should be avoided IMHO.

A decision needs to be made...

-- 
Bart



More information about the fpc-devel mailing list