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

Michael E.

CStoll schrieb:

Zum Ersten: Wer kommt denn auf die clevere Idee, eine static-Variable als temporären Wert für den Post-Inkrement zu verwenden?

Wahrscheinlich hat ihm jemand gesagt, dass er keine Referenzen auf temporäre Objekte zurückgeben darf. Da hat er die Lebensdauer etwas verlängert

Mal abgesehen von den ganzen codetechnischen Mängeln: Was soll Inkrementieren bei ner komplexen Zahl überhaupt sein? Ich hätte höchstens erwartet, dass der Realteil inkrementiert wird. So siehts eher aus nach Exkrementieren.

klingt.net schrieb:

Da das nicht der erste Fehler ist den ich in dem Buch entdeckt habe, bei den anderen konnt ich mir selber noch weiterhelfen, wird das wohl zu eBay wandern.

Bitte nicht. Am Ende kauft das noch jemand.

CStoll

Michael E. schrieb:

CStoll schrieb:

Zum Ersten: Wer kommt denn auf die clevere Idee, eine static-Variable als temporären Wert für den Post-Inkrement zu verwenden?

Wahrscheinlich hat ihm jemand gesagt, dass er keine Referenzen auf temporäre Objekte zurückgeben darf. Da hat er die Lebensdauer etwas verlängert

Dann sollte man ihm als nächstes beibringen, daß es bei manchen Funktionen nicht sinnvoll ist, Referenzen zurückzugeben

@volkard: Ist es dir auch schon aufgefallen? JW ist schon lange genug hier verrufen

SeppJ

CStoll schrieb:

@volkard: Ist es dir auch schon aufgefallen? JW ist schon lange genug hier verrufen

Bisher galt er aber nur als unfähig, nun sind wir schon auf der Stufe wo man annehmen muss, dass er das mit Absicht macht.

volkard

CStoll schrieb:

Dann sollte man ihm als nächstes beibringen, daß es bei manchen Funktionen nicht sinnvoll ist, Referenzen zurückzugeben

Wartet, bis C++ einen Garbage-Collector hat. *grusel*

EOutOfResources

Die Art es auszugeben gefällt mir .

volkard

Dann merke ich noch an, daß der op++(int) den Nutzcode des op++() dupliziert, statt ihn aufzurufen.

SeppJ

volkard schrieb:

Dann merke ich noch an, daß der op++(int) den Nutzcode des op++() dupliziert, statt ihn aufzurufen.

Ich glaube alle Schwächen im Code auf zu zählen, wird ein lange Liste . Ich mache mal weiter: Initialisierungsliste.

Michael E.

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

Michael E.

SeppJ schrieb:

volkard schrieb:

Dann merke ich noch an, daß der op++(int) den Nutzcode des op++() dupliziert, statt ihn aufzurufen.

Ich glaube alle Schwächen im Code auf zu zählen, wird ein lange Liste . Ich mache mal weiter: Initialisierungsliste.

int main(void)

EOutOfResources

Michael E. schrieb:

[...]

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

volkard

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.

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.