Pointerübergabe und Changecurrentelement

[Danilo]

Probleme gibts dann nur wie in dem obigen von dir aufgeführtem Beispiel,
wenn die Strukur eine Variable p.l und einen Pointer *p beinhaltet :]

Sowas wird aber niemand programmieren, da es -wie gesagt-
auch jetzt nicht funktioniert.
Man kein "*p" und "p" zusammen in einer Struktur verwenden,
da immer das Erste der beiden als "p" genommen wird.

[Ynnus]

Wo ist das Problem, wenn man, anstelle eines Pointers zu erstellen, einfach eine Long-Variable in der Structur nimmt und in dieser den Adresswert speichert? Es muss ja nicht als Pointer (mit sternchen) deklariert werden sondern nur als normale Variable. Wenn man jetzt mit diesen Arbeitet, etwa mit ChangeCurrentElement oder per CallFunctionFast macht es doch dem Compiler nix aus ob man da korrekte Pointer mit "*" angibt oder Variablen, sie müssen nur jeweils die Speicheradresse beinhalten. Und das ist bei Long-Variablen doch auch möglich, wo besteht dann das Problem?

[Lars]

wo besteht dann das Problem?

Dass bei manchen Anwendungen ein "echter" Pointer schon ziemlich
praktisch ist. Über einen Pointer kannst du direkt Poke/Peek Befehle
ausführen, ohne noch die PB Befehle aufzurufen.

Code: Alles auswählen

String.s = "Hello World!"
*pointer.BYTE = @String

While *pointer\b
  Debug Chr(*pointer\b)
  *pointer + 1
Wend

Das ist jetzt nicht noch in eine Struktur eingebaut, aber den Zweck kann
man sich denken

[Ynnus]

Durch eine Long-Variable mit Speicherinhalt kann auch aber auch Peek und Poke ausführen:

Code: Alles auswählen

Variable.w = 12345
long_pointer.l = @Variable

Debug "Wert: " + Str(PeekL(long_pointer))
Debug "Adresse: " + Str(long_pointer)

Da besteht also kein Unterschied, ob man nun einen Pointer oder "nur" eine Variable mit Speicheradresse nimmt.

EDIT: Hab mit dein Codebeispiel zu spät angesehen. Ok, das ist zwar ein kleiner Vorteil, aber kaum umständlicher als mit Poke und Peek.

[NicTheQuick]

Ein Vorteil besteht dann darin, wenn man bspw. eine LinkedList programmiert oder sowas.
Hier ein blödes Beispiel:

Code: Alles auswählen

NewList Hallo.l()

Structure LL
  *pNext.LL
  *pPrev.LL
  Value.l
EndStructure

For a.l = 1 To 10
  If AddElement(Hallo()) : Hallo() = a : EndIf
Next

If FirstElement(Hallo())
  *dummy.LL = @Hallo() - 8
  Debug *dummy\pNext\pNext\pNext\Value ; Sollte '4' ausgeben.
EndIf

So und jetzt mach das ganze mal mit [c]PeekBWLF()[/c] und [c]PokeBWLF()[/c].

[Danilo]

EDIT: Hab mit dein Codebeispiel zu spät angesehen. Ok, das ist zwar ein kleiner Vorteil, aber kaum umständlicher als mit Poke und Peek.

Dann könnte man doch gleich die Pointer ganz aus PB herausnehmen,
wenn man alles über Peek/Poke machen kann.

So zu argumentieren ändert nichts daran das es nicht
ordentlich funktioniert.

Du kannst auch ein Long in der Struktur speichern und
dann über einen anderen Pointer darauf zugreifen:

Code: Alles auswählen

Structure xyz
  p.l
EndStructure

a.xyz
a\p = @i

*p.LONG = a\p
*p\l = 12

Debug i

Die 2 Zeilen mit dem Pointer *p ersetzen hier das direkte
"a\*p\l = 12", wenn man in der Struktur den Pointer *p.LONG
benutzen könnte.

Viele Programmierer benutzen sowas z.B. für LinkedLists:

Code: Alles auswählen

Structure MyList
  data1.l
  data2.l
  data3.s
  *prevelement.MyList
  *nextelement.MyList
EndStructure

So kann man eben direkt über den Pointer auf Strukturen
zugreifen, anstatt sich erst den Pointer mit PeekL() zu holen
und dann über einen richtigen Pointer darauf zuzugreifen.

Mit Pointern finde ich es vor allem auch übersichtlicher und
leichter zu lesen, als irgendwas mit PokeL(PeekL(p+16), 12).
(Ein Bekannter von mir codet dauernd so, und ich weiß nie
was der dort gerade macht - muß erst alles auseinandernehmen)