Softwareentwicklung in C++ - ASC

354 12. Operator Overloading
MathVector , id = 0 : standard constructor
MathVector , id = 0 : operator ∗
MathVector , id = 1 : copy constructor , other id = 0
MathVector , id = 1 : d e s t r u c t o r
MathVector , id = 0 : d e s t r u c t o r
Das Makefile zu diesem Meisterwerk findet man erwartungsgemäß auf der
beiliegenden CD-ROM unter dem Namen MathVectorV2TestMakefile.
Vorsicht Falle: Immer wenn man glaubt, endlich eine gute Lösung gefunden
zu haben, stolpert man über einen weiteren Aspekt, der die gute
Lösung dann doch nicht so gut aussehen lässt. So auch bei unserer Operatorfunktion:
Nehmen wir einfach an, wir würden eine spezielle Vektor-Klasse
implementieren, die von unserem Basis Vektor abgeleitet ist und die aus irgendwelchen
Gründen eine geringfügig andere Implementation der Subtraktion
brauchen würde als die Basis. Nun gut, mögen jetzt viele Leser sagen,
dann implementieren wir eben für die Ableitung eine neue Operatorfunktion
für die Subtraktion und die Sache ist gegessen. Leider ist aber die Situation
nicht ganz so einfach. Erinnern wir uns daran, dass wir aus Gründen
der Polymorphismus-Eigenschaft von Klassen das dynamic Binding mittels
virtual kennen gelernt haben. Man kann aber nur Methoden als virtual
deklarieren, mit Funktionen geht das nicht! Das bedeutet, dass unsere Operatorfunktion
den Polymorphismus durchbricht! In unserem Fall haben wir
Glück, denn die Operatorfunktion ist so implementiert, dass sie in Wirklichkeit
nicht selbst rechnet, sondern den virtual Operator * aufruft. Das muss
aber nicht immer der Fall sein.
Wie sorgen wir also nun dafür, dass dieses Loch in der Implementation
gestopft wird? Ganz einfach: Wir führen die Konvention ein, dass eine
Operatorfunktion niemals selbst eine Operation durchführen darf, sondern
immer nur eine Delegation an eine virtual Methode vornehmen darf. In
dieser steckt dann erst wirklich die Logik der Operation.
Ein weiteres Beispiel zu diesem Thema, bei dem es essentiell ist, diese
Konvention einzuhalten, findet sich in Abschnitt 16.6.
12.2 Typumwandlungen
Oft passiert es, dass verschiedene Datentypen zueinander bis zu einem gewissen
Grad kompatibel sind und dementsprechend auch sinnvoll ineinander umgewandelt
werden können. Nehmen wir als kleines Beispiel zur Demonstration
eine Klasse RangeControlledInt, die einen Ganzzahlenwert repräsentiert,
dessen gültiger Wertebereich von der Applikation kontrolliert werden kann.
Einem Objekt dieser Klasse wird beim Konstruieren der gewünschte gültige
Wertebereich übergeben. Ansonsten soll ein solches Objekt voll kompatibel
zu einem int sein, mit der einzigen Ausnahme, dass es die Zuweisung von
Werten, die außerhalb des erlaubten Bereichs liegen, nicht zulässt und mit