[gelöst] Überladen des ++ Operators (Prä-/Postfix)

Michael E.

EOutOfResources schrieb:

Michael E. schrieb:

[...]

Er soll's lassen wenn er's nicht richtig macht...

Tut mir Leid, aber das ist Blödsinn. Sobald Klassen eingeführt wurden, will ich Member ausgeben. Soll dann direkt operator<< überladen werden? Am besten noch bevor der Leser weiß, was public und private heißen.

Michael E.

volkard schrieb:

Michael E. schrieb:

EOutOfResources schrieb:

Die Art es auszugeben gefällt mir .

War klar, dass du daran rummeckerst. Es weiß doch jedes Kind, dass man operator<<(ostream&, MyType) auf jeden Fall schon erklären muss, bevor die erste eigene Ausgabe gemacht werden soll, insbesondere vor operator+ .

Für dieses Beispiel erst den op<< bauen. Dann erst den op++ bauen. Das sagt doch nicht, daß man den op<< bauen sollte, bevor man einen op<< benutzt.
Aber das Beispiel ist eh nicht gut gewählt.
Eine gute Reihenfolge der Lehrinhalte zurechtzuschuggern ist schon mühsam. Aber da muß ein Autor durch.

Die Ausgabe hier ist unabhängig von op++. s. vorigen Post.

volkard

Michael E. schrieb:

EOutOfResources schrieb:

Michael E. schrieb:

[...]

Er soll's lassen wenn er's nicht richtig macht...

Tut mir Leid, aber das ist Blödsinn. Sobald Klassen eingeführt wurden, will ich Member ausgeben. Soll dann direkt operator<< überladen werden? Am besten noch bevor der Leser weiß, was public und private heißen.

Tut mir Leid, aber das ist Blödsinn.

cout << "val1: " << val1++ << '\n';
cout << "val2: " << ++val2 << '\n';

kann man schon verlangen, damit dieses Beispiel nicht ganz so traurig ist.

Das hat schon wieder nichts damit zu tun, daß man den op<< von Anfang bauen müßte. Strohmannargument zum zweiten mal.

volkard

Michael E. schrieb:

Die Ausgabe hier ist unabhängig von op++. s. vorigen Post.

Deswegen kann er ja auch die Reihenfolge so machen, daß der op<< VOR dem op++ gebastelt wird. Wo ist denn das Problem, es wenigsten ein Bißchen ordentlich zu machen, außer, daß man dann ein Buch nicht in einer Nacht in die Tastatur kotzen kann.

Michael E.

volkard schrieb:

Michael E. schrieb:

Die Ausgabe hier ist unabhängig von op++. s. vorigen Post.

Deswegen kann er ja auch die Reihenfolge so machen, daß der op<< VOR dem op++ gebastelt wird. Wo ist denn das Problem, es wenigsten ein Bißchen ordentlich zu machen, außer, daß man dann ein Buch nicht in einer Nacht in die Tastatur kotzen kann.

Und was ist zu dem Zeitpunkt, bevor Operatorüberladung eingeführt wurde?

EOutOfResources

Michael E. schrieb:

Und was ist zu dem Zeitpunkt, bevor Operatorüberladung eingeführt wurde?

Schreibt er's hin und sagt, dass das später behandelt wird.

volkard schrieb:

Wo ist denn das Problem, es wenigsten ein Bißchen ordentlich zu machen, außer, daß man dann ein Buch nicht in einer Nacht in die Tastatur kotzen kann.

Der Satz ist auch eine Signatur wert .

volkard

Michael E. schrieb:

Und was ist zu dem Zeitpunkt, bevor Operatorüberladung eingeführt wurde?

Arbeitszeit beginn(8,15);
Arbeitszeit ende(17,30);
cout << berechneDifferenzInMinuten(ende,beginn) << '\n';

Uups, ich mußte ja gar keine Attribute ausgeben. Eine böse Klasse. Die verkettete Liste und der Vector mußten auch keine Attribute ausgeben. Das Spiel auch nicht. Hmm. Schon komisch. Vielleicht macht man Klassen, die Attribute ausgeben wollen, doch erst nach dem Schreiben eines op<<? Aber da bewegen wir uns schon hinein in die Planung eines Buches, das will ich nicht mir Dir weitertreiben.

Michael E.

EOutOfResources schrieb:

Michael E. schrieb:

Und was ist zu dem Zeitpunkt, bevor Operatorüberladung eingeführt wurde?

Schreibt er's hin und sagt, dass das später behandelt wird.

volkard schrieb:

Arbeitszeit beginn(8,15);
Arbeitszeit ende(17,30);
cout << berechneDifferenzInMinuten(ende,beginn) << '\n';
Uups, ich mußte ja gar keine Attribute ausgeben. Eine böse Klasse. Die verkettete Liste und der Vector mußten auch keine Attribute ausgeben. Das Spiel auch nicht. Hmm. Schon komisch. Vielleicht macht man Klassen, die Attribute ausgeben wollen, doch erst nach dem Schreiben eines op<<? Aber da bewegen wir uns schon hinein in die Planung eines Buches, das will ich nicht mir Dir weitertreiben.

Zuerst Iteratoren zu definieren, ist natürlich noch besser.

volkard

Michael E. schrieb:

Zuerst Iteratoren zu definieren, ist natürlich noch besser.

Wie kommt er jetzt auf Iteratoren?

EOutOfResources

Daneben.

Michael E.

volkard schrieb:

Michael E. schrieb:

Zuerst Iteratoren zu definieren, ist natürlich noch besser.

Wie kommt er jetzt auf Iteratoren?

Irgendwie müssen die Daten ja nach außen kommen. Und Getter wie vector::front, die Referenzen zurückgeben, sind nur selten sinnvoll. Etc. pp.

Aber bitte, übertrag dein Beispiel auf den Originalcode.

Edit:

EOutOfResources schrieb:

Wahrscheinlich war er durch die Bezeichner " beginn " und " ende " irritiert.

Heute mal nicht.

volkard

Michael E. schrieb:

Irgendwie müssen die Daten ja nach außen kommen.

Dem Vector reicht zunächst at(size_t).

Michael E. schrieb:

Und Getter wie vector::front, die Referenzen zurückgeben, sind nur selten sinnvoll.

Bei der Liste, die einen Stack implementiert: Doch, aber klaro. Ja keine Iteratoren!

Michael E. schrieb:

Etc. pp.

Und überhapt. Du machst Dir zu wenig Gedanken bei diesem Thema; alles wirkt unstimmig und nur so dahergesagt. Bin raus.

Michael E.

volkard schrieb:

Michael E. schrieb:

Irgendwie müssen die Daten ja nach außen kommen.

Dem Vector reicht zunächst at(size_t).

Wo ist der Unterschied zu front?

Michael E. schrieb:

Etc. pp.

Und überhapt. Du machst Dir zu wenig Gedanken bei diesem Thema; alles wirkt unstimmig und nur so dahergesagt. Bin raus.

Ich brauch mir keine Gedanken um alle möglichen anderen Klasse zu machen. Du bist doch mit denen angekommen. Bezieh dich doch mal auf die Originalklasse, die ja schließlich kritisiert wurde.

klingt.net

Hätte nicht gedacht das aus dem Beitrag heute noch 4 Seiten werden...
Der Codeschnippsel ist übrigens 1:1 aus dem Buch kopiert, so ein seltsames Bsp. hätte ich mir selber nicht einfallen lassen (können).
int main (void) {... würde ich selber auch nie so schreiben :p
Falls jemand Interesse hat, das Buch ist absofort für einen geringen Obulus käuflich bei mir zu erwerben
Ich hoffe zumindest ich bekomm bei eBay noch den Neurpreis dafuer, immerhin werden dort Sachen gebraucht teurer als neu verkauft.

Klopapier kriege ich in besserer Qualität in jedem Supermarkt.

Du hast mit diesem Buch richtig ins Klo gegriffen, und du solltest den Verlust als Lehrgeld auffassen. Wenn du jemanden findest, der das Buch aus humoristischen Gründen archivieren will, ist das eine Sache, aber bitte verschacher den Mist jetzt nicht an einen ahnungslosen Anfänger, der den Blödsinn darin nicht als solchen erkennen kann. Sonst dauert es nicht lange, bis die nächste arme Seele hier im Forum auftaucht und nach kurzer Zeit erkennen muss, dass der Typ, von dem sie ihr Buch auf eBay gekauft hat, es aus einem bestimmten Grund loswerden wollte (und es womöglich an den nächsten Gimpel weitervertickt). Tu der Gesellschaft einen Gefallen und mach Altpapier draus.

Bitte.

314159265358979

seldon schrieb:

Klopapier kriege ich in besserer Qualität in jedem Supermarkt.

Du hast mit diesem Buch richtig ins Klo gegriffen, und du solltest den Verlust als Lehrgeld auffassen. Wenn du jemanden findest, der das Buch aus humoristischen Gründen archivieren will, ist das eine Sache, aber bitte verschacher den Mist jetzt nicht an einen ahnungslosen Anfänger, der den Blödsinn darin nicht als solchen erkennen kann. Sonst dauert es nicht lange, bis die nächste arme Seele hier im Forum auftaucht und nach kurzer Zeit erkennen muss, dass der Typ, von dem sie ihr Buch auf eBay gekauft hat, es aus einem bestimmten Grund loswerden wollte (und es womöglich an den nächsten Gimpel weitervertickt). Tu der Gesellschaft einen Gefallen und mach Altpapier draus.

Bitte.

Kann man nur zustimmen

pumuckl

Manchmal möchte man dem Verlag ein Pamphlet schreiben, in dem man erklärt, dass sie viele andere Bücher nicht verkaufen, weil sie J.W. verkaufen...

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...

Eisflamme

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.

SeppJ

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.