tstringlist.loadfromstream liest mehr ein, als es soll

[CCRDude]

Das wäre aber bugusing. Denn daß eine StringList nur bis #0 arbeitet, ist imho ein Bug. Der irgendwann gefixt werden kann, und dann sucht man den Fehler...

Heißt ja immerhin TStringList und nicht TPCharList

Leider hat die RTL/VCL einige wenige solcher Stellen, aber Embarcadero fixt sie, wenn bekannt. Zumindest habe ich mal den #0-End-Bug in StringReplace gemeldet und das QC-Ticket wurde sogar geöffnet (ob auch schon gefixt weiß ich gerade nicht mehr).

[Bummi]

lese tut sie alles, aber interpretiert wird nur bis zur #0, in den Zeiten von Unicode sollte man eh andere Wege bestreiten...

[DrUArn]

Hi,


@himitsu: Hatte mich in meinen eigenen Routinen verheddert. Du hast recht! #0 beendet den Lesevorgang. Sicherheitshalber noch mal die Frage: Wird dieses zusätzlich gespeichert #0 (a:=#0; astream.Write(a,sizeof(a))) beim Lesen (tstringlist.LoadFromStream(astream))mit einbezogen - also astream.position hinter dem #0 oder muß man beim Lesen nochmal astream.read(a, sizeof(a) nutzen, um weitere Daten ab der richtigen Stelle zu lesen. Beim Probieren meine ich zu merken, dass der Zeiger schon hinter dem #0 steht.

OK - ich denke der Zeiger muß hinter #0 stehen - denn erst muß tstringlist.LoadFromStream(astream) das #0 ja einlesen ehe das Lesen gestoppt werden kann!

@Bummi: Welche?

MfG Uwe

[Bummi]

du bist auch wenn #0 vorkommt faktisch am Ende des Streams .... es wird nur nicht mehr dargestellt

Delphi-Quellcode:

var
ms:TStringStream;

procedure TForm1.Button1Click(Sender: TObject);
var
 s:String;
begin
    s := '连接测试'+ #13#10 +'Test'+#0;
    ms.WriteString(s);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
   ms.Position := 0;
   ListBox1.Items.LoadFromStream(ms,TEncoding.Unicode);
   Caption := IntToStr(ms.Position) + ' - ' + IntToStr(ms.Size)
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
 ms := TStringStream.Create('',TEncoding.Unicode);
end;

Mir ist noch nicht ganz klar was genau Du vorhast, ich würde das was ich verstanden habe über eine Klasse mit einer Liste von Streams abfackeln, was hier für welche Ausgabe gebraucht wird lässt sich iontern gegf. über zusammenkopieren in neue Streams abfackeln.
Der Ansatz von Jaenicke könnte für Dich passen, auch Dein Ansatz mit Längenspeicherung innerhalb des Streams ist brauchbar, allerdings würde ich den von Komponenten zu ladenden Stream vorher in einen neues Extrahieren.

[himitsu]

Zitat von Bummi:

du bist auch wenn #0 vorkommt faktisch am Ende des Streams .... es wird nur nicht mehr dargestellt

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen Kompatibilität zum PChar.

Ein Delphi-String abeitet über eine Längenangabe und nicht über eine Endemarkierung.

Der einzige "Bug" ist, daß man nach dem Laden, über Add in eine TStringList Strings mit #0 einfügen kann.
Andere Stringlisten, wie z.B. die vom Memo (Lines) arbeiten dagegen anders und beachten indirekt die #0.

[DrUArn]

@Bummi: Wie am Start gesagt - 'ne Fingerübung - wollte nur ein allg. Object probieren, welches Daten in eine Stream speichert - also etwa ein Integer, einen String, ein Byte-Array und eben falls nötig - eine Stringliste.

Delphi-Quellcode:

procedure tstorepersistent_UA.writeotherdata(astream: tstream);
  var i:integer;
      a:char;
begin
astringlist.SaveToStream(astream);
a:=#0;
astream.Write(a,sizeof(a));

astream.write(F_int,sizeof(F_int));
astream.write(i,sizeof(i));
astream.write(pointer(astring)^,i);
astream.Write(f_maxblocksize,sizeof(f_maxblocksize));
astream.Write(abytearray^,maxblocksize);
end;

procedure tstorepersistent_UA.readotherdata(astream: tstream);
 var i:integer;

begin

astringlist.Clear;
astringlist.LoadFromStream(astream);

astream.Read(F_int,sizeof(f_int));
astream.read(F_char,sizeof(F_char));
astream.Read(i,sizeof(i));
SetLength(F_string,i div sizeof(char));
astream.Read(pointer(f_string)^,i);
FreeMem(abytearray);
astream.Read(F_maxblocksize,sizeof(maxblocksize));
getmem(abytearray,maxblocksize);
astream.Read(abytearray^,maxblocksize);
end;

Ohne eine Stringliste funktioniert das. Mit Stringliste kommt's zu Störungen.
Speichere ich z.B. obiges 2 mal und lade es auch 2 mal, dann ist die zweite geladene Stringliste leer (count=0) - womit Du wohl recht hast -das erste Lesen führt schon zum Ende des Streams, auch wenn irgendwo #0 steht und egal, ob ich die Liste am Anfang oder am Ende des Objects schreibe und lese - so sieht es jedenfalls beim Probieren aus.

Mfg Uwe

[Bummi]

@himitsu

Zitat:

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen Kompatibilität zum PChar.

ich habe es auch nie als Bug bezeichnet, sondern wollte nur darauf hinweisen daß man danach am Ende des Streams steht.

@DrUArn
jepp, aber da die Streams ja nicht das Problem sind kannst Du ja Exzerpte in die Stringlisten laden ...

[CCRDude]

Zitat von himitsu:

Das mit der #0 ist kein Bug, sondern Absicht (ein Feature), wegen [der] Kompatibilität zum PChar.

Wie schön. Ich argumentiere, daß Embarcadero das schon in anderen Fällen als Bug anerkannt und behoben hat und es daher ein Bug sein dürfte.

Du argumentierst, daß himitu meint daß es kein Bug wäre und damit ein Feature wäre, und bleibst ohne Belege.

Wem soll ich jetzt glauben?

Da ich aber eine Konkretisierung meines Belegs schuldig geblieben bin:
http://qc.embarcadero.com/wc/qcmain.aspx?d=60730

Auch die Delphi-Hilfe erwähnt eine angeblich erwünschte Kompatibilität in keinster Weise. Ich nehme hier mal AnsiString, weil der schon älter ist. Dort wird explizit der Support von MBCS/DBCS erwähnt, der aber mit PAnsiChar-Kompatibilität unmöglich wäre, weil PChar-kompatible String-Operationen auf MBCS-Texten in AnsiStrings dann jeweils nur ein Zeichen kopieren würden.
http://docwiki.embarcadero.com/VCL/en/System.AnsiString

Zitat von himitsu:

Ein Delphi-String abeitet über eine Längenangabe und nicht über eine Endemarkierung.

Genau. Und ist deswegen auch nicht kompatibel (wenn es um #0 geht), beziehungsweise sollte es nicht sein.

[DrUArn]

Hi,

@alle Diskutanten: Danke für Eure Beiträge, hat mir wieder ein (kleines) Stück geholfen, Delphi zu verstehen. Gelernt, dass man manchmal auch probieren muss, was eine Routine tut (@Bummi's letzter Beitrag). - Bloß habe ich dieses Verhalten von load/save..stream mehr zufällig bemerkt - sonst hätte ich wohl noch ein Stück weiter programmiert und mich später sehr gewundert.

Als nochmal Danke

mfG Uwe