Wann kommt der .-Operator zum Einsatz?

Don06

CStoll schrieb:

@Boris: Nein, die Iteratoren haben "nur" den -> überladen. 'operator.' zu überladen verbietet der Sprachstandard.

Und natürlich den Dereferenz(*)-Operator.

thordk

mbu schrieb:

Soweit ich weiss, ist
object->member();
ja nur ein Alias für
(*object).member();
Liege ich da richtig?

jo, liegst du.

crashterpiece

Beispiel:

class ZahlKlasse {
  int zahl;
};

main() {

  ZahlKlasse klasse1;
  ZahlKlasse* klasse2 = new ZahlKlasse;

  klasse1.zahl = 5;
  klasse2->zahl = 5;

};

so gehts

777

Okay... THX.
Anhand eurer Beispiele habe ich jetzt verstanden, wann Punkt und wann -> Operatoren zum Einsatz kommen.
Doch es bleibt für mich jetzt eine Frage offen:

Warum gibt es überhaupt Zeiger?
Oder warum benutzen heutzutage alle Compiler, welche eine grafische Oberfläche vorgeben zum Zugriff auf API-Objekte Zeiger?
Was genau ist der Sinn, wo es doch auch fast noch leichter mit direkten Objekten geht.

cya
David

CStoll

Zeiger gibt's, um damit auf Objekte zugreifen zu können, die "woanders" liegen (z.B. auf dem Heap). Und Objekte außerhalb des eigenen Funktionsstack anzulegen hat den unbestreitbaren Vorteil, daß sie in der Lage sind, das Funktionsende zu überleben (lokale Variablen werden gelöscht, wenn sie ihren Scope verlassen).

Ja, in einigen Fällen kann man auch Referenzen verwenden, aber die können (außer mit halblegalen Programmiertricks) nach der Erzeugung nicht mehr verbogen werden.

PS: Interessanterweise lassen "modernere" Sprachen eher die lokalen Variablen weg als die Zeiger

777

Jap - in C# isses beispielsweise anders. Hier gibts überhaupt keine Pointer mehr- oder sagen wir: Ich hab noch keine gesehen

CStoll

Klar gibt's in C# und Java auch Pointer - die heißen nur dort nur "Referenzen" (und sind ein wenig unter der Oberfläche verborgen).

(PS: Nein, das sollte jetzt kein Aufruf zum Flamewar werden)

LordJaxom

CStoll schrieb:

Klar gibt's in C# und Java auch Pointer - die heißen nur dort nur "Referenzen" (und sind ein wenig unter der Oberfläche verborgen).

Mal ganz davon abgesehen, dass (ich nenne sie mal zusammenfassend) "Managed-Referenzen" eigentlich Zeiger sind, hat die Sprache C# tatsächlich auch "richtige" Zeiger, also die Dinger mit dem Sternchen. Die lassen sich allerdings nur im Unsafe-Kontext benutzen, sonst weint der Compiler

777

Mhh.... also wegen der Sache mit den Zeigern muss ich dann doch nochmal nachhaken.
Du meintest, dass die deswegen ihre Vorteile haben, weil Objekte normalerweise gelöscht werden, sobald sie die Funktio beendet wird in der sie sich momentan befinden.
Das stimmt zwar, aber es stört doch auch nicht.

Habe ich beispielsweise ein Formular mit Button, dann soll das ja auch nur so lange da sein, wie die WINAPI-MainFunktion läuft.
Sobald diese verlassen wird ist ja eh Ende und man braucht die Objekte nicht mehr.

Zudem befinden sich alle Objekte eines Prozesses ja eh in einem reservierten Speicherbereich.
Also werden auch beim Beenden die Objekte auf die die Pointer zeigen mitgelöscht- oder irre ich mich da?

cya
David

LordJaxom

777 schrieb:

Zudem befinden sich alle Objekte eines Prozesses ja eh in einem reservierten Speicherbereich.
Also werden auch beim Beenden die Objekte auf die die Pointer zeigen mitgelöscht- oder irre ich mich da?

Es gibt aber auch Prozesse, die nicht beendet werden sollen, z.B. Server.

CStoll

Ja, dann müsstest du deinen Button in der Dialog-Funktion anlegen - aber jetzt brauchst du noch eine Möglichkeit, ihn aus deinen Hilfsfunktionen heruas zu erreichen (dort eine eigene lokale Variable anzulegen würde einen weiteren Button erzeugen) - dazu brauchst du Zeiger/Referenzen. Und Windows bietet außerdem die Möglichkeit, Dialogelemente zur Laufzeit zu erzeugen oder zu löschen - für sowas benötigst du etwas ausgefeiltere Reservierungsstrategien als du mit Stack-Variablen erreichen kannst.

(btw, mit "woanders" meinte ich nicht nur den Heap - auch lokale Variablen anderer Funktionen und globale Variablen liegen "woanders")

777

Mhh... also nur wegen der Struktur wichtig?
Aber eigentlich doch mit beidem zu realisieren..-.-

CStoll

Wichtig ist vor allem, daß bei bestimmten Objekten jeder das selbe Objekt meint - und dazu mußt du es einmal zentral anlegen und dann an jeden Nutzer Zeiger oder Referenzen darauf übergeben. Gelegentlich reicht eine Referenz aus, aber mitunter stellen deren Vorteile (v.a. "zeigt ständig auf das selbe Objekt") auch eine Einschränkung dar und du mußt mit Zeigern arbeiten.

777

okay... danke für die Ausführliche Erklärung :-)!!!!

Werd denke mal den 100%igen Sinn dann verstehen, wenn ich weiter C++ mache

cya
David

crashterpiece

Ich würde die Existenz von Zeigern auf historische Gründe schieben. Aufgund der Struktur früherer Betriebssysteme waren Speicher-Benutzungen wohl effektiver mit direkten Speicher-Adressierern (also Pointern).

Mittlerweile ist das Zusammenspiel zwischen Compiler, Sprache, OS, CPU-Performance etc viel sicherer und stärker zusammenhängend geworden, so dass man automatisierte Typsicherungen etc garantieren kann. Prinzipiell hätte man Java ja auch vor 40 Jahren auf den Mainframes laufen lassen können

Daher denke ich mal, ein großer Teil der heutigen Programmiersprachen, die nicht explizit an Hardware gebundenen Code schreiben müssen, kapselt die Zugriffe durch Pointer durch das intuitivere Referenzen-Modell. Und dank modernerer und komplexerer Mikro-Controller wird auch in diesen Bereichen in naher Zukunft das direkte Speicher-Hacking verschwinden und durch einheitliche Architektur-Modelle ersetzt werden.

Simon2

Naja,

prinzipiell ist der Begriff der "Variablen" (beim Programmieren) auch nichts Anderes als ein "Verweis auf ein Stück Speicher". Den historischen "Ansatz" kann ich nachvollziehen:
A) ASM: mov 0xABDEF 0
MASM: mov MYVAR_NAME 0
C) COBOL: move 0 to MYVAR oder C: myVar = 0

Den Unterschied sehe ich aber nicht in der Typsicherheit (schließlich werden in C++ und Java auch Pointer typsicher gemacht), sondern in der "Variabilität": Pointer/Referenzen abstrahieren eine Ebene weiter (weswegen eine "Dereferenzierung" notwendig wird, bevor man auf den Wert zugreifen kann). In einer Anweisung sagt man: "Mache etwas mit dem Wert an dieser Speicheradresse" und bestimmt dabei die Speicheradresse:
A) fest zur Programmierzeit
fest zur Compile-/Laufzeit oder
C) variabel zur Laufzeit.

crashterpiece schrieb:

...kapselt die Zugriffe durch Pointer durch das intuitivere Referenzen-Modell....

Das verstehe ich nicht ... was sind "Pointer" und "Referenzen-Modell" für Dich ?

Gruß,

Simon2.

crashterpiece

Simon2 schrieb:

crashterpiece schrieb:

...kapselt die Zugriffe durch Pointer durch das intuitivere Referenzen-Modell....

Das verstehe ich nicht ... was sind "Pointer" und "Referenzen-Modell" für Dich ?

Gruß,

Simon2.

ich bin der meinung, dass referenzen syntaktisch einfacher zu handeln sind, also weniger sprachelemente ausmachen. da ja viele programmier-anfänger den unterschied zwischen pointer und referenz nicht erkennen können, denke ich lediglich dass das verbergen von expliziten pointern durch das "referenz-modell" verständlicher ist. zumindest meiner erfahrung nach mit java-programmierern, die später auf c++ umgestiegen sind (und weiterhin beim by-value-Paradigma geblieben sind, so dass einfachste methoden durchaus mal laufzeiten im stundenbereich hatten ).

und historisch... nunja, tief im inneren wirds ja immer noch so gemacht. nur wird sich die abstraktion immer weiter weg von der tatsächlichen maschinenebene bewegen.

aber bleiben wir besser beim thema .Operator ...

Simon2

crashterpiece schrieb:

...ich bin der meinung, dass referenzen syntaktisch einfacher zu handeln sind, also weniger sprachelemente ausmachen. da ja viele programmier-anfänger den unterschied zwischen pointer und referenz nicht erkennen können, denke ich lediglich dass das verbergen von expliziten pointern durch das "referenz-modell" verständlicher ist. ...

Ok - Du sprachst, von C++-Referenzen und -Pointern. Beim Ersteren greift man wie auf "Objekte" zu (für die sie ja nur Aliase), während man für Zweitere noch "*" und/oder "->" benötigt. Und die "Kapselung", von der Du sprichst, nimmt der Compiler vor.
Ich denke, nun habe ich's verstanden und kann zustimmen. Danke !

Allerdings stellen Referenzen halt in C++ durchaus etwas Anderes dar als Pointer (je nach Sichtweise "festgebundene Verweise" oder "Aliase"), so dass ein Programmierer früher oder später doch Pointer braucht.

Die Umsteiger-Probleme von Javaprogrammierern liegen IMHO vA in der "äußeren Ähnlichkeit" des Quellcodes. Sähen sich die beiden Sprachen nicht so ähnlich (und gäbe es nicht mehr so viele schlechte Tutorials ), kämen sie vermutlich nicht so schnell auf die Idee, sie zu verwechseln.....

Gruß,

Simon2.