string mit postmessage übermitteln?

[nahpets]

Zitat von himitsu:

Ratet mal, wie intern ein LongString (String, AnsiString, UnicodeString) und auch WideString aufgebaut sind .... Verwaltungsdaten+DemText+#0#0

Langsam hab' ich den Eindruck, ich werd' (oder bin) doch zu alt, um da noch mitzukommen

Heißt das dann, dass hierbei cGETSOURCEFILES :string= 'get source Files'+#0; wir eigentlich ein 'get source Files'#0#0#0 haben und mit PChar dann noch ein #0 dazuhängen und damit dann ein 'get source Files'#0#0#0#0 dabei rauskommt?
Oder kapiert der Kompiler das und macht es von alleine "richtig"?

Und wenn wir schon PChar-Konstanten haben möchten, dann können wir die doch eigentlich auch als PChar deklarieren:

Delphi-Quellcode:

  cFILEDELETION : PChar = 'Deletion of Files';
  cGETSOURCEFILES : PChar = 'get source Files';
  cGETTARGETFILES : PChar = 'get target Files';

Mein olles Delphi 7 frisst das jedenfalls. Oder denke ich jetzt hier um zuviele, altbackenen, Ecken?

[p80286]

Ich meine mich zu erinnern, daß Strings (abgesehen von den Shortstrings) eigentlich aufgemotze PChars sein sollen, aber da ich diesen #0Trailer nach Möglichkeit ignoriere - wofür gibt es die Länge?- gerät das immer wieder in Vergessenheit.

Warum sollte ich in einem Delphi-Programm Konstanten denn als PChar deklarieren?
Aber im Prinzip hast Du recht, da eh nur die Adresse weiter gereicht wird, kann man's auch gleich richtig machen.

Gruß
K-H

[himitsu]

Nein, es sind keine aufgekotzten PChars.
Es sind aufgemotzte dynamische Char-Arrays. array of char

Delphi verwendet die Längenangabe, aber als Kompatibilität zeigt der interne Pointer nicht auf den Anfang der Steuerdaten, sondern dahinter, und hinter dem letzten Zeichen werden im Speicher noch zwei #0 abgelegt.
So kann der String-Pointer direkt als PChar verwendet werden (zum Lesen).

Der ShortString (der String aus Delphi 1 und davor) ist ein Record, mit einem LängenByte und drauf folgenden Chars.
Char 1 war auf BytePosition 1 und das Längenbyte auf BytePosition 0 ... darum sind Strings auch mit 1 indexiert, obwohl dort das erste Char auf BytePosition 0 liegt
und die Steuerdaten (Länge, Refernzzählung und seit 2009 auch CharSize und CodePage) davor liegen.