Aber selbst in der
RTL ist nicht alles
Unicode und in anderen Sprachen ist es das auch nicht.
Lazarus ist z.B. an vielen Stellen UTF-8 und das ist auch
ANSI.
Andere Programmiersprachen kennen auch immernoch
ANSI.
Hatte doch nur ein paar uralte Delphi-Units (10 Jahre) und aktuelle C++-Header, die ich übersetzen wollte.
Der Hersteller liefert seine DLLs aber auch für
OS X und Android und schon war's das mit dem einfach nur Übersetzen, bzw. der eigene Wrapper wird immer schöner, da der Code auch noch unter XE laufen sollte.
Die übersetzten Header hab ich zumindestens zumindestens lösen können
Delphi-Quellcode:
{$IF Declared(PAnsiChar) and not Defined(NoANSI)}
TFeStr = PAnsiChar;
TFeChar = AnsiChar;
{$ELSE}
TFeStr = PByte;
TFeChar = Byte;
{$IFEND}
Und im Wrapper wird umständlich aus
AnsiString RawByteString erstmal ein TBytes.
Byte-Sequenzen ala
#123#27#0#235
kann man so natürlich auch nicht mehr verwenden, aber die paar Stellen lassen sich noch leicht ändern.
Wobei man
Bytes := (123, 27, 0, 235);
in älteren Delphis nicht nehmen kann und mit
Bytes := MakeBytes(123, 27, 0, 235); // MakeBytes(B: array of Byte)
blockiert man sich die neuen Features, aber egal. (die paar Bytes mehr, in den große EXEn, die paar Zeichen mehr im Quellcode und die paar zusätzlichen CPU-Zyklen, neben dem schnellen FMX fallen wirklich nicht auf)
Und warum ist sLineBreak noch ein AnsiChar? Das ist doch auch ein aktuelles Mittel der Wahl.
Gut, daß man keine Lust hatte einen AnsiString-Helper zu bauenn, vorallem da Vererbung bei Helpern nicht funktioniert, für die eigenen 3 AnsiString-Typen.
Und man keine Lust hatte die neuen StringFunktionen auch für
ANSI zu bauen, so seh ich dennoch keinen Grund den AnsiString abzuschaffen, vorallem da er nachweislich ja immernoch funkrioniert, auch im NextGen.
Es wird einfach alles nur umständlicher und sonst hat es
IMHO keine Vorteile.