Wie funktioniert RawByteString? (ab FPC 3.x)

[mschnell]

Und Linux Desktop kann man vernachlässigen.

Doppelter Blödsinn:

1) Linux Desktop funktioniert prima. Verwende ich täglich. Ich würde Windows sofort abschaffen, wenn ich nicht einige Programme benutzen müsste, die es für Linux nicht gibt. Standard-Zeug wir Mail, Browser, Termine, Office, .. geht unter Linux m.E. besser als unter Windows.

2) Pascal-Programmierung ist nicht unbedingt Desktip/GUI. Ich mache immer wieder "embedded" Programme mit Lazarus, meine Kollegen in der Firma haben ein riesiges "embedded" System mit Delphi geschrieben, wo im Betrieb beim Kunden die GUI und die Bindung an Windows nur Ärger macht. Ohne GUI und unter Linux würde es performanter, Ressourcen-schonender und billiger laufen.

-Michael

[Patito]

Code: Alles auswählen

Type TStringType = (stUTF8, stUTF16, stUnicode, stAnsiCP1233, ...];
End;

Was ich hier verwirrend finde ist was stUnicode sein soll? Ist das stUTF32 oder irgendein stDelphiUTF16?
Sowas wie UTF8ToUnicode klingt ja irgendwie tautologisch.

Noch ein paar mehr Fragen zum Thema:

Welchen Typ sollte man eingentlich verwenden wenn man z.B. UTF8 Daten aus einem Stream liest, aber ein paar Zeichen eventuell (wegen Übertragungsfehlern)
ungültige Zeichen sind?

Was macht man wenn man Daten hat, die aus ASCII + ein paar Bytes als Steuerzeichen bestehen.
(Barcodes; APIs zur Kommunikation mit irgendwelchen Geräten; diverse Datenaustausch-Standards(!), ...)

Bei z.B. sowas:

Code: Alles auswählen

 
EndOfSignal = #255;
test := 'DAT' + #17 + #0 + #2 + EndOfSignal; // ASCII Startkennung + Daten-Bytes + Ende
 

Wie sagt man den Konstanten welche Kodierung sie verwenden wollen? Braucht man da nicht noch irgendwas in der Sprache um den Konstanten sagen zu
können wie sie codiert sein sollen? Automatisch irgendeinen Typ zu raten geht hier mit sehr großer Wahrscheinlichkeit schief.

[mse]

Was macht man wenn man Daten hat, die aus ASCII + ein paar Bytes als Steuerzeichen bestehen.
(Barcodes; APIs zur Kommunikation mit irgendwelchen Geräten; diverse Datenaustausch-Standards(!), ...)

Bei z.B. sowas:

Code: Alles auswählen

 
EndOfSignal = #255;
test := 'DAT' + #17 + #0 + #2 + EndOfSignal; // ASCII Startkennung + Daten-Bytes + Ende
 

Dafür gibt es keinen Stringtypen mehr, stattdessen nehme man TBytes. Falls du solche Anwendungen hast, gehörst du nicht mehr zum Delphi-FPC Zielpublikum.
Ich übrigens auch nicht, darum habe ich mit der Entwicklung eines eigenen Kompiler begonnen.

Martin

[theo]

@patito & mse: Verstehe das Problem nicht. Es steht doch im Titel "RawByteString".
Bitte um Erklärung.

[mse]

@patito & mse: Verstehe das Problem nicht. Es steht doch im Titel "RawByteString".
Bitte um Erklärung.

Rawbytestring kann AFAIK nur als Prozedurparameter verwendet werden.

[theo]

Wie das?
Der ist so definiert:

Code: Alles auswählen

  RawByteString       = type AnsiString(CP_NONE);

wobei

Code: Alles auswählen

const
  CP_ACP     = 0;     // default to ANSI code page
  CP_UTF16   = 1200;  // utf-16
  CP_UTF16BE = 1201;  // unicodeFFFE
  CP_UTF7    = 65000; // utf-7
  CP_UTF8    = 65001; // utf-8
  CP_ASCII   = 20127; // us-ascii
  CP_NONE    = $FFFF; // rawbytestring encoding
 

aus rtl/inc/systemh.inc

Lazarus 1.1 r40260:41738M FPC 2.7.1 x86_64-linux-gtk 2

[mse]

Probier's halt.
Vielleicht hat es mittlerweile wieder geändert.

PS und edit: Delphi plant alle Stringtypen bis auf utf-16 UnicodeString abzuschaffen. Der neue string wird nullbasierten 16bit-Einheiten-Index haben und nicht mehr veränderbar sein ("immutable").

[Socke]

Welchen Typ sollte man eingentlich verwenden wenn man z.B. UTF8 Daten aus einem Stream liest, aber ein paar Zeichen eventuell (wegen Übertragungsfehlern)
ungültige Zeichen sind?

Als UTF-8 einlesen und die ungültigen Zeichen richtig behandeln; soweit ich weiß, wir das für UTF aber nicht vorgschrieben, du kannst also ein Ersatzzeichen (Bytewert, Fragezeichen etc.) oder gar nichts ausgeben -- je nach Anwendung.

Code: Alles auswählen

const
  CP_ACP     = 0;     // default to ANSI code page
  CP_UTF16   = 1200;  // utf-16
  CP_UTF16BE = 1201;  // unicodeFFFE
  CP_UTF7    = 65000; // utf-7
  CP_UTF8    = 65001; // utf-8
  CP_ASCII   = 20127; // us-ascii
  CP_NONE    = $FFFF; // rawbytestring encoding
 

aus rtl/inc/systemh.inc

Ich vermisse da UTF-16 Little Endian und Native Endian. So sieht es mir danach aus, als ob wieder implizit eine bestimmte UTF-16-Variante als Standard erhoben würde.

[theo]

Probier's halt.
Vielleicht hat es mittlerweile wieder geändert.

Ich will nicht sagen, dass ich den Durchblick hätte, aber ich verstehe nicht wo ihr in diesem Bsp. ein Problem seht.

Code: Alles auswählen

var test:RawByteString;     
..
test := 'DAT' + #17 + #0 + #2 + EndOfSignal; // ASCII Startkennung + Daten-Bytes + Ende

[Patito]

@patito & mse: Verstehe das Problem nicht. Es steht doch im Titel "RawByteString".
Bitte um Erklärung.

Für mich waren das erst mal nur ein paar Fragen zu konkreten Anwendungsfällen und noch kein Problem.

Ein Problem mit RawByteString wäre für mich eventuell, dass mir in der Sprach-Syntax
nicht klar ist wie ich die Konstanten richtig codiert bekomme.

Wie gesagt: Braucht man da nicht noch irgendwas in der Sprache um den Konstanten sagen zu
können wie sie codiert sein sollen? Wenn die Konstanten automatisch einfach irgendwie codiert sind,
geht das ganze vermutlich schnell schief.

Braucht man jetzt überall Typecasts, oder wäre da nicht eine praktischere Syntax möglich?
#17, 'ABC' für Byte/ASCII
#17U8, 'ABC'U8 für UTF8
#17U16, 'ABC'U16 für UTF16

In Delphi versucht der Compiler ja irgendwie zu raten und so ein #17 wird schon mal gern stillschweigend
beim compilieren von der System-Codepage (des Rechners auf dem der Compiler läuft) nach UTF-16 konvertiert.
Diese Raterei funktioniert zwar anscheinend (zumindest halbwegs) (für gültige Text-Zeichen).
Bei RawByteStrings wird es aber glaube ich schwieriger da etwas zu raten.

[theo]

Ich verstehe nicht ganz, worauf du hinaus willst.

WideString Konstanten in deinem Sinne kannst du z.B. so basteln:

Code: Alles auswählen

const WSConst= WideChar($E4)+WideChar($F6);

[mschnell]

Dazu kommt noch dass der FPC als nativ Compiler gedacht ist, mit dem man für alle möglichen Prozessoren ohne GUI ein Programm schreiben kann.

Ein Compiler hat mit einer GUI überhaupt nichts zu tun. Auch in Delphi, Eclipse und Visual Studio, ... ist der Compiler ein Kommandozeilen-Programm, das von der IDE aufgerufen wird.

Außerdem ist FPC nicht unbedingt als "nativer" Compiler gedacht. Er ist durchaus dazu gedacht und in der Lage "cross" zu kompilieren (der Compiler läuft auf einer CPU/OS Kombination, das übersetzte Programm auf einer anderen).

-Michael

[mschnell]

Delphi plant alle Stringtypen bis auf utf-16 UnicodeString abzuschaffen. Der neue string wird nullbasierten 16bit-Einheiten-Index haben und nicht mehr veränderbar sein ("immutable").

Super. Dann dürfen meine Kollegen ihre 1 Mio Codezeilen wieder mal von A bis Z überarbeiten. Ich hoffe nur, sie haben bei der letzten Änderung schon den Type "String" nicht mehr direkt in Variablen-Deklarationen verwendet, sondern sicherheitshalber immer nur noch einen selbstdefinierten Typ, von dem man zumindest weis, was er tun soll, und den man mit der Suchfunktion finden kann.

Die wievielte inkompatible Veränderung des Types "String" ist das ?

Wie viele inkompatible Versionen ist Lazarus inzwischen im Rückstand ?

-Michael

[theo]

Wie viele inkompatible Versionen ist Lazarus inzwischen im Rückstand ?

Wen interessiert's? Man muss ja nicht jeden Schei* mitmachen.

[mschnell]

Wen interessiert's? Man muss ja nicht jeden Schei* mitmachen.

Tja. Im Moment reißen sich die paar FPC Entwickler die Beine aus, um die fürchterlichen Strings von Delphi XE2 zu implementieren. Und Embarcadero schafft sie gerade wieder ab.

Ziemlich schräg.

-Michael