[gelöst] Überladen des ++ Operators (Prä-/Postfix)
-
Er kann es ja mit dem Warnhinweis bei eBay reinstellen, dass dieses Buch fehlerhaft ist und für den Einstieg in die Programmiersprache sehr ungeeignet ist. Das würde noch etwas schlechte Werbung machen und würde manchen Leuten, die nach Büchern suchen, evtl. die Augen öffnen.
Und zur Didaktik-Diskussion: Ich bin auch kein großer Fan davon Statements zu benutzen, die erst später erklärt werden. Der Anfänger stört sich leicht an jeder Kleinigkeit. Ich fände es besser zu sagen, dass der getter an dieser Stelle nicht die eleganteste Variante ist und man später etwas Besseres kennen lernt.
Hat natürlich auch seine Nachteile, da der Leser ständig nicht-elegante Codefetzen sieht, das ist pädagogisch wohl nicht wertvoll. Im Kapitel zu Operatorenüberladung könnte man natürlich die Reihenfolge ändern, sodass operator<< vor operator++ eingeführt wird. Aber auch hier muss man sich überlegen, ob man nicht etwas vergisst. Möglicherweise gibt es keine Operatoren-Einführungsreihenfolge, die sich gut hintereinanderschalten lässt. Dann muss man etwas nutzen, was man erst später erklärt, auch wenn das nicht optimal ist.
-
Eisflamme schrieb:
Hat natürlich auch seine Nachteile, da der Leser ständig nicht-elegante Codefetzen sieht, das ist pädagogisch wohl nicht wertvoll. Im Kapitel zu Operatorenüberladung könnte man natürlich die Reihenfolge ändern, sodass operator<< vor operator++ eingeführt wird. Aber auch hier muss man sich überlegen, ob man nicht etwas vergisst. Möglicherweise gibt es keine Operatoren-Einführungsreihenfolge, die sich gut hintereinanderschalten lässt. Dann muss man etwas nutzen, was man erst später erklärt, auch wenn das nicht optimal ist.
Das ist eben die Herausforderung, wenn man Lehrbücher schreiben möchte. Andere Lehrbücher (insbesondere die, die hier immer gelobt werden), bekommen das schließlich hin. Aber wie volkard schon passend sagte, kann man solche Bücher eben nicht in einer Nacht in die Tastatur kotzen.
-
error17 schrieb:
Hier wird immer so auf JW herumgetrampelt. Dazu gibt es hier
http://www.file-upload.net/download-3634225/raetsel.txt.html
ein kleines Rätsel...Welches Buch ist es denn? Könnte C++ in 21 Tagen sein, oder (ich habe es nie wirklich durchgearbeitet, obwohl es seit Jahren im Regal steht)?
Ich poste mal den Inhalt der Datei, damit sie sich nicht jeder runterladen muss:
error17 schrieb:
Anbei eine Auswahl von Programmbeispielen mit groben Fehlern aus einem aktuellen Lehrbuch. Das Buch hat nicht mal ein Literaturverzeichnis, will aber ein Fachbuch sein. Ein kleines Rätsel: Welches Buch ist es?
*****************************************************
Seite 325, mensch.h (Auszug)class Mensch { private: // Eigenschaften der Klasse Mensch char *name; // Speicher wird zur Laufzeit reserviert int len; // Länge des Namen unsigned int alter; bool geschlecht; //0 = männlich; 1 = weiblich public: Mensch( const char*, unsigned int, bool ); // ... Rest weggelassen }
Kritik: interne Nutzung von char* statt string. Nachteil 1: eigenes
Memory-Management notwendig, Nachteil 2: fehleranfällig (der Autor
kommt selbst damit nicht klar, wie noch zu sehen)*****************************************************
Seite 327void Mensch::erzeuge(const char* n, unsigned int a, bool g){ // ... vom Konstruktor reservierten Speicher freigeben delete [] name; // Speicher für neuen Namen anfordern len = strlen(n); name = new char[len+1]; strcpy( name, n ); alter = a; geschlecht = g; }
Kritik: Der Code ist nicht exception-sicher. Wenn es ein Problem bei der Speicherbeschaffung gibt, ist das Objekt zerstört, weil vorher delete [] aufgerufen wird. Diese Art Problem durchzieht das ganze Buch.
*****************************************************
Seite 331:
Mensch person1("Adam", 22, Mensch::MANN );
Kritik: Dazu muss man den Konstruktor sehen (Seite 325):
Mensch( const char*, unsigned int, bool );
Obwohl nur ein bool Parameter vorhanden ist, wird ein enum übergeben. Dabei wird die ganz interne Kenntnis ausgenutzt, dass Mensch::MANN implizit auf 0 bzw. false abgebildet wird. D.h. die Reihenfolge MANN, FRAU in der enum-Deklaration
ist entscheidend!*****************************************************
Seite 331:// Zuweisungsoperator überladen - Defintion Mensch& Mensch::operator=( const Mensch& person ) { // Auf Selbst-Zuweisung überprüfen if( this == &person ) { return *this; } else { len = person.len; name = new char[len+1]; strcpy( name, person.name ); alter = person.alter; geschlecht = person.geschlecht; return *this; } }
Kritik: Memory-Leak. Der alte Speicher wird nicht gelöscht. Dieser Fehler kommt oft vor.
*****************************************************
Seite 361: String-Klasse mit char*-Attribut, aber OHNE Zuweisungsoperator, obwohl der schon behandelt wurde. Eine Zuweisung führt daher zum Memory-Leak und fehlerhaften Destruktor-Aufruf.
*****************************************************
Seite 375 ganz oben: ( Postfix-Operator ++)myComplex& operator++(int) { // Für den Rückgabewert myComplex tmp(*this); // Originalwerte ändern _real++; _image++; // ursprünglichen wert zurückgeben return tmp; }
Kritik: Crash-Gefahr! Rückgabe einer lokalen Variablen per Referenz!
*****************************************************
Seite 379:
// Überladung des Indexoperators const char& operator[](unsigned int index) const { static char q = '?'; // Indexüberprüfung if( (index >= 0) && (index < len) ) return buffer[index]; // Im Fehlerfalle ein Fragezeichen zurückgeben return q; }
Kritik:
-
Die Abfrage (index >= 0) ist schwachsinnig, weil index als unsigned int IMMER >= 0 ist.
-
Der Index-Operator blödsinnig konstruiert. Wenn z.B. die Position 1000 im String "Wie geht es Dir? Gut?" abgefragt wird, ist dem Aufrufer nicht klar, ob er ein Fragezeichen gefunden hat oder ob ein Fehler vorliegt. Das hat natürlich mit C++ nix zu tu, so etwas ist in jeder Programmiersprache unsinnig.
*****************************************************
Seite 471, Zeichnung: Dass Wurst und Brot von Supermarkt erben, hat mit objektorientiertem Design nichts zu tun. Der Autor sollte mal ein Buch zur Objektorientierung lesen.
*****************************************************
es gibt noch mehr ... ... aber nicht hier. Das kann jemand anders ergänzen.
-
-
yahendrik schrieb:
Welches Buch ist es denn? Könnte C++ in 21 Tagen sein, oder (ich habe es nie wirklich durchgearbeitet, obwohl es seit Jahren im Regal steht)?
Das Beispiel zum Überladen des Operators ++ ist ja das gleiche wie in diesem Thread, also wird's wohl C++ von A bis Z sein. Aber die erste Ausgabe, wo JW noch eine Referenz auf ein lokales Objekt zurück gibt.
Seite 471, Zeichnung: Dass Wurst und Brot von Supermarkt erben, hat mit objektorientiertem Design nichts zu tun. Der Autor sollte mal ein Buch zur Objektorientierung lesen.
Allein um dieses Schmankerl im Original lesen zu können, würde es sich ja schon lohnen den Threadersteller via Ebay von seiner Ausgabe zu erlösen.
-
SeppJ schrieb:
Seite 471, Zeichnung: Dass Wurst und Brot von Supermarkt erben, hat mit objektorientiertem Design nichts zu tun. Der Autor sollte mal ein Buch zur Objektorientierung lesen.
Allein um dieses Schmankerl im Original lesen zu können, würde es sich ja schon lohnen den Threadersteller via Ebay von seiner Ausgabe zu erlösen.
Sucht mach bei Google nach
"Wurst Brot Supermarkt c++"
. Da findet man eine Menge witzige Kommentare zu dem Thema:jokester auf .spieleprogrammierer.de schrieb:
Der Autor hat OOP nicht verstanden, scheint Schüler bei Herrn Bebel gewesen zu sein. So sind Würste und Brote Supermärkte, und ein Wurstbrot ist angeblich eine Wurst. Man könnte die Liste fast ewig weiterführen...
-
Naja, man muss dazu sagen, dass die Definition von "ist-ein" im objektorientierten Sinn sich nicht vollständig mit der umgangssprachlichen deckt. Ein Quadrat ist umgangssprachlich ein Rechteck, aber objektorientiert würde man eher das Rechteck vom Quadrat ableiten, weil ein Quadrat nicht alles kann, was ein Rechteck kann (ungleich lange Seiten haben, zum Beispiel). Vielleicht wäre der Zusammenhang der Vererbung besser formuliert als "ist-eine-Erweiterung-von", in welchem Sinne man ein Rechteck als Verallgemeinerung eines Quadrats auffassen kann.
Da meine Versuche, in einer Wurst einkaufen zu gehen, allerdings bislang erfolglos blieben und ich es eher selten erlebt habe, dass jemand ein Brot mit Wurstbroten belegt, bleibt die Absurdität des Beispiels vorerst bestehen.
-
seldon schrieb:
Naja, man muss dazu sagen, dass die Definition von "ist-ein" im objektorientierten Sinn sich nicht vollständig mit der umgangssprachlichen deckt. Ein Quadrat ist umgangssprachlich ein Rechteck, aber objektorientiert würde man eher das Rechteck vom Quadrat ableiten, weil ein Quadrat nicht alles kann, was ein Rechteck kann (ungleich lange Seiten haben, zum Beispiel). Vielleicht wäre der Zusammenhang der Vererbung besser formuliert als "ist-eine-Erweiterung-von", in welchem Sinne man ein Rechteck als Verallgemeinerung eines Quadrats auffassen kann.
-
seldon schrieb:
objektorientiert würde man eher das Rechteck vom Quadrat ableiten, weil ein Quadrat nicht alles kann, was ein Rechteck kann (ungleich lange Seiten haben, zum Beispiel).
Alte Leier. Je nach Betrachtungsweise kann man das eine vom anderen, das andere vom einen, oder keins voneinander ableiten.
-
Ich hab den Threadtitel eben editiert [gelöst]... da das Problem sich erledigt hat. Ich war eben in der Uni-Bibliothek und hab mir den Breymann ausgeliehen und auch gleichmal reingelesen. Eine Schande das der Herr Wolf überhaupt Bücher veröffentlichen darf, ich werde am besten mal eine negativ Bewertung bei amazon verfassen. Ich könnte mich in Grund und Boden ärgern soviel Zeit mit diesem Drecksbuch vergeudet zu haben.
-
klingt.net schrieb:
Eine Schande das der Herr Wolf überhaupt Bücher veröffentlichen darf
Meinungsfreiheit ist ein hohes Gut. Aber vielleicht verklagt ja mal jemand den Verlag wegen Betrugs (Täuschung hinsichtlich der Möglichkeit mit diesem Buch C++ lernen zu können) :p
-
Da meine Versuche, in einer Wurst einkaufen zu gehen, allerdings bislang erfolglos blieben und ich es eher selten erlebt habe, dass jemand ein Brot mit Wurstbroten belegt, bleibt die Absurdität des Beispiels vorerst bestehen.
Ich musste erheblich schmunzeln...