ANSISTRING unter Linux verfügbar ???

[bernhard_LA]

type AnsiStringCrossPlatform = {$ifdef MSWINDOWS} ANsistring {$endif } {$ifdef LINUC} RawByteString {$endif }
also muss ich sowas kodiere, gibt's was besseres ?

[Dennis07]

Zitat von bernhard_LA:

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 von Dennis07:

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 von KodeZwerg:

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 von p80286:

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.

[Uwe Raabe]

Zitat von 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.

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.

[himitsu]

Zitat von bernhard_LA:

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.