NextGen und ANSI

[himitsu]

Ich weiß, irgendein Trottel Irgendjemand ist auf die geniale Idee gekommen und hat das dort entfernt.

Nun hat man aber z.B. eine in C++ geschriebene DLL/SO, welche mit AnsiStrings arbeitet.
Type = unsigned char, also eigentlich PAnsiChar

Ohne AnsiStrings und PAnsiChar-Castes und natürlich auch die AnsiChars in den Records wird die ganze Angelegenheit doch echt besch...eiden zu benutzen.


Also ganz im Ernst, warum um Himmels Willen sind die nun auf diese Idee gekommen das zu verstecken, wo sie doch intern selber mit AnsiStrings arbeiten, weil sie es auch nicht besser hinbekommen (siehe die sLineBreak, AssignFile, WriteLn, TTextBuf, TTextRec, UpCase, _FillChar, StringOfChar, GetDir/_UGetDir usw.) und alles Anderes einfach nur noch umständlicher wird, wenn man da mit TEncoding ran muß
und wieso macht man das nicht einfach wieder rückgängig?

[Daniel]

Ganz einfach: Es gibt auf den vom NextGen-Compiler adressierten Plattformen keine ANSI-Strings. Da kannst Du hundert Mal von "Trotteln" reden oder Deinen Lieblings-Smiley nutzen, der seinen Kopf an die Wand schlägt. Ungeachtet der Tatsache, dass es noch Spezialfälle gibt, besteht unsere Welt im Jahr 2015 aus Unicode.
Wenn Du mit einfachen Zeichenfolgen zutun hast, sind das nicht mehr als Array of Bytes, die Du nach Belieben interpretieren kannst. Die von Dir genannten Funktionen wie AssignFile() oder WriteLn() sind wohl aus historischen Gründen noch vorhanden, aber auf allen von NextGen bedienten Plattformen nicht mehr Mittel der Wahl. Da nimmt man einfach Streams.

[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.

[mkinzler]

Es ist doch unerheblich ob Lazarus und andere Programmiersprachen ANSI können. Auf den mobilen Plattformen wird im Normalfall Unicode verwendet.

[himitsu]

Es ist so aber schwieriger/umständlicher, Funktionen zu sharen, wenn es praktisch keine kompatiblen äquivalenten Typen mehr gibt, mit welchen die Bibliotheksschnittstellen deklariert sind.

Es gab mal Zeiten, da haben Hardwarehersteller auch Pascal-Units für ihre DLLs ausgelefert, aber irgendwie haben viele in den letzten 5-10 Jahren damit aufgehört.
(OK, da liegt es oftmals eher am fehlenden Delphi und daß Delphi ja bekanntlich ausstirbt )

Bei der betreffenden Komponente ist es wirklich so, daß 2005/2006 das letzte Mal was an den Pascaldateien gemacht wurde.
Nur 2011 ist in einer der Dateien noch schnell ein Kommentar reingekommen "Achtung, bei XE muß PChar in PAnsiChar geändert werden".
Und ansonsten stellen die C++-Entwickler die noch Headerdateien ihrer DLLs vorallem nur für Visual Stutio (C/C++) bereit, wobei selbst ein halbwegs aktuelles Visual Basic dabei ist.
Die Unterstüzen ja fast alles
* Visual Studio, Borland C++ Builder, Embarcadero C++ Builder, eMbedded Visual C++ 4, Visual Studio 2005/2008/2012, GCC (Linux/Mac OS X), Xcode
* Windows XP/Vista/7/8, Windows CE, Linux, Mac OS X, Android
* 32 und 64 Bit
nur Unicode-Only ist irgendwie sonst fast nirgendwo anzutreffen

Bei anderen Firmen war das auch schon zu beobachten.

[mkinzler]

Der String von iOS ist UTF-16 (alternativ UTF-8). Der String unter Android ist auch UTF-16.

Wenn Du trotzdem mit Ansi arbeiten will nimm den "Patch" von Andreas.

Wenn Du den Hersteller zu einer Meinungsänderung bewegen willst ist die DP auch der falsche Ort. Beschwer Dich direkt bei den Verantwortlichen ( Marco, David, ...)

[himitsu]

Wir wollten die Dateien dann dem Hersteller geben und da würde ich ungern einen Patch drin lassen wollen.
Welcher auch noch nur für die eine Compilerversion funktioniert. (er kann ja nur DCUs liefern)

[himitsu]

Beispiel an einer kurzen Methode:

Delphi-Quellcode:

procedure FETCP_CheckError(iErrorCode: Integer);
var
  Temp: array[0..255] of AnsiChar;
begin
  if iErrorCode < 0 then
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) < 0 then
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress
    else
      raise Exception.CreateFmt('%s', [iErrorCode, string(Temp)]) at ReturnAddress;;
  end;
end;

Was Delphi früher mal alles automatisch machte, darf man jetzt selber machen.

• Speicher reservieren
• das Ende des PAnsiChar suchen
• den String kopieren und nach Unicode umwandeln

Delphi-Quellcode:

procedure FEUSB_CheckError(iErrorCode: Integer);
var
  Temp: TBytes;
  Len:  Integer;
begin
  if iErrorCode < 0 then begin
    SetLength(Temp, 256);
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) >= 0 then begin
      Len := 0;
      while (Len < 256) and (Temp[Len] <> 0) do
        Inc(Len)
      raise Exception.CreateFmt('%s', [iErrorCode, TEncoding.Default.GetString(Temp, 0, Len)]) at ReturnAddress;  // Default heißt jetzt ANSI, was im Grunde auch besser ist, aber XE kennt es noch nicht
    end else
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress;
  end;
end;

Gut, es ginge bestimmt auch so, aber wer weiß, ob sich TEncoding nicht an der #0 und den "ungültigen" Zeichen verschluckt.
Der statische Record geht auch nicht mehr, da die Pointer-Funktionen vom TEncoding im Strict-Protected versteckt sind und ich keine Lust hatte mir das erst freizuschalten, also alles immer schön in den langsamen Speichermanager, anstatt mal eben schnell auf den Stack.

Delphi-Quellcode:

procedure FEUSB_CheckError(iErrorCode: Integer);
var
  Temp: TBytes;
begin
  if iErrorCode < 0 then begin
    SetLength(Temp, 256);
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) >= 0 then 
      raise Exception.CreateFmt('%s', [iErrorCode, PChar(TEncoding.Default.GetString(Temp))]) at ReturnAddress;
    else
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress;
  end;
end;

Ich dachte mal, es würde mit der Zeit leichter werden, da die RTL Einem immer mehr Arbeit abnimmt.

Oder hab ich was übersehn?