[fpc-devel] Encoded AnsiString
Michael Van Canneyt
michael at freepascal.org
Mon Dec 30 13:25:12 CET 2013
On Mon, 30 Dec 2013, Paul Ishenin wrote:
> 30.12.2013 18:33, Michael Van Canneyt пишет:
>>> So how one can help at this stage:
>>> 1. Check related FPC tests and write new for the missing cases.
>>> 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi
>>> during the unicodestring move and check whether something minor can be
>>> added to FPC.
>>> All major changes like the new TStringList class based on UnicodeString
>>> should wait for 2.8 release.
>> I don't think that this is a good idea, it means that e.g.
>> TStrings.SaveToFile() or TFileStream.Create() is still crippled. Better
>> bite the bullet. This is what I wanted to test in feb/march.
> This will also mean that we will release 2.8 much later (looking at cpstr
> development speed probably few years later) because together with this
> implementation we need to solve ansi/unicode RTL problem (dotted unit names
> in RTL and packages).
> Imo it is better to release all that huge changes we have in trunk as is
> (maybe together with resourcestring solution). Then with the following minor
> releases we improve dotted unit names support (like default namespaces)
> together with experiments for ansi/unicode RTL.
I think I understand what you want to say:
Release the codepage strings support with the RTL as-is.
But the "experiments for ansi/unicode RTL" are already in trunk.
Do you plan to take them out ?
What good is having the unicode string support if none of the classes or
units make use of it ? No-one will test it or even be able to test it because
none of the base classes/routines are adapted to it.
More information about the fpc-devel