ANSISTRING unter Linux verfügbar ???

[bernhard_LA]

wir verwenden in einer Unit den Datentyp ANSISTRING,
die Unit System ist eingebunden, allerdings will der compiler ANSISTRING nicht finden.... was mache ich falsch ?

[jaenicke]

AnsiString gibt es dort nicht, nein. Was es soweit ich mich erinnere gibt ist RawByteString.

Bist du sicher, dass du dort so etwas brauchst?

[mkinzler]

https://community.embarcadero.com/es...gs-for-nextgen

[Fritzew]

Was geht ist:

Delphi-Quellcode:

Var UniString : String;
    U8String : UTF8String;
    Raw : RawByteString;

[himitsu]

RawByteString und UTF8String sind doch auch AnsiStrings. :gruebel:
Gingen im NextGen eigentlich die ShortStrings auch nicht? (

Delphi-Quellcode:

ShortString

und

Delphi-Quellcode:

String[123]

)

Was aber immer gehen sollte, ist TEncoding und als TBytes (darin die Chars des ANSI)

[KodeZwerg]

Key Traits of the Coming Delphi For Linux Compiler

Zitat:

It is true, however, that some other string types like AnsiString are not supported. This is mostly a "Windows-centric" data type. If you are still using strings and PChar for managing generic data structures, it is really time to move to TBytes and PByte instead -- or enable pointer math for all data structures. Also the support for the old Pascal ShortString type is limited. Declaring a string [20] variable on Linux will fail. The other string type that is not supported is WideString. This is the old pre-Unicode non-reference counted UTF-16 type used for Windows COM platform integration. In fact, any COM-specific type and feature is missing on Linux, like on all other non-Windows Delphi platforms.

Notice that the TEncoding support is available, so you can read and write text files in any format you want. What you are not directly able to do is process an AnsiString in memory with the standard language support. But you can have an array of bytes (TBytes) representing text in any format in memory, and read and write it on disk, or receive and send via a socket connection, and you ca use the TEncoding support for conversions.

himitsu hat mal wieder voll ins schwarze getroffen:thumb:

[bernhard_LA]

Delphi-Quellcode:

type AnsiStringCrossPlatform = {$ifdef MSWINDOWS} ANsistring {$endif } {$ifdef LINUC} RawByteString {$endif }

also muss ich sowas kodiere, gibt's was besseres ?

[KodeZwerg]

Zitat:

Zitat von jaenicke (Beitrag 1404667)

Bist du sicher, dass du dort so etwas brauchst?

Das würde mich auch interessieren wofür man Windows String-Typen unter non-Windows benötigt.

[Uwe Raabe]

Zitat:

Zitat von KodeZwerg (Beitrag 1404775)

Zitat:

Zitat von jaenicke (Beitrag 1404667)

Bist du sicher, dass du dort so etwas brauchst?

Das würde mich auch interessieren wofür man Windows String-Typen unter non-Windows benötigt.

Auf die Frage haben wir ja bisher noch keine Antwort. Davon hängt allerdings entscheidend ab, welche Lösung man hier vorschlagen kann.

[Dennis07]

Zitat:

Zitat von bernhard_LA (Beitrag 1404774)

Delphi-Quellcode:

type AnsiStringCrossPlatform = {$ifdef MSWINDOWS} ANsistring {$endif } {$ifdef LINUC} RawByteString {$endif }

also muss ich sowas kodiere, gibt's was besseres ?

Kannst du so machen, wäre aber unsinnig.
1. gibt es RawByteString auch unter Windows und
2. ist RawByteString = PChar und
3. musst du diese deswegen stets unterschiedlich behandeln

Somit würde dir so etwas nichts an Aufwand einsparen, sondern deinen Code nur länger und unübersichtlicher machen.

[Uwe Raabe]

Zitat:

Zitat von Dennis07 (Beitrag 1404779)

2. ist RawByteString = PChar und

Da wäre ich mir jetzt nicht so sicher! PChar ist ein Pointer auf einen 2-Byte Char, während RawByteString aus 1-Byte Chars besteht (daher der Name). Man muss halt dann selbst wissen, welches Encoding in den Bytes steckt.

Ich bin aber überzeugt, daß es bessere und vor allem stabilere Lösungen gibt.

[p80286]

Zitat:

System.RawByteString







Up to Parent: System





Delphi


type RawByteString = AnsiString;

also nix Pchar...

Zitat:

Zitat von KodeZwerg (Beitrag 1404775)

Das würde mich auch interessieren wofür man Windows String-Typen unter non-Windows benötigt.

Wenn ich irgendwelche Daten verarbeite ist mir das Betriebssystem zunächst herzlich egal. Erst wenn es ins Spiel kommt mach ich mir Gedanken darüber, ob die von mir gewählte Struktur nativ vom BS verstanden wird.

Gruß
K-H

[KodeZwerg]

Zitat:

Zitat von p80286 (Beitrag 1404787)

Wenn ich irgendwelche Daten verarbeite ist mir das Betriebssystem zunächst herzlich egal.

Das klingt für mich mehr als doof. Ich fahr ja auch nicht an die Tankstelle und tanke "Sprit" sondern ich geh nach Anleitung des Herstellers (in dem Falle das OS) und tanke nicht "Sprit" sondern Diesel oder Benzin.

Ps: Ich will damit sagen, nur weil beides reinpasst bedeutet das nicht das beides funktioniert.

[mkinzler]

Nein. Das bedeutet, dass es solange er keine OS-Funktionen aufruft, egal ist wie das OS Strings verwaltet. Er interpretiert den Speicherinhalt als eine Zeichenkette, in der jedes Zeichen 1 Byte belegt.

[himitsu]

Zitat:

Zitat von bernhard_LA (Beitrag 1404774)

Delphi-Quellcode:

type AnsiStringCrossPlatform = {$ifdef MSWINDOWS} ANsistring {$endif } {$ifdef LINUC} RawByteString {$endif }

RawByteString ist ein AnsiString ohne CodePage, bzw. ohne automatische Konvertierung der Chars.

UTF8String ist ein AnsiString mit UTF-8 als CodePage (CP_UTF8)
Ich glaub es gab noch einen vordefinierten AnsiString mit CP_OEM, welchen man für Consolenanwendungen verwenden würde.

Und AnsiString ist halt ein AnsiString mit der aktuellen System-CodePage (ANSI).


Darum wäre ich auch davon ausgegangen, dass es unter NextGen den RawByteString ebenfalls nicht gibt.
Nicht RawByteString ist der Vorfahre sondern der ältere AnsiString, von dem RawByteString abgeleitet wird.

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1404801)

Nein. Das bedeutet, dass es solange er keine OS-Funktionen aufruft, egal ist wie das OS Strings verwaltet. Er interpretiert den Speicherinhalt als eine Zeichenkette, in der jedes Zeichen 1 Byte belegt.

Im Falle von AnsiString ist das eventuell schon von Bedeutung, da hier OS in direktem Zusammenhang mit dem Compiler steht. Der Linux-Compiler kennt keinen AnsiString und sowohl Linux- als auch Windows-Compiler behandeln RawByteString gleich.

Der Windows-Compiler verarbeitet aber AnsiString anders als RawByteString, auch wenn man keine OS-Funktionen aufruft. Eine Umstellung von AnsiString nach RawByteString kann also ein anderes Verhalten auslösen, erstmal unabhängig vom Zielsystem. Wenn dann aber über IFDEF unter Windows AnsiString und unter Linux RawByteString verwendet wird, hat man dieses unterschiedliche Verhalten eben abhängig vom Zielsystem, was zumindest die Fehlersuche erschweren könnte.

Da wir immer noch nicht wissen, wie aktuell die AnsiStrings unter Windows eingesetzt werden, kann man auch keine Aussage darüber treffen, ob RawByteString ein funktionaler Ersatz sein kann.

[mkinzler]

Meine Antwort bezog sich auf KodeZwergs Antwort.

[KodeZwerg]

Uwe hat schon irgendwie Verstanden wie ich es meinte, solange nichts vom TE kommt geb ich euch allen Recht, ich lag falsch und halte mich hier raus.

[bernhard_LA]

hier weitere Informationen zur Verwendung :
Ansistring wird in einigen DLLs verwendet um Daten von C++ , Matlab und Delphi auszutauschen , im reinen Delphi Kernprogramm in Funktionen wie im Beispiel

Delphi-Quellcode:

  
FS: TFileStream;
SaveString: Ansistring;

begin
  FS := TFileStream.Create(FileName, fmCreate);
  try
    if SaveString <> '' then
      FS.Write(Pointer(SaveString)^, Length(SaveString) * SizeOf(AnsiChar));
  finally
    FS.Free;
  end;

Ziel OS : entweder Windows x64 oder UBUNTU x64 , vermutlich sind die Daten meistens ASCII ...


ist diese Variante für Cross PLatform Daten typen klarer oder eher undurchsichtig ?

Delphi-Quellcode:

        type AnsiString = {$ifdef MSWINDOWS} Ansistring {$endif } 
                          {$ifdef LINUX} RawByteString {$endif }

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1404814)

Ansistring wird in einigen DLLs verwendet um Daten von C++ , Matlab und Delphi auszutauschen

Und mit welchem Datentyp arbeiten diese DLLs unter Linux?

AnsiString setzt immer auch ein Encoding voraus. Wenn man das nicht kennt, kann man die Bedeutung des Inhalts manchmal nur erraten.

Bei AnsiString kann man die zu verwendende CodePage angeben, wie z.B. hier:

Delphi-Quellcode:

const
  cEBCDICCodePage = 1141;

type
  EBCDICString = type AnsiString(cEBCDICCodePage);

Bei einer (auch impliziten) Zuweisung string <-> AnsiString wird diese CodePage für die Umwandlung verwendet. Damit werden dann Zuweisungen dieser Art vollkommen transparent vom Compiler erledigt:

Delphi-Quellcode:

var
  myString: string;
  myEBCDIC: EBCDICString;
begin
  myString := 'Hallo Welt'; // Unicode
  myEBCDIC := myString;     // Unicode -> EBCDIC

  myEBCDIC := 'Hallo Welt'; // Unicode -> EBCDIC
  myString := myEBCDIC;     // EBCDIC -> Unicode
end;

Fehlt die Angabe einer CodePage (z.B. bei Deklaration als AnsiString) wird die aktuelle CodePage von Windows genommen. Ohne Windows gibt es diesen Default aber nicht. Womöglich ein Grund für das Fehlen von AnsiString bei diesen Compilern.

Sollten Umwandlungen nicht vorkommen (was eventuell gar nicht so einfach herauszufinden ist), kann vielleicht alternativ RawByteString verwendet werden. In jedem Fall geht aber TBytes und bei der Umwandlung dann TEncoding verwenden. RawByteString ist also nur für einen Teil der Anwendungsmöglichkeiten geeignet, während TBytes immer geht. Daher würde ich TBytes den Vorzug geben.

[himitsu]

Zitat:

Zitat von bernhard_LA (Beitrag 1404814)

hier weitere Informationen zur Verwendung :
Ansistring wird in einigen DLLs verwendet um Daten von C++ , Matlab und Delphi auszutauschen , im reinen Delphi Kernprogramm in Funktionen wie im Beispiel

Delphi-Quellcode:

  
FS: TFileStream;
SaveString: Ansistring;

begin
  FS := TFileStream.Create(FileName, fmCreate);
  try
    if SaveString <> '' then
      FS.Write(Pointer(SaveString)^, Length(SaveString) * SizeOf(AnsiChar));
  finally
    FS.Free;
  end;

Ziel OS : entweder Windows x64 oder UBUNTU x64 , vermutlich sind die Daten meistens ASCII ...

Das riecht geradezu nach einem TStringStream.

[Rollo62]

Nicht das ich mit Ansi unter Linux was machen möchte, aber

Schonmal das gesehen, habs nicht gecheckt, könnte evtl. hilfreich sein.

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1404822)

Nicht das ich mit Ansi unter Linux was machen möchte, aber

Warum nicht?

UTF-8 ist im Prinzip auch nur ANSI, bzw. ein MultyByteCharset mit der Codepage 65001
und selbst Unicode ist ein MultyByteCharset mit fester Länge und der Codepage 1200, bzw. Big Endian mit der Codepage 1201.



Wie gesagt, man kann alles irgendwie selber machen, aber nativ und ohne große Umstände gibt es halt nur noch Unicode oder eben TEncoding. Dazu dann noch TStringStream, TStringList, IOUtils.TFile (ReadAllLines, ReadAllText, WriteAllLines, WriteAllText).

[Rollo62]

Zitat:

Warum nicht?

Die Umstellung auf Unicode war schon nervig genug, warum also wieder zurück :stupid:

Aber im Ernst:
Ja klar mache ich auch noch von Zeit zu Zeit mit 8-Bit Chars rum,
und ich nutze auch UTF-8 dafür, im Single-Byte-Modus.
Z.B. wenn ich Daten von kleinen Microcontrollern gesendet bekomme, oder aus alten DB.

Trotzdem achte ich bei neuen Strukturen auf UTF-8 (echte Unicodefähigkeit) wo immer möglich,
und werfe Altes über Bord.
Das gilt dann auch für Linux.

Rollo

[himitsu]

Gerade bei Dateien/Stream gibt es bei Multiplatform gern paar kleinere Problemchen.

z.B. nutzen im Windows viele Programme ANSI als Default, wenn eine Textdatei keinen BOM hat,
während im MacOS die selben Dateien aber per Default als UTF-8 behandelt werden wollen.

In Linux/Mac speicherst du UTF-8 und im Windows wird das als ANSI mit "komischen" Umlauten ausgelesen. :stupid:

[bernhard_LA]

@Uwe

also so dann :

Delphi-Quellcode:

 {$ifdef MSWINDOWS} 
         /// AnsiString = AnsiString  ... eh schon da  
         {$endif } 
         {$ifdef LINUX}  type AnsiString = TBytes;
         {$endif }

[jaenicke]

Warum benutzt du denn nicht einfach überall TBytes? Wenn du von Datenaustausch sprichst, hört sich das so nach Missbrauch von AnsiString als Datencontainer an.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1404856)

Warum benutzt du denn nicht einfach überall TBytes? Wenn du von Datenaustausch sprichst, hört sich das so nach Missbrauch von AnsiString als Datencontainer an.

:thumb:

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1404879)

Zitat:

Zitat von jaenicke (Beitrag 1404856)

Warum benutzt du denn nicht einfach überall TBytes? Wenn du von Datenaustausch sprichst, hört sich das so nach Missbrauch von AnsiString als Datencontainer an.

:thumb:

:thumb:
Wobei die älteren Delphis TBytes leider nicht zur Verfügung stellen.

Gruß
K-H

[KodeZwerg]

Zitat:

Zitat von p80286 (Beitrag 1404883)

Zitat:

Zitat von Uwe Raabe (Beitrag 1404879)

Zitat:

Zitat von jaenicke (Beitrag 1404856)

Warum benutzt du denn nicht einfach überall TBytes? Wenn du von Datenaustausch sprichst, hört sich das so nach Missbrauch von AnsiString als Datencontainer an.

:thumb:

:thumb:

:thumb:

Aber nen Array of Byte

[joachimd]

Zitat:

Zitat von jaenicke (Beitrag 1404856)

Warum benutzt du denn nicht einfach überall TBytes? Wenn du von Datenaustausch sprichst, hört sich das so nach Missbrauch von AnsiString als Datencontainer an.

weil evtl die Bibliothek nicht für Linux geschaffen wurde und konsequent AnsiString einsetzt? Ich hab vor etlichen Monaten mal versucht, die ADS Komponenten für Linux anzupassen und hab dann schliesslich aufgegeben, weil es überall AnsiString gibt und zu dem Zeitpunkt ich keine Möglichkeit (wie oben genannt) gefunden habe.

[jaenicke]

Zitat:

Zitat von joachimd (Beitrag 1404892)

weil evtl die Bibliothek nicht für Linux geschaffen wurde und konsequent AnsiString einsetzt? Ich hab vor etlichen Monaten mal versucht, die ADS Komponenten für Linux anzupassen und hab dann schliesslich aufgegeben, weil es überall AnsiString gibt und zu dem Zeitpunkt ich keine Möglichkeit (wie oben genannt) gefunden habe.

Die Logik verstehe ich nicht. :? Dabei hilft es doch auch nicht mit verschiedenen Aliastypen auf den verschiedenen Systemen zu arbeiten. Wenn man TBytes auf einer Plattform benutzt, dann kann man das auch gleich überall nutzen, da man die Anpassung dafür ja ohnehin machen muss.

Warum sollte man dann auf einer Plattform sauber mit TBytes arbeiten und auf der anderen (vermutlich noch mit IFDEFs gewürzt) bei einem unpassenden AnsiString-Container bleiben?

[joachimd]

Zitat:

Zitat von jaenicke (Beitrag 1404893)

Warum sollte man dann auf einer Plattform sauber mit TBytes arbeiten und auf der anderen (vermutlich noch mit IFDEFs gewürzt) bei einem unpassenden AnsiString-Container bleiben?

Weil seit 15 Jahren gewachsen, immer noch Delphi 3 unterstützt, und nicht mit jeder neuen Version neu geschrieben wird. Ich wollte eine schnelle Umsetzung testen - und die ist mit einem Define an zentraler Stelle einfacher als in zig Units per Find&Repülace wild rumzuspielen ;)

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1404883)

Wobei die älteren Delphis TBytes leider nicht zur Verfügung stellen.

Die unterstützen in der Regel (bis auf eine Ausnahme :P) aber auch kein Linux.

[p80286]

Z.B. für Konvertierungsaufgaben wäre es ganz schön gewesen.
Aber wer die alten Delphis noch in Betrieb hat wird die Klippen wohl kennen.

Gruß
K-H

[bernhard_LA]

wenn ich Ansistring jetzt durch TBtyes für LINUX ersetzen lässt sich diese Zeile nicht mehr kompilieren

Delphi-Quellcode:

    if SaveString <> '' then
      FS.Write(Pointer(SaveString)^, Length(SaveString) * SizeOf(AnsiChar));

wie lautet hier die Lösung um unter beiden Plattformen mit einer CodeVariante auszukommen ?
Geht es ohne weitere

Delphi-Quellcode:

$Ifdef

[jaenicke]

Zitat:

Zitat von bernhard_LA (Beitrag 1404947)

wie lautet hier die Lösung um unter beiden Plattformen mit einer CodeVariante auszukommen ?
Geht es ohne weitere

Delphi-Quellcode:

$Ifdef

Gar kein ifdef, nur TBytes auf allen Plattformen.

Das ist ja was ich geschrieben hatte... es macht keinen Sinn mit IFDEF verschiedene Typen zu nutzen. Denn du musst den Code ohnehin für TBytes anpassen und hast dann sauberen Code. Da macht es doch keinen Sinn per IFDEF unter Windows wieder auf unsauberen Code umzuschalten...

Beides unter einen Hut bekommen funktioniert nicht, weil TBytes nullbasiert ist, AnsiStrings aber 1-basiert. Ansonsten könnte man die Adresse des ersten Elements benutzen statt auf Pointer zu casten.

[KodeZwerg]

Zitat:

Zitat von bernhard_LA (Beitrag 1404947)

Delphi-Quellcode:

    if SaveString <> '' then
      FS.Write(Pointer(SaveString)^, Length(SaveString) * SizeOf(AnsiChar));

wie lautet hier die Lösung um unter beiden Plattformen mit einer CodeVariante auszukommen ?

Delphi-Quellcode:

procedure SaveBytesToFile(const Data: TBytes; const FileName: string);
var
  stream: TBytesStream;
begin
  stream := TBytesStream.Create(Data);
  try
    stream.SaveToFile(FileName);
  finally
    stream.Free;
  end;
end;

So vielleicht? In der Hoffnung es gibt mit Linux auch TBytesStream?

[CHackbart]

Als ich vor ein paar Jahren Synapse Android und iOS tauglich machen wollte, habe ich auch Rotz und Wasser geschwitzt. Da ist an allen Ecken und Enden mit Ansistring hantiert wurden und TMarshal.AsAnsi bzw. MarshaledAString schied für aus.
Vielleicht hilft dir ja meine damals verwendete Lösung: https://github.com/TetrisSQC/Synapse...e/synabyte.pas

Dabei fällt mir auf, dass ich teilweise noch "fehlerhafte" Fragmente wie:

Code:

 Stream.Write(MarshaledAString(TMarshal.AsAnsi(Value))^, Length(Value));
     {$ELSE}
  Stream.Write(PAnsiChar(Value)^, Length(Value));

drin habe. Das sollte ich mal bei Gelegenheit noch anpassen.

Christian

[himitsu]

Wie jaenicke es schon sagte, mach es so, wie es überall funktioniert und schmeiß alles Andere raus.

Zitat:

Zitat von bernhard_LA (Beitrag 1404947)

Delphi-Quellcode:

    if SaveString <> '' then
      FS.Write(Pointer(SaveString)^, Length(SaveString) * SizeOf(AnsiChar));

Aber grundsätzlich funktioniert auch dieser Code mit AnsiString und TBytes, wobei SizeOf(AnsiChar) überall passt, da ja überall ANSI drin ist,
und da es immer 1 ist, kann man es natürlich auch weglassen.

Delphi-Quellcode:

SizeOf(Byte)

ergibt das Selbe, ist aber nunmal sinnlos.

Und warum es beim IF mit dem Array nicht geht, sollte klar sein, was man auch über Length lösen könnte, oder man lässt es einfach weg und schreibt dann halt auch die 0 Bytes.


Nja, bezüglich TBytes würde ich dann natürlich auch die Überladung für TBytes verwenden, welches der TStream schon länger besitzt.


Und wie gesagt, es gibt alternativen wie TFile.WriteAll* und TStringStraem, mit denen man sich garnicht um die Straem-Behandlung kümmern muß.