NextGen und ANSI

[himitsu]

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.