Printausgabe bei Aggregation
-
Nein, das reicht nicht. Bitte vollständiges Minimalbeispiel. Dein Code wirft nur immer mehr Gegenfragen auf: Was ist TFloorList? Was ist der Sinn der Klasse Object?
-
Starke Vermutung: Der Fehler steckt in diesem Kommentar:
Floor (const Floor & cFloor); //wenn ich das nicht definiere kriege ich einen fehler, wieso das ohne dem nicht geht, habe ich noch nicht verstandenDenn wenn du nicht weißt, wozu man einen Kopierkonstruktor brauchen kann, dann weißt du auch nicht, was man da reinschreibt. Insbesondere kopierst du dann nichts und verlierst scheinbar die "Werte vom Stock".
-
Bashar schrieb:
Starke Vermutung: Der Fehler steckt in diesem Kommentar:
Floor (const Floor & cFloor); //wenn ich das nicht definiere kriege ich einen fehler, wieso das ohne dem nicht geht, habe ich noch nicht verstandenDenn wenn du nicht weißt, wozu man einen Kopierkonstruktor brauchen kann, dann weißt du auch nicht, was man da reinschreibt. Insbesondere kopierst du dann nichts und verlierst scheinbar die "Werte vom Stock".
wozu einen kopierkonstruktor benutzen?:
um ein uninitialisiertes objekt mit einem schon initiliasierten objekt zu initiliasierenaber wieso reicht bei meinem fall nicht der default copy-ctor?
denn wenn ich die schnittstelle für den copy-ctor wieder ausblende bekomme ich folgendes:Error 1 error C2248: 'Object::Object' : cannot access private member declared in class 'Object'habe es straightforward die eine Zeile im Stock-Copy-Ctor dazugeschrieben und es geht. Das was ich aber wirklich nicht weiß, ist:
wieso reicht der default copy-ctor nicht?
-
Du hast folgende Möglichkeiten, das herauszufinden:
- Bei der Fehlermeldung, die auftritt, wenn der Kopierkonstruktor von Floor nicht definiert ist, sagt dir der Compiler, an welcher Stelle er benötigt wird.
- Du könntest dein Programm durchgehen und überlegen, wo wohl Objekte vom Typ Floor kopiert werden.
- Du könntest im Kopierkonstruktor von Floor einen Breakpoint setzen.
-
Weil dein Floor ein Object ist und ein Object ist bei dir nicht kopierbar. Die Frage ist immer noch: Wozu ist die Object-Klasse eigentlich gut?
-
Bashar schrieb:
Du hast folgende Möglichkeiten, das herauszufinden:
- Bei der Fehlermeldung, die auftritt, wenn der Kopierkonstruktor von Floor nicht definiert ist, sagt dir der Compiler, an welcher Stelle er benötigt wird.
- Du könntest dein Programm durchgehen und überlegen, wo wohl Objekte vom Typ Floor kopiert werden.
- Du könntest im Kopierkonstruktor von Floor einen Breakpoint setzen.
- fehler in der zeile 43 (ist jetzt nichtssagend, ohne irgendeine klasse im main zu benutzen) wo nur die zeichen }; stehen.
2)hab jetzt genau den von dir vorhergesagten effekt gesehen
3)siehe zwei
SeppJ schrieb:
Weil dein Floor ein Object ist und ein Object ist bei dir nicht kopierbar. Die Frage ist immer noch: Wozu ist die Object-Klasse eigentlich gut?
durch die eigene defintion des copy-ctors habe ich jetzt dieses effekt ausgehebelt?
also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet
-
ACnut schrieb:
also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet
1. Deine Basisklasse macht etwas. Nämlich verhindern, dass die entsprechenden Objekte kopiert werden können.
2. Wenn sie nichts besonderes können, wozu soll das dann gut sein?
3. Bist du wirklich sicher, dass du das richtig verstanden hast?
-
SeppJ schrieb:
3. Bist du wirklich sicher, dass du das richtig verstanden hast?
GoF: program to an interface, not an implementation
Das Gesetz Nummer 1 in Java. Immer erst ein Interface schreiben mit den Methoden und dann eine Klasse, die es implementiert. Quasi die Java-Version von Header-Dateien (lol).
-
SeppJ schrieb:
ACnut schrieb:
also in der oop vorlesung haben wir gelernt, dass es gutes stil ist, wenn man von einer basis aller basisklassen (der nichts besonderes kann) andere klassen ableitet
1. Deine Basisklasse macht etwas. Nämlich verhindern, dass die entsprechenden Objekte kopiert werden können.
2. Wenn sie nichts besonderes können, wozu soll das dann gut sein?
3. Bist du wirklich sicher, dass du das richtig verstanden hast?1)also werden auch die default copy-ctoren der abgeleiteten klassen auch verhindert, ->sofern man diese selbst definiert (da bräuchte ich noch deine antwort)<-
2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...bräuchte hier immer noch eine antwort:
durch die eigene defintion des copy-ctors für Floor ist diese sperre zumindest für floor deaktiviert oder?[quote="java-checker"]
SeppJ schrieb:
Das Gesetz Nummer 1 in Java. Immer erst ein Interface schreiben mit den Methoden und dann eine Klasse, die es implementiert. Quasi die Java-Version von Header-Dateien (lol).
ja genau sowas ähnliches hat er bei uns auch gesagt( vielleicht auch nur, weil er auch java unterrichtet)
-
ACnut schrieb:
1)also werden auch die default copy-ctoren der abgeleiteten klassen auch verhindert, ->sofern man diese selbst definiert (da bräuchte ich noch deine antwort)<-
Nicht direkt, aber der compilergenerierte Copy-Ctor ruft automatisch den der Basisklasse auf, und das geht nicht, wenn der privat ist. Wenn du selbst einen definierst, und in der Initialisiererliste nicht den Basisklassen-Kopierkonstruktor aufrufst, dann nicht.
2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...
Das war ziemlich sicher Sarkasmus (und passt auch nicht ganz, Object ist ja kein Interface).
-
1)also werden auch die default copy-ctoren der abgeleiteten klassen auch verhindert, ->sofern man diese selbst definiert (da bräuchte ich noch deine antwort)<-[/quote]
Nicht direkt, aber der compilergenerierte Copy-Ctor ruft automatisch den der Basisklasse auf, und das geht nicht, wenn der privat ist. Wenn du selbst einen definierst, und in der Initialisiererliste nicht den Basisklassen-Kopierkonstruktor aufrufst, dann nicht.hmmm ok, danke

2,3)hier haben wir eine ähnliche antwort wie der von java-checker gehört. ableitung von abstrakten klassen,uml-design...
Das war ziemlich sicher Sarkasmus (und passt auch nicht ganz, Object ist ja kein Interface).[/quote]
also jetzt bin ich ziemlich verunsichert

ich glaub ich werde den lehrer nochmal fragendanke für die hilfe
mfg
ACnut