Guck dir mal Kapitel 7.7 an:

www.fh-jena.de/~gmueller/Kurs_halle

Ist zwar nicht groß, aber immerhin.

danke
irgenwie kann ich mir den vorteiel von Pointern immer noch nicht so klar vorstellen

Hallo

Ok, machen wirs einmal anders: Wieso siehst du den Vorteil nicht?
Bzw. was erscheint dir den Unvorteilhaft an Pointern?

Grüsse

warum soll ich nun in meinemn programm Pointer verwenden ?
wenn es auch anders geht ?

Zeiger zu verwenden ist kein Muss sondern eine Alternative. Was man ohne Zeiger erledigen kann, sollte man auch ohne machen.

Du wirst um einen Integer zu deklarieren doch nicht so vorgehen wollen:

ist doch viel zu umständlich, also warum soll ich bzw. kann ich nun pointer verwenden ?

Genau.
Es macht Sinn, Pointer zu verwenden, wenn das Programm schnell laufen soll und möglichst wneig Speicher verbrauchen soll.
Anstatt 10MB an Array-Daten hin- und herzuschaufeln, übergibst du Prozeduren einfach einen Pointer, der ist 4 Byte lang und past in die Westentasche. Das geht schneller und braucht weniger Speicher.
Es ist einfach eine Frage des guten Programmierstils, Pointer zu verwenden, wo sie Sinn machen, weil Windows nunmal Multitasking unterstützt und man nicht mit eigenen PRogrammen den ganzen Speicher für sich beanspruchen soll.

Und noch ein Beispiel fällt mir ein, weil ich es grad' selber implementiere *g*
Listen!
Da wie wir alle wissen bei linearen Listen (z.B. Arrays, Strings o.ä.) die Objekte alle zusammenhängend in einem Speicherbereich sein müssen, was beim verlängern des Arrays zu Speichermanagementproblemen führt, kann man mit Pointer das Ganze einfach umgehen.
Das Prinzip der doppelt (oder auch einfach) verketteten Listen baut nämlich auf Pointer auf. Jeder Pointer enthält Daten und zusätzlich einen Zeiger auf den jeweils nächsten Eintrag in der Liste. Damit hat man wie auf einer Kette alle Perlen aneinander und kann durch einfaches abzählen zu einem Eintrag gelangen. Die Pointer ermöglichen es hier, die Daten an einem beliebigen Platz im Speicher zu speichern und dort auch wieder vollständig freuzugeben (New und Dispose), ohne daß man an der Kette an sich etwas merkt. So muss der Datenraum nicht zusammenhängend sein, obwohl es den Anschein macht, als wäre er dies.
Das ganze würde ohne Pointer überhaupt nicht funktionieren, hier muss man sie also einsetzen, oder eben ganz auf die Funktionalität verzichten.

Nachdem du anscheinend noch immer Schwierigkeiten hast den Sinn von Pointern zu verstehen hier eine etwas ausführlicheres Beispiel:

Kennst du die VirtualTreeView-Komponente? Falls nicht hier eine kurze Beschreibung: die VirtualTreeView-Komponente ist eine komplett selbstständige Implementierung eines Treeviews und basiert weder auf der VCL noch auf der Windows-Klasse. Die Kompo ist sehr schnell und äußerst flexibel.

Woher kommt nun die Flexibilität dieses TreeViews? Ganz einfach.. jede Node besteht nur aus der internen Struktur und ansonsten einfach nur aus einem Pointer. Zu Programmstart (oder schon zur Entwicklunszeit) gibt man an wieviel Speicher für jede Node reserviert werden soll. In diesem Reservierten Speicherplatz kann man nun Daten ablegen -> jede Node hat ihren Speicherblock mit ihren Daten. Im Allgemeinen verwendet man einfach einen Record und initialisiert die NodeData-Größe mit der Größe des Records. Man kann aber noch eine Stufe tiefer gehen.. was ist, wenn ich völlig verschiedene Nodes hab und für die verschiedenen Nodes verschiedene Records benötige? Ganz einfach.. ich deklariere einen Set welche verschiedenen NodeTypen es gibt:

und einen allgemeinen Record:

und dann noch die verschiedenen Records für die verschiedenen Typen.

Also NodeData-Größe wird dann einfach die Größe des allgemeinen Records angegeben und je nachdem was für eine Node du erzeugst setzt du das aNodeType-Feld, allozierst den nötigen Speicher und schreibst die Adresse das Speicherblocks in pData. Und schon hast du ein absolut flexibles System!

Und falls du noch immer nicht genug hast : die nächste Version meines X-Spy arbeitet mit dyn. Bindung von Objekt-Eigenschaften an VirtualTreeView-Columns und je nachdem welche Objekt-Eigenschaften als VirtualTreeView-Column sichtbar sein sollen müssen dementsprechend die Informationen über die Klasse geholt werden und in einem dyn. erzeugen record gespeichert werden.
D.h.:

• Informationen über die Objekt-Felder per RTTI holen (jede Menge Pointer)
  
• Die Tag-Felder der Columns enthalten einen Pointer auf eine Liste der Objekt-Eigenschaften die sie verwalten (also die in dieser Column angezeigt werden sollen) welche auch wieder nur Pointer auf Records sind die alle nötigen Daten über die Objekt-Eigenschaften enthalten
  
• Die einzelnen NodeData enthalten jeweils einen Pointer auf einen dyn. erzeugten Record mit den jeweiligen Daten
  
• Um den NodeData-Record zu füllen, müssen dyn. Objekt-Eigenschaften ausgelesen werden. Wenn die Objekt-Eigenschaft auf ein privates Feld zugreift, so wird die Adresse dieses Feldes berechnet (aus der Adresse des Objektes und der RTTI-Information der Eigenschaft) und in den Record kopiert. Handelt es sich um eine Get-Methode, so wird zuerst die Adresse der Methode berechnet und anschließend per ASM (weil dyn.) aufgerufen.

Du siehst also, Pointer sind überall!

BTW: das Tutorial ist nicht von Tino sondern von mir!

Hallo

Du arbeites immer wenn du ein Objekt erzeugts mit einem Pointer...
(Objekte werden deshalb unteranderem auch Referenztypen genannt)

Grüsse

und...wie ich oben schon sagte..jedes event (OnClick etc.) hat einen pointer...selbst (oder gerade) die internen prozessor register sind oft pointer...und so weiter. Wir könnten dich totschmeissen, mit pointer-beispielen

POINTER SIND ELEMENTAR

Hallo,

tommie-lie hat folgendes geschrieben:

Und noch ein Beispiel fällt mir ein, weil ich es grad' selber implementiere *g* Listen!

noch viel gravierender wird es, wenn du Bäume speichern musst. Wenn du z.B. einen Binären Baum hast, die höhe ergiebt sich erst zur Laufzeit. Du kannst das ganze in einem (dynamischen) eindimensionalen Array ablegen. Das ist aber relativ umständlich und speicheraufwändig (du musst auch für nicht vorhandene Kinder speicher reservieren.
Wenn du das mit Pointern machst, kannst du einen Tatsächlich Baum nachbauen. Die Speicherbereiche ( New(MyRecord) ) sind die Knoten und die Zeiger Stellen die Äste da.
Das sieht dann so aus:

Quelle: www.mpi-sb.mpg.de/~b...sung/Vorlesung5.html

Du musst nur da Speicher reservieren wo auch ein Element ist, also z.B. nicht für die Kinder des Elementes mit dem Inhalt 75. Bei der Array lösung müsstest du das aber machen. Außerdem ist die Pointer Variante in der regel Schneller, da keine Indizes berechnet werden müssen (wo ist das Rechte Kind des Elementes im MyTreeArray[4]) sondern nur Zeiger verfolgte werden müssen (also JMP Befehle auf Assembler Ebene).

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

noch viel gravierender wird es, wenn du Bäume speichern musst.

Jupp. Aber selbst auf die verketteten Listen bin ich nur gekommen, weil ich das grad' selber brauche, an einen Baum habe ich gar nicht gedacht. Das geht erst recht nur mit Pointern, denn wenn man's mit Arrays macht, weiß man ja nie vorher wa kommt, irgendwo ist man also ständig am Array-Vergrößern oder -Verkleinern. Und das Prinzip, bzw der Sinn von Pontern dabei ist ja der gleiche (nur so eine schöne Grafik wie du habe ich nicht *g*).

@Nimloth & maximus: Es ging ihm ja nicht darum, wo sie alle versteckt benutzt werden, sondern wo es Sinn macht, daß er selbst sich drum kümmert und weiß, was es ist. Selbst für mich sind Objekte nur Klasseninstanzen, um den Pointer dahinter kümmere ich mich auch nicht, wenn ich es nicht unbedingt muss...

Hallo,

tommie-lie hat folgendes geschrieben:

Jupp. Aber selbst auf die verketteten Listen bin ich nur gekommen, weil ich das grad' selber brauche,

da muste ich während der Ausbildung einige von machen (einfach-, mehrfach-, ringverkettet), so wurde uns der umgang mit Pointern begebracht.
Wenn man sich am Anfang (eines Projektes) übrigens die Mühe macht sich verwaltungsfunktionen zu schreiben kann man damit sehr konfortabel und Effektiv arbeiten. Ein Beispiel habe ich hier mal gepostet.

tommie-lie hat folgendes geschrieben:

an einen Baum habe ich gar nicht gedacht.

Ich hatte mal eine Vorlesung "Algorithmen und Datenstrukturen". Da mussten wir auch Mechanismen lernen, wie man Bäume in Arrays ablegt. Glaube mir (besonders du mimi), es ist unnötig kompliziert, weil Bäume eine nicht Arrayfreundliche struktur sind. Bei Binären Bäumen geht es noch so grade, bei Dynamischen (man weiß nicht wie viele Kinder welcher Knoten hat) wird es ein echtes Problem. Eine Pointer Struktur ist da viel "natürlicher".

tommie-lie hat folgendes geschrieben:

(nur so eine schöne Grafik wie du habe ich nicht *g*).

Google macht's möglich. Solche Grafiken gibt es zu zig tausenden da draußen, die oben dargestellte ist die erste die ich fand .
Für deine Liste währe diese nicht schlecht:

Quelle: hal.iwr.uni-heidelbe...nf1/html/node46.html

Der dazugehörige Artikel scheind auch für jeden der sich mit dem Thema vertraut machen will interessant zu sein.

Gruß
Klabautermann

Zitat:

da muste ich während der Ausbildung einige von machen (einfach-, mehrfach-, ringverkettet)

Ringverkettet brauchte ich zwar nciht, aber wenn ich mir angucke, was andere so in der Ausbildung machen, regt sich in mir das Gefühl, daß ich anderen unglaublich weit vorraus bin

Zitat:

Wenn man sich am Anfang (eines Projektes) übrigens die Mühe macht sich verwaltungsfunktionen zu schreiben kann man damit sehr konfortabel und Effektiv arbeiten.

Keine Angst, ich hab's gleich in 'ne Klasse gepackt, mit einem Array-Property, funktionen für Add, Search, Delete usw.
Damit arbeitet's sich jetzt genauso komfortabel wie mit 'ner normalen Liste (z.B. StringList), nur eben daß ich meine Records zurückkriege

Zitat:

Für deine Liste währe diese [Grafik] nicht schlecht:

Ne, ich hab' 'ne doppelt verkettete, deine Grafik war nur einfach verkettet. Die Pointer auf den jeweils vorherigen Eintrag fehlen

Hi,

tommie-lie hat folgendes geschrieben:

aber wenn ich mir angucke, was andere so in der Ausbildung machen, regt sich in mir das Gefühl, daß ich anderen unglaublich weit vorraus bin

ich rege mich immer herlich drüber auf, was meine "heranwachsenden" Kollegen in ihrer Ausbildung alles (nicht) Lernen. Es kommt mir so vor als währe 'ne brauchbare (schulische) Ausbildung heutzutage der reine Glücksfall.

tommie-lie hat folgendes geschrieben:

Ne, ich hab' 'ne doppelt verkettete,

Dann nimm die hier:

Quelle: www.jeckle.de/vorlesung/sei/kIV.html

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

Dann nimm die hier:

Genau!
Da hat mimi jetzt auch eine Abbildung zu meinem Beispiel
(immer andere für einen Suchen lassen )

sorry leute das ich mich nicht gemeldet hatte - das
"Benachrichtigt mich, wenn eine Antwort geschrieben wurde"
hat nicht so richtig funktioniert
nachdem ich nun den sin verstanden habe, würde ich gerne ein ausfürlichs tutor darüber lesen(ich weiß tino hatte eins geschrieben,aber ich hallte es für sinvol gerade für anfänger die sich mit neuen bereichen befassen, sollten unterschiedliche dokus/tutors lesen. um sie besser zu verstehen, keine weiß alles )

Also generelle Tutorials solltest du genug finden, schau einfach mal bei Delphi-Source, hier oder in der Delphi-Praxis. Ansonsten natürlich bei Google (Tipp: google.de hat unter dem Eingabefeld drei Radiogroups, der mittlere dürfte für dich Gold wert sein ).
Artikel über verkettete Listen hat Klabautermann in seinen Quellenangaben verlinkt, die Artikel (die teilweise aus Unterrichtstoff der Vorlesungen bestehen) sind äußerst informativ, ansonsten wieder nach "verketteten Listen" googlen.

Hallo Mimi,

guck dir auch mal die Quellen an, die ich zu den Abbildungen angegeben habe, für gewöhnlich sind diese Tutorials, wenn auch nicht umbedingt für delphi. Für das algemeoine verständniss sollte die Sprache aber egal sein.
Beim überfliegen macht z.B. das heir einen recht guten eindurck (auch wenns für Java ist).

Gruß
Klabautermann