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 ?
and:
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.
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
