O
Gumble schrieb:
hm, dann kann ich nimmer auf std::cout zugreifen und er wirft mir noch ein paar Fehler wegen '<<'
Von std::cout muss deine Klasse ja auch nichts wissen Wenn du an anderer Stelle cout/cin etc. brauchst, ist <iostream> dafür der richtige Header.
Dachte immer, ich steck alle includes in den Header - was ist nun usus?
Am besten so wenig #includes wie möglich im Header. Mit Vorausdeklarationen und dem "pimpl-Idiom" kann man da sogar eine Wissenschaft für sich draus machen, damit größere Projekte schneller kompilieren und seltener neu kompiliert werden müssen, wenn sich Header ändern.
Hab ich wirklich Nachteile wenn ich das selber definier?
Du musst sie halt erstmal alle tippen. Danach gilt: Code, den man nicht tippt, muss man nicht warten Als einziger direkter Nachteil fällt mir hier nur ein, dass die automatisch generierten Versionen inline und dadurch vermutlich schneller wären (vor allem der Destruktor), wenn der Linker das nicht merkt und selber gerade biegt.
soll ich nur eine Funktion (die mit der Referenz als Rückgabe) verwenden? Gibt das irgendwelche Vor- oder Nachteile?
Nein, auf jeden Fall brauchst du zwei Funktionen: Eine, mit der man den Wert ändern kann und eine, mit der man den Wert einer "const Complex" auslesen kann. Das finde ich schon gut, wie es ist.
Meister Meyers aus dem Effektiv C++ Buch hat das doch empfohlen, also lass ich es lieber so zur sicherheit
Hm ja. Aber überleg mal, wofür der in EffC++ vermutlich gut war und warum das hier nicht zutrifft
