Zeiger auf Klasse
-
jo finde ich auch, dass das redundant ist....
wenn ich das programm bei mir kompiliere, dann gibt er die richtigen sachen aus... also ich kann keinen fehler so mehr finden....
-
eine sache gibts noch zu bemängeln:
class book : public medium { private: char *title, *lang, *author, *isbn; float price; public: book(char *my_title, char *my_lang, float my_price, char *my_author, char *my_isbn); void print(); };
price title und lang sind bereits in medium enthalten, diese information ist also redundant da schon vorhanden.
Nun fragst du dich sicherlich: wie kann ich denn auf die variablen von medium zugreifen?
ganz einfach: du machst sie einfach protected anstatt private
-
ich glaube habe auch noch eine:
book::book(char *my_title, char *my_lang, float my_price, char *my_author, char *my_isbn) : medium(my_title, my_lang, my_price) { title = my_title; //ist das nicht überflüssig??? lang = my_lang; price = my_price; author = my_author; isbn = my_isbn; }
titel, lang und price können doch auch wegfallen... er benutzt doch schon den elementinitialisierer(? weiß nicht genau, ob der so heißt ?)
@otze:
er muss sie doch gar nicht protected machen, wenn er mit dem konstruktor der medium klasse die elemente initialsisiert.... der konstruktor ist doch public, also kann er auch auf die private elemente zugreifen..
oder irre ich mich da? ich programmiere noch nicht so lange...
-
direkt zugriff auf private geht bei public vererbung NIE, nur bei private vererbung und friend ist das möglich
//edit natürlich initialisiert er die werte im ctor der klasse, aber wenn man etwas weiter denkt, kann das nichts werden, denn wenn er irgendwo in der Buch Klasse den preis ändern wollte, dann würde sich das nicht auf die basisklasse auswirken.
-
ja, aber kann man dafür nicht in der basisklasse setter-methoden machen, die dann die abgeleitete klasse aufrufen kann, um den preis zu ändern? es wäre doch möglich, oder nicht?
ist das dann schlechter stil, wenn man getter/setter-methoden verwendet?
wie gesagt, ich kenne die grundlagen, weiß aber nicht, wann was besser ist, oder was man generell vermeiden sollte... kannste mir da ein paar tipps geben? würde mich sehr darüber freuen.
-
in dem fall währe es schlechter stil, da die abgeleitete Klasse keine separaten werte besitzen soll, sie soll nur erweiterungen bieten(und selbst das muss sie nicht).
und nur so am rande: wieso 2x die gleichenw erte an unterschiedlichen stellen speichern, wenn ans a) einfacher b) schöner und c) platzsparender machen kann
-
ich habe ja seinen sourcecode geändert.... bei mir enthält die abgeleitete klasse nur noch die zusätzlichen elemente... (also ohne price usw.)
und ich benutze die Liste der STL.. zudem habe ich char* zu string geändert...
-
wozu std::list?
-
otze schrieb:
wozu std::list?
verstehe ich jetzt nicht?
ich habe die Liste der STL benutzt, damit ich ein bisschen mehr lerne, da ich die sachen der STL nicht so oft benutze... übung macht den meister
-
ahso
dachte, es hätte speziell was mit diesem problem zu tun
-
otze schrieb:
frage am rande:
/** * Konstruktor * * @param char my_title Titel des Buches * @param char my_lang Sprache des Buches * @param float my_price Preis des Buches * @param char my_author Autor des Buches * @param char my_isbn ISBN-Nummer des Buches */
müsst ihr das machen?
ich empfinde diese information als ziemlich redundantJa leider. Ich würde auch gerne darauf verzichten, aber es wird ja gefordert. Aber in Zukunft werde ich hier diese Informationen herauslassen.
-
leech schrieb:
ich habe ja seinen sourcecode geändert.... bei mir enthält die abgeleitete klasse nur noch die zusätzlichen elemente... (also ohne price usw.)
und ich benutze die Liste der STL.. zudem habe ich char* zu string geändert...Sorry, dass ich erst jetzt antworte. Hatte gestern Abend nach langem Probieren nicht mehr die Nerven und bin einfach ins Bett. Das würde bedeuten, dass ich in den abgeleiteten Klassen jeweils nur noch Autor und ISBN-Nummer benötige, da ich die anderen drei Sachen bereits in Medium vorhanden habe.
Soweit ich weis, kann ich den Typ string nur benutzen, wenn ich diese Bibliothek explizit einbinde, richtig? Und das darf ich leider nicht
-
leech schrieb:
wenn ich das programm bei mir kompiliere, dann gibt er die richtigen sachen aus... also ich kann keinen fehler so mehr finden....
Kompilieren kann ich das ganze auch. Er rief allerdings bei den beiden Objekten vom Typ Buch und Film die print-Methode der Medium-Klasse auf. Vielleicht liegt es aber auch daran, dass ich die Attribute in den abgeleiteten Klassen noch einmal mit übernommen habe. Ich werde dies heute Abend mal ausprobieren.
So kam folgendes heraus:
Titel: Mein Titel Sprache: Deutsch Preis: 0.00
aber eigentlich müsste folgendes angezeigt werden
Titel: Buch1 Sprache: Deutsch Preis: 19.50 Autor: Autor1 ISBN: 123-456-789
Vielen Dank für eure Hilfe
Steffenchen
-
Nur so nebenbei.. Bist zufällig in Köln an der GSO?
Da würd die Aufgabenstellung nämlcih genau passen
-
Vernochan schrieb:
Nur so nebenbei.. Bist zufällig in Köln an der GSO?
Da würd die Aufgabenstellung nämlcih genau passenNein, in Frankfurt. Aber irgendwie cool zu hören, dass die Lehrer zum Teil das Rad auch nicht neu erfinden.
-
Steffenchen schrieb:
Soweit ich weis, kann ich den Typ string nur benutzen, wenn ich diese Bibliothek explizit einbinde, richtig? Und das darf ich leider nicht
#include <string> using namespace std;
Ich bin mir jetzt nicht sicher, ob dafür ne extra lib eingebunden wird. Aber wenn man schon in C++ programmiert, dann sollte man imho C-Strings (also char Arrays) nach Möglichkeit vermeiden.
-
Das hat mir auch schon jemand gesagt, allerdings darf ich
#include <string>
leider nicht verwenden.
-
otze schrieb:
direkt zugriff auf private geht bei public vererbung NIE, nur bei private vererbung und friend ist das möglich
Hab ich was verpasst? Ich dachte eigentlich, dass das mit public Vererbung und friend geht.
-
hast du. auf das,was in base private ist, hat man in derived keinerlei zugriff.
-
Wieso kompiliert mein Compiler aber sowas? Kannst du mir mal die Stelle im Standard verraten, wo das steht. Ich bin gerade zu faul zum Suchen.