Warum Pointer in C
-
und vergiß nicht die dynamische Speicherwverwaltung mit den Zeigern...
Auch etwas unentbehrliches mit dem man arbeiten kann und auch sollte.
-
nicht nur unentbehrlich, ich würde sagen, essentiell
!Wenn du irgendwo im Speicher Daten vorliegen hast, die du nicht immer mit einer Variablen beschreiben kannst (wie z.B. angesprochen wurde: dynamische, oder falls du Daten extern bekommst - über andere Module, über ports, über irgendeine Schnittstelle (Grafikkarte z.B.)) und nicht immer kopieren willst, musst du wissen, wo die Daten liegen, um genau auf sie dann zugreifen zu können. Und Pointer speichern genau solche Adressen!
-
Wie hat man vorher eigentlich dann Datenspeicher vergeben oder gab es diese dynamische Speichereverwaltung von Anfang an in der Programmiersprache ?!?
-
cHillb3rT schrieb:
Wie hat man vorher eigentlich dann Datenspeicher vergeben oder gab es diese dynamische Speichereverwaltung von Anfang an in der Programmiersprache ?!?
Redest du von C? Nein, anfangs gab es sowas nicht. Was aber niemanden davon abgehalten hat, sich das selbst zu implementieren, siehe z.B. Kernighan&Ritchie. Später wurde daraus, weil es soviele benutzt haben, eine Bibliotheksfunktion.
-
cHillb3rT schrieb:
Zeiger werden benutzt, damit unverständliche Programme effizienter werden und zudem mehr Überblick gewähren.
Nicht wirklich
-
Faustregel: Wenns ohne Zeiger geht, machs ohne Zeiger. Das im Wesentlichen aus Sicherheitsgründen; in etwa 4 von 10 Fällen sind uninitialisierte Pointer die Ursache für Segfaults, weitere 5 sind buffer overflows. Ich schätze, dass sie damit hinter Speicherlecks (ebenfalls pointer!) auf der Liste der beliebtesten Programmierfehler ganz vorne kommen.
Natürlich kommt man nicht immer um Pointer herum - in C zum Beispiel ist es die einzige Möglichkeit, call by reference zu implementieren, und dynamische Speicherverwaltung ist ohne pointer auch nicht so einfach realisierbar. Trotzdem macht es in aller Regel Sinn, nach einem Weg ohne Pointer zu suchen. Da, wo das nicht möglich ist, ist auf jeden Fall Vorsicht geboten, und jede Menge Kontrolle - valgrind zum Beispiel ist sehr nützlich beim Aufspüren von Speicherlecks.
-
Kleines Beispiel ur Problematik der Pointer:
Diese an und für sich nützliche Eigenschaft, dass man die Interpretation des Typs beeinflussen kann, führt dazu, dass sich Schlamperei beim Programmieren zu den schlimmsten und schwersten zu findenden Fehlern aufschaukeln kann.
Nehmen wir einmal an ein Pointer zeigt auf den Speicherplatz, der für einen „char“ reserviert ist. Nun behandelt man den dort vermuteten Wert als „int“, z. B. bei uns 4 Bytes lang.
Damit liest bzw. überschreibt man im schlimmsten Fall sogar 3 Bytes, die eigentlich jemand anderen gehören. Und dies muss nicht unter Umständen bemerkt werden, sondern erst später, weil die Variable vielleicht erst später im Programm aufgerufen wird und dadurch der Fehler später auftaucht.
Sobald auf die Variable zugegriffen wird, kommt nur Unsinn bei der Ausgabe raus oder wenn der „int“-Wert ein Berechnungswert ist, dann wundert man sich, warum der Wert, den das Programm berechnet immer falsch ist.
Falls wir dann noch mit dem Pointer auf einen Pointer verweisen und den „korrupten“ Pointer weiterbenutzen, kann dieser auf Speicherstellen außerhalb des Programms verweisen und auch zum Computerabsturz führen.
-
cHillb3rT schrieb:
Diese an und für sich nützliche Eigenschaft, dass man die Interpretation des Typs beeinflussen kann, führt dazu, dass sich Schlamperei beim Programmieren zu den schlimmsten und schwersten zu findenden Fehlern aufschaukeln kann.
Solche Fehler habe ich noch nie gemacht... Man castet ja nicht blöd rum, sondern nur dann wenn man es braucht.
Falls wir dann noch mit dem Pointer auf einen Pointer verweisen und den „korrupten“ Pointer weiterbenutzen, kann dieser auf Speicherstellen außerhalb des Programms verweisen und auch zum Computerabsturz führen.
Aber nur auf sehr alten Betriebssystemen
-
/me findet es lustig, wenn Leute hören X sei böse, und sich dann selbst zusammenreimen, warum das wohl so sein sollte
-
Bei High-Level-Programmierung, die immer abstrakter wird, ist es ja wirklich so, dass Pointer langsam überflüssig werden (man denke nur an .NET), aber wenn es um Low-Level geht (oder DirectX, da benutzt man ja bald mehr Zeiger als "normale" Variablen...
) kommen sie mir so normal vor, dass ich gar nicht über deren Existenzlegitimation mache...
-
Till schrieb:
Bei High-Level-Programmierung, die immer abstrakter wird, ist es ja wirklich so, dass Pointer langsam überflüssig werden (man denke nur an .NET)
Dort heissen die Zeiger Referenzen - aber bis auf Pointer Arithmentik sind es Zeiger wie in C.
aber wenn es um Low-Level geht (oder DirectX, da benutzt man ja bald mehr Zeiger als "normale" Variablen...
).NET hat für dich keine Zeiger, DirectX aber schon. Hat dann Managed DirectX somit Zeiger oder nicht?
kommen sie mir so normal vor, dass ich gar nicht über deren Existenzlegitimation mache...
Wüsste auch nicht, was an Zeigern unnormal sein sollte... Im Prinzip braucht das nahezu jede Sprache - oder wie würdest du sonst so simple Sachen wie einen Baum oder eine Liste implementieren? Ohne 'Zeiger' tut man sich da dann doch etwas schwer...
-
sorry, ich meinte unmanaged DirectX, was anderes habe ich mir noch gar nicht angeschaut. Mit High-Level und .NET meine ich nur, dass Zeiger (bzw. "Referenzen") immer mehr vor dem Programmierer "versteckt" werden, aber für Low-Level ist es ja klar - bin halt eben der "konservative" Zeiger-Fan
-
Eigentlich stimmt das ganz und gar nicht, in den hohen Sprachen wie Java gibt es Zeiger, die sogar auf null zeigen dürfen.
Im gegensatz zu C++ wo man dafür Zeiger hat und Referenzen, als Aliase (C++ rockt halt :D).Ohne Zeiger geht gar nichts egal auf welcher Ebene, wenn ne Sprache keine Zeiger hat, oder
diese nicht als Referenzen tarnt, dann ist es nicht möglich dynamische Datenstrukturen zu erzeugen.
-
ich sagte, "immer mehr versteckt werden", damit meinte ich die Tendenz. Aber ich bin froh, dass hier so viele Zeiger-Liebhaber rumlaufen...