allgemeine Pointer Frage

[p80286]

ich hab's mir so gemerkt:
Zeiger:=Adr(variable); oder
wie Himitsu es ausgeführt hat
Zeiger:=@Variable; der Zugriff erfolgt dann über
TIrgendeinTyp(Zeiger^) wichtig ist nur Zeiger enthält nur die Adressinformation, der eigentliche Wert ist in Zeiger^ Gruß
K-H

[Jonas Shinaniganz]

Mir stellt sich da spontan die Frage:

http://www.delphi-treff.de/tutorials...tei-speichern/

Wieso ein Typecast auf PChar um dann den Pointer zu dereferenzieren?

Stream.Write(PChar(Daten[I].Name)^, Len);
kann man da nicht einfach

Code:

Daten[I].Name

übergeben?

grüße

[DeddyH]

Lies doch einfach mal 3 Sätze weiter

[Jonas Shinaniganz]

ah

Okay, ich hatte folgendes gemacht:

Wenn myarray[I].mystring mir nur die SpeicherAdresse in den STREAM schreibt dann kann Ich doch myarray[I].mystring^ direkt dereferenzieren oder?

Dann gibts aber den Compilerfehler "Zeigertyp erforderlich". Dann Casten wir den String als PChar und dereferenzieren dann, wieso ist dann kein "Zeigertyp erforderlich"?

Grüße

[himitsu]

Ein "LongString" ist halt intern ein Zeiger.

Man könnte nun str[1] übergeben, oder PChar(str)^ , nur daß Ersteres knallt, wenn der String leer ist, wärend PChar im Falle eines Leerstrings (intern nil) einen Zeiger auf einen alternativen "leeren String" zurückgibt (also einen "String" aus #0 bestehend, bzw. genauer aus #0#0)

Zitat:

Wenn myarray[I].mystring mir nur die SpeicherAdresse in den STREAM schreibt dann kann Ich doch myarray[I].mystring^ direkt dereferenzieren oder?

Du hast das jetzt in einer Datei gespeichert ... ja, dann kannst du das "jetzt" auch wieder dereferenzieren,
aber lies die Datei mal morgen wieder aus (abgesehn davon, daß du dir dann beim Auslesen des "Zeigers" die automatische Speicherverwaltung des Strings zerschossen hast)

Deswegen gibt es ja auch spezialisierte Streams, welche direkt mit Strings umgehen können.
TStringStream, TReader, TWriter, TStringList uvm.

[Jonas Shinaniganz]

Okay bevor ich weiter leichtfertig Fragen stelle merke ich grade, da sind noch ein paar nette Sachen zu lernen.

Ich verstehe z.b. nicht warum in dem Tutorial LongInt genommen wurde und kein Integer. Oder warum es mit AnsiChar funktioniert aber falls ich aus dem Datentyp einen normalen String mache, nicht mehr richtig...

Das mit dem Str[1] leuchtet ein.

danke

[p80286]

Vielleicht weil der autor damit betonen wollte, daß es sich um eine 32bit-Zahl handelt.
Ich würde dann ein longword bevorzugen, weil dann das Vorzeichen ausgeschlossen ist, aber über die Typen kann man trefflich streiten.

Gruß
K-H

Zitat von Jonas Shinaniganz:

Oder warum es mit AnsiChar funktioniert aber falls ich aus dem Datentyp einen normalen String mache, nicht mehr richtig...

was meinst du da ganz konkret?
einen "normalen" String gibt es nicht!

[DeddyH]

Bevor wir hier langatmig erklären, verweise ich aus Faulheit auf den Hersteller

[himitsu]

LongInt: Damals, als dieses tutorial geschrieben wurde, war Integer noch ein dynamischer Typ, bzw. ein Alias. (in Win 3.1 war er 16 Bit, in Win32 war er 32 Bit und in Win64 wäre er 64 Bit gewesen).

Nun war nur jemand auf die saublöde Idee gekommen den Integer einzufrieren (das war mal nicht Emba ... die sind C++ nur um Jahre verspätet nachgelaufen)
und stattdessen wurd jetzt der NativeInt erfunden.

Beim Speichern oder Datenübertragen sollte man aber grundsätzlich nur generische Typen verwenden, also Jene, welche sich niemals verändern.
Einfaches Beispiel, welches sei 2009 immer wieder für Probleme sorgt, ist der Char, String, PChar usw.), wenn man das früher mit "ANSI" gespeichert hatte und nun versucht als Unicode auszulesen, dann muß das schief gehn.
Oder eben die Verwendung von APIs ... wenn da Einer das als ANSI übergibt oder auslies und der Andere aber Unicode nutzt, dann paßt das ebenfalls nicht zusammen und keiner versteht was der Andere sagt.

[p80286]

Und da wundern sich manche, daß Pointer gerne gemieden werden.

Gruß
K-H