[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 mailing list