PokeS() PeekS() sicher mit Null-Ende oder Länge angeben

[STARGÅTE]

Tachchen,

ja ich muss nun mal eine sehr anfängermäsige Frage stellen

In der hilfe zu PeekS() steht ja:

Der String sollte mit einem '0' Zeichen enden (Null-terminierter String), andernfalls wird der Speicher solange ausgelesen, bis ein '0' Zeichen auftritt.

Kann ich also sicher sein, dass wenn ich meherere Strings hintereinander in einen Speicher schreibe (PokeS) welche immer mit einer Null getrent sind (PokeC(*Buffer, 0)), dass dann später beim auslesen wirklich wieder der exakte Strins ausgelesen wird ?

Denn bei ReadString() im bei Files ist das ja ledier nicht der fall.

Liest einen String aus der '#Datei', bis ein 'End Of Line' (deutsch: "Ende der Zeile") Zeichen gefunden wird

Dort kann ich also durchaus einen String schreiben, er würde dann aber mehrere ReadStrings brauchen wenn der String dieses EoL hat (LF, CR, irgendwas davon ^^)

Sollte man nun lieber gleich einheitlich auf Nummer sicher gehen und auf die String sachen verzichten, und statt dessen mit
CopyMemory() bzw WriteData arbeiten und im Speicher/Datei immer zuerst eine Long schreiben mit der Länge in Bytes des Strings und dann "per Hand" den StringInhalt kopieren, sodass beim lesen wirklich 100% sicher gegangen werden kann dass alles wieder so wird wie es war ?

[7x7]

Der String sollte mit einem '0' Zeichen enden (Null-terminierter String), andernfalls wird der Speicher solange ausgelesen, bis ein '0' Zeichen auftritt.

Tja, wenns so da steht, dann wird es wohl so sein.

Aber wenn du sowieso ein eigenes Stringmanagment verwenden möchtest, ist die gespeicherte Länge auf jeden Fall mal hilfreich für evtl. andere Stringoperationen

[NoUser]

Kann ich also sicher sein, dass wenn ich meherere Strings hintereinander in einen Speicher schreibe (PokeS) welche immer mit einer Null getrent sind (PokeC(*Buffer, 0)), dass dann später beim auslesen wirklich wieder der exakte Strins ausgelesen wird ?

Ich würde mal sagen Ja. Bei Unicode sollten es aber glaube ich zwei Nullen am ende des Strings sein. Angabe ohne Gewähr.

[STARGÅTE]

@marroh
Jo, klar deswegen ja PokeC(*Buffer, 0), das ist ja je nach Art 1 oder 2 Bytes

[Josh]

Kann ich also sicher sein, dass wenn ich meherere Strings hintereinander in einen Speicher schreibe (PokeS) welche immer mit einer Null getrent sind (PokeC(*Buffer, 0)), dass dann später beim auslesen wirklich wieder der exakte Strins ausgelesen wird ?

wenn du zu wenig speicher allociert hast, dann kann deine null überschrieben werden. ansonsten würde ich sagen, dass du dir sicher sein kannst. ich würde nichts eigenes machen, da der aufwand nicht dafür steht.

solltest du es aber doch machen wollen, würde ich gleich auf basis von bstrings machen, wo der long wert vor dem gespeicherten pointer steht. bstrings würden ja theoretisch keine null zum terminieren brauchen, so einen fall habe ich aber bis jetzt noch nie gefunden.

[Fluid Byte]

Tachchen,Kann ich also sicher sein, dass wenn ich meherere Strings hintereinander in einen Speicher schreibe (PokeS) welche immer mit einer Null getrent sind (PokeC(*Buffer, 0)), dass dann später beim auslesen wirklich wieder der exakte Strins ausgelesen wird ?

Ja.

Denn bei ReadString() im bei Files ist das ja ledier nicht der fall.

Doch, doch

Code: Alles auswählen

CreateFile(0,GetTemporaryDirectory() + "test.txt")
WriteString(0,"GUTEN") : WriteByte(0,0)
WriteString(0,"TAG") : WriteByte(0,0)
WriteString(0,"!") : WriteByte(0,0)
CloseFile(0)

ReadFile(0,GetTemporaryDirectory() + "test.txt")
Debug ReadString(0)
Debug ReadString(0)
Debug ReadString(0)
CloseFile(0)

[NoUser]

@marroh
Jo, klar deswegen ja PokeC(*Buffer, 0), das ist ja je nach Art 1 oder 2 Bytes

Wo Du recht hast, hast Du recht. Habe das PokeC(*Buffer, 0) (also Char) überlesen.