Softwareentwicklung in C++ - ASC

15.2 Unions im OO Kontext 469
durch die entsprechenden Typumwandlungs-Operatoren in den Zeilen 95–110
ersetzt.
Die Implementationen des Copy Constructors und des Zuweisungsoperators
bergen keine Neuigkeiten, also sehen wir uns nur noch kurz die Verwendung
unserer gekapselten Union an:
• In Zeile 161 wird setValue mit einem uint32 Parameter aufgerufen. Der
explizite Cast ist notwendig, da ja 10 einfach als int interpretiert wird und
somit der Compiler vor einem Ambiguitätsproblem stehen würde.
• In den Zeilen 165–166 wird korrekt auf die Union zugegriffen und dementsprechend
funktioniert alles wie geplant.
• In den Zeilen 167–168 jedoch wird versucht einen double Wert zu lesen,
der hier ungültig ist. Zum Glück gibt’s das try ... catch Konstrukt :-).
Anzumerken wäre hier noch, dass Fehlermeldungen wie in den Zeilen 174
und 189 im Normalfall immer auf cerr und nicht auf cout geschrieben
werden müssen. Im Demoprogramm wurde nur deshalb auf cout geschrieben,
um die Reihenfolge der einzelnen Ausgaben nicht durcheinander zu
bringen.
• In den Zeilen 177–190 findet dasselbe Spielchen noch einmal statt, nur eben
hier mit einem double Wert.
Dass meine Beschreibung der Vorgänge nicht frei erfunden ist, sieht man am
folgenden Output, den das Programm liefert:
DummyUnion constructor
t r y i n g uint32 value : 1 0
t r y i n g double value : oops − t r i e d to a c c e s s wrong type . . .
t r y i n g double value : 2 0 . 5
t r y i n g uint32 value : oops − t r i e d to a c c e s s wrong type . . .
DummyUnion d e s t r u c t o r
Obwohl wir hier also offensichtlich einen Weg gefunden haben, Unions einigermaßen
sicher zu machen, sollte man sich einige Gedanken um deren
Verwendung bzw. um die Vermeidung derselben machen:
Wenn wir hier einmal ganz bestimmte und besondere Vorgaben durch die
Hardware oder durch Fremdsysteme außen vor lassen, ist der einzige Grund
für die Verwendung von Unions die damit erreichbare Speicherersparnis.
Überlegt man allerdings, dass der von einer Union benötigte Speicher
immer ihrem größten Member entspricht, dann kommt man zu folgendem
Schluss: Sollten alle Members einigermaßen gleich groß sein, dann erreicht
man eine sinnvolle Ersparnis. Sollte es jedoch zumindest einen Member geben,
der im Vergleich zu den anderen sehr groß ist, dann ist die Ersparnis
nicht mehr wirklich gegeben. Ganz im Gegenteil! Man kann hierbei nämlich
je nach Anwendung sogar eine große Speicherverschwendung bewirken, denn
auch für die kleinen Members wird immer der Platz des bzw. der großen
belegt!
Aus dieser Überlegung heraus kommt man schnell zu dem Schluss, dass es
in solchen Fällen besser wäre, mit einer vernünftigen Klassenhierarchie und
unter sinnvoller Ausnützung der Polymorphismus-Eigenschaften zu arbeiten.