Hallo, Vorab: die Begriffe im Betreff suggerrieren villeicht, dass ich der Meinung bin, es gäbe in C Objekte. Ich habe das nur gemacht, weil es keinen direkten C++ Filter im Forum gibt. Zu meiner Frage: Ich habe mir ein Buch über C++ gekauft : "Grundkurs C++" aus dem Galileo Verlag von Jürgen Wolf. Jetzt habe ich eine Frage was den Umgang mit Klassen angeht. Wenn ich eine Klasse myClass definiere und damit erstmal umgehe wie mit einer normalen Variablendeklaration á la myClass Class_Nr_1; myClass Class_Nr_2; Dann liegen die ja noch nicht im Heap, aber ich kann deren Methoden nutzten. Wenn ich jetzt aber mit Class_Nr1 = new myClass; Class_Nr2 = new myClass; arbeite, habe ich die beiden im Heap stehen. Aber was habe ich davon? Gut, ich habe gelesen das man damit zur laufzeit arbeiten kann, aber ist das wirklich alles? Geht nur darum im Grunde das Prinzip der Strukturen aus C so zu erweitern, dass eben auch Funktionen in den "Strukturen" stehen können? Die Sache mit der Kapselung ist mir schon klar. Im Grunde würde ich doch dann nie den new Operator verwenden, wenn ich von einem Objekt im Vorhinein sicher weiß, wie viele ich brauche? Dann kann ich mir ja auch das Zerstören sparen. viele Grüße, Jasson
Gast
#2575496
Jasson JFK schrieb: > Im Grunde würde ich doch dann nie den new Operator verwenden, wenn ich > von einem Objekt im Vorhinein sicher weiß, wie viele ich brauche? doch, wenn eine funktion z.b. ein Object zurückliefer soll. Dann musst du es mit new anlegen weil es sonst nur lokal in der funktion vorhanden ist.
Jasson JFK schrieb: > Im Grunde würde ich doch dann nie den new Operator verwenden, wenn ich > von einem Objekt im Vorhinein sicher weiß, wie viele ich brauche? > Dann kann ich mir ja auch das Zerstören sparen. Im Prinzip richtig. Und du sollst auch nicht Objekte dynamisch erzeugen, wenn du vorher genau weißt, wieviele du brauchen wirst. Aber diesen Luxus hast du nun mal nicht immer. Liest du beispielsweise irgendwelche Datensätze von einem File ein, wobei jeder Datensatz programmintern sinnvollerweise als Objekt abgebildet wird, dann weißt du vorher nicht, wieviele es werden.
Gast
#2575697
Jasson JFK schrieb: > Jetzt habe ich eine Frage was den Umgang mit Klassen angeht. Wenn ich > eine Klasse myClass definiere und damit erstmal umgehe wie mit einer > normalen Variablendeklaration á la > > myClass Class_Nr_1; > myClass Class_Nr_2; > > Dann liegen die ja noch nicht im Heap, "Heap" gibt's in C++ eigentlich nicht. Es gibt drei Arten von Speicher, nämlich statisch, automatisch und dynamisch. Was die beiden Objekte oben sind, hängt davon ab, wo du die definierst. > Wenn ich jetzt aber mit > Class_Nr1 = new myClass; > Class_Nr2 = new myClass; > arbeite, habe ich die beiden im Heap stehen. > Aber was habe ich davon? Gut, ich habe gelesen das man damit zur > laufzeit arbeiten kann, aber ist das wirklich alles? Geht nur darum im > Grunde das Prinzip der Strukturen aus C so zu erweitern, dass eben auch > Funktionen in den "Strukturen" stehen können? Nein. Das ist eine syntaktische Hilfe, um objektorientierte Programmierung "schöner" zu machen, aber Objektorientierte Programmierung beinhaltet da einges mehr. Ein wesentlicher Punkt ist z.B. Polymorphie. Wenn du zur Compilezeit noch nicht weißt, von welchem Typ das Objekt später sein wird, mußt du es dynamisch anlegen.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
> Im Grunde würde ich doch dann nie den new Operator verwenden, wenn ich > von einem Objekt im Vorhinein sicher weiß, wie viele ich brauche? > Dann kann ich mir ja auch das Zerstören sparen. Kommt drauf an. Ein Objekt, das du in einer Funktion definierst, existiert auch nur so lange, bis die Funktion beendet ist. Ein globales Objekt lebt, bis das Programm beendet wird. Wenn du die Lebensdauer eines Objekts frei bestimmen möchtest, mußt du es mit new anlegen.
Ah ok, diese Begriffe Polymorphie, überladen u.ä. hatte ich letztes Semester in "so einem halbem" Modul - reicht natürlich im Grunde nur "um es mal gehört zu haben"... Wenn ich es also richtig mitgenommen habe, hängt sich das Gedankengut von c++ also längst nicht nur an diesem "new" Operator auf. Davon war ich nämlich so verwirrt, weil ich dachte erst dadurch bekommt die OO erst wirklich ihren Namen und macht auch erst/nur damit Sinn. Also eigentlich kommt man didaktisch viel weiter, das Ganze (wenigstens erstmal) nur als Erweiterung des "struc" Prinzips zu sehen. Firma dankt!
myClass Class_Nr_1; ruft auch den new Operator der Klasse auf, sonst könnte man ihn für Klassen nicht überladen. Es gibt in C++ einen "operator new" für Build in Datentypen, funktioniert ähnlich wie malloc und kann nicht überladen werden. Und den "new operator" für Klassen und der kann überladen werden.
Hans-georg Lehnard schrieb: > myClass Class_Nr_1; > > ruft auch den new Operator der Klasse auf, sonst könnte man ihn für > Klassen nicht überladen. Das ist Unsinn! > Es gibt in C++ einen "operator new" für Build in Datentypen, > funktioniert ähnlich wie malloc und kann nicht überladen werden. Und den > "new operator" für Klassen und der kann überladen werden. Das kann er, aber das ist etwas, das man selten benötigt, und es hat auch nichts mit der Fragestellung zu tun.
Gast
#2576137
Hans-georg Lehnard schrieb: > myClass Class_Nr_1; > > ruft auch den new Operator der Klasse auf ruft Konstructor bei definition und new operator ruft Konstruktor direkt bei aufruf. Zweck der new hat Rolf gut beschriben.
Gast
#2576160
verwechselst du da nicht etwas, h-g-l? das hat nichts mit dem New Operator zu tun. damit wird das Objekt auf dem stach erzeugt, wodurch der konstruktor aufgerufen wird...
Jasson JFK schrieb: > Also eigentlich kommt man didaktisch viel weiter, das Ganze (wenigstens > erstmal) nur als Erweiterung des "struc" Prinzips zu sehen. Ja, mache ich auch so. Sind im Prinzip Structs mit Funktionszeigern und etwas Kapselung.
Kommt halt drauf an, ob man C++ nur als etwas "schickeres" C verwenden will, oder ob man richtig objektorientiert programmieren will. In letzterem Fall kommt man mit eurer Sichtweise nicht weit. Da ist dann ein komplettes Umdenken nötig.
Wo hört die Sichtweise denn auf?
Spätestens bei virtual, würde ich sagen.
Klaus Wachtler schrieb: > Spätestens bei virtual, würde ich sagen. Aber allerspätestens. Ich würde sagen ein guter 'Einstiegspunkt' ist dort gegeben, wenn man realisiert, dass man von Klassen andere Klassen ableiten kann und was sich dann daraus alles an Konsequenzen ergibt. Wenn man noch früher einsetzen will, dann besteht (meiner Meinung nach) ein ganz wesentlicher Anschauungswechsel darin, dass es 'früher' nur Daten (in einer Datenstruktur) gab, an denen sich Funktionen nach Belieben vergreifen. In der OOP verschmelzen aber Daten und Ausführungseinheiten zu Objekten, wobei jedes Objekt sich um sich selbst kümmert und die Memberfunktionen ein Weg sind, dem Objekt Befehle zu erteilen. Der Aufruf einer Funktion ist gleichzustellen der Aufforderung an einen Mechanismus etwas zu tun, wobei es dem Mechanismus selber obliegt zu entscheiden, WIE diese Aktion implementiert wird. Das ist für mich einer der ganz wesentlichen Wechsel in der Denkweise. Hört sich einfach an, dauert aber seine Zeit, bis man ihn verinnerlicht hat.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.