Softwareentwicklung in C++ - ASC

Klaus Schmaranz 

Softwareentwicklung in C++ 

18. November 2002 

Springer-Verlag 

Berlin Heidelberg NewYork 

London Paris Tokyo 

Hong Kong Barcelona 

Budapest

Vorwort des Autors 

C ++ ist aus vielen guten Gründen derzeit eine der am weitesten verbreiteten 

objektorientierten Programmiersprachen. Einer der wichtigsten der angesprochenen 

vielen guten Gründe für diese Verbreitung ist sicherlich die Flexibilität 

der Sprache, die es erlaubt praktisch von tiefster Maschinenebene 

bis zu beliebig hohen Abstraktionslevels alle Probleme auf eine saubere und 

konsistente Art anpacken zu können. 

Durch seine mittlerweile schon recht lange Geschichte (bezogen auf die 

schnelllebige Welt der Informatik) hat der Sprachstandard von C ++ im Lauf 

der Zeit bereits einige kleine und größere Änderungen hinter sich gebracht. 

Alle diese Anpassungen waren in meinen Augen immer sehr durchdachte Verbesserungen, 

die dazu geführt haben, dass man gewisse Dinge noch eleganter 

lösen konnte als zuvor. Vor allem hatten die angesprochenen Veränderungen 

zum allergrößten Teil den Charakter von Erweiterungen, es wurden also 

keine künstlichen Inkompatibilitäten erzeugt, die ein moving Target in der 

Entwicklung dargestellt hätten. Ich bin selbst in die C ++ Entwicklung bereits 

zu Zeiten der sehr frühen Versionen eingestiegen und war begeistert von den 

Möglichkeiten, elegante Lösungen für Probleme zu konzipieren. Jetzt, viele 

Jahre später, bin ich von C ++ in seiner heutigen Form mehr begeistert denn 

je. 

Eines soll allerdings auch nicht verschwiegen werden: Um C ++ wirklich 

zu beherrschen, braucht man viel Erfahrung! Vor allem muss man den Sinn 

hinter den einzelnen Konstrukten der Sprache wirklich verstanden haben, um 

sie richtig einsetzen zu können. Die Gefahr, gewisse Features aufgrund von 

Unverständnis zu missbrauchen und dadurch unsauberen Code zu erzeugen, 

ist nicht gering! 

Leider muss ich sagen, dass gar nicht so wenige Entwickler, die C ++ einsetzen, 

die Sprache nicht in vollem Umfang beherrschen. Jedoch, und das ist 

genau das Problematische daran, glauben die meisten dieser Entwickler, dass 

sie gut mit C ++ umgehen könnten. Aus diesem Grund habe ich versucht, die 

Erfahrungen aus meinen eigenen Fehlern sowie die Erfahrungen mit Fehlern 

und Unverständnis Anderer in dieses Buch einzubringen. 

Das Buch ist nach bestem Wissen und Gewissen so gestaltet, dass C ++ 

und die wichtigen Aspekte, die erst eine saubere Objektorientierung ausmachen, 

so aufbauend und gut strukturiert wie möglich vermittelt werden.

VI Vorwort des Autors 

Es ist das vorliegende Werk auch zusätzlich noch ein Resultat aus seiner 

Verwendung im Rahmen eines im Studium sehr früh angesiedelten Programmierpraktikums 

an der Technischen Universität Graz. Aus den Reihen der 

Studierenden, die quasi als “Versuchskaninchen” fungierten kamen sehr viele 

und sehr fruchtbare Anregungen, was den Aufbau und gewisse Erklärungen 

betrifft. Das Buch wurde aber nicht nur von Leuten gelesen, die C ++ erst lernen 

mussten, sondern auch von einigen Leuten, die bereits echte C ++ Profis 

sind. Von beiden Lesergruppen gab es durchgehend sehr positive Reaktionen, 

sowohl was die fachliche Seite als auch was die Strukturierung und die leserische 

Seite betrifft (der Begriff “literarische” Seite wäre wohl doch etwas zu 

hoch gegriffen :-)). Auch die Profis waren angetan davon, dass sie in einigen 

Punkten durch die Lektüre dieses Buchs ein tieferes Verständnis für gewisse 

Dinge vermittelt bekamen und entsprechend etwas dazugelernt haben. 

Obwohl es in diesem Buch naturgegebenermaßen sehr stark um technische 

Aspekte geht, habe ich versucht, es so angenehm lesbar wie möglich zu 

machen. Ich bin einfach der Ansicht, dass Fachbücher nicht nur trocken irgendwelche 

Fakten vermitteln sollen, sondern dass man auch Spaß am Lesen 

haben muss. Auf diese Art hat man gleich viel mehr Motivation, das Gelernte 

auch wirklich in die Tat umzusetzen. 

Einen Aspekt zum Umgang mit diesem Buch, der im Prinzip für alle 

Fachbücher Gültigkeit besitzt, möchte ich hier noch kurz ansprechen: Es 

steckt eine riesige Menge an Information auf den einzelnen Seiten. Je nach 

Wissensstand der Leser ist es im Normalfall praktisch nicht möglich, diese 

gesamte Information auch wirklich bei einmaligem Durchlesen zu verinnerlichen. 

Deshalb ist es sehr geistreich, nach einiger Zeit das Buch erneut zur 

Hand zu nehmen und es noch einmal durchzugehen. Einer meiner Studierenden 

hat dies mit folgender Aussage auf den Punkt gebracht: 

Ich habe das Buch gelesen und mich mit allen darin beschriebenen Dingen 

gespielt, bis ich geglaubt habe, sie zu verstehen. Danach habe ich das Buch 

als Nachschlagewerk verwendet. Nach einiger Zeit dachte ich mir, ich lese es 

einfach zum Spaß noch einmal von vorne bis hinten durch. Und bei diesem 

zweiten Mal sind mir erst viele Dinge aufgefallen, die bisher spurlos an mir 

vorüber gegangen sind. Genau diese Dinge aber waren die wirklich Wichtigen 

für die Praxis. 

In diesem Sinne wünsche ich allen Lesern viel Spaß bei der Lektüre und 

einen guten Einstieg in die Welt von C ++. 

Klaus Schmaranz Graz im August 2002

Danksagung 

Vorwort des Autors VII 

Ein Buch zu schreiben ist ganz grundsätzlich einmal sehr viel Arbeit. Vor 

allem ist es Arbeit, die man nicht durchgehend allein im stillen Kämmerlein 

erledigen kann, denn einerseits wird man betriebsblind und andererseits 

würde man zwischendurch mehr als nur einmal die Nerven nach einer durchtippten 

Nacht wegwerfen. Aus diesem Grund gilt mein Dank in der Folge 

nicht nur den Personen, die in Form von Diskussionen und Kritik den Inhalt 

direkt und nachhaltig beeinflusst haben und den Personen, die das Buch 

lektoriert haben. Mein Dank gilt ebenso allen Personen, die für mich immer 

ansprechbar waren, wenn mein Nervenkostüm wieder einmal nicht im 

allerbesten Zustand war. Einige der nachstehend angeführten Leute haben 

in diesem ganzen Prozess auch mehr als nur eine Rolle übernommen. 

Ich kann und möchte keine Reihung der Wichtigkeit der einzelnen Beteiligten 

vornehmen, denn dies ist ein Ding der Unmöglichkeit. Jede einzelne 

Person war ein wichtiger Teil in einem komplizierten Puzzle, das nach seiner 

Zusammensetzung das fertige Buch ergeben hat. Wie es bei Puzzles üblich 

ist, hinterlässt jedes fehlende Stück ein Loch und jedes einzelne Loch stört 

das Gesamtbild enorm. 

Es wird Zeit, zum Wesentlichen zu kommen: Mein Dank gilt meinem 

Institutsleiter Hermann Maurer, der mehr als einfach nur “der Chef” ist. 

Auch als guter Freund steht er immer mit aufmunternden Worten, gutem 

Rat und Unterstützung zur Seite. Wie bereits bei meinem ersten Buch Softwareentwicklung 

in C war auch hier wieder Hermann Engesser mein direkter 

Ansprechpartner beim Verlag und in gewohnter Weise unbürokratisch und 

sehr kooperativ. Meine Arbeitskollegen, Informatik-Gurus und außerdem 

guten Freunde Karl Blümlinger, Christof Dallermassl und Dieter Freismuth 

waren freiwillige Leser des Manuskripts und durchkämmten dieses auf fachliche 

Ungereimtheiten und sonstige Fehler. Christof Rabel, seines Zeichens 

enorm kompetenter C ++ Spezialist, war durch seine mannigfaltigen Kommentare 

und seine Diskussionsbereitschaft eine sehr große Hilfe, wenn ich 

wieder einmal mit Betriebsblindheit geschlagen war. Ebenso wichtig waren 

viele Diskussionen mit meinem guten Freund und Informatik-Guru Dirk 

Schwartmann, der mir viele Denkanstöße zur Aufbereitung des Inhalts aus 

seinem reichen Erfahrungsschatz gab. Da schon sehr viel von guten Freunden 

die Rede war, geht es gleich mit solchen weiter: Mein herzlichster Dank 

gebührt Monika Tragner und Anita Lang, die aufgrund ihrer germanistischen 

Kompetenz ehrenamtlich und kurz entschlossen das Lektorat für dieses Buch 

übernommen haben. Neben den wichtigen Personen in meinem Leben, die 

direkt an der Arbeit beteiligt waren, gibt es auch solche, die “nur” indirekt 

ihren Teil zur Entstehung des Buchs beigetragen haben, indem sie einfach für 

mich da waren. Dies bedeutet aber nicht, dass ihr Beitrag deshalb geringer 

gewesen wäre. Hierbei wären vor allem Manuela Burger und meine Eltern zu 

nennen, die mir in vielerlei Hinsicht immer eine ganz große Hilfe waren und 

sind.

VIII Vorwort des Autors 

Last, but not least, geht auch mein besonderer Dank an die Studierenden 

der TU-Graz, die im Sommersemester 2002 das Programmierpraktikum besucht 

haben, sowie an Harald Krottmaier und an die Tutoren und Tutorinnen, 

die bei der Durchführung desselben geholfen haben. 

Aus besonders traurigem Anlass möchte ich diese Danksagung zum Zeitpunkt 

der Drucklegung an dieser Stelle noch ergänzen und widme dieses Buch meinem 

Vater, dessen Tod mich heute völlig unerwartet, aber dafür umso tiefer 

getroffen hat. 

Klaus Schmaranz Graz am 17. November 2002

Inhaltsverzeichnis 

1. Ziel und Inhalt dieses Buchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.1 Zum Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

1.4 Die beiliegende CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Teil I: Low-Level Konzepte von C++ . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2. Datentypen und Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.1 Primitive Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.2 Deklaration, Definition und Initialisierung . . . . . . . . . . . . . . . . . 20 

2.3 Das erste C++ Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.4 Zusammengesetzte Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

2.4.1 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

2.4.2 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

2.4.3 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

2.5 Scope und Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

2.6 Symbolische Konstanten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

2.7 Eigene Typdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

3. Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

3.1 Überblick und Reihenfolge der Auswertung . . . . . . . . . . . . . . . . 53 

3.2 Arithmetische Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

3.3 Logische- und Vergleichsoperatoren . . . . . . . . . . . . . . . . . . . . . . . 59 

3.4 Bitoperatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

3.5 Zuweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

3.6 Datentypabfragen und explizite Typecasts . . . . . . . . . . . . . . . . . 61 

3.6.1 Type Identification und Run-Time-Type-Information. 62 

3.6.2 Unchecked Cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

3.6.3 Compiletime-checked Cast . . . . . . . . . . . . . . . . . . . . . . . . 67 

3.6.4 Runtime-checked Cast . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

3.6.5 Remove-const Cast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

3.6.6 C-Style Casts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

X Inhaltsverzeichnis 

4. Kontrollstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

4.1 Selection Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

4.2 Schleifen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

4.3 Das unselige goto Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

5. Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

6. Pointer und References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

6.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

6.2 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 

6.2.1 Pointer und Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

6.2.2 Dynamische Memory Verwaltung . . . . . . . . . . . . . . . . . . 119 

6.2.3 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

6.2.4 Funktionspointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

6.2.5 Besondere Aspekte von Pointern . . . . . . . . . . . . . . . . . . 126 

Call-by-reference auf Pointer . . . . . . . . . . . . . . . . . . . . . . 126 

Mehrfachpointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

Pointer und Typecasts . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

7. Der Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 

7.1 Include Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

7.2 Bedingte Übersetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

7.3 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 

Teil II: Objektorientierte Konzepte von C++ . . . . . . . . . . . . . . . . . 141 

8. Objektorientierung Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

8.1 Module und Abläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

8.1.1 Der Weg zum Arbeitsplatz – ein kleines Beispiel . . . . . 146 

8.2 Klassen und Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

8.3 Richtige Verwendung der OO Mechanismen . . . . . . . . . . . . . . . . 161 

9. Klassen in C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

9.1 Besonderheiten von Structures in C++ . . . . . . . . . . . . . . . . . . . . 168 

9.2 Einfache Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

9.2.1 Konstruktor und Destruktor genauer beleuchtet . . . . . 178 

9.2.2 Der Copy Konstruktor . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 

9.2.3 Initialisierung vs. Zuweisung . . . . . . . . . . . . . . . . . . . . . . 188 

9.2.4 Deklarieren von Konstruktoren als explicit . . . . . . . . 189 

9.2.5 Object- und Class-Members. . . . . . . . . . . . . . . . . . . . . . . 192 

9.3 Abgeleitete Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 

9.3.1 Mehrfachvererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 

9.3.2 Konstruktoren und Destruktoren . . . . . . . . . . . . . . . . . . 215 

9.4 Weitere wichtige technische Aspekte . . . . . . . . . . . . . . . . . . . . . . 219 

9.4.1 Static und Dynamic Binding . . . . . . . . . . . . . . . . . . . . . . 219

Inhaltsverzeichnis XI 

9.4.2 Abstrakte Methoden und Klassen. . . . . . . . . . . . . . . . . . 232 

9.4.3 Virtuelle Ableitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

9.4.4 Downcasts von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 

9.4.5 Friends von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

9.4.6 Overloading von const und non-const Methoden . . . 250 

9.4.7 Besonderheiten bei der Initialisierung . . . . . . . . . . . . . . 251 

9.4.8 Temporäre Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 

10. Memory – ein kleines Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

10.1 Das ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

10.1.1 Identifikation der Grobmodule . . . . . . . . . . . . . . . . . . . . 258 

10.1.2 Weitere Zerlegung der einzelnen Grobmodule . . . . . . . 259 

Input Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

Spielsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

Output Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

Memory Spielfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

Memory Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

Commandline Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

10.2 Das DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

10.2.1 Klassendiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

10.2.2 Klassendeklarationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 

10.2.3 Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 

10.2.4 ObjectDeletor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

10.2.5 Konkrete Deletors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

10.2.6 ArgumentHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 

10.2.7 MemoryCommandlineArgumentHandler . . . . . . . . . . . . . 272 

10.2.8 CommandlineHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

10.2.9 SimpleOutputHandling . . . . . . . . . . . . . . . . . . . . . . . . . . 275 

10.2.10 Displayable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 

10.2.11 OutputContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 

10.2.12 TextOutputContext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 

10.2.13 GameCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 

10.2.14 MemoryGameCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 

10.2.15 MemoryGameboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 

10.2.16 IntDisplayable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 

10.2.17 TextDisplayable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 

10.2.18 Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 

10.2.19 WordEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 

10.2.20 SimpleInputHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 

10.2.21 SimpleEventHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 

10.2.22 MemoryGameControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 

10.2.23 MemoryCardSymbolGenerator . . . . . . . . . . . . . . . . . . . . . 300 

10.2.24 MemoryCardpair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 

10.3 Auszüge aus der Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 304

XII Inhaltsverzeichnis 

11. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 

12. Operator Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 

12.1 Grundprinzipien des Operator Overloadings . . . . . . . . . . . . . . . . 335 

12.2 Typumwandlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 

12.3 Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 

12.3.1 Einfaches new und delete . . . . . . . . . . . . . . . . . . . . . . . . 363 

12.3.2 Array new und delete . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 

12.3.3 Placement Operator new . . . . . . . . . . . . . . . . . . . . . . . . . 374 

12.3.4 delete mit zwei Parametern . . . . . . . . . . . . . . . . . . . . . . 381 

12.3.5 Globale new und delete Operatoren . . . . . . . . . . . . . . . 385 

12.3.6 Weitere Aspekte der eigenen Speicherverwaltung . . . . 391 

Vererbung von new und delete . . . . . . . . . . . . . . . . . . . 391 

Verhalten bei “Ausgehen” des Speichers . . . . . . . . . . . . 397 

12.4 Abschließendes zu overloadable Operators . . . . . . . . . . . . . . . . . 400 

13. Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 

13.1 Function Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 

13.2 Overloading Aspekte von Function Templates . . . . . . . . . . . . . . 414 

13.3 Class Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 

13.4 Ableiten von Class Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 

13.5 Explizite Spezialisierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 

13.6 Verschiedenes zu Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 

13.7 Source Code Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 

14. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 

15. Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 

15.1 mutable Member Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 

15.2 Unions im OO Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 

15.3 Funktionspointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 

15.4 Besondere Keywords, Diagraphs und Trigraphs . . . . . . . . . . . . . 475 

15.5 volatile Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 

15.6 RTTI und dynamic cast im OO Kontext . . . . . . . . . . . . . . . . . . 477 

15.7 Weiterführendes zu Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 

Teil III: Ausgesuchte Teile aus der C++ Standard Library . . . 491 

16. Die C++ Standard Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 

16.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 

16.2 Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 

16.2.1 Vektoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 

16.2.2 Listen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 

16.2.3 Double-Ended Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 

16.2.4 Standard Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Inhaltsverzeichnis XIII 

16.2.5 Priority Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 

16.2.6 Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 

16.2.7 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 

16.2.8 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 

16.2.9 Zusammenfassung der Container-Operationen . . . . . . . 510 

16.3 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 

16.4 Allocators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 

16.5 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518 

16.6 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 

16.7 Numerik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531 

16.8 Algorithmen und Funktionsobjekte . . . . . . . . . . . . . . . . . . . . . . . 534 

A. Coding-Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 

A.1 Generelle Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537 

A.2 Coding-Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 

A.3 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 

B. Vollständige Implementation des Memory Spiels . . . . . . . . . . 543 

B.1 Implementationen der einzelnen Klassen . . . . . . . . . . . . . . . . . . . 543 

B.1.1 Das Hauptprogramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 

B.1.2 Implementation von Vector . . . . . . . . . . . . . . . . . . . . . . 545 

B.1.3 Implementation von CommandlineHandling . . . . . . . . . 546 

B.1.4 Implementation von SimpleOutputHandling . . . . . . . . 547 

B.1.5 Implementation von GameCard . . . . . . . . . . . . . . . . . . . . 547 

B.1.6 Implementation von MemoryGameCard . . . . . . . . . . . . . . 547 

B.1.7 Implementation von MemoryGameboard . . . . . . . . . . . . . 548 

B.1.8 Implementation von SimpleInputHandling . . . . . . . . . 552 

B.1.9 Implementation von MemoryGameControl . . . . . . . . . . . 552 

B.1.10 Implementation von MemoryCardSymbolGenerator. . . 554 

B.1.11 Implementation von MemoryCardpair . . . . . . . . . . . . . . 556 

B.1.12 Variablen für die konkreten Deletors . . . . . . . . . . . . . . . 557 

B.1.13 Das MemoryMakefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

1. Ziel und Inhalt dieses Buchs 

Dieses Buch richtet sich an alle, die gerne die Programmiersprache C ++ von 

Grund auf erlernen wollen oder ihre Kenntnisse vertiefen wollen. Es wird 

hierbei ein gewisses Grundverständnis für die Softwareentwicklung im Allgemeinen 

vorausgesetzt. Kenntnisse der Programmiersprache C sind natürlich 

auch nicht von Nachteil. C ++ hat sich, wie der Name schon sagt, aus C entwickelt 

und ist dessen objektorientiertes Pendant. Im Prinzip ist mit sehr 

wenigen Ausnahmen alles, was für C gilt, auch für C ++ gültig, allerdings ist 

der Sprachumfang von C ++ durch die Objektorientierung bedeutend größer. 

Lesern, die noch keine Erfahrung mit der Programmiersprache C haben, oder 

vielleicht noch überhaupt keine Erfahrung mit der Softwareentwicklung im 

Allgemeinen, sei als Grundlage, vor dem Durcharbeiten dieses Buchs, das 

Buch Softwareentwicklung in C ans Herz gelegt. 

Um nicht missverstanden zu werden: Ich möchte mit diesen einleitenden 

Sätzen keineswegs den Verkauf des oben genannten Buchs ankurbeln (eine 

elektronische Version desselben liegt ohnehin gratis der mitgelieferten CD- 

ROM bei). Es ist auch im vorliegenden Buch alles an Information enthalten, 

was man zum Erlernen von C ++ braucht, auch wenn man noch kein C kann. 

Nur ist das grundlegende C-Wissen im zuvor genannten Buch ungleich detaillierter 

enthalten und daher für Einsteiger bei weitem leichter genießbar. 

Eine derartig detaillierte Beschreibung der grundlegenden Dinge im hier vorliegenden 

Buch über C ++ würde dessen Rahmen bei weitem sprengen. 

Die Intention hinter der Empfehlung, zuerst C zu lernen, hat gute Gründe, 

die ich noch kurz näher erläutern möchte: Um C ++ wirklich gut zu beherrschen, 

muss man unbedingt tieferes Verständnis in zwei verschiedenen Wissensgebieten 

erlangen: 

1. Man muss das Konzept der objektorientierten (kurz: OO) Programmierung 

verinnerlicht haben, um ein sauber durchdachtes und schlüssiges 

Softwaredesign erstellen zu können. 

2. Man muss ein gewisses Verständnis für die interne Arbeitsweise eines 

Computers entwickelt haben, um das sauber durchdachte Design auch 

vernünftig umsetzen zu können. 

Die Erfahrung zeigt, dass man viel Zeit und Nerven spart, wenn man nicht 

beide Dinge zugleich lernt. In vielen Büchern und in noch mehr Kursen wird

2 1. Ziel und Inhalt dieses Buchs 

versucht, Softwareentwicklung gleich anhand einer objektorientierten Sprache 

zu lehren. Das Argument für diese Vorgehensweise klingt auf den ersten 

Blick sehr schlüssig: OO-Sprachen wurden entwickelt, weil den Menschen die 

OO-Denkweise besser liegt als die imperative. Also stellen OO-Sprachen, im 

Vergleich zu imperativen Sprachen, eine deutliche Verbesserung dar und sind 

deswegen auch leichter zu erlernen. 

Leider wurden bei diesem Argument ein paar Kleinigkeiten übersehen: 

Erstens haben Problemlösungen, egal ob mit OO-Sprachen oder mit imperativen 

Sprachen, immer einen imperativen Anteil. Man muss ja einem Computer 

“genau sagen, was er tun soll”, zumindest im Kleinen. Das geht ohne 

Verständnis für die interne Arbeitsweise nicht wirklich. Zweitens existiert 

sehr wohl ein Unterschied zwischen der saloppen Denkweise von Menschen 

und den absolut exakten Formulierungen, die einer Programmiersprache zugrunde 

liegen. Drittens wurden OO-Sprachen über lange Zeit hinweg immer 

weiterentwickelt, um noch eleganter und besser einsetzbar zu sein. Dementsprechend 

fanden viele Konstrukte in OO-Sprachen Eingang, die erst dann 

zu verstehen sind, wenn man die notwendige Erfahrung hat, um deren Sinn 

nachvollziehen zu können. 

Wählt man also für die ersten Schritte in der Softwareentwicklung gleich 

eine OO-Sprache, so ist man gezwungen, einige Interna zu begreifen, obwohl 

das notwendige Handwerkszeug und die notwendige Erfahrung dazu fehlen. 

Meine Beobachtungen von C ++ Neulingen zeigen folgendes Bild: 

• Die meisten Entwickler, die zuvor entweder C oder eine andere imperative 

Sprache beherrschen, finden sehr schnell Gefallen an C ++, da sie endlich 

ein Problem elegant lösen können. Es ist mit der nötigen Erfahrung bei 

richtiger Anwendung des OO-Ansatzes (und nur dann!) möglich, Probleme 

elegant in kleine, in sich abgeschlossene Teilprobleme zu zerlegen. 

Damit kann man sich immer um das Wesentliche des entsprechenden Teilproblems 

kümmern, ohne durchgehend das große Ganze akribisch im Auge 

behalten zu müssen. Natürlich geht dies nur, nachdem das große Ganze 

einmal vernünftig auf höherer Abstraktionsebene entworfen wurde. 

• Fast alle Entwickler, die C ++ (oder auch Java) als Einstiegssprache lernen, 

ohne zuvor mit einer imperativen Sprache gearbeitet zu haben, finden C ++ 

unglaublich kompliziert und sehen den Wald vor lauter Bäumen nicht mehr. 

Das liegt daran, dass sie vor vielen Problemen, die durch das OO-Konzept 

gelöst werden, überhaupt noch nie gestanden sind! Wie soll man auch eine 

Problemlösung verstehen und den damit verbundenen Overhead gerne in 

Kauf nehmen, wenn man das Problem nicht kennt bzw. nicht verstanden 

hat? 

Lesern, die trotz dieser Argumente keine Lust haben, zuerst C zu lernen, 

sondern sich gleich C ++ aneignen wollen, möchte ich zumindest die beiliegende 

elektronische Version von Softwareentwicklung in C als Nachschlagewerk 

für Zwischendurch empfehlen. Es schadet in jedem Fall nicht, wenn man

1.1 Zum Inhalt 3 

z.B. bei Abhandlungen über Pointer einmal einen kurzen Blick in das entsprechende 

Kapitel des anderen Buchs wirft oder dieses vielleicht sogar im 

Schnellverfahren einmal von vorne bis hinten querliest. 

Auf einen Punkt sei noch ganz besonders hingewiesen: C ++ als OO- 

Sprache unterstützt sehr elegant alle Eigenschaften, die immer mit OO- 

Softwareentwicklung in Verbindung gebracht werden. Die wichtigsten Schlagworte 

hierbei sind sicherlich die Modularität und die Wiederverwendbarkeit 

von Code. Ganz bewusst habe ich das Wort unterstützt besonders hervorgehoben, 

denn es herrscht der allgemeine Irrglaube, dass gewisse Eigenschaften, 

wie z.B. Wiederverwendbarkeit, allein durch das Verwenden einer OO- 

Sprache automatisch existieren bzw. erzwungen werden. Dies ist definitiv 

falsch. 

Kritisch betrachtet ist sogar das Gegenteil der Fall! Bei Verwendung von 

OO-Sprachen kann man Fehler im Design viel länger hinter abenteuerlichen 

Objektkonstruktionen verstecken, als es bei Verwendung von imperativen 

Sprachen jemals möglich wäre. Wenn man dann allerdings den Punkt erreicht, 

an dem “nichts mehr geht”, dann ist die Katastrophe bei weitem 

größer, als sie sonst jemals werden könnte. Bei imperativen Sprachen muss 

man viel früher das Handtuch werfen, weil man bei weitem schneller den 

Punkt erreicht, an dem man nichts mehr an einem Teil eines Programms 

ändern kann, ohne gleich an einer ganz anderen Ecke im Programm eine Katastrophe 

hervorzurufen. Bei OO-Sprachen kann man sich bewusst noch eine 

Zeit lang an diesen Problemen vorbei schwindeln, indem man Objektkapselungsmechanismen 

missbraucht. 

Das Ziel bei jeder Softwareentwicklung ist immer, dass das Endprodukt 

sauber und robust ist. Daher wird in diesem Buch besonderer Wert darauf 

gelegt, OO-Softwareentwicklung richtig zu betreiben, denn nur dann gelangt 

man zum gewünschten Ziel. Dazu ist sehr viel Erfahrung vonnöten, vor allem, 

wenn es um saubere, elegante und allgemein einsetzbare Problemlösungsansätze 

geht. Wo auch immer auf dem Weg zum erklärten Ziel typische 

Stolpersteine liegen, an denen sich C ++ Neulinge erfahrungsgemäß stoßen 

können, wird besonders auf sie hingewiesen. 

1.1 Zum Inhalt 

Das Buch führt in kleinen Schritten von den Prinzipien der OO-Softwareentwicklung 

über die Grundlagen der Sprache (z.B. primitive Datentypen, wie 

sie auch in C existieren) und über die ersten objektorientierten Gehversuche 

zu zum Teil sehr speziellen Konstrukten von C ++. Es wird immer besonderer 

Wert darauf gelegt, das Warum zu verstehen, anstatt nur ein Kochbuch mit 

einfachen Rezepten anzubieten. Nur zu oft sieht man C ++ Code, der aus 

purem Unverständnis der Hintergründe unglaublich kompliziert ist, obwohl 

die Sprache an und für sich eine elegante Lösungen ermöglichen würde.


Zu allen Sprachkonstrukten werden entsprechende Beispiele angeführt 

und ausführlich erklärt. Diese Beispiele sind durchgehend mit kleinen Zeilennummern 

am linken Rand versehen, um ein Referenzieren im beschreibenden 

Text einfacher zu machen. Natürlich sind diese Zeilennummern nicht Teil 

des C ++ Codes und dürfen dementsprechend nicht in Programmen vorkommen! 

Alle Beispiele, die im Buch angeführt sind, wurden so nahe wie möglich an 

sinnvolle Konstrukte angelehnt, die auch in der täglichen Praxis vorkommen. 

Auch die Herangehensweise an Problemlösungen, die in diesem Buch vermittelt 

wird, hat sich über lange Zeit bewährt. Natürlich bedeutet dies nicht, 

dass die angeführten Beispiele die einzig mögliche Lösung zu einem Problem 

darstellen. Ich möchte unbedingt dazu anregen, über alternative Lösungen 

nachzudenken und diese mit den vorgeschlagenen zu vergleichen. Dies ist 

die beste Methode, den Umgang mit verschiedensten Aspekten der Softwareentwicklung 

zu üben und die Kenntnisse über eine Programmiersprache zu 

vertiefen. 

Um das Buch so gut wie möglich zu strukturieren, wurde es in drei Hauptteile 

untergliedert: 

Teil I – Low-Level Konzepte von C ++: Im ersten Teil des Buchs werden alle 

Konzepte von C ++ besprochen, die noch nichts mit Objektorientierung 

zu tun haben. Im Prinzip sind dies einerseits Konzepte, die C ++ von 

C übernommen hat, andererseits einige Features, die entweder im Vergleich 

zu C sinnvoll erweitert wurden bzw. völlig neu sind. Wo auch 

immer Unterschiede zwischen C und C ++ zu finden sind, sind diese explizit 

angemerkt. 

Teil II – Objektorientierte Konzepte von C ++: Im zweiten Teil des Buchs werden 

die Features von C ++ besprochen, die direkt mit OO-Softwareentwicklung 

zu tun haben und die es in C vom Konzept her überhaupt 

nicht gibt. 

Teil III – Ausgesuchte Teile aus der C ++ Standard Library: Zu C ++ gibt es 

eine sehr große Standard-Klassenbibliothek, die vieles enthält, was man 

im Programmieralltag gut gebrauchen kann. Der Vorteil der Standard- 

Library ist, dass man nicht für die alltäglichen Bedürfnisse das Rad neu 

erfinden muss und auch nicht auf Code von Drittherstellern angewiesen 

ist. Die Standard-Library hat, wie der Name schon sagt, den Vorteil, dass 

ihr Inhalt erstens standardisiert ist und dass sie zweitens standardmäßig 

bei jedem (ok, fast jedem :-)) C ++ Compiler mitgeliefert wird. 

Um nun diese Standard-Library umfassend mit erklärenden Codebeispielen 

zu behandeln, müsste dieses Buch mindestens den doppelten Umfang 

haben. Aus diesem Grund wird im dritten Teil des Buchs vor allem der 

prinzipielle Umfang dieser Library vorgestellt, um einen Überblick zu 

vermitteln. Umfassendere Beschreibungen gibt es nur zu den Teilen, die 

man im “üblichen” Alltag sehr häufig braucht. Durch diese Art der Beschreibung 

werden die Konzepte klar genug beleuchtet, dass man die Ein-

1.1 Zum Inhalt 5 

stiegspunkte hat, die man braucht, um mit der Online-Dokumentation 

problemlos zu Rande zu kommen. 

Um besondere Hinweise im Buch auf einen Blick erkennen zu können, sind 

diese extra hervorgehoben und besitzen eine besondere Kennzeichnung am 

Rand: 

• Das Zeichen signalisiert einen Hinweis auf einen Stolperstein. 

• Das Zeichen signalisiert einen Hinweis auf einen wichtigen Unterschied 

zwischen C und C ++. 

• Das Zeichen signalisiert, dass es als Zusatzinformation zu einem bestimmten 

Thema eine ausführliche Abhandlung im Buch Softwareentwicklung 

in C gibt. Eine elektronische Version dieses Buchs ist auch auf der 

beiliegenden CD-ROM vorhanden. 

Diese speziellen Hinweise auf C-Konstrukte wurden für Leser eingeführt, 

die im Umgang mit der Programmiersprache C noch ein wenig unsicher 

sind oder überhaupt noch keine C-Erfahrung haben. 

Ein paar Worte möchte ich noch über das Thema Entwicklungsumgebung 

verlieren: C ++ Entwicklungsumgebungen gibt es wie Sand am Meer. Je 

nachdem, um welche Entwicklungsumgebung es sich handelt und für welche 

Zielplattform diese gedacht ist, ist sowohl der Funktionsumfang als auch der 

Umfang zusätzlicher plattformabhängiger Libraries sehr verschieden. Nun ist 

es nicht im Sinne des Erfinders, C ++ als allgemein einsetzbare Programmiersprache 

an einer bestimmten Umgebung festzumachen. Aus diesem Grund 

wurde folgende Wahl getroffen: 

Die empfohlene Entwicklungsumgebung, auf der auch prinzipiell das gesamte 

Buch beruht, ist eine Umgebung unter Linux mit dem GNU C ++ Compiler 

und GNU make. Diese Entscheidung ist darin begründet, dass dies eine 

frei verfügbare Open-Source Umgebung ist. Sie ist auch eine der stabilsten 

Entwicklungsumgebungen, die derzeit zur Verfügung stehen. 

Es soll sich nun allerdings niemand abschrecken lassen, der lieber unter 

MS-Windows mit einer anderen Entwicklungsumgebung arbeiten will. Das 

Wissen, das in diesem Buch vermittelt wird, ist natürlich auch dafür gültig. 

Es steht also jedem frei, eine beliebige Umgebung zu verwenden, ohne dass 

dadurch Einschränkungen zu erwarten sind. Jedoch möchte ich jedem Softwareentwickler 

gerne ans Herz legen, es zumindest interessehalber einmal mit 

Linux zu probieren. Nach einer kurzen Eingewöhnungsphase lernt man doch 

gewisse Vorteile schätzen. 

Eine kurze Warnung möchte ich jedoch an dieser Stelle noch aussprechen: 

Einige Compiler entsprechen definitiv in einigen “Feinheiten” nicht dem C ++ 

Standard und einige Compiler haben auch nicht alle Features implementiert, 

die im Standard enthalten sind. Dies betrifft auch die sehr weit verbreiteten 

Compiler gewisser Firmen, die den PC Markt beherrschen. Um zu erfahren, 

wo diese Compiler vom Standard abweichen, wirft man am besten einen Blick


auf die entsprechenden Web-Pages der Compilerhersteller. Dort existiert 

üblicherweise eine Liste, die Auskunft über die Abweichungen vom Standard 

gibt. Sollten Leser also auf Beispiele im Buch stoßen, die mit ihrem Compiler 

nicht übersetzbar sind, so möchte ich empfehlen, einen Blick auf die Web- 

Page des Herstellers zu werfen. Sollten dann immer noch Ungereimtheiten 

existieren, so ist das Feedback-Forum zum Buch (siehe Abschnitt 1.3) der 

beste Ort, eine Frage anzubringen. Ich werde dann so schnell wie möglich 

versuchen, Klarheit zu schaffen. 

Leser, die sich gar nicht sicher sind, ob sie nun Linux ausprobieren sollen 

oder nicht, können auch einen Zwischenweg wählen: Alle nützlichen Tools 

(GNU C ++ Compiler, Emacs als Editor und viele kleine Helferlein, wie z.B. 

make oder tar) sind auch als MS-Windows Portierungen frei im Internet 

verfügbar. Kurze Beschreibungen, die den Einstieg in die Arbeit mit diesen 

Tools erleichtern, sind auch im Buch Softwareentwicklung in C, das bereits 

zu Beginn dieses Kapitels genannt wurde, enthalten. 

1.2 Motivation 

Softwareentwickler stehen in der Industrie im Regelfall unter starkem Druck. 

Es wird von ihnen nur zu oft verlangt, dass sie unrealistische Termine einhalten, 

dass sie jederzeit auf Wunsch mitten in der Entwicklung neue Features 

in die Software einbauen oder auch, dass sie einfach während der Entwicklung 

Konzepte ändern. Das Allerschlimmste, das allerdings passieren kann, 

ist, dass ein Kunde oder Vorgesetzter frühzeitig “schnell einmal etwas sehen 

will”. Leider bedeutet hier der Begriff etwas sehen, dass man einen Teil eines 

lauffähigen Programms demonstrieren muss. Kann man dies nicht, bzw. 

versucht man, ein erstelltes Design zu zeigen, dann sieht man sich sehr oft 

Zweifeln ausgesetzt, “ob man denn überhaupt etwas weiterbringt”. 

Nun funktioniert aber saubere Softwareentwicklung nicht so, dass man 

sich einfach zum Computer setzt und schnell ein Programm schreibt. Abgesehen 

davon, dass das sowieso die schlechtest mögliche Herangehensweise 

ist, ist die Komplexität heutiger Softwarepakete so hoch, dass dieser Ansatz 

niemals funktionieren kann. Leider herrscht immer noch die Meinung vor, 

dass die tatsächliche Arbeit bei der Softwareentwicklung die Implementation 

der Software ist. Dies ist aber vollkommen falsch! Der größte Teil der Arbeit 

im Rahmen einer sauberen (!!) Entwicklung findet in der Designphase 

statt! Das Codieren selbst nimmt im Rahmen eines Entwicklungszyklus nur 

einen sehr geringen Teil der Zeit in Anspruch. Einen weiteren großen Teil 

im Zyklus nehmen die laufenden Tests ein, die die Software von den ersten 

Designschritten bis zum Endprodukt begleiten müssen. 

Sieht man sich den Projektfortschritt bei einer sauberen Entwicklung an, 

so stellt man Folgendes fest: Lange Zeit scheint die Arbeit nur schleppend 

voranzugehen. Es gibt viele Diskussionsphasen im Team und das Ergebnis 

dieser Diskussionsphasen sind Entwürfe auf Papier. Im Regelfall wird bis

1.2 Motivation 7 

über die Hälfte der Gesamtentwicklungszeit hinaus keine Zeile Code produziert. 

Danach allerdings scheint sich die Arbeit von außen gesehen enorm 

zu beschleunigen. In sehr kurzer Zeit wird sehr viel implementiert und die 

Implementation ist üblicherweise auch relativ fehlerfrei. 

Wenn man im Gegensatz dazu den Projektfortschritt bei einer Hacklösung 

ansieht, bei der die Arbeit gleich von Beginn an am Computer stattfindet, ohne 

zuerst ein vollständiges (!!) und schlüssiges (!!) Design zu erstellen, dann 

beobachtet man als Außenstehender im Prinzip das Gegenteil: Zu Beginn 

passiert in kurzer Zeit sehr viel und es gibt sehr schnell einen Prototypen zu 

sehen, der einen Teil der geforderten Funktionalität mehr oder weniger gut 

implementiert. Gewisse Fehler werden natürlich toleriert, denn man steckt 

ja noch mitten in der Entwicklung. Mit jedem zusätzlichen Feature, das die 

Software dem Endprodukt näher bringt, geht die Arbeit schleppender voran. 

Nach einer gewissen Zeit bedeuten auch die kleinsten Erweiterungen des 

halbfertigen Pakets bereits immensen Implementationsaufwand. Außerdem 

steigt die Fehlerhäufigkeit auf ein unerträglich hohes Maß. Das Beheben von 

Fehlern wird immer mehr zum Spießrutenlauf, denn mit jeder Änderung in 

einem Teil der Software passieren ungeahnte Dinge in anderen Teilen der 

Software. Mit Glück ist das geforderte Produkt vom Funktionsumfang her 

klein genug, dass man dessen Fertigstellung noch irgendwie mehr schlecht als 

recht über die Runden bringt. Sehr oft allerdings muss man den Kunden erklären, 

dass gewisse Features “aus technischen Gründen gar nicht realisierbar 

sind” und hoffen, dass diese das akzeptieren. 

Noch viel dramatischer wird das Bild, wenn Erweiterungen oder Änderungen 

eines existenten Softwarepakets gefordert sind. Bei der sauberen Entwicklung 

ist die Erweiterbarkeit ein Teil des Konzepts und im Regelfall sind 

neue Features relativ einfach realisierbar. Sollte durch neue Features das 

Ursprungskonzept verändert werden müssen, so ist auch das im Normalfall 

möglich, wenn auch mit einigem Aufwand verbunden. Das Endprodukt bleibt 

trotzdem sauber. 

Ganz im Gegensatz dazu steht die Erweiterbarkeit der Hacklösung. Schon 

die kleinsten Änderungen dauern enorm lang und destabilisieren die gesamte 

Software. Sehr oft beobachtet man den Fall, dass in sogenannten Bugfix- 

Releases zwar einige bekannte schwere Fehler behoben wurden, dafür aber 

mindestens genau so viele neue Fehler eingebaut wurden, da die Auswirkungen 

von Programmänderungen nicht mehr überschaubar sind. 

Vollkommen katastrophal wird es, wenn man die Menge an Source-Code 

eines sauberen Projekts mit der einer Hacklösung vergleicht. Im Normalfall 

ist die Hacklösung bei gleicher Funktionalität gleich x-Mal so groß wie die 

saubere Lösung. Nicht nur, dass die Codemenge ungleich größer ist, auch die 

Komplexität des Codes ist durch Seiteneffekte enorm. 

Es gibt einen ganz bestimmten Grund, warum ich mich über saubere 

und Hacklösungen so ausführlich auslasse: Zur Zeit, zu der OO-Sprachen, 

insbesondere C ++, ihren Eingang in die Industrie fanden, war die Euphorie


über die diesen Sprachen angedichteten Eigenschaften riesig. Plötzlich wurde 

überall von Wiederverwendung gesprochen und davon, dass sich dadurch die 

Entwicklungszyklen drastisch verkürzen. Entsprechend wurden sofort die 

Entwicklungszeiten kürzer angesetzt als zuvor, allerdings bei einer höheren 

Anzahl von Features. Man arbeitet ja objektorientiert, und damit geht das 

alles viel besser und schneller. 

Leider wurde bei dieser Euphorie etwas übersehen: OO-Entwicklung will 

erst richtig gelernt sein und es braucht einige Erfahrung, um ein tragfähiges 

Konzept zu erstellen! Aber genau die Zeit, die Entwickler brauchen, um 

die Denkweise vollständig zu verinnerlichen und die Konzepte hinter dieser 

Denkweise in vernünftige Softwarekonstrukte umzusetzen, wurde und wird 

ihnen nicht ausreichend gegeben. Es ist für erfahrene C-Entwickler ohne 

große Probleme möglich, C ++ als Sprache in einigen Tagen, bis zu wenigen 

Wochen, zu lernen. Es ist allerdings vollkommen unmöglich, die Denkmuster 

innerhalb dieser kurzen Zeit umzustellen. Imperativ zu programmieren 

ist eben einmal ein ganz anderer Ansatz als objektorientiert zu entwickeln. 

Vor allem verändert sich das Design der Software drastisch! Die Syntax von 

C ++ zu beherrschen bedeutet noch lange nicht, objektorientiert C ++ zu programmieren. 

Es ist leicht, C ++ zu vergewaltigen, also Klassen und andere 

Konstrukte zu verwenden und trotzdem im Prinzip rein imperativ zu programmieren. 

Genau bei einer solchen Arbeitsweise kauft man den gesamten 

Overhead von C ++ gegenüber C ein, ohne die damit verbundenen zusätzlichen 

Möglichkeiten zum Vorteil zu nützen. 

Polemisch festgestellt: Wenn man mit einem Kleinwagen gut umgehen 

kann, dann bedeutet dies noch lange nicht, dass man sich einfach in ein 

Rennauto setzen kann und damit schneller ans Ziel kommt. Die Gefahr, 

durch das Rennauto überfordert zu werden, seine Grenzen nicht zu kennen 

und deshalb gleich einen Unfall zu haben, ist sehr groß. 

Deshalb kann ich abschließend nur sagen, dass alle Leser dieses Buchs sich 

so viel Zeit wie möglich zum Spielen und Probieren nehmen sollten, um C ++ 

und die dahinter liegenden Konzepte zu verstehen, bevor sie sich an C ++ 

im Rahmen einer kommerziellen Entwicklung versuchen. 

1.3 Feedback 

Software wird niemals fertig. Kaum wird eine Version freigegeben, kommen 

auch schon die nächsten Wünsche. Genau dasselbe passiert bei Büchern, die 

Wissen vermitteln sollen. Es gibt kein Buch, das man nicht noch verbessern 

könnte und das gilt natürlich auch (hoffentlich nicht ganz besonders) 

für dieses Buch. Aus diesem Grund gibt es ein Feedback-Forum, über das 

Wünsche, Anregungen, Beschwerden, Lob und Tadel an den Autor übermittelt 

werden können. Dieses Feedback Forum ist online erreichbar unter der 

Web-Page zum Buch: 

http://courses.iicm.edu/SWEntwicklungInCplusplus

1.4 Die beiliegende CD-ROM 9 

Ich würde mich freuen, wenn die eine oder andere Leserin bzw. der eine 

oder andere Leser dazu beiträgt, dieses Buch zu verbessern, indem sie/er 

entsprechende Vorschläge macht. 

Das Feedback-Forum ist aber nicht nur dazu gedacht, Lesern die Möglichkeit 

zu geben, ihre Meinung zum Buch mitzuteilen. Ich sehe das Forum vielmehr 

als Leserforum, in dem auch eigene Beispiele, Alternativen zu vorgeschlagenen 

Lösungen, etc. veröffentlicht werden können und diverse Aspekte 

der Softwareentwicklung diskutiert werden können. Es wäre schön, wenn 

das Forum eine Eigendynamik in diese Richtung entwickeln würde, denn das 

kommt sicher vielen Leuten zugute. 

1.4 Die beiliegende CD-ROM 

Dem Buch liegt eine CD-ROM bei. Weil der Inhalt einer CD-ROM im Gegensatz 

zu einem Buch sehr kurzlebig ist, möchte ich an dieser Stelle nur so 

viel erwähnen: Es sind auf der CD-ROM alle im Buch abgedruckten Programme 

vorhanden. Was sonst noch auf der CD-ROM zu finden ist und wie 

man damit arbeitet, kann man erfahren, indem man die Datei 

index.html 

mit einem der gängigen Internet-Browser ansieht. Eventuelle Zusätze, die 

sich im Lauf der Zeit nach Auslieferung der CD-ROM als nützliche Add-ons 

herausstellen, sind immer aktuell über die zuvor erwähnte Web-Page zum 

Buch abrufbar.

Teil I 

Low-Level Konzepte von C++

2. Datentypen und Variablen 

Die Verwendung von Variablen ist eines der Grundkonzepte von OO-Sprachen, 

gleich wie bei imperativen und im Gegensatz zu funktionalen Programmiersprachen. 

Prinzipiell ist eine Variable ein Datenobjekt, das über einen symbolischen 

Namen (=Identifier) angesprochen werden kann und dessen Inhalt 

vom Programm manipuliert werden kann. Zusätzlich zum Identifier besitzen 

Variablen in C ++ auch noch einen Datentyp, der über ihre Natur Auskunft 

gibt. Damit wird dem Compiler mitgeteilt, welchen Speicherbedarf eine Variable 

hat und welche Operationen auf ihr ausführbar sind, bzw. wie gewisse 

Operatoren in diesem Kontext interpretiert werden müssen. 

2.1 Primitive Datentypen 

Als sogenannte primitive Datentypen werden die Typen bezeichnet, mit denen 

ein Computer im Prinzip “von sich aus” umgehen kann. Dies sind verschiedene 

Arten von Ganzzahlen (=integrale Typen), verschiedene Arten von 

Gleitkommazahlen (=floating-point Typen) und darstellbare Zeichen (=Characters). 

In C ++ stehen alle primitiven Datentypen zur Verfügung, die bereits 

in C existieren. Wie man in der folgenden Tabelle sehen kann, gibt es in C ++ 

auch einen boolschen Datentyp, den man in C vermisst. Ebenso ist wchar_t 

ein eingebauter Datentyp und nicht, wie in C, ein simples typedef. 

Typ Bedeutung 

char Ein Character, nimmt ein (üblicherweise) 8 Bit Zeichen auf. 

wchar_t Ein wide Character, nimmt ein mindestens (!) 

16 Bit Zeichen auf. 

bool Ein boolscher Wert, kann einen der Werte true oder 

false annehmen 

int Ein ganzzahliger Wert in der für die jeweilige Maschine 

“natürlichen” Größe. 

float Eine Gleitkommazahl mit einfacher Genauigkeit. 

double Eine Gleitkommazahl mit doppelter Genauigkeit. 

Zum Thema 8 Bit Zeichen in einem char möchte ich noch eine kurze 

Ergänzung liefern: Per Definition ist ein char mindestens 8 Bit lang. Aller-

14 2. Datentypen und Variablen 

dings ist auf allen gebräuchlichen Plattformen ein char wirklich genau 8 Bit 

lang und deshalb werde ich diese Spitzfindigkeit in der Folge nicht mehr weiter 

beachten. 

Wie in C gibt es auch noch die folgenden Qualifiers, mit denen man die 

Eigenschaften bestimmter Grunddatentypen steuern kann: 

Qualifier Bedeutung anwendbar auf 

signed vorzeichenbehaftet (normalerweise char, int 

nicht explizit angegeben) 

unsigned nicht vorzeichenbehaftet char, int 

short “kurz” int 

long “lang” int, double 

Der Qualifier signed wurde hier nur aus Gründen der Vollständigkeit angegeben. 

Im Normalfall wird dieser nicht explizit in Programmen verwendet, 

da als Default immer angenommen wird, dass es sich um eine vorzeichenbehaftete 

Zahl handelt. 

Wenn man die erste Tabelle mit den Grunddatentypen näher betrachtet, 

dann fällt auf, dass C ++ leider ein ganz großes Manko von C geerbt 

hat: Den Datentypen liegt die “natürliche” Größe auf verschiedenen Zielplattformen 

zugrunde! Man kann nun viel über Vor- und Nachteile dieser 

Spezifikation diskutieren. Tatsache ist, dass oft sogar von erfahrenen Entwicklern 

immer wieder falsche Annahmen über die Größe von Datentypen 

getroffen werden. Dies führt dann in manchen Fällen zu völlig unerklärbaren 

Fehlern mit manchmal katastrophalen Auswirkungen. 

Die möglichen Kombinationen der Grunddatentypen mit entsprechenden 

Qualifiers ergibt folgendes Gesamtbild: 

char: 

Eine Variable vom Typ char kann genau ein Zeichen aus dem gültigen 

(üblicherweise) 8 Bit-Zeichensatz der jeweiligen Zielplattform halten. 

Vorsicht ist geboten, denn es wird keine bindende Aussage getroffen, welcher 

Zeichensatz auf der Zielplattform gültig ist. Hier gibt es massive Unterschiede, 

denn außer Plattformabhängigkeiten gibt es auch Abhängigkeiten 

von der natürliche Sprache (z.B. Deutsch, Englisch), auf die ein 

Zeichensatz ausgelegt ist. Im Prinzip ist das Einzige, was man einigermaßen 

sicher sagen kann, dass im Normalfall ein Zeichensatz die Buchstaben 

a–z, A–Z, die Zahlen 0–9 und die wichtigsten Satzzeichen, wie Punkt, 

Komma, etc. enthält. Man kann jedoch nicht davon ausgehen, dass diese 

Zeichen in verschiedenen Zeichensätzen denselben Character-Code besitzen. 

Man kann nicht einmal davon ausgehen, dass alle möglichen 256 

Zeichen tatsächlich in einem Zeichensatz belegt sind, dass also ein echter 

8 Bit Zeichensatz vorliegt. Oft findet man einen 7 Bit Zeichensatz auf 

einer Maschine vor, bei dem Characters mit einem Code größer als 127 

einfach “leer” sind.

2.1 Primitive Datentypen 15 

Wenn man sich kurz überlegt, dass in einem char einfach nur ein Code 

in Form einer Zahl gespeichert wird, der dann erst bei der Darstellung 

des entsprechenden Zeichens in einer Zeichensatztabelle “nachgeschlagen” 

wird, dann erkennt man leicht, was es mit einem char eigentlich 

im Grunde auf sich hat: Für den Computer ist er einfach eine (zumeist) 

8 Bit lange Ganzzahl. Daher kann man auch mit einem char rechnen 

wie mit allen anderen integralen Datentypen. 

Hier ist allerdings allergrößte Vorsicht geboten: Es gibt keine bindende 

Definition, ob ein Compiler einen char nun prinzipiell als signed oder 

unsigned behandelt! Will man also einen char als kleine vorzeichenbehaftete 

Ganzzahl verwenden, so ist der einzig sichere Weg, den voll 

ausgeschriebenen Datentyp signed char zu verwenden. In diesem Fall 

ist dann das Fassungsvermögen mit einem Wertebereich von -128–127 

nicht gerade berauschend, aber je nach Anwendung ist dies ausreichend 

und wird aus Gründen der Speicher-Ersparnis verwendet. 

signed char: 

Wenn schon bei char nicht gesagt ist, ob dieser auf einer Plattform nun 

vorzeichenbehaftet ist oder nicht, dann muss man einen vorzeichenbehafteten 

char eben erzwingen, wenn man unbedingt einen solchen benötigt. 

Genau dies ist dann der hier vorgestellte signed char mit einem Wertebereich 

von -128–127. 

unsigned char: 

Wo man einen signed char erzwingen kann, gibt es natürlich auch ein 

(sicher-)nicht-vorzeichenbehaftetes Pendant dazu: den unsigned char 

mit dem resultierenden Wertebereich von 0–255. 

Im Zusammenhang mit der Darstellung von Zeichen aus dem Zeichensatz 

ist es egal, ob man mit char, signed char oder unsigned char arbeitet. 

Zum “Nachschlagen” in der Zeichensatztabelle wird er sowieso als nichtvorzeichenbehaftet 

betrachtet (oder hat schon jemand negative ASCII- 

Codes gesehen? :-)). 

wchar_t: 

Für einen wchar_t gilt dasselbe, was schon über char gesagt wurde. Der 

einzige Unterschied ist, dass es sich hier um einen “Wide” Character 

handelt, der für Unicode und ähnliche Zeichensätze eingesetzt wird und 

als solcher mindestens 16 Bit lang ist. Sich den Kopf über signed und 

unsigned Varianten desselben zu zerbrechen hat auch nicht übertrieben 

viel Sinn, denn zum Rechnen stehen in diesem Größenbereich bereits die 

“echten” Ganzzahlen zur Verfügung (z.B. short). 

bool: 

Der Datentyp bool ist ein primitiver Typ, der in C ++ erst vor wenigen 

Jahren eingeführt und zum Standard erklärt wurde. In C und in 

frühen C ++ Implementationen gab es diesen Datentyp noch nicht, allerdings 

gab es auch damals schon starke Bestrebungen, einen solchen 

einzuführen. Aus diesem Grund findet man in vielen älteren Standard


Libraries noch verschiedenste Typdefinitionen für einen boolschen Wert, 

die von boolean über Boolean und BOOL bis zu bool reichen. Natürlich 

gab es auch die entsprechenden Definitionen der Wahrheitswerte dazu, 

die ebenfalls nicht standardisiert waren. Beliebige Schreibweisen wie z.B. 

TRUE/FALSE für die Wahrheitswerte existierten. 

Um diesem Wildwuchs Einhalt zu gebieten, wurde der Datentyp bool mit 

den dazugehörigen Wahrheitswerten true und false in den C ++ Standard 

aufgenommen. Wo auch immer man also explizit einen boolschen 

Wert braucht, wird unbedingt die Verwendung dieses Typs empfohlen. 

Rekapituliert man kurz die Definition von C, die auch C ++ vollinhaltlich 

zugrunde liegt, wann etwas als wahr bzw. falsch interpretiert wird, dann 

kommt man schnell auf des Pudels Kern, wie ein bool intern funktioniert: 

• Ein Ganzzahlenwert von 0 wird als false interpretiert. 

• Jeder Ganzzahlenwert ungleich 0 wird als true interpretiert. 

Der Datentyp bool ist in Wirklichkeit hinter den Kulissen ein Ganzzahlendatentyp. 

Es ist für ihn keine bestimmte Größe vorgeschrieben. 

Üblicherweise wird ein bool intern durch einen char oder auch einen 

short (siehe unten) repräsentiert. 

Per Definition ist false die Ganzzahl 0. Weil nun für true das ganze 

Spektrum aller möglichen Zahlen ungleich 0 zur Verfügung steht, einigte 

man sich darauf, true durch die Ganzzahl 1 zu repräsentieren. 

Wo auch immer Variablen vom Typ bool in Rechenoperationen verwendet 

werden (ja, das funktioniert, bool ist ja eine Ganzzahl!), werden sie 

implizit zu int (siehe unten) umgewandelt. Eine Zuweisung von einer 

Ganzzahl auf einen bool führt dazu, dass ein Wert von 0 zu false wird 

(was sonst, false ist ja auch 0 :-)) und jeder Wert ungleich 0 wird konvertiert 

zu true (also einfach zu 1). 

Verwirrend? Keine Sorge, wir werden in der Folge noch ein Beispiel 

betrachten, in dem diese Zusammenhänge genau demonstriert werden. 

Das Einzige, was es mit bool, true und false auf sich hat, ist, dass 

hier ein eigener Datentyp eingeführt wurde und die Wahrheitswerte im 

Endeffekt genau definiert auf 0 und 1 abgebildet werden, anstatt auf 0 

und “irgendwas ungleich 0”, um dem existierenden Wildwuchs ein Ende 

zu setzen. 

int: 

Der Datentyp int (oder ganz genau signed int, diese Schreibweise 

ist aber nicht üblich) repräsentiert den vorzeichenbehafteten Standard- 

Ganzzahlentyp auf der jeweiligen Zielplattform. Es gibt keine Regel, wie 

groß denn nun ein int tatsächlich ist. Heute üblich ist eine Größe von 

32 Bit, verlassen darf man sich darauf allerdings niemals! Bis vor nicht 

allzu langer Zeit waren 16 Bit für einen int auf PC-Systemen durchaus 

üblich. Was passiert, wenn man sich darauf verlässt, dass 32 Bit 

zur Verfügung stehen (Wertebereich ca. -2 Mrd.–2 Mrd.) und plötzlich


hat man aber nur noch 16 Bits zum Speichern einer Zahl (Wertebereich 

-32768–32767), das kann man sich sicherlich ausmalen. 

unsigned int bzw. unsigned: 

Der Datentyp unsigned (=übliche Kurzform für unsigned int) unterliegt 

genau denselben Gesetzen wie sein vorzeichenbehaftetes Pendant: 

Sein Fassungsvermögen ist maschinenabhängig. Allerdings ist ein 

unsigned auf einer Zielplattform garantiert immer gleich lang wie ein 

int, nur die Interpretation ist verschieden: Ein unsigned wird immer 

als positive Ganzzahl betrachtet, also ohne Vorzeichenbit. Damit kann 

er auf Kosten der wegfallenden negativen Zahlen “doppelt so große” positive 

Zahlen speichern (0 gilt auch als positive Zahl!) wie sein vorzeichenbehafteter 

Bruder. 

short int bzw. short: 

Der Datentyp short (=übliche Kurzform für short int) bezeichnet 

einen “kurzen” int. Tolle und unglaublich genaue Aussage, oder :-)? 

Leider kann wirklich nichts allzu Genaues darüber gesagt werden. Das 

Einzige, was per Definition garantiert ist, ist Folgendes: 

Ein short ist eine vorzeichenbehaftete Ganzzahl, deren Größe kleiner 

oder gleich der Größe eines int ist. Zum Glück kann man die Aussage 

zumindest ein kleines Bisschen präzisieren: Es wird auch garantiert, dass 

ein short mindestens 16 Bit lang ist. 

unsigned short int bzw. unsigned short: 

Genauso toll, wie die Aussage über short ausgefallen ist, fällt sie auch 

für unsigned short (=übliche Kurzform für unsigned short int) aus: 

Ein unsigned short bezeichnet einen “kurzen” unsigned. Garantieren 

kann man wieder nur: 

Ein unsigned short ist eine positive Ganzzahl, deren Größe kleiner oder 

gleich der Größe eines unsigned ist. Auch hier gilt natürlich wieder, dass 

die Länge mindestens 16 Bit beträgt. 

long int bzw. long: 

Weil wir gerade bei den epochalen Erkenntnissen waren, machen wir 

damit gleich weiter: Ein long (=übliche Kurzform für long int) bezeichnet 

einen “langen” int, für den Folgendes garantiert ist: 

Ein long ist eine vorzeichenbehaftete Ganzzahl, deren Fassungsvermögen 

größer oder gleich dem eines int ist. Zum Glück kann man auch diese 

Aussage zumindest ein kleines Bisschen präzisieren: Es wird weiters 

garantiert, dass ein long mindestens 32 Bit lang ist. 

unsigned long int bzw. unsigned long: 

Dass nun für einen unsigned long (=übliche Kurzform für 

unsigned long int) Folgendes gilt, läßt sich leicht erraten: 

Ein unsigned long ist eine positive Ganzzahl, deren Fassungsvermögen 

größer oder gleich dem eines unsigned ist. Die Garantie für die Mindestlänge 

von 32 Bit gilt natürlich hier ebenfalls. 

long long int bzw. long long:


Je nach Plattform gibt es auch einen “besonders langen” long Wert. 

Seine Existenz ist allerdings vom Compiler abhängig. Hier hilft leider nur 

ausprobieren. Wenn er definiert ist, so kann man Folgendes garantiert 

sagen: 

Ein long long ist eine vorzeichenbehaftete Ganzzahl, deren Fassungsvermögen 

größer oder gleich dem eines long ist. 

unsigned long long int bzw. unsigned long long: 

Bezüglich der Existenz eines unsigned long long gilt dasselbe, wie für 

den long long Datentyp zuvor. Wenn er definiert ist, so ist Folgendes 

garantiert: 

Ein unsigned long long ist eine positive Ganzzahl, deren Fassungsvermögen 

größer oder gleich dem eines unsigned long ist. 

float: 

Wie die Ganzzahl-Datentypen, so sind auch die Gleitkomma-Datentypen 

von C ++ maschinenabhängig: float repräsentiert eine vorzeichenbehaftete 

Gleitkommazahl mit einfacher Genauigkeit (=single Precision), was 

auch immer das heißt. Ich möchte es einfach so formulieren: Arbeitet 

man in einem Programm mit Gleitkommazahlen, deren Größe sich in einem 

Bereich von in etwa ±10 15 –±10 35 bewegt und bei denen Rundungsfehler 

keine besondere Rolle spielen, dann ist die Verwendung von float 

normalerweise ausreichend. Will man ganz genau über das Fassungsvermögen, 

die Genauigkeit und andere Eigenschaften eines float und 

auch anderer Datentypen Bescheid wissen, so kann man dies über die sogenannten 

numeric_limits tun. Da es sich hierbei um eine objektorientierte 

Implementation handelt, wird die Besprechung auf Abschnitt 16.7 

verschoben. 

Nicht-vorzeichenbehaftete Gleitkommazahlen (also unsigned float) gibt 

es nicht. Aufgrund der Natur dieser Zahlen wären diese auch nicht besonders 

sinnvoll. 

double: 

Ein double repräsentiert eine vorzeichenbehaftete Gleitkommazahl mit 

doppelter Genauigkeit (=double Precision), was auch immer man darunter 

nun versteht. Als kleinen Anhaltspunkt möchte ich eigentlich nur 

erwähnen, dass double üblicherweise vom Wertebereich (ca. ±10 300 ) 

als auch von der Anfälligkeit gegenüber Rundungsfehlern her für gängige 

Gleitkomma-Anwendungen brauchbar ist. Auch hier sind, wie bei float, 

alle Eigenschaften über die numeric_limits herausfindbar. 

long double: 

Wo auch immer double nicht ausreichend ist, kann man auf long double 

zurückgreifen, der eine Gleitkommazahl mit erweiterter Genauigkeit 

(=extended Precision) bezeichnet. Hier wird es allerdings gleich noch 

etwas schwammiger als bei float und double zuvor, denn Genaues über 

seine Natur und sein Fassungsvermögen erfährt man wirklich nur noch 

durch die entsprechenden Abfragen von numeric_limits.


Leser, die ihr Grundwissen über primitive Datentypen (auch Gleitkommazahlen), 

Besonderheiten derselben und die interne Repräsentation derselben 

kurz durch eine viel ausführlichere Erklärung auffrischen möchten, finden eine 

genaue Behandlung dieses Themas in Kapitel 4 und auch in Anhang A 

des Buchs Softwareentwicklung in C. 

Dort wird auch anhand von Beispielen die besondere Gefahr beim Mischen 

von Datentypen sowie von signed und unsigned-Varianten desselben Typs 

aufgezeigt. Alle diese Betrachtungen sind nicht nur für C sondern auch für 

C ++ zu 100% gültig! 

Leider findet man immer wieder dieselben Fehler beim Umgang mit Variablen 

verschiedener Datentypen, egal, ob sie nun von Neulingen begangen 

werden oder ob es sich um erfahrenere Entwickler handelt. Die Ursache vieler 

Fehler ist sicherlich darin zu finden, dass Datentypen einfach einmal nach 

dem Motto “es gibt sie und sie funktionieren” betrachtet werden. Die genauen 

Interna werden als “das weiß sowieso der Computer” abgetan. Ich möchte 

wirklich allen Lesern ans Herz legen, sich zumindest einmal mit den Interna 

genau auseinanderzusetzen, um das notwendige Verständnis für potentielle 

Fehlerquellen zu entwickeln. Aus diesem Grund möchte ich dieses Kapitel 

auch mit ein paar Hinweisen auf mögliche Fallen schließen: 

Vorsicht Falle: Es dürfen niemals Annahmen über die Größe und das damit 

verbundene Fassungsvermögen von Datentypen getroffen werden. Insbesondere 

ist das Einzige, was man in Bezug auf die Größe von Ganzzahlendatentypen 

garantieren kann, Folgendes: 

sizeof(short)


Vorsicht Falle: Annahmen über den zugrunde liegenden Zeichensatz auf 

einer Plattform sind nicht zulässig. Aus diesem Grund sollen niemals Characters 

im Programm hardcodiert durch ihren Character-Code definiert werden. 

Weiters ist keinesfalls garantiert, dass es im Zeichensatz des Zielsystems 

bestimmte Sonderzeichen (z.B. deutsche Umlaute) überhaupt gibt. 

Das Thema der Zeichensätze ist leider ohnehin ein sehr Leidiges, da gerade 

hier praktisch seit der Erfindung der Computer viele parallele “Standards” 

existieren. 

2.2 Deklaration, Definition und Initialisierung 

Nachdem jetzt zumindest bekannt ist, welche primitiven Datentypen für Variablen 

zur Verfügung stehen, wird es Zeit, diese auch wirklich zu verwenden. 

Dazu möchte ich gleich zu Beginn eine Definition der Begriffe Deklaration, 

Definition und Initialisierung anführen, denn diese Begriffe werden fast 

durchgehend in der Literatur völlig durchmischt und nur allzu oft gänzlich 

falsch verwendet. 

Deklaration: Etwas zu deklarieren bedeutet, einen Hinweis zu geben, dass 

es “irgendwo” so etwas gibt. Im Falle einer Variable bedeutet damit eine 

Deklaration einfach nur einen Hinweis an den Compiler: 

Es gibt eine Variable unter einem bestimmten Namen mit einem bestimmten 

Typ. Sollte genau dieser Variablenname irgendwo verwendet werden, 

dann weißt du, wie sie zu behandeln ist. 

Im Falle einer Variable bedeutet deklarieren definitiv nicht, sie anzulegen 

und für sie Speicher zu reservieren, obwohl sich diese Fehlverwendung 

des Begriffs durch die Literatur durchzieht. Speicher reservieren, etc. ist 

eine Definition! 

Definition: Etwas zu definieren bedeutet, es tatsächlich mit allen Konsequenzen 

anzulegen. Im Falle einer Variable wird z.B. intern der Code eingesetzt, 

der entsprechenden Speicherplatz reserviert, etc. 

Einer der Hauptgründe, warum die Begriffe Deklaration und Definition 

so oft vermischt werden, ist, weil in den meisten Programmiersprachen, 

so auch in C ++, die Deklaration nicht explizit stattfinden muss (aber 

kann!), sondern die Deklaration auch implizit bei der Definition passieren 

kann. 

Initialisierung: Etwas zu initialisieren bedeutet, ihm beim Anlegen einen 

Startwert zuzuweisen. Dies kann in den meisten Programmiersprachen, 

auch in C ++, im Rahmen einer Definition geschehen, aber niemals bei 

einer expliziten Deklaration. Im Prinzip sonnenklar, denn wo nichts 

angelegt wird, dort kann auch nichts zugewiesen werden!

2.2 Deklaration, Definition und Initialisierung 21 

In C ++ wurde auch der Begriff der extern-Deklaration für die Deklaration 

von Variablen von C übernommen. Zum Thema der expliziten Deklaration 

von Variablen in C findet sich in Kapitel 17 im Buch Softwareentwicklung in 

C eine ausführlichere Diskussion, die auch für C ++ volle Gültigkeit hat. 

Explizite Deklaration von Variablen ist nur notwendig, wenn eine Variable 

in einem anderen File verwendet werden soll als in dem, in dem sie 

definiert wurde. Der Grund ist einfach: Beim übersetzen “sieht” der Compiler 

immer nur ein File nach dem anderen. Erst der Linker, als letztes Glied 

bei der Programmübersetzung, sieht alle Files und verknüpft sie zu einem 

Gesamtprogramm. Nun muss in einem solchen Fall also dem Compiler mitgeteilt 

werden, dass es eine Variable unter einem bestimmten Namen und 

mit einem bestimmten Typ “irgendwo anders” gibt. Selbstredend muss eine 

Deklaration für eine Variable denselben Typ angeben, wie die Definition, ansonsten 

beschwert sich der Compiler. Wie sich weiters leicht erraten lässt, 

darf es in einem Programm, egal aus wie vielen Files es besteht, immer nur 

genau eine Definition und beliebig viele Deklarationen geben. 

Der soeben beschriebene Fall, der eine explizite Deklaration notwendig 

macht, ist allerdings nicht der Regelfall. In sauber strukturiertem Code passiert 

es sehr selten bis überhaupt nicht, dass globale Variablen existieren, 

die aus mehreren Files heraus sichtbar sein müssen. Der Normalfall in C ++ 

ist der, dass Variablen in einem einzigen Schritt deklariert und gleichzeitig 

definiert werden. Dies geschieht, gleich wie in C, in der folgenden Form: 

; 

Es wird also zuerst der Typ (mit optionalem Qualifier), gefolgt vom 

gewünschten (hoffentlich sprechenden!) Variablennamen angegeben. Beispiele 

für gültige Variablendefinitionen wären: 

int count; 

unsigned index; 

long x_coordinate; 

Es gibt auch die Möglichkeit, mehrere Variablen desselben Typs gleich gemeinsam 

in einem Statement zu definieren, indem man die einzelnen Variablennamen 

durch einen Beistrich trennt. Ein Beispiel hierfür wäre: 

bool connected, sending_data, receiving_data; 

Allerdings möchte ich von dieser Art der Definition aus Gründen der Lesbarkeit 

des endgültigen Programms dringend abraten! Es tut nicht weh, wenn 

ein Programm um wenige Zeilen länger wird, aber es hilft, auf einen Blick 

alles zu finden. 

Wie später noch näher beleuchtet werden wird, gibt es einen sehr wichtigen 

Unterschied zwischen C und C ++, was den erlaubten Ort von Variablendefinitionen 

angeht. In C durften Variablen ausschließlich zu Beginn eines 

Blocks definiert werden. Im Gegensatz dazu dürfen Variablen in C ++ prinzipiell 

beliebig im laufenden Code definiert werden, was den resultierenden 

Code deutlich lesbarer machen kann. Neben der erhöhten Lesbarkeit gibt es,


je nach Situation, auch eine Performancesteigerung zu erwähnen. Denn wo 

keine Variable angelegt (und initialisiert) wird, dort wird auch kein Speicher 

und keine Rechenleistung dafür verbraucht. 

Ist man tatsächlich gezwungen, Variablen aus bereits genannten Gründen 

explizit zu deklarieren, so geschieht dies durch Voranstellen des Keywords 

extern. Das Statement 

extern bool master_running; 

stellt eine solche explizite Deklaration dar. Durch diese wird dem Compiler 

nur mitgeteilt, dass es “irgendwo” die Variable namens master_running gibt, 

und dass sie den Typ bool hat. 

Eine explizite Initialisierung von Variablen kann zusammen mit deren 

Definition vorgenommen werden, indem man ihnen gleich direkt einen Wert 

zuweist (ich setze hier mutigerweise das = Zeichen als Zuweisungsoperator 

als bekannt voraus :-)). Beispiele für gültige Definitionen von Variablen, die 

gleich eine Initialisierung beinhalten, wären: 

int count = 0; 

unsigned long x_coord = 0, y_coord = 0; 

Für den Fall, dass keine explizite Initialisierung wie eben beschrieben 

vorgenommen wird, verhält sich C ++ anders (und besser!) als C. Es wird 

nämlich unter bestimmten Umständen eine implizite Initialisierung durchgeführt, 

was in C nicht der Fall ist. 

Diese bestimmten Umstände, die zu einer impliziten Initialisierung führen, 

sind Folgende: 

• Globale Variablen werden auf ihre entsprechenden Nullwerte initialisiert. 

• Als static definierte lokale Variablen werden auf ihre entsprechenden Nullwerte 

initialisiert. 

Leser, denen nicht aus C geläufig ist, was static prinzipiell bewirkt, 

möchte ich auf Abschnitt 17.3 von Softwareentwicklung in C hinweisen. 

• Namespace Variablen werden auf ihre entsprechenden Nullwerte initialisiert 

(was Namespace Variablen genau sind, wird in Kapitel 14 noch erklärt). 

Entsprechende Nullwerte im Sinne der Initialisierung bedeutet, dass Zahlenvariablen 

auf 0 (bzw. 0.0 bei Gleitkommazahlen), Pointer auf 0 und bool- 

Variablen auf false initialisiert werden. 

Vorsicht Falle: Lokale Variablen (=auto-Variablen) werden nicht implizit 

initialisiert. Einer der häufigsten und am schwierigsten zu lokalisierenden 

Fehler ist es, Variablen nicht zu initialisieren, ihnen auch danach keinen Wert 

zuzuweisen, dann aber ihren Inhalt auszulesen! Dieser Inhalt ist dann “irgendein” 

Wert. Das Problem, das einen solchen Fehler so schwer lokalisierbar 

macht, ist der Umstand, dass ziemlich oft tatsächlich zufällig (durch Interna 

des Systems) ein Nullwert in der Variable steht. Damit kann es passieren,

2.2 Deklaration, Definition und Initialisierung 23 

dass Programme lange Zeit scheinbar fehlerlos arbeiten, bis plötzlich nach 

einer kleinen Änderung an irgendeiner Stelle im Programm die unerklärlichsten 

Dinge passieren, obwohl der geänderte Teil und der verrückt spielende 

Teil im Prinzip gar nichts miteinander zu tun haben. Wenn so etwas unter 

dem üblichen Zeitdruck bei der Softwareentwicklung passiert, freuen sich 

die Hersteller von Kaffeeautomaten und die Pizzalieferanten, denn die spätnächtliche 

Debugging-Session ist damit garantiert (mit etwas Glück ist es nur 

eine Nacht :-)). 

Da das Thema der internen Abwicklung der Initialisierung mit dem jetzigen 

Wissensstand noch nicht erschöpfend abgehandelt werden kann, vor 

allem da es im Kontext mit den OO-Features von C ++ noch einiges dazu zu 

sagen gibt, möchte ich es im Augenblick bei diesen grundsätzlichen Aussagen 

belassen. Wo auch immer es wichtige weitere Fakten dazu gibt, werden diese 

ergänzend angeführt. 

Eine Kleinigkeit, die zwar auch bei der Initialisierung gebraucht wird, 

aber im Prinzip ein eigenes Thema ist, sind die sogenannten Literals. Als 

Literals werden explizite konstante Zahlen- (z.B. 17, 12.5, etc.) und andere 

Werte (z.B. ’a’, true) bezeichnet. 

Ich möchte das Thema dieser besonderen Konstanten bzw. Literals hier nur 

kurz und beispielhaft behandeln, da es im Prinzip völlig intuitiv ist. Leser, 

die sich nach dieser kurzen Beschreibung vielleicht doch nicht so sicher fühlen, 

möchte ich auf Kapitel 4 aus Softwareentwicklung in C verweisen. 

Leser, die mit dem oktalen oder dem hexadezimalen Zahlensystem noch 

nicht vertraut sind, finden zusätzliche Information dazu in Abschnitt A.2.2 

im Buch Softwareentwicklung in C. 

Ganzzahlen-Literals: Diese sind im Kontext mit allen verschiedenen Variationen 

von Ganzzahl-Datentypen verwendbar, also für int, short, 

unsigned, etc., natürlich auch für char bzw. unsigned char und, last, 

but not least auch bei bool. Bei Verwendung im Kontext mit bool gibt 

es noch ein paar Kleinigkeiten zu wissen, ein Beispiel dazu findet sich 

weiter unten. 

Die üblichste Schreibweise, die für die meisten Belange die beste ist, 

ist die völlig intuitive Dezimalschreibweise: Man schreibt einfach die 

gewünschte Zahl, also z.B. 12, 348. Neben dieser Schreibweise gibt es 

aber noch zwei besondere Schreibweisen, nämlich die hexadezimale (=zur 

Basis 16) und die oktale (=zur Basis 8). Oktalzahlen werden durch eine 

vorangestellte 0 gekennzeichnet, Hexadezimalzahlen (kurz: hex-Zahlen) 

durch das Präfix 0x. Die folgenden Literals sind also im Prinzip gleichwertig: 

18, 0x12 und 022, denn die letzteren beiden sind nur andere 

Darstellungen von 18 im hexadezimalen bzw. oktalen Zahlensystem. 

Will man ein Ganzzahlen-Literal explizit als unsigned kennzeichnen, so 

gibt man ihm das Suffix U bzw. u. Will man explizit ein long-Literal, so


ist das Suffix L bzw. l angebracht. Also bezeichnet z.B. 18U oder auch 

18u explizit einen unsigned Wert, wogegen 18 vom Compiler als int 

betrachtet wird. Durch 18L wird dann entsprechend eine Interpretation 

als long erzwungen. Natürlich funktioniert die Kombination 18UL zum 

Erzwingen einer Interpretation als unsigned long genauso. 

Wenn man, wie es in der Praxis der Regelfall ist, explizit keine Interpretation 

als bestimmten Datentyp erzwingt, so “schätzt” der Compiler, 

was die sinnvollste Interpretation wäre und handelt entsprechend. 

Boolean-Literals: Wie zu erwarten sind die Boolean-Literals einfach als true 

bzw. false hinschreibbar, ohne dass irgendwelche besonderen Konventionen, 

wie z.B. Anführungszeichen vonnöten wären. 

Character-Literals: Ein Character-Literal wird einfach als entsprechender 

Character, eingeschlossen in einfache Anführungszeichen dargestellt 

(z.B. ’x’ steht für den Character x). Das Umschließen mit einfachen 

Anführungszeichen ist notwendig, denn woher sollte sonst der Compiler 

zwischen einem Buchstaben und z.B. einer Variable mit einem einbuchstabigen 

Namen unterscheiden können (abgesehen davon, dass einbuchstabige 

Namen sowieso nicht erwünscht sind :-))? 

Nun gibt es auch Characters, die nicht so einfach als druckbare (!) Einzelzeichen 

zur Verfügung stehen, wie z.B. ein Zeilenumbruch oder ein Tabulator. 

Für diesen Fall gibt es die sogenannten Escape-Sequenzen, die aus 

einem \ (=Backslash), gefolgt von zumindest einem Zeichen bestehen. 

Ein typischer Vertreter davon ist z.B. ’\n’, was für einen Zeilenumbruch 

steht, oder ’\\’, was das Backslash-Zeichen selbst darstellt. 

Steht man vor dem Problem, dass man ein Zeichen als char-Literal schreiben 

will, das weder direkt darstellbar ist, noch über eine vordefinierte 

Escape-Sequenz zur Verfügung steht, so kann man auch direkt dessen 

numerischen Character-Code in einer Escape-Sequenz verwenden. Diese 

Sequenz hat dann die Form ’\ddd’, wobei ddd für eine dreistellige 

Oktalzahl steht. 

Wide-Character-Literals: Das einzige Problem bei diesen Literals ist, dem 

Compiler klar zu machen, dass er es nicht mit einem normalen char zu 

tun hat, sondern mit einem wchar_t. Dies geschieht durch Voranstellen 

von L vor das Literal. Z.B. würde also L’x’ den Unicode Buchstaben x 

bezeichnen. Im Vorgriff möchte ich hier auch noch gleich erwähnen, dass 

diese Regel auch für Strings gilt: Man stellt ihnen ein L voran. Wenn 

also ein normaler String z.B. als "otto" geschrieben wird, so wird sein 

Unicode-Pendant als L"otto" im Code verewigt. 

Gleitkomma-Literals: Auch diese Literals sind völlig intuitiv, z.B. stellen 

17.3 oder 2.0 gültige Gleitkommazahlen dar. Die “wissenschaftliche” 

Schreibweise, z.B. 0.173e2 (steht für 0.173 ∗ 10 2 ) oder 14.93e-15 (steht 

für 14.93 ∗ 10 −15 ) ist zulässig. Hierbei ist darauf zu achten, dass keine 

Leerzeichen im Literal vorkommen. Z.B. wäre 14.93 e -15 ungültig!

2.3 Das erste C++ Programm 25 

Prinzipiell werden Gleitkomma-Literals vom Compiler als double interpretiert, 

jedoch kann man wie bei Ganzzahl-Literals auch eine andere 

Interpretation (als float) erzwingen, sollte dies gewünscht sein. Man 

muss dazu nur das Suffix F bzw. f verwenden, also z.B. 2.5f. 

Vorsicht Falle: Vor allem im deutschsprachigen Raum gibt es manchmal 

das eine oder andere Problem bei Neulingen: Das Dezimaltrennzeichen 

bei Gleitkommazahlen ist in C ++ immer ein Punkt! Ein Komma 

wird vom Compiler nicht akzeptiert. 

2.3 Das erste C++ Programm 

Genug der grauen Theorie, es wird nun wirklich Zeit für ein kleines Beispiel, 

das die bisher diskutierten Dinge zusammenfasst. Dazu schreiben wir ein 

C ++ Programm mit dem Namen var_demo.cpp. 

Ein kleiner Exkurs: Historisch gesehen haben sich für C ++ Programme 

die Extensions cpp, cc und C (im Gegensatz zu c für C-Programmen) 

eingebürgert. Welche Extension man nun verwendet, ist im Prinzip Geschmackssache. 

Ich war selbst aus mehreren Gründen immer ein Anhänger 

von C, aber mittlerweile setzt sich cpp auf allen Plattformen als Standard 

durch. Leider gibt es im Augenblick auch weit verbreitete Compiler gewisser 

Hersteller, die sich absolut weigern, Programme mit einem C als Extension 

als C ++ Programme anzuerkennen. Das allerdings ist definitiv in meinen 

Augen nicht akzeptabel. Wie dem auch sei, im Rahmen dieses Buchs wird 

durchgehend cpp als Extension verwendet. 

Lesern, die bisher noch nie ein C-Programm gesehen haben, möchte ich die 

Lektüre von Kapitel 3 aus Softwareentwicklung in C sehr ans Herz legen, 

bevor wir zum ersten C ++ Programm kommen. 

Das File var_demo.cpp hat folgenden Inhalt (man bemerke: Das erste 

Programm heißt nicht hello_world.cpp :-)): 

1 // var demo . cpp − demo program to show the behaviour o f C++ Variables 

2 

3 #include 

4 

5 using std : : cout ; 

6 using std : : endl ; 

7 

8 void aFunction ( ) ; // function d e c l a r a t i o n 

9 

10 int a g l o b a l v a r = 1 7 ; // e x p l i c i t l y i n i t i a l i z e d 

11 int a n o t h e r g l o b a l v a r ; // i m p l i c i t l y i n i t i a l i z e d to 0 

12 

13 int main ( int argc , char ∗ argv [ ] )


14 { 

15 aFunction ( ) ; 

16 

17 cout

a g l o b a l v a r : 1 7 

a n o t h e r g l o b a l v a r : 0 

bool s e t to true : 1 

bool s e t to f a l s e : 0 

bool from i n t : 1 

bool to i n t : 1 

signed (−1) or unsigned ( 2 5 5 ) char ? −1 

c a l l c o u n t e r : 2 

u n i n i t i a l i z e d var : 134513980 


Der hier inkludierte Output stammt von einem 32 Bit Linux System. Die Zeilen, 

die die Werte der uninitialisierten Variablen anzeigen, können natürlich 

bei jedem neuen Programmlauf und je nach System verschiedensten Output 

liefern. Die Zeile, in der ausgegeben wird, ob wir es auf unserem System implizit 

mit signed oder unsigned Characters zu tun haben, ist natürlich von 

System zu System verschieden. Auf den meisten Systemen wird allerdings 

-1 ausgegeben werden. 

Bösartigerweise habe ich ein wenig vorgegriffen und im Programm bereits 

ein C ++ Konstrukt verwendet, das erst im OO-Teil des Buchs genau 

besprochen werden wird: Den Standard-Output-Stream (namens cout) zur 

Bildschirmausgabe. Aber keine Panik, dieser Stream erleichtert unser Leben 

als Entwickler deutlich und es ist auch ganz einfach, damit umzugehen. 

Führen wir also das Programm einmal häppchenweise einer Analyse zu: 

• Bevor wir zu den technischen Details kommen, muss ich noch kurz etwas 

anmerken: Leser, denen z.B. die Namen der globalen Variablen komisch 

vorkommen, weil sie mit einem Underline enden, möchte ich kurz auf den 

Coding Standard in Anhang A verweisen, der den Beispielen in diesem 

Buch zugrunde liegt. 

• In Zeile 1 sehen wir die typische Schreibweise von Kommentaren in C ++: 

Ein Kommentar beginnt mit // irgendwo in der Zeile und endet automatisch 

mit dem Ende der Zeile. 

In C ++ kann auch die C-Schreibweise der Block-Kommentare verwendet 

werden, die mit /* begonnen und mit */ beendet wird. Dies wird allerdings 

nicht empfohlen, da Schachtelungen dieser Blöcke nicht erlaubt sind und 

dies zu Problemen führen kann. Eine genaue Diskussion zu diesem Thema 

findet sich in Softwareentwicklung in C in Kapitel 4. 

• Das #include-Statement in Zeile 3 bewirkt, dass Entwickler, die Standard- 

C gewohnt sind, lächelnd den Kopf schütteln und sich sicher sind, dass mir 

hier ein Fehler unterlaufen ist, denn hier sollte doch wohl 

#include 

stehen. Leser, die noch keine Erfahrung mit C haben, beginnen erst jetzt 

lächelnd den Kopf zu schütteln und sind sich sicher, dass ich im Fieber 

liege, weil ich gerade wirres Zeug schreibe. Beides ist mitnichten der Fall! 

Des Rätsels Lösung sieht folgendermaßen aus: 

– Ich habe bereits erwähnt, dass es explizite Deklarationen von Variablen 

gibt. Ebenso gibt es auch explizite Deklarationen von allen möglichen


anderen Dingen, wie z.B. Funktionen (in Zeile 8 unseres Programms 

zu sehen) oder Klassen und anderen Datentypen, die wir noch kennen 

lernen werden. In sogenannten Libraries, also Programmbibliotheken, 

werden hilfreiche Tools zur Verfügung gestellt, die Entwicklern das Leben 

erleichtern. Diese Libraries werden vom Linker zu unserem ausführbaren 

Programm (=Executable) dazugehängt, damit der darin enthaltene Code 

auch vom Programm aus aufrufbar ist. Die Deklarationen, was nun 

genau für uns im Programm aus den Libraries verwendbar ist, stehen 

in sogenannten Header-Files. Header-Files haben üblicherweise die File- 

Extension .h. 

– Die Header-Files der Libraries, die wir im Programm verwenden wollen, 

müssen wir explizit einbinden, damit die Deklarationen wirksam 

werden. Diese Aufgabe übernimmt der sogenannte Preprocessor, auf 

den wir später noch genauer eingehen werden. Dieser arbeitet das Programm 

noch vor dem C ++ Compiler durch und nimmt textuelle Übersetzungen 

vor. Das Einbinden der Headers erfolgt mittels der #include 

Preprocessor-Anweisung. 

– Bei #include wurde traditionsgemäß immer der Name der Headers inklusive 

der Extension .h angegeben, dies hat sich allerdings in den neueren 

Versionen der C ++ Compiler geändert. Einerseits aus Gründen der 

Kompatibilität zu älteren Versionen und andererseits um gewisse Optimierungen 

z.B. durch Vor-Übersetzung von Headers zu ermöglichen, 

wird es dem Preprocessor bei Standard-Headers selbst überlassen, die 

entsprechende Extension implizit zu verwenden oder auch einfach mit 

Headers ohne Extension zu arbeiten. Damit wird bei solchen Headers 

keine File-Extension mehr angegeben. Genaueres zur Arbeitsweise des 

Preprocessors wird in Kapitel 7 besprochen. 

• Die beiden Anweisungen in den Zeilen 5–6 des Programms möchte ich hier 

kurz überspringen und erst weiter unten bei der Erklärung von cout darauf 

zurückkommen. 

• In Zeile 8 steht die Deklaration einer Funktion namens aFunction, deren 

Definition ab Zeile 40 zu finden ist. Für Leser, die noch keine Erfahrung 

mit C haben und noch nicht so genau wissen, was eine Funktion ist, möchte 

ich ganz kurz vorgreifen: 

Eine Funktion ist eine Zusammenfassung mehrerer Anweisungen zu einem 

aufrufbaren Ganzen. Sie nimmt beliebig viele Parameter entgegen und liefert 

einen return-Wert als Ergebnis. 

Eine genaue Erklärung, was es mit Funktionen in C prinzipiell auf sich hat, 

findet sich in Kapitel 8 des Buchs Softwareentwicklung in C. Ausgenommen 

von einigen sehr angenehmen Erweiterungen in C ++, auf die später noch 

näher eingegangen wird, besitzt alles, was für Funktionen in C gilt, auch 

in C ++ seine volle Gültigkeit.


• Zeile 10 zeigt die Definition einer globalen Variable mit expliziter Initialisierung, 

wie sie auch in C üblich ist. 

• In Zeile 11 finden wir dann eine implizite Initialisierung, wie sie nur in C ++, 

nicht aber in C funktioniert. Durch das Fehlen einer expliziten Initialisierung 

setzt der Compiler beim Übersetzen den richtigen Code ein, der die 

Variable automatisch auf 0 initialisiert. 

• Wie in C, so ist auch in C ++ Programmen die spezielle Funktion main der 

Startpunkt eines jeden Programms. Und auch hier nimmt main als ersten 

Parameter die Anzahl der übergebenen Command-Line Arguments und 

als zweiten Parameter ein Array von Strings, das ebendiese hält. Auch der 

return-Wert von main ist wie gewohnt ein int. 

Eine genaue Beschreibung, was es mit den Command-Line Arguments auf 

sich hat, findet sich in Abschnitt 20.1 in Softwareentwicklung in C. 

• Den Aufruf von aFunction in Zeile 15 möchte ich an dieser Stelle überspringen, 

viel interessanter ist das Konstrukt, das in Zeile 17 zu finden 

ist: 

– cout ist der Name des Output-Streams, der den Standard-Output von 

Programmen repräsentiert. Dieses cout trägt auch Schuld daran, dass 

im Programm der Header iostream inkludiert wurde, denn dort findet 

sich seine Deklaration. 

– Was rechts neben cout so aussieht wie der left-Shift Bit-Operator, hat 

in Verbindung mit Output-Streams in C ++ eine besondere Bedeutung, 

nämlich: Schreibe das Folgende auf diesen Stream. Diese Definition des 


teilen wir dem Compiler mit, dass wir cout aus dem Namespace std 

verwenden wollen. Würden wir diese Anweisung nicht im Programm 

stehen haben, dann würde sich der Compiler bei jeder Verwendung von 

cout beschweren, dass er diesen Stream nicht kennt. 

Ganz gleich verhält es sich mit endl. Eine genaue Erklärung, was es 

mit Namespaces auf sich hat, findet sich in Kapitel 14. Einstweilen ist 

es genug, zu wissen, dass man mittels using die Verwendung gewisser 

Teile aus einem Namespace bekannt gibt. 

Fassen wir also noch einmal die Einzelteile in Zeile 17 zusammen, dann 

liest sie sich so: Schreibe hintereinander den String "a_global_var_: " 

und den Inhalt der int-Variablen a_global_var_, gefolgt von einem Zeilenumbruch 

auf den Standard-Output des Programms. 

• In Zeile 20 findet sich ein Beispiel dafür, dass Variablen in C ++ beliebig im 

laufenden Code definiert werden können, was in C nicht möglich ist. 

• In den Zeilen 24–28 wird eine besondere Eigenschaft von Variablen vom 

Typ bool demonstriert: Sie sind kompatibel zu int-Variablen in der Hinsicht, 

dass man beliebige Zahlen zuweisen kann. Allerdings werden die 

Zahlen bei der Zuweisung immer genau auf die vordefinierten Wahrheitswerte 

true und false, also auf 0 und 1 reduziert. 

• In den Zeilen 30–32 wird kurz demonstriert, wie man untersuchen kann, ob 

char auf einer Zielplattform nun per Default als signed oder als unsigned 

interpretiert wird: Liefert Zeile 32 als Output die Zahl 255, so wird char 

als unsigned interpretiert. Liefert sie allerdings als Output -1, so liegt per 

Default eine signed-Interpretation zugrunde. 

Wem jetzt nicht ganz klar ist, wie man plötzlich von 255 auf -1 kommt: 255 

ist die längste Zahl, die man mit 8 Bit ohne Vorzeichen darstellen kann. 

Dabei sind intern alle Bits gesetzt (=auf 1). Wird diese Zahl nun als signed 

interpretiert, dann wird das höchstwertige Bit davon zum Vorzeichenbit. 

Weil dieses gesetzt ist, wird die ganze Zahl als negative Zahl angesehen. Die 

8 Bit-Darstellung von -1 entspricht genau dem, was in der Zahl enthalten 

ist: Es sind alle Bits gesetzt. 

Lesern, die noch ein wenig unsicher mit der internen Darstellung von 

binären Ganzzahlen sind, möchte ich an dieser Stelle die Lektüre von Anhang 

A.2 aus Softwareentwicklung in C empfehlen. 

• Zeile 42 in aFunction demonstriert noch, dass auch als static definierte 

Variablen implizit initialisiert werden. 

• Last, but not least demonstriert Zeile 46, dass uninitialisierte Variablen nun 

wirklich keine sehr gute Idee sind. Dass eine solche Variable “irgendeinen” 

nicht vorherbestimmbaren Wert hat, sieht man eindeutig am Output des 

Programms.

2.4 Zusammengesetzte Datentypen 

2.4 Zusammengesetzte Datentypen 31 

Die reale Welt besteht nicht einfach nur aus einzelnen, allein stehenden Zahlen 

oder Buchstaben. Es liegt in der Natur der Sache, dass verschiedenste 

Zusammengehörigkeiten von kleineren Einheiten ein großes Ganzes ergeben. 

Wenn man einfach nur geschriebenen Text betrachtet, dann sieht man schon, 

dass mehrere Buchstaben aneinander gereiht ein Wort ergeben, mehrere Worte 

ergeben einen Satz, mehrere Sätze einen Absatz, etc. Parallel dazu liegt 

einem gedruckten Text noch eine Seitenstruktur zugrunde, usw. 

Um den Entwicklern beim Modellieren wie auch immer gearteter Zusammenhänge 

entgegenzukommen, gibt es in C ++ neben den OO-Konstrukten 

zur Modellierung von Zusammenhängen auch die von C übernommenen zusammengesetzten 

Datentypen. Dieses Kapitel befasst sich genau mit diesen, 

denn auch für OO-Entwicklung ist das Wissen darüber unabdingbar. 

2.4.1 Arrays 

Der erste zusammengesetzte Datentyp, der näher unter die Lupe genommen 

werden soll, ist das Array, genauer gesagt, das statische Array (Anm.: Der 

Unterschied zum dynamischen Array, das später besprochen wird, liegt nur 

in der Art und Weise, wie Speicher dafür reserviert wird). 

Ein Array ist einfach ein indizierbares Feld von Daten desselben Typs, egal 

um welchen Typ es sich dabei handelt. Bei der Definition von Array Variablen 

in C ++ wird angegeben, welchen Typ die einzelnen Elemente haben und wie 

viele Elemente maximal darin gespeichert werden können. Syntaktisch und 

semantisch entspricht dies der Definition einer “normalen” Variable, gefolgt 

von der Anzahl der Elemente in eckigen Klammern. Z.B. würde die Definition 

eines Arrays, das 50 Characters halten kann, folgendermaßen aussehen: 

char my_char_array[50]; 

Zuvor war die Rede davon, dass ein Array indizierbar ist, dass man also 

über einen Index auf die einzelnen Elemente dieses Arrays zugreifen kann. 

Dies wird einfach dadurch bewerkstelligt, dass man beim Zugriff den Index 

des gewünschten Elements in eckigen Klammern der entsprechenden Variable 

nachstellt. Will man z.B. aus dem oben definierten Array das Element mit 

dem Index 20 ansprechen, dann liest sich das so: 

my_char_array[20] 

Man kann natürlich sowohl das angesprochene Element auslesen als ihm 

auch einen Wert zuweisen. Jetzt ist nur noch genau zu klären, was es mit 

dem Index auf sich hat: Wie in den meisten Programmiersprachen üblich, 

ist der Index des ersten Elements 0! Das bedeutet also logischerweise, dass 

für ein Array mit size Elementen die Indizes von 0...(size − 1) im erlaubten 

Bereich liegen. 

Vorsicht Falle: In C ++ Programmen wird zur Laufzeit keine Überprüfung 

vorgenommen, ob der indizierte Zugriff auf ein Array auch innerhalb der


erlaubten Grenzen liegt! Zumeist wird auf einzelne Elemente eines Arrays 

auch nicht über konstante Werte zugegriffen, sondern es wird im Programm 

ein Index ausgerechnet, über den dann zugegriffen wird. Dabei passiert es 

z.B. durch typische off-by-one Fehler (=durch Unachtsamkeit alles um 1 verschoben) 

nur allzu leicht, dass man einmal danebengreift. Das Programm 

quittiert im Glücksfall solche Fehler sofort mit einer entsprechenden Segmentation 

Violation oder mit einem Blue-Screen. Hat man Pech, dann stürzt das 

Programm nicht ab, weil der Speicher, auf den man irrtümlich zugreift, dem 

Programm selbst gehört. Damit überschreibt man unabsichtlich irgendetwas, 

was gerade zufällig dort zu liegen kam (z.B. ein Element eines anderen 

Arrays). Als Folge verfärben ungeahnte seltsame Ergebnisse bei diversen 

Testläufen das Gesicht des Entwicklers zuerst in ein zartes Rosa, das im Lauf 

der Zeit in ein kräftiges Rot umschlägt. Dann setzt die Phase des kalten 

Schweißes ein, wobei gleichzeitig das Gesicht zu einem leicht grünlichen Weiß 

verblasst. 

Für die Initialisierung der einzelnen Felder von Array-Variablen gilt dasselbe, 

was bereits für Variablen primitiver Datentypen gesagt wurde: globale, 

static-auto und Namespace Variablen werden auf die jeweiligen 0-Werte initialisiert. 

Legt man also z.B. eine globale Variable an, die ein statisches 

int-Array repräsentiert, so werden bei Fehlen von expliziter Initialisierung 

die einzelnen Elemente auf 0 gesetzt. 

Natürlich kann man Arrays, gleich wie in C, explizit initialisieren. Dazu 

gibt man die Werte zu dessen Initialisierung, getrennt durch Beistriche, in einem 

Block an (d.h. von geschwungenen Klammern eingefasst). Dies lässt sich 

am besten gleich an einem Beispiel zeigen, das das Initialisierungsverhalten 

von Arrays demonstriert (array_initializing_demo.cpp): 

1 // a r r a y i n i t i a l i z i n g d e m o . cpp − small program to demonstrate , how 

2 // array i n i t i a l i z i n g works in C++ 

3 


5 



8 

9 // i m p l i c i t l y i n i t i a l i z e d 

10 int f i r s t g l o b a l a r r a y [ 5 ] ; 

11 

12 // e x p l i c i t l y i n i t i a l i z e d 

13 int s e c o n d g l o b a l a r r a y [ ] = { 1 , 2 , 3 , 4 , 5 } ; 

14 

15 // parts of the array e x p l i c i t l y i n i t i a l i z e d 

16 // r e s t of i t i m p l i c i t l y i n i t i a l i z e d 

17 int t h i r d g l o b a l a r r a y [ 5 ] = { 1 , 2 , 3 } ; 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 int main ( int argc , char ∗ argv [ ] ) 

21 { 

22 unsigned count ; 

23 

24 cout

26 cout


Sobald alle Werte aus der expliziten Initialisierung “aufgebraucht” sind, wird 

der verbleibende Rest des Arrays auf 0 gesetzt. 

In den Zeilen 13 und 17 sieht man, dass man bei Verwendung expliziter 

Initialisierung die Wahl hat, entweder den Compiler die Größe eines Arrays 

ermitteln zu lassen oder die Größe selbst vorzugeben. Wenn man allerdings 

die Größe selbst vorgibt, so muss diese unbedingt größer oder gleich der Anzahl 

der Elemente in der Initialisierungsliste sein. Ansonsten reagiert der 

Compiler gar nicht sehr freundlich. Würde man z.B. in Zeile 17 als Größe 

den Wert 2 anstatt 5 angeben, dann würde der Compiler zu Recht behaupten, 

dass man sich gefälligst entscheiden soll, was man denn nun überhaupt 

will. Einerseits soll ein Array mit Größe 2 angelegt werden, andererseits will 

man gleich danach aber 3 Elemente hinein schreiben. Allerdings lässt sich 

durch richtig Stellen der gewünschten Anzahl der Elemente der Compiler 

ganz einfach wieder beruhigen :-). 

Arrays gibt es, gleich wie in C, nicht nur eindimensional, sondern im 

Prinzip mit beliebig vielen Dimensionen (solange der Speicher nicht ausgeht...). 

Auch das ist am besten schnell an einem Beispiel demonstriert 

(multi_dimensional_array_demo.cpp): 

1 // multi dimensional array demo . cpp − a short demo program f o r 

2 // multidimensional arrays 

3 


5 



8 

9 // i m p l i c i t l y i n i t i a l i z e d matrix 

10 int f i r s t d e m o m a t r i x [ 3 ] [ 3 ] ; 

11 

12 // e x p l i c i t l y i n i t i a l i z e d matrix 

13 int second demo matrix [ ] [ 3 ] = { { 1 , 2 , 3 } , 

14 { 4 , 5 , 6 } , 

15 { 7 , 8 , 9 } } ; 

16 

17 // parts of the matrix e x p l i c i t l y i n i t i a l i z e d 

18 // r e s t of i t i m p l i c i t l y i n i t i a l i z e d 

19 int third demo matrix [ 3 ] [ 3 ] = { { 1 , 2 , 3 } , 

20 { 4 , 5 } } ; 

21 

22 

23 // a l s o t h i s i s p o s s i b l e 

24 int fourth demo matrix [ 3 ] [ 3 ] = { { 1 , 2 , 3 } , 

25 { 4 , 5 } , 

26 { 6 , 7 , 8 } } ; 

27 

28 // t h i s r e s u l t s in a warning , but i s p o s s i b l e 

29 int fifth demo matrix [ 3 ] [ 3 ] = { 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 } ; 

30 


32 { 

33 int outer count = 0; 

34 int inner count = 0; 

35 

36 cout


39 for ( inner count = 0 ; inner count < 3 ; inner count++) 

40 cout


Dimensionen mit ihren jeweiligen Größen angegeben. Dass hier wieder eine 

implizite Initialisierung stattfindet, versteht sich von selbst. Diese Matrix 

wird in den Zeilen 36–42 Element für Element ausgegeben. 

Die Zeilen 13–15 zeigen, wie man mehrdimensionale Arrays explizit initialisiert, 

nämlich Zeile für Zeile! Jede Zeile für sich wird in einen Block 

verpackt (indem man sie in geschwungene Klammern einschließt). Die einzelnen 

Blöcke, je einer für eine Zeile, werden in gewohnter Manier durch 

Beistriche getrennt und in einem umschließenden Block zusammengefasst. 

So weit klingt das alles ganz logisch und man vermutet, dass man auf diese 

Weise auch einfach wieder das Erraten des Fassungsvermögens für die einzelnen 

Dimensionen dem Compiler überlassen kann. In Zeile 13 erkennt man 

allerdings dabei eine Besonderheit, die auf den ersten Blick eigentlich nicht 

ganz verständlich ist: Hier ist die erste Dimension dem Compiler überlassen, 

die zweite Dimension aber ist explizit angegeben! Das ist nicht passiert, 

weil ich gerade beim Schreiben des Programms in einem Zustand schwerer 

geistiger Umnachtung war, dies ist tatsächlich verpflichtend! Man darf ausschließlich 

die erste Dimension leer lassen, alle weiteren Dimensionen 

müssen explizit angegeben werden. 

Der Grund für diese, zugegeben etwas komische, Einschränkung ist ein 

historischer, wie in Zeile 29 demonstriert wird: Es ist nicht verpflichtend, 

die einzelnen Zeilen in Blöcken zusammenzufassen. Im Prinzip ist es auch 

möglich, einfach alles in einem Block aneinander zu reihen. Je nach Compiler 

und eingestelltem Warning-Level wird dies zwar heutzutage als gefährlich 

beanstandet, dies bedeutet aber nicht, dass es nicht möglich wäre. Der Output 

dieses Arrays, der von den Zeilen 68–74 erzeugt wird, zeigt auch, wie 

die einzelnen Initialisierungswerte vom Compiler verwendet werden: Es werden 

die Elemente einfach der Reihe nach auf die einzelnen Zeilen der Matrix 

aufgeteilt. Wenn eine Zeile voll ist, wird mit der nächsten weitergemacht. 

Jetzt kann man sich auch ausmalen, woher die Einschränkung kommt, 

dass nur die erste Dimension leer gelassen werden darf: Woher soll denn der 

Compiler erraten können, wie die Aufteilung der Elemente auf die einzelnen 

Dimensionen des Arrays erfolgen soll? Sind z.B. 12 Elemente nun 2 Zeilen 

zu je 6 Spalten oder doch 4 Zeilen zu je 3 Spalten oder...? 

Obwohl durch die in C ++ erlaubte (eigentlich sogar stark empfohlene) 

vollständige blockweise Aufteilung alle Dimensionen für den Compiler ersichtlich 

sind, gibt es eben leider noch die von C geerbte Altlast des nicht- 

Spezifizierens der einzelnen Sub-Blöcke. Deshalb wurde konsequenterweise 

definiert, dass die historische Regel weiterhin Gültigkeit hat, dass nur eine 

Dimension dem Compiler überlassen werden darf. 

Bleiben wir aber bei der sauberen Schreibweise zur Initialisierung: Die 

Definition der Matrix in den Zeilen 19–20 zeigt, dass man sich auch bei 

beliebig vielen Dimensionen auf die implizite Initialisierung des verbleibenden 

Rests durch den Compiler verlassen kann. Auch der Fall, dass “mitten drin”


einzelne Zeilen nicht vollständig explizit initialisiert werden, ist möglich, wie 

die Zeilen 24–26 zeigen. 

Vorsicht Falle: Ich möchte dringend raten, die “Spaghetti-Schreibweise”, 

die in Zeile 29 des soeben behandelten Programms demonstriert ist, nicht 

in Programmen zu verwenden. Man kann sich leicht vorstellen, dass diese 

Schreibweise sehr schnell unübersichtlich und damit fehleranfällig wird. Es 

genügt schon, ein Element zwischendurch zu vergessen und alle nachfolgenden 

Elemente sind um eben dieses fehlende Element nach vorne verschoben. 

Wie unterhaltsam die Suche nach solchen Fehlern wird, überlasse ich der 

Phantasie der Leser. 

2.4.2 Structures 

Arrays, die zuvor behandelt wurden, sind Aggregate vieler Elemente desselben 

Typs. Oft braucht man aber Aggregate mehrerer Elemente verschiedenen 

Typs, die man aufgrund ihrer logischen Zusammengehörigkeit miteinander 

koppeln möchte. Typische Beispiele für solche Bedürfnisse sind z.B. bei 

Adressen zu finden: Hier werden Name, Ortsbezeichnung, Straße, Hausnummer, 

etc. zu einem gemeinsamen Ganzen, eben der Adresse, verbunden. 

Bevor ich allerdings zur Beschreibung der sogenannten Structures komme, 

die diesen gewünschten Aggregat-Typen darstellen, möchte ich noch etwas 

vorausschicken: Im Prinzip sind Structures in C ++ nicht mehr das, was sie in 

C einmal waren. In C ++ sind sie eigentlich Classes, nur dass alle ihre Members 

public sind (Genaueres dazu findet sich in Kapitel 9). Alles, was man in 

C mit Structures machen konnte, kann man auch in C ++ und noch Einiges 

mehr. Um also Structures im C ++ Sinn ernsthaft beschreiben zu können, 

brauchen wir den entsprechenden OO-Kontext. Deshalb ist die nachfolgende 

Abhandlung über Structures entsprechend kurz gehalten. Wir werden auf 

das Thema später noch einmal in Abschnitt 9.1 zurückkommen. 

Eine ausführliche Beschreibung von Structures, wie sie in C existieren, kann 

man in Kapitel 11 des Buchs Softwareentwicklung in C nachlesen. Dort 

wird auch auf einige wichtige Aspekte der Kapselung eingegangen, die im 

Endeffekt zum Konzept von Classes in C ++ geführt haben. 

Am einfachsten sind Structures gleich am Beispiel erklärt. Um nicht, 

wie praktisch überall in der Literatur üblich, eine Adresse zur Erklärung 

heranzuziehen, bin ich fast schon unglaublich kreativ und verwende ein 

Pixel, das x und y-Koordinaten, sowie eine Farbe als Status besitzt :-) 

(struct_demo.cpp): 

1 // struct demo . cpp − a tiny demo program f o r the use o f s t r u c t u r e s 

2 


4




7 

8 struct Pixel 

9 { 

10 unsigned x coord ; 

11 unsigned y coord ; 

12 // the s i n g l e c o l o r channels red , green and blue 

13 // are accessed through the i n d i c e s 0 , 1 and 2 

14 unsigned short rgb value [ 3 ] ; 

15 } ; 

16 

17 struct Pixel g l o b a l p i x e l ; // i m p l i c i t l y i n i t i a l i z e d 

18 


20 { 

21 struct Pixel o n e p i x e l ; 

22 

23 o n e p i x e l . x coord = 10; 

24 o n e p i x e l . y coord = 30; 

25 o n e p i x e l . rgb value [ 0 ] = 0xFF ; // maximum red 

26 o n e p i x e l . rgb value [ 1 ] = 0 x00 ; // no green 

27 o n e p i x e l . rgb value [ 2 ] = 0 x00 ; // no blue 

28 

29 cout


Vorsicht Falle: Nur allzu leicht wird der Strichpunkt nach der schließenden 

Klammer des Deklarationsblocks der Members einer Structure vergessen. 

Dies führt dann zu äußerst kryptischen Fehlermeldungen des Compilers, da 

dieser versucht, das nachfolgende Statement noch mit der laufenden Deklaration 

in Verbindung zu bringen. Neulinge suchen bei solchen Fehlermeldungen 

zumeist verzweifelt am falschen Ort nach dem Fehler, da der Ort der Fehlermeldung 

des Compilers im Regelfall eine der Zeilen ist, die der struct- 

Deklaration nachfolgen, obwohl der tatsächliche Fehler, also der vergessene 

Strichpunkt, bereits weiter oben liegt. 

Deshalb ist es bei unerklärlichen Fehlermeldungen in vermeintlich richtigen 

Programmzeilen immer sehr ratsam, auch ein wenig im Code nach oben 

zu sehen, ob sich nicht vielleicht irgendwo eine offiziell nicht (durch Strichpunkt) 

beendete Deklaration einer Structure findet. 

Bevor wir uns wieder dem Programm zuwenden, möchte ich noch schnell 

erklären, warum ich bei Structures auf dem Begriff der Deklaration herumreite. 

Normalerweise wird immer von der Definition einer struct gesprochen 

(sogar von mir selbst im Buch Softwareentwicklung in C ). 

Ich bin aus folgendem Grund selbst dazu übergegangen, sehr pingelig 

zu sein und auch hier konsequent den Begriff der Deklaration einer struct 

zu verwenden: Man kann sich einfach überlegen, was ein Compiler aus einer 

struct-Deklaration macht. Er nimmt sie quasi als benutzerdefinierten 

Datentyp und entnimmt der Deklaration, welche Members in ihr enthalten 

sind und unter welchen Namen sie ansprechbar sind. Es wird kein Speicher 

angelegt oder irgendetwas Anderes unternommen, was sich an der Stelle 

der Deklaration im übersetzten Programm wiederfinden würde. Und dieser 

Hinweis “es gibt eine struct, die folgendermaßen aussieht...” ist genau eine 

Deklaration. Die Definition einer Variable dieses Typs erfolgt dann erst 

später, z.B. in unserem Programm in Zeile 17. 

Nach diesem kurzen Exkurs wieder zurück zu unserem Programm: Eine 

struct ist, wie schon erwähnt, ein Aggregat aus verschiedenen Members, 

die beliebigen Typs sein können. Members können auch z.B. selbst wieder 

irgendwelche Structures sein. Wie man nun eine Variable definiert, der eine 

struct zugrunde liegt, sieht man in den Zeilen 17 und 21. 

Nach der Definition einer struct-Variable kann man auf die einzelnen 

Members zugreifen, die für diese struct deklariert wurden. Dies geschieht, 

indem man dem Variablennamen einen Punkt nachstellt, gefolgt vom Namen 

des gewünschten Members. Die einzelnen Members der Variable one_pixel 

werden z.B. angesprochen, wie in den Zeilen 23–27 gezeigt. 

Auch bei struct-Variablen gelten wieder dieselben Regeln für die implizite 

Initialisierung, wie sie bereits besprochen wurden. Bei der impliziten 

Initialisierung werden alle Members einzeln auf ihre entsprechenden Nullwerte 

gesetzt. Die Definition von global_pixel_ und das Ausgeben ihres 

Inhalts in den Zeilen 29–34 demonstrieren dies.


Ganz wichtige Aussagen über die Members einer struct bin ich noch 

schuldig geblieben, die in Kürze in Verbindung mit Unions und später ganz 

besonders in Verbindung mit Pointern an Bedeutung gewinnen: 

• Die einzelnen Members einer struct sind garantiert genau in der Reihenfolge 

im Speicher angeordnet, in der sie in der Deklaration der struct 

angeführt werden. 

• Es wird allerdings nicht garantiert, dass die einzelnen Members unmittelbar 

hintereinander im Speicher zu liegen kommen! Je nach Compiler 

und Zielplattform kann es passieren, dass zwischen den einzelnen Members 

“Löcher” im Speicher frei bleiben. 

• Es wird garantiert, dass die Startadresse des ersten Members im Speicher 

mit der Startadresse der gesamten struct übereinstimmt. 

2.4.3 Unions 

Es gibt Fälle, in denen man damit umgehen können muss, dass Variablen 

einen kontextabhängigen Typ besitzen. Als Motivation für die Existenz eines 

solchen Konstrukts möchte ich hier das Event-Handling bei graphischen 

Benutzeroberflächen anführen: 

• Die Benutzeroberflächen der verschiedenen gängigen Betriebssysteme (MS- 

Windows, Unix, MacOS, etc.) folgen alle demselben Prinzip: Egal, was 

passiert, ob nun eine Taste am Keyboard gedrückt wird, die Maus bewegt 

wird oder sonstige Ereignisse auftreten, die Programme bekommen eine 

Mitteilung über das Auftreten eines solchen Ereignisses als sogenannten 

Event bzw. als Message mitgeteilt. 

• Alle Events werden ungeachtet des Typs in dieselbe Queue für das jeweilige 

Programm gestellt, das von ihnen betroffen ist. Das Programm hat die 

Aufgabe, diese Events Stück für Stück aus der Queue zu lesen und darauf 

zu reagieren. 

Nun kann man sich leicht vorstellen, dass z.B. ein Keyboard-Event ganz andere 

Informationen enthält als ein Mouse-Event. Bei einem Keyboard-Event ist 

es interessant, welche Taste gedrückt wurde, welche Modifiers (=Shift, Ctrl, 

etc.) gerade gedrückt waren, als die Taste gedrückt wurde und vielleicht 

auch noch, wann diese Taste gedrückt wurde. Bei einem Mouse-Event hingegen 

ist es interessant, wo der Mauszeiger gerade steht, ob eine oder mehrere 

Maustasten gedrückt wurden, etc. 

Es gibt nun, je nach System, eine Unmenge verschiedener Event-Typen 

mit der daraus folgenden Unmenge an verschiedener Information, die für die 

einzelnen Typen relevant ist. Eine besonders brutale Methode, wie man nun 

alle möglichen Informationsteile aller möglichen verschiedenen Events unter 

einen Hut bekommt, ist die Definition einer struct, die für alle verschiedenen 

Fälle alle verschiedenen Members enthält. Je nach Typ des Events 

ist dann nur ein geringer Bruchteil davon interessant und der Rest enthält


undefinierte Werte. Woher sollte auch bei einem Keyboard Event eine Koordinate 

kommen? Der Computer weiß ja doch nicht, wo am Schreibtisch 

nun das Keyboard steht und ob das linke obere oder das linke untere Eck des 

Schreibtischs die Nullposition markiert :-). 

Was also benötigt wird, ist die Möglichkeit, sogenannte Varianten zu 

implementieren. In unserem Fall der Events würde eine solche Variante bei 

einem Keyboard-Event nur die Daten besitzen, die für das Keyboard-Handling 

interessant sind, bei einem Mouse-Event nur die, die für das Mouse-Handling 

interessant sind, etc. 

Wie auch C stellt uns C ++ ein solches Konstrukt zur Verfügung: die 

union. Auch hier muss ich, wie schon bei den Structures, vorausschicken, 

dass Unions in C ++ durch die Objektorientierung der Sprache umfassender 

definiert sind, als in C. Auf die Besonderheiten, die sich daraus ergeben, 

komme ich Abschnitt 15.2 zu sprechen. 

Bleiben wir hier aber im Augenblick beim Wesentlichen. Per Definition 

lässt sich eine union folgendermaßen charakterisieren: 

Eine union entspricht einer struct mit dem essentiellen Unterschied, 

dass sich die Members denselben Speicherplatz teilen! Dadurch wird 

Folgendes impliziert: 

• Der Speicherbedarf einer union ist immer genau so hoch, wie der Speicherbedarf 

für den größten darin enthaltenen Member. Dies kommt genau daher, 

dass ja Members in einer union nur alternativ Gültigkeit besitzen 

(anstatt gleichzeitig, wie bei einer struct). 

• Gerade erwähnt, aber weil es so wichtig ist, noch einmal: Es besitzt zu 

einem gewissen Zeitpunkt immer nur ein einziger Member Gültigkeit! 

Die restlichen Members enthalten keine sinnvollen Werte. 

• Die Deklaration einer union erfolgt äquivalent zur Deklaration einer struct, 

nur wird statt des Keywords struct das Keyword union verwendet. 

• Der Zugriff auf Members einer union erfolgt analog zum Zugriff auf Members 

einer struct. Es wird ebenfalls einem Variablennamen ein Punkt 

gefolgt vom Namen des gewünschten Members nachgestellt. 

• Es gibt keine von der Sprache direkt unterstützte Möglichkeit, zur Laufzeit 

herauszufinden, welcher der Members einer union gerade Gültigkeit 

besitzt! 

Vorsicht Falle: Wie schon erwähnt, stellt C ++ keine direkte Möglichkeit 

zur Verfügung, mittels der man den zu einem bestimmten Zeitpunkt gültigen 

Member einer union herausfinden kann. Genau dieser Umstand macht eine 

union zu einem potentiellen Kandidaten für Softwarefehler. In Programmen 

finden sich leider immer wieder die abstrusesten Konstrukte, die entweder 

davon ausgehen, dass “jetzt sowieso nur dieser Member gültig sein kann” 

oder in denen sonstige wilde Annahmen und Schätzungen stattfinden. 

Vor solchen Vorgehensweisen möchte ich unbedingt abraten, denn diese 

führen unweigerlich früher oder später durch Fehlzugriffe zu den unglaub-


lichsten Effekten. In der Folge werden Methodiken vorgestellt, wie man auch 

ein so gefährliches Konstrukt wie eine union sauber und sicher verwenden 

kann. 

Die erste Methode, wie man erreichen kann, dass zur Laufzeit bekannt 

ist, welcher Member einer union gerade Gültigkeit hat, wird im folgenden 

Demoprogrämmchen gezeigt (first_union_demo.cpp): 

1 // first union demo . cpp − demo program f o r s a f e r use o f unions 

2 


4 

5 #define KEY EVENT 1 

6 #define MOUSE EVENT 2 

7 

8 struct KeyEvent 

9 { 

10 unsigned event type ; 

11 unsigned char key ; 

12 unsigned char m o d i f i e r s ; 

13 } ; 

14 

15 struct MouseEvent 

16 { 


18 unsigned x coord ; 

19 unsigned y coord ; 

20 unsigned char buttons pressed ; 

21 } ; 

22 

23 union Event 

24 { 


26 struct KeyEvent key event ; 

27 struct MouseEvent mouse event ; 

28 } ; 

29 


31 { 

32 union Event event ; 

33 

34 // used f o r a key event 

35 event . event type = KEY EVENT; 

36 event . key event . key = ’ x ’ ; 

37 event . key event . m o d i f i e r s = 0; 

38 

39 // the same v a r i a b l e , but used f o r a mouse event 

40 event . event type = MOUSE EVENT; 

41 event . mouse event . x coord = 10; 

42 event . mouse event . y coord = 40; 

43 event . mouse event . buttons pressed = 0; 

44 

45 return ( 0 ) ; 

46 } 

Absichtlich ist hier kein Output in den laufenden Text eingebunden, denn 

das tolle Programm liefert ganz einfach keinen :-). 

Leser, die im Umgang mit C noch nicht geübt sind, finden in den Zeilen 5– 

6 ein bisher unbekanntes Konstrukt vor. Keine Panik – der Preprocessor, für 

den diese Zeilen gedacht sind, wird in Kapitel 7 noch näher erklärt. Einst-


weilen möchte ich es dabei belassen, dass in den Zeilen 5 und 6 einfach nur 

symbolische Konstanten definiert sind, die den Code lesbarer machen. Es 

sind dies die Konstanten KEY_EVENT und MOUSE_EVENT, die dann in den Zeilen 

35 und 40 für die Angabe des Event-Typs verwendet werden. 

Das Kernstück unseres Programms findet sich in den Zeilen 23–28: die 

Deklaration der union Event. Diese ist so definiert, dass sich drei Members 

denselben Speicherplatz teilen, nämlich ein einfacher unsigned-Member und 

zwei weitere Members, die alternativ entweder eine struct KeyEvent oder 

eine struct MouseEvent speichern können. Warum nun garantiert werden 

kann, dass der Member event_type aus der union Event immer Gültigkeit 

hat und nicht den Alternativen zum Opfer fällt, sieht man am besten an 

Abbildung 2.1, die die Anordnung der Elemente im Speicher skizziert. 

memory addresses 

alternate union members 

unsigned struct KeyEvent struct MouseEvent 

event_type 

event_type 

key 

modifiers 

event_type 

event_type 

event_type 

buttons_pressed 

union Event 

Abbildung 2.1: Anordnung der Union-Members im Speicher 

In dieser Skizze ist der Adressraum im Speicher des Computers von oben 

nach unten aufsteigend aufgetragen. Von links nach rechts sind die einzelnen 

überlappenden Members der union Event mit ihrer jeweiligen Ausdehnung 

im Adressraum eingezeichnet. Hierbei symbolisieren die jeweiligen mit vollem 

Strich gezeichneten Blöcke den tatsächlichen Speicherbedarf einzelner Teile 

der Alternativen. Strichliert eingefasst sind die Gesamtelemente. 

Die Skizze ist also wie folgt zu lesen: 

• Ganz links ist der erste Member der union Event, also der unsigned, der 

den Typ repräsentiert, aufgezeichnet. 

• Das zweite Element von links ist eine Skizze der struct KeyEvent mit ihren 

einzelnen Members, nämlich event_type, key und modifiers. An diesem 

Element sieht man beispielhaft, was bei der Beschreibung von Structures 

damit gemeint war, dass nicht garantiert ist, dass die Elemente im 

Speicher unmittelbar aufeinander folgen: Zwischen key und modifiers ist 

ein solches mögliches “Loch” dargestellt. 

• Das dritte Element ganz rechts ist eine Skizze der struct MouseEvent mit 

ihren einzelnen Members.


• Die union Event braucht genau so viel Speicher, wie der größte ihrer Members, 

in diesem Fall die struct MouseEvent. 

Bei der Besprechung von Structures war neben dem eventuellen Vorhandensein 

von Löchern im Speicher auch die Rede davon, dass die Startadresse 

einer struct garantiert gleich der Startadresse ihres ersten Members ist. Die 

wichtige Aussage, die es bei Unions zu Adressen im Speicher zu treffen gibt, 

ist Folgende: 

Die Startadresse der alternativen Members, die in einer union deklariert 

sind, ist garantiert für alle dieselbe und diese ist auch garantiert die Startadresse 

der gesamten union. 

Genau aus diesen Aussagen zu den Startadressen von Members in einer 

struct und in einer union ergibt sich, dass die event_type members alle 

garantiert genau übereinander (=an ein und derselben Stelle) zu liegen 

kommen. Es ist also egal, welcher Member der union gerade gültig ist, das 

Ergebnis der Abfrage nach dem event_type ist garantiert immer dasselbe. 

Das Einzige, worauf jetzt noch unbedingt Acht gegeben werden muss ist, 

dass man niemals vergisst, den zu einer gewissen Zeit gültigen Typ bei einer 

Zuweisung auch wirklich korrekt entsprechend ihrer Verwendung zu setzen. 

Dass man vor jeder Auslese-Operation aus einer union dann auch den Typ 

abfragen und entsprechend handeln muss, versteht sich selbstredend. 

Die soeben vorgestellte Vorgehensweise hat den Vorteil, dass man bei 

Verwendung von Pointern und mittels eines expliziten Typecasts die Union 

auf den derzeit aktiven Member casten kann (siehe Abschnitt 3.6). Dadurch 

würde man sich das hier sehr störende doppelte Ansprechen von Members 

ersparen, wie es z.B. in Zeile 36 vorkommt. Es gibt auch eine andere Möglichkeit, 

wie man eine union einsetzen kann, nämlich als anonymous union. 

Betrachten wir dies gleich an einem Beispiel (anonymous_union_demo.cpp): 

1 // anonymous union demo . cpp − demo program f o r anonymous unions 

2 


4 

5 #define INT TYPE 1 

6 #define FLOAT TYPE 2 

7 #define DOUBLE TYPE 3 

8 

9 struct NumberAlternative 

10 { 

11 short type ; 

12 union 

13 { 

14 int i n t v a l u e ; 

15 float f l o a t v a l u e ; 

16 double double value ; 

17 } ; 

18 } ; 

19 


21 { 

22 struct NumberAlternative num alternative ; 

23 

24 // used as a f l o a t j u s t a c c e s s f l o a t v a l u e

25 // of the anonymous union 

26 num alternative . type = FLOAT TYPE; 

27 num alternative . f l o a t v a l u e = 1 7 . 0 ; 

28 

29 // used as an i n t j u s t a c c e s s i n t v a l u e 

30 // of the anonymous union 

31 num alternative . type = INT TYPE; 

32 num alternative . i n t v a l u e = 10; 

33 

34 return ( 0 ) ; 

35 } 


In diesem Beispiel findet sich eine anonymous union direkt als Member einer 

struct in den Zeilen 12–17 wieder. Da kein expliziter Member in der struct 

existiert, der vom Typ union wäre, sondern einfach nur 3 Members zu einer 

union zusammengefasst werden, sind diese 3 Members der struct einfach alternativ, 

ohne weitere Indirektion ansprechbar. In den Zeilen 27 und 32 sieht 

man, dass alternativ die Members float_value oder int_value verwendet 

werden, je nachdem, welcher Datentyp nun gehalten wird. 

Vorsicht Falle: Trotz aller Vorteile, die eine union in bestimmten Fällen 

bietet, möchte ich doch besonders darauf hinweisen, dass sie in einem Programm 

einen besonderen Gefahrenpunkt darstellt! Im OO-Teil dieses Buchs 

werden wir Möglichkeiten kennen lernen, wie man durch saubere Datenkapselung 

diese Gefahren so weit wie möglich eliminiert. Es gibt nämlich nur 

sehr wenige Probleme, die noch schlimmer sind, als sich mit irrtümlich fehlinterpretierten 

Daten herumzuschlagen! 

Manche Leser mögen sich nun wundern, warum ich das Thema der impliziten 

Initialisierung bei Unions bisher unter den Tisch gekehrt habe. Der 

Grund ist einfach: Eine union wird zwar gleich wie z.B. eine struct auf 

einen Nullwert initialisiert, allerdings kann man sich leicht vorstellen, dass 

es hierbei eine kleine Diskrepanz gibt. Die Members einer union teilen sich 

denselben Speicherplatz, welchen Member also setzt man auf 0? Im Falle, 

dass alle Members primitive Datentypen bzw. Structures bestehend nur aus 

primitiven Datentypen sind, ist die Antwort einfach, wenn man um die internen 

Repräsentationen der primitiven Datentypen Bescheid weiß: Es wird 

einfach der gesamte Speicher, der von der union beansprucht wird, Byte für 

Byte auf 0 gesetzt und damit ergeben sich automatisch für alle Members die 

entsprechenden Nullwerte. 

Gar nicht so einfach zu beantworten wird die Frage später im OO-Teil 

werden, wenn wir es mit Classes zu tun bekommen. Deshalb möchte ich 

bereits hier im Vorgriff eine Warnung aussprechen: 

Vorsicht Falle: Dadurch, dass sich die Members einer union denselben 

Speicherplatz teilen, besteht das Problem, dass beim Anlegen einer union 

bekannt sein müsste, welcher Member gerade Gültigkeit besitzt, um sie entsprechend 

implizit initialisieren zu können. Aber genau das kann man gar


nicht wissen! Aus diesem Grund darf man sich niemals auf die implizite 

Initialisierung von Unions verlassen. 

Der Vollständigkeit halber möchte ich hier zum Thema union noch den Querverweis 

auf Kapitel 19 aus Softwareentwicklung in C anführen, in dem dieses 

Thema ausführlich behandelt wird. 

2.5 Scope und Lifetime 

Zwei wichtige Kenngrößen begegnen uns im Life-Cycle von Variablen: Scope 

und Lifetime. Dabei bezeichnet der Begriff Scope (auch: Sichtbarkeit), wo 

im Programm eine Variable unter dem Namen ansprechbar ist, unter dem 

sie definiert wurde. Der Begriff Lifetime (auch: Lebenszeit) bezeichnet, wie 

lange der Speicher, der beim Definieren einer Variable angelegt wurde, erhalten 

bleibt. Diese zwei Größen sind keineswegs äquivalent, wie von manchen 

Entwicklern fälschlicherweise angenommen wird! 

Abgesehen von einigen Besonderheiten, die uns im Lauf der Zeit in diesem 

Buch noch begegnen werden, gelten für C ++ dieselben Regeln für Scope und 

Lifetime, wie sie auch in C Gültigkeit besitzen: 

• Eine Variable ist immer innerhalb des Blocks sichtbar, in dem sie definiert 

wurde und zwar genau ab dem Punkt, an dem sie definiert wurde 

(man kann ja an jeder beliebigen Stelle im laufenden Code eine Variable 

definieren). 

• Die Lifetime einer Variable erstreckt sich von deren Definition bis zum 

Verlassen des umschließenden Blocks. Allerdings kann man als Entwickler 

explizit durch static-Definitionen darauf Einfluss nehmen. 

• Bei Schachtelung von Blöcken können Definitionen auftreten, bei denen Variablen 

äußerer Blöcke durch Variablen innerer Blöcke “versteckt” werden. 

Dies passiert, wenn in einem inneren Block eine Variable mit demselben 

Namen definiert wird, wie sie schon in einem äußeren Block definiert wurde. 

Durch eine solche Definition kommt eine äußere Variable out of Scope. 

• Globale Variablen werden einem fiktiven “alles umschließenden Block” zugerechnet 

und dementsprechend beginnt ihre Lifetime zu dem Zeitpunkt, 

zu dem ihr Initialisierungscode ausgeführt wird (noch vor Aufruf von main!) 

und dauert den gesamten restlichen Programmlauf an. Ihr Scope ist ohne 

explizite Deklaration aus rein compilertechnischen Gründen auf ein einziges 

File beschränkt, allerdings kann man den Scope durch entsprechende 

extern Deklaration auf andere Files erweitern.

2.6 Symbolische Konstanten 47 

Ich möchte Lesern, die ungeübt im Umgang mit Scope und Lifetime von 

Variablen in C sind, wärmstens die Lektüre der Abschnitte 8.2, 17.1 und 

17.3 aus Softwareentwicklung in C ans Herz legen! 

Zu Scope und Lifetime gibt es noch zusätzliche Aspekte, die sich aus der 

Objektorientierung und aus dem Konzept von Namespaces ergeben. Diese 

besonderen Aspekte werden an den entsprechenden Stellen ergänzend angeführt. 

2.6 Symbolische Konstanten 

Der Begriff der symbolischen Konstanten bedeutet eine Zuordnung eines symbolischen 

Namens zu einem konstanten Wert, wobei im Programm der symbolische 

(sprechende!) Name verwendet wird, anstelle des dahinter versteckten 

konstanten Wertes. Entwickelt man z.B. Software, in der die maximale 

Anzahl gleichzeitiger Benutzer eine Rolle spielt, so ist es natürlich wünschenswert, 

im Code einfach einen symbolischen Namen wie MAX_USERS zu verwenden, 

anstatt z.B. überall 120 hinzuschreiben. 

Für den Gebrauch von symbolischen Konstanten gibt es vor allem zwei 

Hauptmotivationen: 

• Konstanten mit sprechenden Namen machen den Code bei weitem leichter 

lesbar als kryptische hardcodierte Werte. 

• Konstanten, die an einer Stelle definiert und dann vielfach im Code verwendet 

werden, erhöhen die Wartbarkeit und Erweiterbarkeit der Software 

erheblich. Nimmt man das Beispiel mit der maximalen Anzahl gleichzeitiger 

Benutzer von zuvor zur Hand, dann sieht man sofort, dass es einfacher 

ist, an einer Stelle die Definition von MAX_USERS von z.B. 120 auf 200 

zu ändern, anstatt im gesamten Code nach jedem Auftreten der Zahl 120 

zu suchen und diese auszubessern. Lesern, die nun meinen, dass so etwas 

ja sowieso bei modernen Editoren nach der Search-and-Replace Methode 

funktioniert, möchte ich nur entgegenhalten, dass ja keinesfalls garantiert 

ist, dass die Zahl 120 nicht auch anderwärtig für etwas völlig Verschiedenes 

gebraucht wird. Diese Vorkommen will man natürlich nicht ändern und 

damit bleibt nur noch mühsamste Handarbeit. Ab einer gewissen Menge 

Code ist jede Änderung de facto unmöglich. 

Im Unterschied zu C, wo ausschließlich Preprocessor-Macros für symbolische 

Konstanten verwendet werden, ist in C ++ eine Möglichkeit der Definition 

von symbolischen Konstanten im Sprachumfang enthalten. Diese werden im 

Prinzip definiert wie Variablen, nur dass vor die Bezeichnung des Datentyps 

noch das Keyword const gestellt wird. 

Der Vorteil der Art der Definition von Konstanten in C ++ gegenüber der 

in C üblichen Preprocessor-Variante liegt auf der Hand: Konstanten in C ++


besitzen einen genau definierten Datentyp! Mit Preprocessor-Macros erreicht 

man nur eine rein textuelle Ersetzung im Code, die keine Typensicherheit 

bietet. 

Wie man am folgenden Beispiel sehen kann, ist die Definition von Konstanten 

völlig intuitiv (const_demo.cpp): 

1 // const demo . cpp − a tiny demo program f o r the use o f 

2 // typesafe constant d e f i n i t i o n s in C++ 

3 


5 

6 const unsigned short RED PART = 0 ; 

7 const unsigned short GREEN PART = 1; 

8 const unsigned short BLUE PART = 2 ; 

9 

10 const unsigned short MAX COLOR INTENSITY = 0xFF ; 

11 const unsigned short MIN COLOR INTENSITY = 0 x00 ; 

12 


14 { 

15 // constants do not need to be g l o b a l , the same 

16 // r u l e s apply f o r the scope o f constants that 

17 // are v a l i d f o r v a r i a b l e s in C++ 

18 const unsigned short NUM COLOR CHANNELS = 3; 

19 

20 unsigned short rgb value [NUM COLOR CHANNELS] ; 

21 

22 rgb value [RED PART] = MAX COLOR INTENSITY; 

23 rgb value [GREEN PART] = MIN COLOR INTENSITY; 

24 rgb value [BLUE PART] = MIN COLOR INTENSITY; 

25 

26 return ( 0 ) ; 

27 } 

Ich denke, es erübrigt sich, dieses Programm genau zu erklären. Allerdings 

schaden ein paar kleine Anmerkungen vielleicht nicht: 

• Wie der Name schon sagt, sind Konstanten unveränderbar. Also wird logischerweise 

jeder Versuch, einer Konstante im Programm etwas zuzuweisen, 

mit einem Compilerfehler enden. 

• Konstanten müssen explizit auf einen Wert initialisiert werden. Vergisst 

man die Initialisierung und schreibt z.B. 

const unsigned short RED_PART; 

so wird dies vom Compiler bemängelt. Dieses Verhalten ist auch logisch, 

denn wozu sollte man eine Konstante brauchen, wenn sie dann vom Compiler 

implizit auf 0 gesetzt werden soll? 

• Im Gegensatz zu Preprocessor-Macros folgen Konstantendefinitionen in 

C ++ den Scope-Regeln, die auch für Variablen gelten. 

• Weil eine Konstante nicht änderbar ist, muss auch nicht unbedingt Speicherplatz 

für sie reserviert werden. Der Compiler kann nach vorheriger 

Überprüfung der Typenkompatibilität ihren Wert einfach einsetzen. Dies 

hat zwei Konsequenzen:

2.7 Eigene Typdefinitionen 49 

1. Konstanten haben im Prinzip keine Lifetime, denn im laufenden Programm 

gibt es für sie nicht unbedingt einen reservierten Speicher. Einzig 

der Scope folgt garantiert denselben Regeln wie für Variablen. 

2. Die Zugriffszeiten von Konstanten nach C ++ Konvention sind, wenn 

der Compiler sauber arbeitet, äquivalent zu denen, die bei Verwendung 

von Preprocessor-Macros entstehen. Manche Entwickler verwenden C ++ 

Konstanten nicht, da sie glauben, dass sie dadurch Einbußen bei der 

Laufzeit des Programms in Kauf nehmen müssen, doch das ist falsch. 

Nur der Vollständigkeit halber möchte ich an dieser Stelle erwähnen, dass wir 

neben der Definition von symbolischen Konstanten noch andere Situationen 

kennen lernen werden, in denen das Keyword const eine wichtige Rolle spielt. 

Entsprechende Ergänzungen folgen zu gegebener Zeit. 

2.7 Eigene Typdefinitionen 

Es gibt verschiedene Fälle, bei denen Entwickler sich wünschen, für einen 

bestimmten Datentyp einen symbolischen Namen zur Verfügung zu haben. 

Z.B. wissen wir, dass das Fassungsvermögen eines int maschinenabhängig 

ist. Es gibt aber Fälle, in denen man unbedingt z.B. einen 32 Bit langen 

Ganzzahltyp braucht und in denen es daher nicht ausreichend ist, zu wissen, 

dass ein int auch eventuell nur 16 Bit lang sein kann, weil man mit 16 Bit 

nicht arbeiten kann. Speziell bei plattformübergreifender Entwicklung ist es 

definitiv ein Ding der Unmöglichkeit, beim Portieren eines Programms z.B. 

alle int-Variablen händisch auf long zu ändern, bloß weil ein int auf der 

Zielplattform einfach zu kurz ist. 

Aus diesem Grund gibt es in C das typedef-Statement, das auch in C ++ 

zur Verfügung steht. Mit Hilfe dieses Statements kann man ein benutzerdefiniertes 

Synonym für einen bestimmten Datentyp einführen, wie man an 

folgendem Beispiel sieht (typedef_demo.cpp): 

1 // typedef demo . cpp − demo program f o r the use o f typedef 

2 


4 



7 

8 typedef signed char i nt8 ; 

9 typedef unsigned char uint8 ; 

10 typedef short int16 ; 

11 typedef unsigned short uint16 ; 

12 typedef int int32 ; 

13 typedef unsigned int uint32 ; 

14 typedef long long int64 ; 

15 typedef unsigned long long uint64 ; 

16 


18 { 

19 i n t 8 e x a m p l e 8 b i t i n t e g e r = 0;


20 uint8 e x a m p l e u n s i g n e d 8 b i t i n t e g e r = 0; 

21 

22 int64 e x a m p l e 6 4 b i t i n t e g e r = 0; 

23 uint64 e x a m p l e u n s i g n e d 6 4 b i t i n t e g e r = 0; 

24 

25 cout

2.7 Eigene Typdefinitionen 51 

Um überprüfen zu können, ob auf einer bestimmten Zielplattform die durch 

typedef spezifizierten Synonyme auch korrekt sind, kann man folgendes Testprogramm 

heranziehen: 

1 // u s e r t y p e s t e s t . cpp − t e s t program to determine whether 

2 // u s e r t y p e s . h has to be adopted f o r a new development platform . 

3 


5 #include ” u s e r t y p e s . h” 

6 



9 


11 { 

12 cout

3. Operatoren 

Nachdem nun einmal die wichtigsten Grunddatentypen besprochen wurden, 

die in C ++ zur Verfügung stehen (Pointer, References und OO-Konstrukte 

kommen noch), wollen wir mit diesen natürlich auch vernünftig arbeiten 

können. Dazu werden in der Folge alle Operatoren besprochen, die wir im 

täglichen Umgang mit C ++ brauchen. 

Der Vollständigkeit halber möchte ich an dieser Stelle zwei Dinge erwähnen: 

1. In diesem Kapitel sind alle Operatoren angeführt, die es in C ++ gibt. 

Zu manchen davon wurden allerdings die Grundlagen bisher noch nicht 

besprochen, die notwendig sind, um sie genau zu verstehen. Daher wird 

eine vollständige Abhandlung zu diesen speziellen Operatoren auf die 

jeweiligen Kapitel später im Buch verschoben. 

Um späteres Nachschlagen der Operatoren nicht allzu sehr zu erschweren, 

wollte ich in diesem Kapitel zumindest einen gemeinsamen Einstiegspunkt 

bieten. 

2. In C ++ gibt es den Mechanismus des Operator-Overloadings. Dies bedeutet, 

dass man als Entwickler Zusammenhänge zwischen Operatoren und 

Datentypen sowie die Funktionsweise von Operatoren in Verbindung mit 

bestimmten Typen beeinflussen bzw. selbst definieren kann. 

In der Folge wird nur auf die Standard-Bedeutung von Operatoren eingegangen, 

wie sie im Core von C ++ implementiert ist. Welche Operatoren 

nun welche Funktionsweise in Verbindung mit allen möglichen Libraries 

haben, muss immer der jeweiligen Dokumentation zu den Libraries entnommen 

werden. 

Lesern, die noch sehr wenig Erfahrung mit der Softwareentwicklung im Allgemeinen 

haben, empfehle ich an dieser Stelle als wichtigen Einstieg die Lektüre 

von Kapitel 5 von Softwareentwicklung in C. Dort findet sich eine sehr genaue 

Beschreibung der wichtigsten Operatoren mit sehr vielen Beispielen. 

3.1 Überblick und Reihenfolge der Auswertung 

Die Reihenfolge, in der Operatoren in längeren Ausdrücken ausgewertet werden, 

ist im Sprachstandard von C ++ festgelegt und in Stein gemeißelt. Daran

54 3. Operatoren 

kann auch durch Operator-Overloading, wie wir es noch kennen lernen werden, 

nichts geändert werden. Die Regeln, die hierbei gelten, sind einfach: 

• Alle Operatoren besitzen einen bestimmten Rang (=Precedence). Eine 

Auflistung der Operatoren nach ihren Rängen ergibt die sogenannte Rangreihenfolge 

(=Order of Precedence) der Operatoren untereinander. 

Ein typisches Beispiel für die Rangreihenfolge kennt man ja aus der Schulmathematik, 

wo z.B. die Regel Punkt- vor Strichrechnung gelehrt wird. 

Diese besagt, dass Multiplikation und Division (=Punktrechnung) ranggleich 

sind, ebenso wie Addition und Subtraktion (=Strichrechnung), dass 

jedoch die Punktrechnung insgesamt im Rang höher ist als die Strichrechnung. 

In wie auch immer gearteten Ausdrücken werden die Operatoren immer 

ihrer Rangreihenfolge gemäß, also vom höchsten bis zum tiefsten Rang 

absteigend, ausgewertet. 

• Findet sich in einem Ausdruck eine Kette von Operatoren mit demselben 

Rang (also gleichwertige Operatoren), so werden diese der Reihe nach von 

links nach rechts ausgewertet. 

• Wenn die Reihenfolge der Auswertung beeinflusst werden soll, so gibt es 

die Möglichkeit zur Klammerung von Ausdrücken. Dazu können Paare von 

runden Klammern in beliebiger Schachtelungstiefe verwendet werden. Bei 

Klammerungen wird, wie zu erwarten, garantiert, dass die Ausdrücke von 

innen nach außen in der Schachtelungshierarchie abgearbeitet werden. 

Aus Gründen der Lesbarkeit von Ausdrücken möchte ich noch eine Kleinigkeit 

anregen: Klammerungen dürfen natürlich nicht ausschließlich dazu verwendet 

werden, die vorgegebene Auswertungsreihenfolge zu verändern, sondern 

sie sind immer erlaubt. Für die Reihenfolge der Auswertung im Prinzip 

unnötige Klammerungen schlagen sich definitiv nicht im Laufzeitverhalten 

des Programms nieder. Allerdings erhöhen sie die Lesbarkeit von längeren 

Ausdrücken erheblich, wenn man sie zum Signalisieren von logischen Zusammengehörigkeiten 

verwendet. Salopp formuliert wäre mein Rat also Folgender: 

Ein paar Klammern zu viel schaden nicht, ein paar zu wenig machen 

das Leben schwer. 

In der Folge ist aus Gründen des Überblicks einmal eine Tabelle mit der 

Gesamtaufstellung aller Operatoren zusammen mit ihrem zugehörigen Rang 

zu finden. Hierbei bedeutet eine niedrige Zahl für den Rang eine höhere 

Priorität in der Reihenfolge. Diese Konvention, dass eine niedrige Rangzahl 

eine hohe Priorität bedeutet, ist in sehr vielen Prioritätsschemata üblich, 

deshalb will ich mit dieser Systematik hier nicht brechen. 

Für die Bedeutungen der einzelnen Operatoren wurden bewusst die englischen 

Bezeichnungen verwendet, da diese im täglichen Leben des Softwareentwicklers 

gebräuchlicher sind als die oftmals sehr holprigen deutschen 

Übersetzungen. 

Allen Lesern, die nun erschrecken, weil die Tabelle vielleicht doch auf den 

ersten Blick nicht wirklich unglaublich informativ erscheint, kann ich nur

3.1 Überblick und Reihenfolge der Auswertung 55 

sagen: Bitte keine Panik! Es ist durchaus kein Problem, die folgende Tabelle 

einmal einfach zu überspringen und sie nur bei Bedarf zum Nachschlagen 

zu verwenden. Eine Legende zu den verwendeten Konventionen findet sich 

gleich unterhalb der Tabelle. 

Rang Bedeutung Operator im Kontext 

1 scope resolution classname::member 

namespace-name::member 

1 global ::name 

::qualified-name 

2 member access object.member 

2 member access pointer->member 

2 index pointer[expr] 

2 function call expr(expr-list) 

2 value construction type(expr-list) 

2 post increment lvalue++ 

2 post decrement lvalue-- 

2 type identification typeid(type) 

2 runtime type info typeid(expr) 

2 runtime-checked cast dynamic_cast(expr) 

2 compiletime-checked cast static_cast(expr) 

2 unchecked cast reinterpret_cast(expr) 

2 remove-const cast const_cast(expr) 

3 size of sizeof expr 

sizeof(type) 

3 pre increment ++lvalue 

3 pre decrement --lvalue 

3 bit complement ~expr 

3 logical NOT !expr 

3 unary minus -expr 

3 unary plus +expr 

3 address of &lvalue 

3 dereference *expr 

3 create (allocate) new type 

3 create (alloc and init) new type(expr-list) 

3 create (place) new(expr-list)type 

3 create (place and init) new(expr-list)type(expr-list) 

3 delete (deallocate) delete pointer 

3 delete array delete[] pointer 

3 cast (type)expr 

4 member access object.*pointer-to-member 

4 member access pointer->*pointer-to-member 

5 multiply expr * expr 

5 divide expr / expr 

5 modulo expr % expr


Rang Bedeutung Operator im Kontext 

6 add expr + expr 

6 subtract expr - expr 

7 bit shift left expr > expr 

8 less than expr < expr 

8 less than or equal expr expr 

8 greater than or equal expr >= expr 

9 equal expr == expr 

9 not equal expr != expr 

10 bit AND expr & expr 

11 bit XOR expr ^ expr 

12 bit OR expr | expr 

13 logical AND expr && expr 

14 logical OR expr || expr 

15 conditional expression expr ? expr : expr 

16 assign lvalue = expr 

16 multiply and assign lvalue *= expr 

16 divide and assign lvalue /= expr 

16 modulo and assign lvalue %= expr 

16 add and assign lvalue += expr 

16 subtract and assign lvalue -= expr 

16 bit shift left and assign lvalue = expr 

16 bit AND and assign lvalue &= expr 

16 bit OR and assign lvalue |= expr 

16 bit XOR and assign lvalue ^= expr 

17 throw exception throw expr 

18 sequencing expr , expr 

Legende: 

In der Spalte Operator im Kontext wird die Verwendung des jeweiligen Operators 

skizziert. Dabei stehen kursiv gesetzte Worte für ein Argument, das 

der Operator nimmt und in teletype gesetzte Worte bzw. Zeichen definieren 

den Operator selbst. Die Bedeutung der einzelnen Argumente ist wie folgt: 

name: Beliebiger Name (z.B. Variablenname, Funktionsname) im aktuellen 

Kontext (wird im OO-Teil besprochen). 

qualified-name: Beliebiger “vollständiger” Name ohne Rücksicht auf den aktuellen 

Kontext (wird im OO-Teil besprochen). 

classname: Name einer Klasse (wird im OO-Teil besprochen). 

namespace-name: Name eines Namespaces (wird im OO-Teil besprochen).

3.2 Arithmetische Operatoren 57 

type: Eine beliebige Typenbezeichnung, egal ob es sich um einen primitiven 

Datentyp, einen zusammengesetzten Datentyp oder einen benutzerdefinierten 

Datentyp handelt. 

object: Eine beliebige Instanz einer Klasse (siehe OO-Teil), Structure oder 

Union. 

member: Name eines Members, egal ob es sich nun um den Member einer 

Structure, einer Union oder eines Namespaces handelt. 

pointer: Ein beliebiger Pointer. 

pointer-to-member: Ein Pointer, der auf einen Member zeigt. 

expr: Ein beliebiger Ausdruck nach den Syntax- und Semantikregeln von 

C ++. Dies kann z.B. eine Berechnung, wie var1 + var2 sein oder auch 

ein Funktionsaufruf, wie myFunc(), etc. 

expr-list: Eine Liste von expr, durch Kommas getrennt. 

lvalue: Bezeichnet ganz allgemein “irgendeinen Speicher im Memory”, also 

z.B. eine Variable. Der Begriff lvalue bedeutet voll ausgeschrieben leftvalue, 

weil er z.B. auf der linken Seite einer Zuweisung vorkommen kann. 

Die wirklich wichtige Eigenschaft eines lvalues ist die, dass in ihm (eventuell 

nach Auswertung einer expr, die zu einem lvalue evaluiert) etwas 

gespeichert werden kann. 

Das bedeutet, dass z.B. ein Ausdruck 

var1 = var2 + var3 * var4; 

gemäß den Prioritäten in der Tabelle in folgender Reihenfolge ausgewertet 

wird: 

• Zuerst wird var3 mit var4 multipliziert, denn * hat mit 5 den in der 

Priorität am höchsten stehenden Rang. 

• Das Ergebnis aus dieser Multiplikation wird zu var2 addiert, denn die 

Addition hat mit 6 den in der Priorität am zweithöchsten stehenden Rang. 

• Danach wird das Endergebnis auf var1 zugewiesen, denn die Zuweisung 

kommt mit Rang 16 erst zu allerletzt dran. 

3.2 Arithmetische Operatoren 

In C ++ finden sich als binäre arithmetische Operatoren die vier Grundrechnungsarten 

(+, -, *, /) und der “modulo”-Operator (%), der den Divisionsrest 

berechnet. Der Begriff der binären arithmetischen Operatoren kommt daher, 

dass diese Operatoren immer zwei Operanden, einen linken und einen rechten, 

entgegennehmen. Ich glaube, es ist unnötig, hier eine große Abhandlung 

zu schreiben, wie man z.B. die Addition zweier Zahlen darstellt, denn dies 

ist absolut intuitiv. 

Sehr wohl möchte ich allerdings eine paar Worte über das Verhalten in 

Bezug auf die Datentypen, die bei einer Operation verwendet werden, verlieren:


Bis auf den “modulo”-Operator, der nur für Ganzzahlen definiert ist, 

sind alle binären arithmetischen Operatoren sowohl auf Ganzzahlen als auch 

auf Gleitkommazahlen anwendbar. Mischt man verschiedene Datentypen in 

einer Operation, indem man z.B. einen double-Wert zu einem int addiert, so 

wird intern eine so genannte implizite Typumwandlung vorgenommen. Diese 

Umwandlung erfolgt dergestalt, dass immer der mächtigste Datentyp für die 

Operation herangezogen wird. Auch das Ergebnis der Operation entspricht 

dann diesem mächtigsten Datentyp. Im Beispiel der Addition eines double zu 

einem int wird also zuerst der int in sein double-äquivalent umgewandelt, 

dann wird die Addition durchgeführt und das Ergebnis ist vom Typ double. 

Mischt man z.B. einen short und einen int in einer Operation, so ist der 

mächtigere Datentyp natürlich int und das Spielchen läuft wie erwartet mit 

int ab. 

Im Prinzip ist das alles ganz logisch, trotzdem wird immer wieder eine 

ganz wichtige Tatsache übersehen: Man muss diesen Umstand auch beim 

Zuweisen des Ergebnisses an eine Variable beachten! Es passiert leider 

nur allzu oft, dass der Datentyp der Variable, die das Ergebnis hält, 

weniger mächtig ist, als das Ergebnis selbst. Damit muss das Ergebnis dann 

wieder in einen weniger mächtigen Typ gewandelt werden, um in der Variable 

speicherbar zu sein. Bei dieser Operation besteht dann die Gefahr, dass 

das Fassungsvermögen des Ergebnistyps zu klein ist, wodurch es zu einer 

Verfälschung des Ergebnisses kommt. 

Begleitend zum Thema der impliziten Typumwandlungen empfehle ich die 

Lektüre von Kapitel 6 aus Softwareentwicklung in C. 

Neben den binären arithmetischen Operatoren gibt es auch noch die sogenannten 

unären arithmetischen Operatoren, also solche, die nicht zwei Operanden 

miteinander verknüpfen, sondern im Gegensatz dazu nur auf einen 

Operanden wirken. Ein solcher unärer arithmetischer Operator ist natürlich 

das negative Vorzeichen, das man einem Operanden voranstellt. Im Gegensatz 

zu C gibt es in C ++ auch das positive Vorzeichen als definierten unären 

arithmetischen Operator. Man mag nun sagen, dass dies vielleicht nicht 

notwendig ist, denn ein positives Vorzeichen tut ja eigentlich gar nichts, allerdings 

ist es aus Gründen der Vollständigkeit und in Hinblick auf Operator 

Overloading durchaus sinnvoll, dieses zuzulassen. 

Neben dem negativen und dem positiven Vorzeichen gibt es allerdings 

noch viel interessantere unäre Operatoren, die sehr typisch für C ++ (und 

auch C) sind und die für Neulinge immer wieder einen kleinen Stolperstein 

darstellen. Die Rede ist hier von den pre- und post-increment, sowie von den 

pre- und post-decrement Operatoren, die nur auf ganzzahlige Datentypen 

angewandt werden können. 

Der increment-Operator wird als ++ dargestellt, der decrement-Operator 

als --. Ob es sich um eine pre- oder post-Version des jeweiligen Operators 

handelt, wird dadurch bestimmt, ob er dem Operanden vorangestellt (pre-

3.3 Logische- und Vergleichsoperatoren 59 

increment bzw. decrement) oder hinten nachgestellt wird (post-increment 

bzw. decrement). Eine Anwendung dieser Operatoren auf eine Variable bewirkt 

eine nachhaltige Änderung ihres Inhalts in Form einer Zuweisung. Dies 

verrät uns auch ein Blick in die Operator-Tabelle: Diese Operatoren verlangen 

einen lvalue als Operanden! Aber abgesehen von der Inhaltsänderung 

hat es noch etwas Besonderes mit diesen Operatoren auf sich, wie man am 

verschiedenen Rang der pre- und post-Versionen in der Tabelle sieht: 

• Pre-increment bzw. pre-decrement bewirken, dass zuerst das Ergebnis der 

increment- bzw. decrement-Operation berechnet (und gespeichert) wird 

und mit dem neuen Wert weitergearbeitet wird. 

• Post-increment bzw. post-decrement bewirken, dass mit dem alten Wert 

weitergearbeitet wird und erst danach die increment- bzw. decrement- 

Operation durchgeführt wird. 

Klingt kompliziert, ist es aber gar nicht, wenn man sich diese Zusammenhänge 

am Beispiel ansieht. Der Ausdruck 

var1 = var2++; 

wird so ausgewertet, dass zuerst eine Zuweisung des Inhalts von var2 auf 

var1 stattfindet und danach var2 inkrementiert wird. Nehmen wir z.B. an, 

dass vor der Auswertung dieses Ausdrucks var2 den Wert 5 enthält. Dann 

enthält nach Auswertung des Ausdrucks var1 den Wert 5 und var2 den Wert 

6. Betrachtet man den Ausdruck 

var1 = ++var2; 

so wird zuerst die increment-Operation durchgeführt und dann das Ergebnis 

zugewiesen. Hätte var2 wieder vor der Auswertung den Wert 5, so würden 

nach Auswertung des Ausdrucks sowohl var1 als auch var2 den Wert 6 enthalten. 

Eine sehr genaue Abhandlung zum Thema der pre- und post-increment bzw. 

-decrement Operatoren findet sich im Buch Softwareentwicklung in C in Abschnitt 

5.2.2. 

3.3 Logische- und Vergleichsoperatoren 

Wie man der Tabelle entnehmen kann, stehen zum Vergleich von Werten 

in C ++ folgende Operatoren zur Verfügung: == prüft auf Gleichheit, != auf 

Ungleichheit, > prüft, ob der linke Wert größer als der rechte ist, < prüft, 

ob der linke Wert kleiner als der rechte ist, >= und


Definition, dass 0 als false gilt, jedoch war nicht genau definiert, was nun 

als true gilt. Irgendetwas ungleich 0 eben. Aus diesem Grund gibt es in 

C keine exakte Definition, welchen Wert sie für true liefern. In C ++ jedoch 

gilt garantiert, dass die Operationen ein “echtes” C ++ true, also 1 liefern. 

In den meisten Fällen mag das unwichtig sein, allerdings gibt es Umstände, 

z.B. beim Abspeichern von boolean-Werten in bestimmten Einzelbits einer 

Ganzzahl, wo diese genauere Definition von C ++ sehr nützlich sein kann. 

Vorsicht Falle: Der Vergleichsoperator == kann nur allzu leicht einmal 

durch eine Unachtsamkeit in einem Programm zum Zuweisungsoperator = 

mutieren. Da die Zuweisung so definiert ist, dass sie als Ergebnis den zugewiesenen 

Wert liefert, betrachtet das der Compiler keineswegs als Fehler. 

Soll er auch gar nicht, denn oft wird dies tatsächlich absichtlich gemacht. 

Moderne Compiler produzieren allerdings mittlerweile zum Glück Warnings 

über possible unintended assignments, die man mit entsprechenden Klammerungen 

verhindern kann. 

Als logische Verknüpfungsoperatoren findet man in C ++ auch wieder die 

alten Bekannten, die es schon in C gab: && repräsentiert ein logisches AND, 

|| ein logisches OR und ! ein logisches NOT. 

Bis auf den Tipp, dass gerade bei Verknüpfungen mehrerer logischer Abfragen 

durch diese Operatoren eine entsprechende Klammerung den Code 

sehr viel lesbarer macht als eine einfache Aneinanderreihung, möchte ich zu 

diesen Operatoren keine weiteren Worte verlieren. Sie sind ganz einfach intuitiv 

anwendbar. 

Lesern, die in C ungeübt sind, wird zum Thema der Vergleichsoperatoren 

und der logischen Verknüpfungen Abschnitt 5.3 aus Softwareentwicklung in 

C noch Zusatzinformation geboten. 

3.4 Bitoperatoren 

Die Bit-Verknüpfungsoperatoren & (Bit-AND), | (Bit-OR), ^ (Bit-XOR) und 

~ (Bit-NOT oder auch Komplement bzw. 1-er Komplement) sowie die entsprechenden 

Bit-Shiftoperatoren > (Bitright-shift 

bzw SR) stehen in C ++ zur Manipulation von Einzelbits und 

Bitmasken in ganzzahligen Werten zur Verfügung. 

Leider hat sich vor allem in den letzten Jahren die Meinung stark eingebürgert, 

dass man dieses “maschinennahe Zeug” ja sowieso nicht braucht 

und dass das nur für Assemblerprogrammierer interessant ist. Dies ist mitnichten 

der Fall! Im Prinzip begegnen Softwareentwicklern viel öfter sogenannte 

Flags, als auf den ersten Blick zu vermuten wäre (z.B. bei File- 

Operationen). Weiters hilft das Wissen um Bitrepräsentationen und Bitope-

3.6 Datentypabfragen und explizite Typecasts 61 

ratoren in gewissen Bereichen unglaublich viel, wenn es um effiziente Implementationen 

geht. 

Ich habe jetzt nicht vor, eine lange Abhandlung über Bitoperatoren hier in 

diesem Buch zu verewigen. Allerdings muss ich allen Lesern, die sich im 

Umgang mit Bitmasken und ähnlichen Konstrukten nicht ganz sicher fühlen, 

unbedingt den dringenden Rat geben, sich einmal Abschnitt 5.4 im Buch 

Softwareentwicklung in C genau zu Gemüte zu führen! Dort wird auf die 

wichtigen Zusammenhänge sehr detailliert und beispielunterstützt eingegangen. 

3.5 Zuweisungen 

Der Zuweisungs-Operator =, sowie die einzelnen Zuweisungs-Kurzformen (*=, 

/=, %=, +=, -=, =, &=, |= und ^=) sind in C ++ äquivalent zu C. Der 

Ausdruck 

var1 += var2; 

ist die Kurzform zu 

var1 = var1 + var2; 

Man sieht also, dass durch die Verwendung der Zuweisungs-Kurzformen 

Ausdrücke kürzer und kompakter formuliert werden können. Darum und weil 

die Verwendung der Kurzformen sowieso in C und C ++ absolut typisch ist, 

möchte ich unbedingt anregen, diese Operatoren nicht zu ignorieren. Von 

vielen Neulingen werden diese Operatoren als etwas Unnötiges erachtet und 

daher werden sie nicht verwendet. Im Sinne eines guten Programmierstils 

möchte ich von dieser Vorgehensweise abraten. Außerdem möchte ich auch 

noch darauf hinweisen, dass es sehr wohl ziemliche Unterschiede in der Performance 

zwischen Kurzzuweisung und Operation mit nachfolgender Zuweisung 

geben kann. Der Beweis zu dieser Aussage wird später noch in Kapitel 12 

angetreten. 

3.6 Datentypabfragen und explizite Typecasts 

Es wurde bereits im Rahmen der Diskussion der arithmetischen Operatoren 

(siehe Abschnitt 3.2) besprochen, dass der Compiler gewisse implizite Umwandlungen 

von Datentypen vornimmt, wenn dies zur Durchführung einer 

Operation notwendig ist. Sehr oft will man dies nicht dem Compiler überlassen, 

sondern selbst eine Umwandlung erzwingen. Dies geschieht durch 

sogenannte explizite Typecasts (oder auch explizite Casts). Die Gründe für 

explizite Casts sind mannigfaltig, der Häufigste davon ist, dass es unter gewissen 

Umständen dem Compiler beim besten Willen nicht möglich ist, zu 

erraten, welcher Typ denn nun der geeignete ist, bzw. auch, wie denn nun


die Umwandlung in diesen Typ erfolgen soll. Vor allem im OO-Teil werden 

wir noch viele Beispiele zu dieser Thematik kennen lernen. 

Im Unterschied zu C, das nur einen einzigen Cast-Operator kennt, gibt es 

in C ++ mehrere verschiedene Operatoren dafür. Außerdem existiert in C ++ 

auch ein Mechanismus, zur Laufzeit Information über den Typ von Variablen 

zu erhalten, die sogenannte Run-Time-Type-Information (kurz: RTTI ). 

Ganz bewusst möchte ich bei der Besprechung von Typecasts nicht mit 

den sogenannten C-Style Casts beginnen, die allen Lesern mit C-Vorbildung 

im Prinzip bekannt sind. Das Problem hierbei ist nämlich, dass diese C- 

Style Casts in C ++ eigentlich eine Kombination aus mehreren Möglichkeiten 

sind, wie man Typen umwandeln kann. Diese Möglichkeiten beinhalten auch 

solche, die auf RTTI zurückgreifen, um Casts korrekt ausführen zu können. 

Daher möchte ich in diesem Kapitel zunächst Type-Identification und RTTI, 

danach die verschiedenen zur Verfügung stehenden Cast-Operatoren und erst 

am Ende den klassischen C-Style Cast besprechen. 

Obwohl das Thema der Casts in der Folge sehr genau besprochen wird, 

möchte ich trotzdem, quasi “zum Aufwärmen”, den Lesern Kapitel 13 aus 

Softwareentwicklung in C empfehlen. 

Vorsicht Falle: Entwickler, die einige Erfahrung mit C und mit älteren Versionen 

von C ++ haben, neigen dazu, bei weitem öfter als notwendig explizite 

Casts einzusetzen. Egal, um welche Variante der in der Folge vorgestellten 

Casts es sich handelt, ungefährlich sind sie im Prinzip alle nicht. Neuere 

C ++ Versionen können in sehr vielen Situationen implizite Casts vornehmen, 

die von alten C ++ Versionen und insbesondere auch von C noch nicht durchgeführt 

wurden. 

Um nun keine Zeitbomben in ein Programm einzubauen, sollte man unbedingt 

folgenden Tipp beherzigen: Casts sollen nur dort verwendet werden, 

wo sie unbedingt notwendig sind. Im Fall, dass man sich nicht sicher ist, 

ob man einen Cast braucht oder nicht, schreibt man am besten nicht in vorauseilendem 

Gehorsam einen expliziten Cast. Das schlimmste was dadurch 

passieren kann ist, dass sich der Compiler beschwert. Danach kann man den 

Cast immer noch ergänzen. 

3.6.1 Type Identification und Run-Time-Type-Information 

In diesem Abschnitt wird ein Feature von C ++ besprochen, dass es in C 

überhaupt nicht gibt: Die Möglichkeit, den Typ eines Objekts (z.B. einer 

Variable) herauszufinden. 

Leider muss ich hier einen kleinen Spagat in Bezug auf die Struktur dieses 

Buchs machen, denn bei den Themen Type Identification und RTTI bekommen 

wir es plötzlich mit Klassen zu tun, weil dies in der Natur der hierfür


definierten Operatoren liegt. Würde ich dieses Thema hier aussparen und 

erst im OO-Teil des Buchs anschneiden, dann würde wichtige Information 

fehlen, die es erst ermöglicht, Casts richtig zu begreifen. Die Behandlung 

der Casts in den OO-Teil zu verlegen funktioniert auch nicht, denn ohne dieses 

Wissen würden wichtige Voraussetzungen fehlen, die jetzt schon benötigt 

werden. Also möchte ich einen Kompromiss eingehen: In der Folge werden 

hier die Prinzipien der benötigten Mechanismen umrissen, ohne ganz genau 

auf deren Details einzugehen. Eine ergänzende Abhandlung von RTTI wird 

in Abschnitt 15.6 nachgeliefert. 

Zurück zum Thema Type Identification: C ++ bietet die Möglichkeit, zur 

Laufzeit eines Programms zu Typinformationen z.B. von Variablen zu kommen. 

Dazu existiert der typeid-Operator, den wir uns am besten gleich 

einmal am Beispiel ansehen (typeid_demo.cpp): 

1 // typeid demo . cpp − demo f o r C++ type i d e n t i f i c a t i o n f e a t u r e s 

2 


4 #include < t y peinfo> 


6 



9 

10 struct TestStruct 

11 { 

12 int just a member ; 

13 char one more member ; 

14 } ; 

15 

16 union TestUnion 

17 { 

18 int j u s t a v a r i a n t ; 

19 char one more variant ; 

20 } ; 

21 

22 typedef struct TestStruct TypedefedTestStruct ; 

23 typedef union TestUnion TypedefedTestUnion ; 

24 


26 { 

27 int32 t e s t v a r = 0; 

28 

29 cout


46 typeid ( long long ) . name()


Von Zeile 10 bis Zeile 23 findet man die Deklaration einer Structure, einer 

Union und zwei entsprechende typedef-Statements, die später zu Demonstrationszwecken 

verwendet werden. 

Die Variable test_var, die in Zeile 27 definiert wird, ist auch noch keine 

Besonderheit, allerdings das Statement in den Zeilen 29–30 enthält eine 

Neuigkeit: 

• In Zeile 30 wird der typeid-Operator aufgerufen. Dieser Operator ist derjenige, 

der in unserer zusammenfassenden Operatoren-Tabelle als 

typeid(type) unter dem Begriff Type Identification verewigt wurde. 

• Dieser typeid-Operator liefert uns interne, Compiler-implementationsspezifische 

bzw., je nach Typ und System, auch OS-implementationsspezifische 

Information zu einem Datentyp. Diese Information wird als 

Objekt vom Typ type_info geliefert – hier sind wir plötzlich beim OO- 

Teil angelangt. 

• Um nun nicht OO-Features von C ++ besprechen zu müssen, stelle ich einfach 

in den Raum, dass man mit einem Objekt zum Teil ähnlich umgeht, 

wie man es mit einer Structure tut: Ein Objekt besitzt ebenfalls Members 

und gleich wie bei einer Structure wird auf diese mittels des Punkt- 

Operators zugegriffen. Members können bei einem Objekt nicht nur Variablen, 

sondern auch sogenannte Methoden (im Prinzip Funktionen) sein. 

Und genau um eine solche Methode handelt es sich bei name(), wie sie in 

Zeile 30 aufgerufen wird. 

• Die Methode name() liefert bei Aufruf einen String, der den internen, 

Compiler- und plattformabhängigen Namen eines Typs repräsentiert. Dieser 

muss aus Implementationsgründen nämlich nicht derselbe sein, wie der 

Typname, den wir im Programm verwenden, wie man auch am Output 

sieht. Es verwendet z.B. das mit g++ compilierte Programm unter Linux 

für einen char intern einfach den Namen c. 

Natürlich kann man typeid nicht nur einfach auf Typen anwenden, denn 

dies allein wäre ziemlich sinnlos. Man kann typeid auch auf beliebige Expressions, 

also z.B. auf Variablen anwenden, wie man z.B. im Statement in 

den Zeilen 64–65 sieht. Und genau dabei handelt es sich, wie auch in unserer 

Operatorentabelle zu sehen ist, um das so wichtige RTTI -Feature von 

C ++: Mittels RTTI ist es in C ++ möglich, zur Laufzeit den Typ, zu dem eine 

Expression evaluiert, abzufragen. 

Und damit sieht man auch, warum es notwendig ist, typeid auf einen Typ 

wie int anwenden zu können: Nachdem ja intern die Typen nicht mehr die 

uns bekannten Namen haben, sondern plattformabhängige Identifications, 

wäre es ansonsten unmöglich herauszufinden, ob etwas z.B. jetzt wirklich 

vom Typ int ist. Bestimmte Cast-Operatoren, die wir gleich in der Folge 

kennen lernen werden, verwenden die gelieferte Typinformation (zu der intern 

um einiges mehr als nur der Name gehört, der hier abgefragt wird), um 

die Kompatibilität von Datentypen festzustellen, bevor sie ihre Umwandlung 

durchführen.


Was sieht man an unserem kleinen Demoprogrämmchen noch, wenn man 

den Output näher betrachtet? 

• Die ersten 3 Zeilen des Outputs zeigen uns die schon besprochene Plattformabhängigkeit 

des Datentyps char, nämlich, dass nicht gesagt ist, ob 

er nun intern als signed char oder unsigned char betrachtet wird. Wir 

sehen, dass char, signed char und unsigned char intern unter drei verschiedenen 

Namen bekannt sind, nämlich c, Sc und Uc. 

• Die zweiten 3 Zeilen des Outputs wiederum zeigen uns, dass dies beim Datentyp 

short sehr wohl wieder genau definiert ist, denn der interne Name 

von short und signed short ist derselbe (s), wogegen unsigned short, 

wie zu erwarten, den internen Namen Us trägt. Für die Datentypen int, 

long und long long gilt dasselbe wie für short. Aus Gründen der Platzersparnis 

wurden die entsprechenden Programmzeilen hier nicht verewigt. 

Leser, die meinen Aussagen nicht ohne Kontrolle trauen, können gerne zur 

Überprüfung die entsprechenden Zeilen im Programm ergänzen :-). 

• Vergleicht man z.B. den internen Namen unseres mittels typedef in 

user_types.h definierten Typs int32 mit dem internen Namen eines “echten” 

int, so kommt man einer Begriffs-Fehlverwendung aus den Urzeiten 

von C auf die Spur: Intern besitzen beide, also int32 und int denselben 

Typ, sie sind also nicht nur kompatibel, sondern sie sind tatsächlich 

äquivalent und dementsprechend zur Laufzeit nicht mehr voneinander zu 

unterscheiden. Was sagt uns das? Nun, ganz einfach: typedef dient nur 

dazu, dem Compiler einen Hinweis zu geben, dass da ein Typ int32 verwendet 

wird, der aber in Wirklichkeit ein int ist. Der Compiler nimmt das 

hin und macht intern aus jedem int32 einen “echten” int. Rekapitulieren 

wir nun noch kurz, was es zum Thema Definition und Deklaration zu sagen 

gibt, dann erkennen wir, dass es sich bei typedef nicht, wie suggeriert, 

um eine Typ-Definition, sondern eigentlich nur um eine Typ-Deklaration 

handelt! Von Rechts wegen müsste es also typedecl heißen und nicht 

typedef. Ich gebe ja zu, dass es sich hier um eine Spitzfindigkeit handelt, 

aber man sieht daran, dass auch in der Computerwelt nicht immer alles so 

genau ist, wie es sein sollte. 

• In den letzten 4 Zeilen des Outputs erkennt man, was der hier verwendete 

Compiler aus Namen von zusammengesetzten Datentypen wie Unions 

und Structures macht: Der Name, der der Structure bzw. Union gegeben 

wurde, wird auch intern beibehalten, allerdings bekommt er eine Zahl als 

Präfix. Diese wird bei g++ zu Laufzeit-Optimierungszwecken verwendet. 

Ja, ok, jetzt gehe ich endgültig zu weit. Ich höre schon auf damit... :-). 

Mit dem Wissen über die Möglichkeiten des Herausfindens von Information 

über Datentypen bewaffnet, haben wir jetzt das notwendige Handwerkszeug, 

um die verschiedenen Cast-Operatoren zu begreifen, die es in C ++ gibt. Also 

stürzen wir uns ins Vergnügen und widmen diesen Casts einen näheren Blick.

3.6.2 Unchecked Cast 


Der erste Cast-Operator, den wir betrachten, repräsentiert den sogenannten 

unchecked Cast. Dieser Cast ist, wie der Name schon sagt, einer, bei dem keine 

Überprüfungen stattfinden. Daher ist er zwar einerseits der Cast, mit dem 

man die gefinkeltsten Konstrukte basteln kann, andererseits aber auch der 

gefährlichste Cast, den man anwenden kann. Beachtet man, dass der Operator 

dazu reinterpret_cast heißt, so kann man sich auch leicht ausmalen, 

was intern passiert: Was auch immer sich hinter einem Datentyp verbirgt, 

wird einfach anders interpretiert. Es wird nicht einmal versucht, eine echte 

Umwandlung durchzuführen, sondern es wird ganz einfach nur als anderer 

Typ behandelt. Damit kann man im Prinzip alles in alles, ohne Rücksicht 

auf Verluste, umwandeln. Ganz so krass ist es nicht, denn zumindest wird 

eine minimale Überprüfung vom Compiler vorgenommen, nämlich, ob die 

neue Typinterpretation zumindest überhaupt irgendeinen Sinn ergeben könnte. 

Die Gefahr, dass dabei wahnwitzigste Dinge passieren, ist natürlich riesig 

und die Portabilität von Programmen, die ausgiebig mit reinterpret_cast 

arbeiten, ist im Normalfall als nicht berauschend bis nicht gegeben zu bezeichnen. 

Da die tollsten Effekte (sowohl im positiven als auch im negativen Sinn) 

bei einem reinterpret_cast vor allem in Verbindung mit Pointern und den 

dahinterstehenden Daten zu erzielen sind, möchte ich das Beispiel dazu bis 

zur Behandlung der Pointer in C ++ verschieben. 

Kurz umrissen kann man sagen, dass reinterpret_cast dazu gedacht 

ist, zwischen Typen umzuwandeln, die im Prinzip keinen ursächlichen Zusammenhang 

haben (z.B. int und pointer). Dass man von solchen Dingen 

im Normalfall tunlichst die Finger lassen sollte, werde ich noch öfter in diesem 

Buch erwähnen :-). 

Vorsicht Falle: Dadurch, dass bei einem reinterpret_cast einfach das 

Bitmuster des Speicherabbilds eines Datums unangetastet bestehen bleibt 

und nur als anderer Datentyp interpretiert wird, ergibt sich eine ungeahnte 

Palette von Fehlermöglichkeiten. Fehler, die durch falsche Annahmen über 

die Interpretation von Datentypen zustande kommen, sind unheimlich schwer 

zu finden. 

Jedenfalls möchte ich hier eine sehr starke Empfehlung abgeben: Finger 

weg von reinterpret_cast, wenn es irgendwie möglich ist!!! 

3.6.3 Compiletime-checked Cast 

Der Compiletime-checked Cast, der durch den Operator static_cast 

repräsentiert wird, ist dazu gedacht, zwischen Typen umzuwandeln, die in 

einem irgendwie gearteten ursächlichen Zusammenhang zueinander stehen. 

Ein Beispiel hierfür wäre die Umwandlung eines int in einen float. Für diese 

Umwandlung gibt es eine genaue Vorschrift, nämlich wie ein- und dieselbe


Zahl als int und als float dargestellt wird. Wendet man einen static_cast 

in die umgekehrte Richtung, also von float auf int an, so wird der float 

Wert zumindest bestmöglich in einen int umgewandelt, soll heißen, es werden 

die Kommastellen verworfen und der ganzzahlige Anteil wandert in den int. 

Dieses Verhalten läßt sich einfach mit folgendem Programm demonstrieren 

(static_cast_demo.cpp): 

1 // s t a t i c c a s t d e m o . cpp − small demo program f o r s t a t i c c a s t 

2 



5 



8 


10 { 

11 int32 a n i n t v a r = 17; 

12 float c o n v e r t e d f l o a t v a r = static cast(a n i n t v a r ) ; 

13 

14 cout


man, dass -1 interpretiert als unsigned nicht wirklich so toll ist! Und hier 

kann auch der beste Compiler nichts machen, denn wie schon erwähnt, wird 

der Code zur Umwandlung zur Compiletime eingesetzt. Zu dieser Zeit ist 

allerdings im Normalfall nicht bekannt, dass vielleicht später zur Laufzeit 

ein negativer Wert in einen unsigned Wert verwandelt werden soll. 

Vorsicht Falle: Auch ein static_cast bewahrt nicht vor den schweren Fehlern, 

die beim Mischen von signed und unsigned Typen passieren können, 

denn zur Compiletime, zu der der entsprechende Umwandlungscode eingesetzt 

wird, ist der umzuwandelnde Wert ja noch nicht überprüfbar! Aus 

diesem Grund muss ich zum wiederholten Mal darauf hinweisen, dass unvorsichtiges 

Mischen von Datentypen katastrophale Folgen haben kann und 

tunlichst unterlassen werden soll! 

3.6.4 Runtime-checked Cast 

Es gibt beim Arbeiten mit Klassen und Objekten in C ++ Fälle, die wir im OO- 

Teil noch kennen lernen werden, bei denen der Compiler bei der Übersetzung 

des Programms nicht wissen kann, mit welchem Typ man es zur Laufzeit in 

einem Ausdruck zu tun haben wird. In diesem Fall ist ein static_cast nicht 

verwendbar, da für einen static_cast vom Compiler Code eingesetzt wird, 

der die tatsächliche Umwandlung vornimmt. Wenn aber der Typ zu dieser 

Zeit noch unbekannt ist, welchen Code soll der Compiler dann einsetzen? 

Der Fall, dass man erst zur Laufzeit entscheiden kann, welchen Typ ein 

Objekt nun wirklich hat, kommt in der OO-Programmierung relativ oft vor, 

also darf man nicht verhindern, dass eine eventuell zur Laufzeit korrekte 

Umwandlung bereits im Vorfeld vom Compiler abgelehnt wird, bloß weil er 

nicht feststellen kann, ob hier später korrekt oder inkorrekt umgewandelt 

würde und welchen Code er einsetzen soll. Damit würde man die Flexibilität 

von C ++ stark einschränken. Schlimmer noch, man würde sogar saubere 

Programmierung zugunsten von brute-force Ansätzen verhindern! 

Aus diesem Grund wurde in C ++ der dynamic_cast eingeführt. Dieser 

sagt dem Compiler, dass er Code einsetzen soll, der erst zur Laufzeit entscheidet, 

ob eine Umwandlung nun zulässig ist oder nicht. Sollte sie zur Laufzeit 

als zulässig erkannt werden, so wird sie entsprechend durchgeführt, wenn 

nicht, wird zur Laufzeit ein Fehler generiert. Die Syntax und Semantik eines 

Aufrufs von dynamic_cast sind dieselbe wie wir sie schon von static_cast 

kennen. 

Leser, die nun hoffen, dass ein dynamic_cast vor den schweren Fehlern 

bewahren würde, die man beim Mischen von signed und unsigned Typen 

machen kann, die muss ich leider enttäuschen. Der dynamic_cast kümmert 

sich nur um Dinge, die bei Klassenhierarchien bei der OO-Programmierung 

interessant sind und zu denen wir noch kommen werden. Er ist leider auf


primitive Datentypen nicht einmal anwendbar und der Versuch dieser Anwendung 

wird vom Compiler mit unfreundlichen Meldungen und Abbruch 

der Übersetzung quittiert. Ich gebe zu, dass es schön wäre, einen Cast zur 

Verfügung zu haben, der zur Laufzeit eine Plausibilitätsprüfung z.B. bei 

signed auf unsigned Casts durchführt, nur leider existiert dieser in C ++ 

nicht. 

Durch die Natur der Anwendung von dynamic_cast im Kontext von Klassenhierarchien 

muss ich leider auch hier auf ein Beispiel verzichten und die 

Leser auf später vertrösten. 

3.6.5 Remove-const Cast 

Wir werden bei der Diskussion über Funktionen und im OO-Teil bei der Beschreibung 

von Methoden noch eine Anwendung von const kennen lernen, 

die über das reine Definieren von Konstanten hinausgeht: Man kann Parameter 

und return-Values als const deklarieren, womit man ein ungewolltes 

Ändern derselben verhindert. 

Manchmal, aber wirklich nur manchmal, gibt es Fälle, in denen man etwas 

als const deklariert, um damit auszudrücken, dass man ja wirklich nichts 

ändern will. Bloß gibt es die Situation, in der sich aus der Sichtweise eines 

Entwicklers an einem Objekt zwar äußerlich nichts ändert, wohl aber irgendwelche 

internen Kleinigkeiten umdefiniert werden. Damit sieht ein Objekt 

nach außen hin konstant aus und soll auch zur Beruhigung der Entwickler 

als solches deklariert werden. Diese Eigenschaft wird als logische Konstantheit 

oder auch logical Constness bezeichnet, im Gegensatz zur physischen 

Konstantheit oder auch physical Constness. 

Damit landet man allerdings in einem kleinen Dilemma: Wenn etwas 

als const deklariert ist, aber intern gar nicht so konstant ist, wie man es 

nach außen vorspielen will, wie realisiert man das? Genau dazu wurde der 

const_cast eingeführt, der es erlaubt, dass ein als const gekennzeichnetes 

Objekt nach Umwandlung trotzdem geändert werden kann. Es bleibt hierbei 

den Entwicklern überlassen, wie sie nach außen hin den Eindruck der 

Konstanz aufrecht halten. Eines ist jedoch sicher: Nach außen hin muss der 

Eindruck gewahrt bleiben, denn sonst erzeugt man eine ungeahnte Fehlerquelle! 

Auch zu diesem Cast verschiebe ich das entsprechende Beispiel auf später, 

da mit den bis jetzt zur Verfügung stehenden Konstrukten die Sinnhaftigkeit 

und die Gefahren noch nicht besonders eindrucksvoll darstellbar sind. 

3.6.6 C-Style Casts 

Zu guter Letzt kommen wir zu der Gattung von Casts, die bereits aus C 

geläufig sind. Daher auch der Name C-Style Cast. Der Grund, warum diese 

hier als letzte anstatt als erste Variante des Casts diskutiert werden, wurde


bereits erwähnt: C-Style Casts sind eine Mischung aus den bisher erklärten 

verschiedenen Arten von Casts. 

Beim C-Style Cast stellt man den gewünschten Zieldatentyp in runden 

Klammern dem umzuwandelnden Datum voran. Es wird hierbei nicht definiert, 

welche Art der Umwandlung stattfindet. Ein C-Style Cast wird so 

lange vom Compiler ohne Kommentar akzeptiert, wie er durch irgendeine beliebige 

Kombination von static_cast, reinterpret_cast und const_cast 

durchführbar ist. 

Man sieht bei dieser Definition gleich die Gefahr: Ein Entwickler kann 

nicht steuern, welche Art von Cast nun vom Compiler eingesetzt wird. 

Es kann also passieren, dass aufgrund einer Fehlannahme eines Entwicklers 

über die Natur eines Datentyps der Compiler gezwungen ist, einen 

reinterpret_cast einzusetzen, obwohl dies gar nicht beabsichtigt war. In 

diesem Fall hat man dann ein Programm erzeugt, das vielleicht gar nicht 

mehr wirklich portabel ist, obwohl man nach bestem Wissen und Gewissen 

glaubt, sauberen Code geschrieben zu haben! 

Ich möchte also hier nur kurz zeigen, wie ein C-Style Cast formuliert 

wird, jedoch nicht ohne die Warnung, dass man die Finger davon lassen 

sollte (c_style_cast_demo.cpp): 

1 // c s t y l e c a s t d e m o . cpp − demo f o r the use o f C−s t y l e c a s t s 

2 



5 



8 


10 { 

11 unsigned char a c h a r a c t e r = ’ x ’ ; 

12 

13 // the c−s t y l e cast variant 

14 cout


Wieso eigentlich kommt man im oberen Programm durch einen einfachen 

Cast plötzlich von einem dargestellten Zeichen zu einer dargestellten Zahl? 

Nein, völlig falsch... es ist weder weiße noch schwarze Magie im Spiel und ich 

habe den Output auch nicht nachträglich im Buch verändert. Bei der kurzen 

Beschreibung von cout in Abschnitt 2.3 habe ich bereits ganz kurz erklärt, 

dass es im Prinzip egal ist, was man ihm übergibt, denn es wird immer die 

Repräsentation gewählt, die einem Datentyp entspricht. Bei einem char ist 

die default Repräsentation eben, dass er als Zeichen ausgegeben wird, also 

hier als x. Bei einem int wird per Default die Darstellung als Zahl gewählt. 

Genau das haben wir uns hier zunutze gemacht: Der Cast auf int32 bewirkt, 

dass cout als Datentyp eben einen int32 vorgesetzt bekommt, den es 

natürlich als Zahl darstellen will. Dass die dargestellte Zahl dem Character- 

Code von x auf der jeweiligen Zielplattform entspricht, versteht sich von 

selbst. 

Vorsicht Falle: Neben dem bereits erwähnten Problem, dass man die Art 

der Umwandlung nicht mehr in der Hand hat, gibt es einen zweiten Grund, 

warum man einen C-Style Cast nicht verwenden sollte: Seine Auffindbarkeit 

(oder besser nicht-Auffindbarkeit) im Code bei nachträglichen Änderungen. 

Es ist ein Leichtes, automatisch nach bestimmten Vorkommen von 

static_cast und den anderen speziellen Operatoren zu suchen. Es ist unendlich 

mühsam und gleichzeitig fehlerträchtig, nach dem Vorkommen zweier 

runder Klammern mit einem Datentyp dazwischen zu suchen, denn hier kann 

man in vielen Fällen nichts mehr automatisieren. 

Das bedeutet, dass die Einstellung vieler Entwickler, einfach einmal einen 

C-Style Cast zu verwenden, weil er schneller geschrieben ist und diesen 

nachträglich gegen die “richtigen” Casts auszutauschen, gar nicht so toll ist. 

Durch die schlechte Automatisierbarkeit dieses Vorgangs bleiben im Regelfall 

dann die C-Style Casts einfach im Code stehen und das ist garantiert nicht 

das, was man erreichen will!

4. Kontrollstrukturen 

Als Kontrollstrukturen bezeichnet man Konstrukte, die uns helfen, den Programmablauf 

zu beeinflussen, anstatt immer nur sequenziell von oben nach 

unten Zeile für Zeile auszuführen. Wie zu erwarten hat C ++ alle Kontrollstrukturen 

(z.B. if...else, while, etc.) von C übernommen. Neu hinzugekommen 

ist in C ++ einzig das Exception-Handling, allerdings wird dieses 

erst im OO-Teil des Buchs genauer behandelt. Jedoch möchte ich trotzdem 

allen Lesern, die bereits C beherrschen, empfehlen, dieses Kapitel zumindest 

zu überfliegen, denn es gibt in C ++ bei einzelnen Kontrollstrukturen einige 

kleine Feinheiten, die in C nicht vorkommen. Vor allem geht es hierbei um 

Aspekte zur Definition von Variablen, die ja in C ++ überall im laufenden 

Code vorkommen können. 

Eine sehr genaue Abhandlung über Kontrollstrukturen in C findet sich in 

Kapitel 7 von Softwareentwicklung in C. Allen Lesern, die in C noch nicht 

ganz sattelfest sind, möchte ich dieses Kapitel dringend empfehlen, da die 

Basics zu den Kontrollstrukturen hier nur sehr gestrafft abgehandelt werden. 

Ganz kurz zur Auffrischung möchte ich zwei Definitionen wiederholen, die 

nachfolgend gebraucht werden: 

• Ein atomares Statement in C ++ besteht aus einer oder mehreren Expressions, 

gefolgt von einem Strichpunkt. Oft wird auch der Begriff Programmzeile 

dafür verwendet. 

• Es gibt die Möglichkeit, mehrere atomare Statements zu einem zusammengesetzten 

Statement oder auch Block zusammenzufassen. Eine Zusammenfassung 

zu einem Block erreicht man, indem man die zusammengehörigen 

einzelnen Statements (atomare oder selbst bereits zusammengesetzte) 

durch geschwungene Klammern einfasst. 

Wo auch immer in der Folge der Begriff Statement verwendet wird, kann 

sowohl ein einzelnes Statement als auch ein Block stehen.

74 4. Kontrollstrukturen 

4.1 Selection Statements 

Unter dem Oberbegriff Selection Statements sind die Statements zusammengefasst, 

die, je nach Ergebnis der Auswertung einer Bedingung, zu einem 

bestimmten Programmteil verzweigen, also eine Auswahl treffen. 

Wie zu erwarten treffen wir hier unsere alten Bekannten aus C, nämlich 

if...else und switch. Das if...else Konstrukt sieht formal folgendermaßen 

aus: 

if (condition) 

statement1 

else 

statement2 

Dazu zu sagen wäre noch, dass der else-Zweig optional ist, also weggelassen 

werden kann, wenn er nicht gebraucht wird. Ein kleines Beispiel möchte 

ich hier auch noch zeigen, das prinzipiell einmal die Verwendung von if 

demonstriert (if_demo.cpp): 

1 // if demo . cpp − tiny program that shows the use o f i f in C++ 

2 



5 



8 

9 const i nt8 DESIRED INT8 BYTES = 1; 

10 const i nt8 DESIRED UINT8 BYTES = 1; 







17 


19 { 

20 i f ( ( sizeof ( i nt8 ) == DESIRED INT8 BYTES) && 

21 ( sizeof ( uint8 ) == DESIRED UINT8 BYTES) && 

22 ( sizeof ( int16 ) == DESIRED INT16 BYTES) && 





27 ( sizeof ( uint64 ) == DESIRED UINT64 BYTES) ) 

28 { 

29 cout

4.1 Selection Statements 75 

41 // For the r e s t of the types analogous statements 

42 // have to be i n s e r t e d here . I leave t h i s up to you . . . 

43 

44 return (−1); 

45 } 

Ich denke, das Programm braucht wirklich keine große Erklärung, deshalb 

möchte ich an dieser Stelle nur einen kleinen Tipp anbringen, der die Lesbarkeit 

von Code betrifft: In den Zeilen 28–31 sieht man, dass das Programm 

eine alles ok Meldung ausgibt und durch Aufruf von return in Zeile 30 

terminiert, indem es die main-Funktion verlässt. Das bedeutet, dass das Programm 

in diesem Fall sicherlich niemals Zeile 32 erreichen kann. Aus diesem 

Grund ist hier auch kein else notwendig, obwohl die Zeilen von 32 weg bis 

zum Ende des Programms quasi einen logischen else-Zweig darstellen. Diese 

Vorgangsweise ist sehr anzuraten, denn ansonsten gibt es Fälle, in denen 

durch ungeschickte if...else-Konstrukte eine unübersichtliche Schachtelungshierarchie 

von Blöcken entsteht, was die Wartbarkeit und Änderbarkeit 

von Code deutlich verringert. 

Es gibt auch einen besonderen Operator, der unter dem Namen conditional 

Expression bekannt ist und der im Prinzip einer sehr kurzen und prägnanten 

Form von if...else entspricht. Die Rede ist von 

condition ? true-expr : false-expr 

Hierbei stellt condition eine Bedingung dar, die evaluiert wird. Für den Fall, 

dass sie zu true evaluiert, wird mit der Auswertung der true-expr fortgefahren, 

ansonsten mit der false-expr. Sehr oft findet man eine solche conditional 

expression bei bedingten Zuweisungen. Das Statement 

int number = orig > MAX ? MAX : orig; 

weist z.B. der Variablen number den Wert MAX zu, sofern orig größer ist als 

dieser, ansonsten wird orig zugewiesen. Für Neulinge ist diese Schreibweise 

zwar eher ungewohnt, aber ich möchte im Sinne von klarem und einfach lesbarem 

Code allen Lesern empfehlen, sich mit diesem Statement anzufreunden 

und es auch wirklich zu verwenden. 

Hat man viele Alternativen, aus denen man aussuchen will, so kann 

es schnell passieren, dass eine Reihe von (vielleicht sogar geschachtelten) 

if...else Statements ziemlich unübersichtlich wird. Aus diesem Grund 

gibt es das switch Konstrukt, das sich formal folgendermaßen präsentiert: 

switch(condition) 

{ 

case const1 : 

statement1 

case const2 : 

statement2 

... 

default: 

statement-xx 

}


Ich habe hier bewusst nicht die zwar völlig korrekte, aber für Erklärungszwecke 

ebenso völlig sinnlose Schreibweise 

switch(condition) 

statement 

verwendet, denn darunter kann man sich nun wirklich nicht vorstellen, was 

switch eigentlich tut :-). 

Auch für die kurze Erklärung von switch schreiten wir am besten gleich 

zum Beispiel (switch_demo.cpp): 

1 // switch demo . cpp − tiny program that shows the use o f i f in C++ 

2 



5 



8 

9 const char SHOW = ’ s ’ ; 

10 const char QUIT = ’ q ’ ; 

11 const char EXIT = ’ x ’ ; 

12 


14 { 

15 char j u s t a c h a r = ’ q ’ ; 

16 

17 switch ( j u s t a c h a r ) 

18 { 

19 case SHOW: 

20 cout

4.1 Selection Statements 77 

• Der default-Label steht speziell für alles Andere, was nicht direkt abgedeckt 

wurde. 

Vorsicht Falle: Oft versuchen ungeübte C ++ Entwickler, eine Variable irgendwo 

mitten in der Reihe der case-Labels zu definieren und auch gleich 

explizit zu initialisieren, weil C ++ die Definition von Variablen ja “überall” 

gestattet. Dies ist allerdings der direkte Weg zu einem Compilerfehler, wie 

man sich leicht vorstellen kann: 

Die Definition ist dabei nicht das wirkliche Problem, denn der Compiler 

könnte hierbei einfach den notwendigen zusätzlichen Speicher gleich zu 

Beginn des Blocks reservieren. Das ginge also noch eventuell ohne Fehlermeldung 

ab. 

Die explizite Initialisierung bei der Definition ist das Problem! Das würde 

nämlich bedeuten, dass der Code für die Initialisierung auch im Prinzip übersprungen 

werden könnte, je nachdem, bei welchem case-Label der Einsprung 

erfolgt. Jetzt kann man natürlich behaupten, dass ja der Code für die Initialisierung 

auch zusammen mit dem Code für die Speicherreservierung vom 

Compiler nach oben gerückt werden könnte. Das geht aber leider nicht, denn 

wer sagt denn, dass zu Beginn des Blocks schon alles bekannt ist, was für 

die Initialisierung gebraucht wird? Es könnte ja später noch etwas berechnet 

werden, was die Initialisierung verändert, weil Initialisierungswerte in C ++ 

nicht notwendigerweise Konstanten sein müssen! 

Will man also eine Variable irgendwo innerhalb des Blocks definieren, 

der die case-Labels enthält, dann bleibt nichts anderes übrig, als entweder 

einen eigenen Sub-Block zu schreiben, oder auf die explizite Initialisierung 

zu verzichten und stattdessen eine normale Wertzuweisung vorzunehmen. 

Einen weiteren wichtigen Punkt zum Thema der Definition von Variablen 

gibt es, der noch nicht von C her bekannt ist: Es ist möglich, innerhalb 

einer condition eine Variable zu definieren! Scope und Lifetime dieser Variable 

erstrecken sich dann auf den gesamten vom entsprechenden Konstrukt 

verwalteten Block. Z.B. im Fall eines if ohne zugehöriges else auf den if- 

Zweig, im Fall eines if...else auf if- und else-Zweig. Der Vorteil dieser 

Möglichkeit liegt auf der Hand: Scope und Lifetime von Variablen sind, wo 

notwendig, auf ihren minimalen Verwendungsbereich festgelegt, anstatt auf 

den gesamten umschließenden Block. 

Betrachten wir am besten am Beispiel, wie wir solche Variablendefinitionen 

innerhalb von Conditions sehr sinnvoll einsetzen können 

(definition_in_condition_demo.cpp): 

1 // d e f i n i t i o n i n c o n d i t i o n d e m o . cpp − small program to show where 

2 // a d e f i n i t i o n i n s i d e a condition makes sense 

3 



6 

7 using std : : cout ;



9 


11 { 

12 const int32 MODULUS = 3; 

13 

14 int32 value = 8; 

15 

16 i f ( int32 d i v r e s t = value % MODULUS) 

17 cout

4.2 Schleifen 79 

Vorsicht Falle: Ein weiteres Problem wird durch Missverständnisse und/oder 

Schlampigkeiten bei der Implementation gewisser Compiler hervorgerufen: 

Manche Compiler beschränken den Scope einer Variable, die in 

der condition definiert wird, fälschlicherweise nicht auf das vom Konstrukt 

verwaltete Statement, sondern auf den umschließenden Block! Dass damit 

der Sinn dieser Möglichkeit ad absurdum geführt wird, versteht sich 

von selbst. Ob der verwendete Compiler einer dieser nicht spezifikationsgemäß 

arbeitenden ist, läßt sich leicht mit folgendem Programm überprüfen 

(definition_compiler_test.cpp): 

1 // d e f i n i t i o n c o m p i l e r t e s t . cpp − small t e s t program to f i n d out 

2 // i f a compiler works c o r r e c t l y 

3 


5 { 

6 i f ( char t e s t v a r = ’ x ’ ) 

7 ; 

8 char t e s t v a r = ’ y ’ ; 

9 return ( 0 ) ; 

10 } 

Abgesehen von Warnings wegen unbenutzter Variablen darf der Compiler 

keinen Fehler erzeugen, wenn er korrekt arbeitet. Bemängelt der Compiler 

bei der Übersetzung eine doppelte Definition von test_var, so hat man es 

mit einem der falsch implementierten Sorte zu tun (und sollte sich eventuell 

den Umstieg auf einen anderen überlegen :-)). 

4.2 Schleifen 

Die altbekannten while, do...while und for Schleifen sind auch in C ++ 

selbstverständlich vorhanden. Eine while Schleife sieht formal folgendermaßen 

aus: 

while(condition) 

statement 

In einer while Schleife wird vor jedem einzelnen Durchlauf die condition 

überprüft. Evaluiert diese zu true, so wird statement genau einmal ausgeführt, 

also der Schleifenrumpf genau einmal durchlaufen. Danach findet 

die nächste Überprüfung der condition und ein eventueller erneuter Durchlauf 

statt, etc., bis die condition zu false evaluiert. Sobald dies der Fall ist, 

wird statement nicht mehr ausgeführt. Stattdessen wird mit der Ausführung 

beim ihm nachfolgenden Code fortgefahren. 

Dies bedeutet, dass es passieren kann, dass statement nicht ein einziges 

Mal ausgeführt wird, nämlich dann, wenn condition bereits beim ersten Mal 

zu false evaluiert.


Im Gegensatz zu einer while Schleife wird bei einer do...while Schleife 

statement immer zumindest einmal ausgeführt, wie sich leicht an der folgenden 

formalen Definition erkennen lässt: 

do 

statement 

while(condition) 

Die Überprüfung von condition findet erst nach dem Ausführen von statement 

statt. Evaluiert sie zu true, wird statement erneut ausgeführt, so lange, 

bis condition zu false evaluiert. 

Zu guter Letzt kommen wir noch zum mächtigsten Schleifenkonstrukt in 

C ++, nämlich zu den for Schleifen. Ein Blick auf deren formale Definition 

ergibt folgendes Bild: 

for(init;condition;step-expr) 

statement 

Anstatt nur eine condition zu überprüfen, macht eine for Schleife gleich 

bedeutend mehr, wie man in der Definition des Schleifenkopfs sieht: Beim 

ersten Erreichen der Schleife wird das init Statement ausgeführt. Danach 

wird die condition überprüft. Evaluiert diese zu true, dann wird statement 

ausgeführt, gefolgt von step-expr. Damit sind wir am Ende eines Durchlaufs 

angelangt und es wird mit der Überprüfung von condition fortgefahren. Die 

Schleife durchläuft in gewohnter Manier die Abfolge vom Überprüfen der 

condition bis zum Ausführen der step-expr so oft, bis condition einmal zu 

false evaluiert. 

Noch eine Besonderheit zeichnet die for Schleife aus: Die einzelnen 

Ausdrücke init, condition und step-expr können auch leer gelassen werden, 

was dann im Extremfall sogar zu einer (hoffentlich gewollten) Endlosschleife 

führen kann: for(;;). 

Gerade for Schleifen bereiten C-Neulingen, ob der großen Flexibilität in 

ihrer Anwendung, manchmal gewisse Probleme. Leser, die sich selbst zu 

den C-Neulingen zählen, sollten aus diesem Grund wirklich die sehr genaue 

Behandlung dieser Schleifen in Softwareentwicklung in C in Abschnitt 7.5 

nachschlagen. 

Die bereits angesprochene Möglichkeit der Definition von Variablen an 

ungewöhnlichen Stellen ist bei for Schleifen besonders interessant: Man kann 

benötigte Laufvariablen einfach im init Statement im Schleifenkopf definieren 

und sie haben damit einen Scope und eine Lifetime, die genau auf das von 

for kontrollierte Statement begrenzt ist. 

Ein kurzes Demo Programm zur Verwendung der möglichen Variablendefinitionen 

im Schleifenkopf soll die in C ++ übliche “saubere” Schreibweise 

z.B. einer Zählschleife demonstrieren (for_demo.cpp):

1 // for demo . cpp − small f o r−loop demo program 

2 



5 



8 


10 { 

11 for ( int16 count = 0 ; count < 3 ; count++) 

12 cout


23 cout


10 { 

11 int32 s p a g h e t t i c o u n t e r = 0; 

12 

13 nirvana : 

14 cout

5. Funktionen 

Prinzipiell ist eine Funktion eine Zusammenfassung mehrerer Anweisungen zu 

einem aufrufbaren Ganzen. Weiters nimmt eine Funktion Parameter entgegen 

und liefert einen return-Wert. Die Definition einer Funktion sieht formal 

folgendermaßen aus: 

retval function-name(param-list) 

{ 

block-of-code 

} 

Hierbei bezeichnet retval den return-Wert der Funktion, wobei bei der Definition 

hier einfach ein Datentyp (z.B. int) angegeben wird. Der (sprechende!!!) 

Name einer Funktion wird durch function-name definiert und dieser 

ist gefolgt von einer Parameterliste, hier durch param-list gekennzeichnet, in 

runden Klammern. Diese gesamte erste Zeile bezeichnet man auch als Funktionskopf 

. Der Code, der ausgeführt wird, wenn eine Funktion aufgerufen 

wird, steht als Block (also durch geschwungene Klammern eingefasst) in Anschluss 

an den Kopf. Diesen Block bezeichnet man auch als Funktionsrumpf . 

Die Parameterübergabe beim Aufruf von Funktionen erfolgt gleich wie in 

C immer als call-by-value. Das bedeutet, dass immer zuerst eine vollständige 

Evaluierung der Ausdrücke stattfindet, die als Parameter übergeben werden 

und dass das Ergebnis dieser Evaluierung als Wert an die Funktion übergeben 

wird. Sollte man z.B. eine Variable als Parameter an eine Funktion 

übergeben, so kann innerhalb der Funktion problemlos der Wert des Parameters 

beliebig verändert werden, der Wert der Variable außerhalb ändert sich 

garantiert nicht! 

Das Liefern eines return-Wertes erfolgt über ein explizites return Statement, 

das genau dort in der Funktion steht, wo der Rücksprung erfolgen 

soll. Es kann auch mehrere return Statements in einer Funktion geben, die 

je nach Kontrollfluss des Programms (z.B. durch if...else) alternativ den 

Rücksprung veranlassen. Es wird garantiert, dass der Rücksprung aus einer 

Funktion genau an der Stelle des return Statements stattfindet. 

Nicht so selten gibt es auch Fälle, dass Funktionen gar keinen return-Wert 

liefern, weil sie eigentlich nur als Prozeduren gebraucht werden, die irgendeine 

Aufgabe (z.B. Bildschirmanzeige) erfüllen. Für diese Fälle gibt es den

86 5. Funktionen 

“Datentyp” void. Daher kommt auch der in C und C ++ geläufige Name 

einer void-Funktion, womit eine reine Prozedur gemeint ist. Will man den 

Rücksprung aus einer void Funktion veranlassen, so geschieht das mittels 

eines “reinen” return Statements, also ohne Angabe eines Return-Values. 

Im Gegensatz zu “echten” Funktionen, bei denen ja durch die Deklaration 

zwingend vorgeschrieben ist, dass sie einen Wert eines gewissen Typs liefern, 

muss bei void Funktionen kein explizites return Statement existieren. Sobald 

das Ende des Funktionsrumpfes erreicht ist, wird bei void Funktionen 

der automatische Rücksprung zum Aufrufer veranlasst. 

Der wichtigste Punkt bei Funktionen ist nicht, wie viele glauben, die technische 

Abhandlung, wie man sie definiert und aufruft. Viel wichtiger ist die 

richtige und sinnvolle Verwendung von Funktionen, um Software sauber 

zu strukturieren und Abstraktionslevels zu schaffen. Um dies gut zu 

schaffen, braucht es einiges an Erfahrung. Man muss das Prinzip der schrittweisen 

Verfeinerung beim Herangehen an eine Problemstellung erst einmal 

wirklich verinnerlicht haben, um in der Lage zu sein, Code sauber zu strukturieren. 

Beim Arbeiten mit Funktionen geht es immer darum, Gemeinsamkeiten 

zu finden und diese auf sinnvoll parametrisierte Codestücke abzubilden. 

Lesern, die hier noch möglicherweise ein kleineres oder größeres Defizit haben, 

möchte ich Kapitel 8 aus Softwareentwicklung in C zur Einstimmung 

auf das Kommende wärmstens empfehlen. 

Ich möchte mich hier absichtlich zum jetzigen Zeitpunkt nicht extrem detailliert 

über Abstraktions- und Struktur-Aspekte von Funktionen auslassen, 

denn wir werden im OO-Teil des Buchs erst die sogenannten Methoden kennen 

lernen. Obwohl diese auf den ersten Blick den hier besprochenen Funktionen 

täuschend ähnlich sehen, stellen sie doch hinter den Kulissen durch ihre 

Kontextbezogenheit ein viel mächtigeres Konstrukt als “normale” Funktionen 

dar. Deshalb wird dieses Kapitel vor allem auf technische Aspekte von 

Funktionen eingehen und nicht so sehr auf softwaretechnologische und z.T. 

philosophische Betrachtungen zu deren richtiger Anwendung. All das wird 

dann dafür umso exzessiver bei der Besprechung von Klassen, Objekten und 

Methoden nachgeholt :-). 

Allen Lesern, die geübt im Umgang mit C sind und die jetzt denken, dass 

Funktionen ja sowieso ein alter Hut sind, möchte ich eindringlich widersprechen! 

C ++ hat durch das Konzept des Overloadings einige nette Features und 

auch Stolpersteine auf Lager, die aus C völlig unbekannt sind! 

Wenden wir uns zuerst einmal an einem Beispiel den Features von Funktionen 

in C ++ zu, bevor wir in die Tiefen vordringen und dort mit ein paar 

netten Fallen konfrontiert werden (function_demo.cpp): 

1 // function demo . cpp − demonstration o f f u n c t i o n s in C++ 

2 


4 #include ” u s e r t y p e s . h”

5 



8 

9 // function d e c l a r a t i o n s 

10 int32 square ( int32 num) ; 

11 double square (double num) ; 

12 void show ( int32 num) ; 

13 void show (double num) ; 

14 

5. Funktionen 87 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


17 { 

18 int32 a number = 4; 

19 double one more number = 4 . 0 ; 

20 

21 int32 a square = square ( a number ) ; 

22 double one more square = square ( one more number ) ; 

23 

24 show ( a square ) ; 

25 show ( one more square ) ; 

26 

27 // i m p l i c i t conversions can a l s o take place : 

28 int16 and one more = 3; 

29 show ( square ( and one more ) ) ; 

30 } 

31 

32 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

33 int32 square ( int32 num) 

34 { 

35 return (num ∗ num) ; 

36 } 

37 

38 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

39 double square (double num) 

40 { 


42 } 

43 

44 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

45 void show ( int32 num) 

46 { 

47 cout


In den Zeilen 10–13 unseres Programms kann man erkennen, wie man Funktionen 

deklariert: Man schreibt die Signatur der Funktionen, gefolgt von 

einem Strichpunkt. Dies ist einfach ein Hinweis an den Compiler, dass es 

eine Funktion unter einem bestimmten Namen, mit einem bestimmten Parametersatz 

und mit einem bestimmten return-Wert irgendwo gibt. 

Genau in diesen Deklarationszeilen fällt auch schon auf, dass es in C ++ 

mit Funktionen etwas auf sich hat, was es in C einfach nicht gibt: In den 

Zeilen 10 und 11, sowie in den Zeilen 12 und 13 sind jeweils zwei Funktionen 

deklariert, die denselben Namen haben! Sie unterscheiden sich nur durch 

ihre Parameter und durch den return-Wert. Genau diese Möglichkeit wird als 

Overloading bezeichnet. Die genauen Regeln für Overloading von Funktionen 

sind Folgende: 

• Overloading von Funktionen bedeutet, dass es mehrere Funktionen mit 

demselben Namen geben kann. 

• Die einzelnen Funktionen, die an einem Overloading beteiligt sind, müssen 

sich zumindest in einem Parameter voneinander unterscheiden. 

• Es ist nicht von Belang, ob sich die Funktionen in der Anzahl der Parameter 

oder in den Typen oder in beiden Punkten unterscheiden. 

• Ein Overloading von Funktionen, die denselben Namen und denselben Parametersatz 

besitzen und sich ausschließlich im return-Wert voneinander 

unterscheiden, ist nicht möglich. 

Um Overloading überhaupt erst möglich zu machen, laufen schematisch gesehen 

compilerintern folgende Prozesse ab: 

• Bei der Deklaration von Funktionen (explizit oder implizit bei der Definition) 

wird das sogenannte Name-Mangling durchgeführt. Das bedeutet, 

dass der Name jeder Funktion einfach intern verlängert wird, indem er um 

den Parametersatz und um den return-Wert erweitert wird. Hierbei sind 

allerdings nicht die Namen der Parameter, sondern nur deren Typen interessant. 

Wie nun genau eine Funktion intern nach dem Name-Mangling aussieht 

ist compilerabhängig! Um sich leichter etwas vorstellen zu können, 

nehmen wir ein mögliches Beispiel, wie ein Compiler das Name-Mangling 

durchführen könnte. Eine Funktion 

int myFunction(int count,double value) 

könnte durch das Name-Mangling intern unter dem Namen 

myFunctionid_i 

bekannt sein. Der Name ergibt sich einfach daraus, dass an den Funktionsnamen 

der Reihe nach die internen Bezeichner der einzelnen Datentypen 

angehängt werden, gefolgt von einem Underline und dem internen Bezeichner 

für den Typ des return-Wertes. Dies bedeutet nun, dass der Compiler 

tatsächlich intern die Namensgleichheiten aufhebt und lauter Funktionen 

mit verschiedenen Namen erzeugt. Dies ist auch notwendig, denn ansonsten 

könnte der Linker seine Arbeit nicht mehr verrichten. Dieser weiß ja


vom Overloading in Wirklichkeit gar nichts. Ihm wird nur noch Object- 

Code mit symbolischen Namen zur endgültigen Adressauflösung gegeben. 

Deshalb muss der Compiler dafür sorgen, dass im Object-Code garantiert 

keine Namensgleichheiten mehr vorkommen. 

• Wenn eine Funktion aufgerufen wird, dann analysiert der Compiler die 

Aufrufparameter und sucht aus den ihm bekannten Funktionen des entsprechenden 

Namens diejenige, die “am besten” zum Parametersatz des 

Aufrufs passt. Zum Beispiel wird in unserem Demoprogramm in Zeile 21 

die Funktion square mit einem int32 als Parameter aufgerufen. Dieser 

Aufruf passt am besten zur Variante von square, die in Zeile 10 deklariert 

und ab Zeile 33 definiert ist. Daher wird genau dieser Funktionsaufruf 

eingesetzt. 

• Dass nur der Parametersatz zur Unterscheidung herangezogen wird und 

nicht auch der return-Wert (worüber übrigens schon des Öfteren diskutiert 

wurde), ist auch leicht einzusehen. Im laufenden Code ist nämlich 

nicht wirklich immer ersichtlich, welcher return-Wert nun erwartet wird. 

Es ist ja z.B. auch möglich, dass jemand einfach in unserem Programm 

square aufruft, aber das Ergebnis keineswegs verwendet, weder durch eine 

Zuweisung, noch in einer Berechnung. Und woher soll der Compiler dann 

seine Information bekommen, welche der overloaded Funktionen er jetzt 

einsetzen soll? 

Neben dem Overloading gibt es bei Funktionen in C ++ noch ein sehr angenehmes 

Feature, das Entwickler dabei unterstützt, sauberen Code zu schreiben: 

Funktionen können sogenannte default Parameter besitzen. Am Beispiel sieht 

das folgendermaßen aus (default_param_demo.cpp): 

1 // default param demo . cpp − demo o f d e f a u l t parameters 

2 



5 



8 


10 void show ( int32 num, bool show prefix = f a l s e ) ; 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


14 { 

15 show ( 1 7 ) ; 

16 show ( 1 7 , false ) ; 

17 show ( 1 7 , true ) ; 

18 } 

19 

20 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

21 void show ( int32 num, bool show prefix ) 

22 { 

23 i f ( show prefix ) 

24 cout


Dieses Demoprogrämmchen erzeugt dann folgenden Output: 

17 

17 

the value i s : 1 7 

In Zeile 10 sieht man, wie man eine Funktion mit default Parametern deklariert: 

Man stellt einem Parameter ganz einfach ein = gefolgt vom gewünschten 

default Wert nach. Dies liest sich quasi wie eine Zuweisung. Wirft man einen 

näheren Blick auf Zeile 15, dann sieht man auch, was es mit den default 

Parametern auf sich hat. Es wird nämlich in Zeile 15 die Funktion show 

nur mit einem Parameter aufgerufen, obwohl sie aber mit zwei Parametern 

deklariert (und definiert) ist. Der Compiler setzt hier einfach intern für den 

zweiten Parameter den in der Deklaration angegebenen default Wert (hier 

false) ein. Zeile 16 zeigt einen vollständig expliziten Aufruf, der, ebenso wie 

Zeile 17, keinen Gebrauch vom default Parameter macht. 

Die folgenden Regeln gelten bei der Arbeit mit default Parametern: 

• Es kann beliebig viele default Parameter geben, diese müssen aber immer 

alle am Ende der Parameterliste stehen. Es ist natürlich auch problemlos 

möglich, alle Parameter einer Funktion als default Parameter zu deklarieren. 

Eine Deklaration 

void func(int par1, int par2 = 0, int par3 = 0, int par4 = 0); 

ist also gültig, wohingegen die Deklaration 

void func(int par1, int par2 = 0, int par3, int par4 = 0); 

zu einem Compilerfehler führt, denn par2 ist ein default Parameter, der 

nachfolgende par3 allerdings nicht. Wie soll der Compiler also z.B. bei 

einem Aufruf 

func(11,22,33); 

nun erraten können, ob 22 nun für par2 und 33 für par3 genommen werden 

soll, oder vielleicht doch eher der default Wert für par2, 22 für par3 und 

33 für par4? 

• Neben der eben erwähnten Regel, dass default Parameter allesamt am Ende 

der Liste stehen müssen, gibt es noch eine zweite Regel, die Ambiguitäten 

bei der Auflösung verhindert: Default Parameter werden von links nach 

rechts der Reihe nach mit übergebenen Parameterwerten belegt, bis alle 

übergebenen Parameter aufgebraucht sind. Haben wir z.B. folgende Funktion: 

void func(int par1 = 0, int par2 = 0, int par3 = 0) 

dann führt ein Aufruf 

func(1,2); 

dazu, dass für par1 der Wert 1 und für par2 der Wert 2 übergeben wird. 

Für par3 wird der default Wert 0 aus der Deklaration eingesetzt. 

Die Angabe eines default Parameters wird nur in der Deklaration benötigt, 

nicht aber in der Definition. Der Compiler ist dafür verantwortlich, den


korrekten Parameter beim Aufruf der Funktion einzusetzen. Wenn man den 

default Parameter auch in der Definition angibt, dann führt dies bei vielen 

Compilern zu einem Fehler. 

So viele Möglichkeiten übersichtlichen Code zu schreiben sich in C ++ 

durch Overloading und default Parameter ergeben, so viele Fallen tun sich 

auch auf, wenn man nicht ganz genau weiß, was man macht! Das folgende 

Programm demonstriert, wie man den Compiler so weit bringen kann, dass er 

freiwillig keine Auflösung gewisser Funktionsaufrufe mehr vornimmt, sondern 

sich beschwert, dass er ja nicht Gedanken lesen kann um zu erraten, welchen 

Aufruf man nun beabsichtigt hat (overloading_problems.cpp): 

1 // overloading problems . cpp − demo o f problems with overloading 

2 



5 



8 


10 void show ( int32 num, bool show prefix = f a l s e ) ; 

11 void show ( float num, bool show prefix = f a l s e ) ; 

12 void show (double num) ; 

13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


16 { 

17 float f l o a t v a l = 1 2 . 5 ; 

18 int32 i n t v a l = 20; 

19 int16 a n o t h e r i n t v a l = 10; 

20 int64 one more int val = 10; 

21 

22 show ( i n t v a l ) ; 

23 show ( f l o a t v a l ) ; 

24 show ( a n o t h e r i n t v a l ) ; 

25 show ( 1 2 . 5 ) ; 

26 

27 show ( one more int val ) ; // ambiguity problem ! 

28 // problem solved by f o r c i n g a c e r t a i n i n t e r p r e t a t i o n 

29 show ( static cast(one more int val ) ) ; 

30 

31 show ( 1 2 . 5 , false ) ; // ambiguity problem ! 

32 // problem solved by f o r c i n g a c e r t a i n i n t e r p r e t a t i o n 

33 show ( static cast(12.5), f a l s e ) ; 

34 return ( 0 ) ; 

35 } 

36 

37 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

38 void show ( int32 num, bool show prefix = f a l s e ) 

39 { 

40 cout


51 cout


paar für den Exponenten reserviert, fehlen also bei der Mantisse und 

bewirken, je nach Zahl, ein Abschneiden des int64 Wertes. 

Zum Glück kann man als Entwickler eingreifen und dem Compiler in seiner 

dunklen Stunde der Unentschlossenheit mitteilen, was man eigentlich 

will. Dies geschieht in Zeile 29, denn durch den expliziten Cast hat es der 

Compiler wieder mit einem int32 als Parameter zu tun. Was er damit 

anfangen soll, weiß er und setzt den Aufruf der in Zeile 10 deklarierten 

Funktion ein. 

Zeile 31: Auch diese Zeile treibt den Compiler zur Verzweiflung, denn er steht 

vor der Wahl, einen double entweder zu einem float oder zu einem 

int32 verkommen zu lassen, um eine der Funktionen deklariert in den 

Zeilen 10 und 11 aufrufen zu können. Beides ist natürlich aus bekannten 

Gründen nicht problemlos, also beschwert sich der Compiler lieber und 

überlässt den Entwicklern die Entscheidung. Die Lösung des Problems 

ist, wie anzunehmen war, wieder ein expliziter Cast. In Zeile 33 sieht 

man den entsprechenden korrigierten Aufruf. 

Alle Aussagen, die ich hier über den Aufruf bestimmter Funktionen aus einer 

Reihe von Varianten getroffen habe, lassen sich leicht verifizieren, indem man 

die beiden problematischen Zeilen auskommentiert, die zum Ambiguitätsproblem 

führen und danach das Programm übersetzt. Der Output, der dann 

generiert wird, sieht folgendermaßen aus: 

show ( int32 , bool ) c a l l e d 

20 

show ( f l o a t , bool ) c a l l e d 

12.5 


10 

show ( double ) c a l l e d 

12.5 


10 

show ( f l o a t , bool ) c a l l e d 

12.5 

Das Regelwerk, nach dem der Compiler versucht, den bestmöglichen Funktionsaufruf 

aus einer Reihe von Alternativen zu finden, ist relativ komplex. 

Jedoch ist es so ausgelegt, dass immer die Variante eingesetzt wird, bei der 

keine gefährlichen Umwandlungen auftreten. Kann der Compiler keine solche 

Variante finden und steht vor einer Reihe von Alternativen, die alle nicht 

optimal sind, so muss man als Entwickler durch einen expliziten Cast eingreifen. 

Vorsicht Falle: Gerade C ++ Neulinge neigen oft dazu, Overloading zu 

übertreiben und für viele verschiedene Datentypen, die eigentlich kompatibel 

wären, eigene Funktionen zu schreiben, anstatt sich auf die Kompatibilität 

zu verlassen. Dies kann schnell zu Überraschungen führen, wenn man sich 

zu wenig Gedanken über die Auswirkungen macht. Deshalb möchte ich hier 

drei Tipps geben:


• Das genaue Verstehen der Interna und der Zusammenhänge der einzelnen 

Datentypen ist eine der wichtigsten Voraussetzungen für eine saubere 

Entwicklung! Viele Entwickler, nicht nur Neulinge, haben hier ein großes 

Wissensdefizit, weil sie die Interna als “unnötigen Ballast” betrachten, den 

man “heutzutage sowieso nicht mehr braucht”. Diese Einstellung ist grundfalsch! 

• Niemals das Overloading übertreiben! Im Fall unserer show Funktion wäre 

es klug gewesen, eine Variante mit int64 und eine mit long double zu 

schreiben. Damit hat man für Gleitkomma und Integer Typen immer den 

mächtigsten Datentyp zur Verfügung und der Compiler hat keine Probleme 

mehr. 

• Das Mischen von Overloading und default Parametern ist nach Möglichkeit 

zu vermeiden, denn es kann sehr leicht unbeabsichtigte Ambiguitäten und/oder 

unsauberen Code zur Folge haben. Ein Beispiel für solchen schlechten 

Programmierstil ist auch in unserem Demoprogramm zu finden, denn es 

gibt eine show Funktion mit einem double Parameter und eine zweite mit 

einem float und einem zusätzlichen default Parameter. Stattdessen wäre 

eine einzige Funktion mit einem long double und zusätzlichem default 

Parameter sehr viel besser gewesen! 

Vorsicht Falle: Ja, gleich noch eine. Der Deklaration von Funktionen 

kommt durch das Overloading in C ++ eine unglaublich wichtige Rolle zu, weil 

erst dadurch der Compiler alle Alternativen kennt. Welche tollen Effekte 

das Vergessen einer einzigen Deklaration hervorrufen kann, sieht man an 

folgendem Programm (missing_decl_problem.cpp): 

1 // missing decl problem . cpp − demo o f a problem that a r i s e s when 

2 // a function d e c l a r a t i o n i s missing 

3 



6 



9 


11 void show ( int16 num) ; 

12 

13 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


15 { 

16 show ( 1 2 3 4 5 6 7 . 5 ) ; // here the c a l l to show ( int16 ) i s taken ! ! ! ! 

17 return ( 0 ) ; 

18 } 

19 

20 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

21 void show ( int16 num) 

22 { 

23 cout

27 void show (double num) 

28 { 

29 cout


24 { 

25 cout

1 // i n l i n e f u n c t i o n d e m o . cpp − demo o f i n l i n e f u n c t i o n s 

2 



5 



8 


9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 inline double square (double num) 

11 { 


13 } 

14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


17 { 

18 cout


1 // i n l i n e f u n c d i f f i c u l t . cpp − demo f o r i n l i n e f u n c t i o n s that 

2 // are d i f f i c u l t f o r the compiler 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 inline uint64 f a c t ( uint64 num) 

12 { 

13 return (num < = 1 ? 1 : (num ∗ f a c t (num − 1 ) ) ) ; 

14 } 

15 

16 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


18 { 

19 cout


Einsatz. Dieser Umstand ist einfach zu erkennen, wenn man bedenkt, dass 

auch inline Funktionen einen eindeutigen Funktionspointer besitzen und 

z.B. static Variablen in ihnen vorkommen dürfen. 

Zur Verwendung von inline Funktionen möchte ich folgende Vorgehensweise 

anregen: 

• Es sollen ausschließlich Funktionen als inline deklariert werden, die wirklich 

außerordentlich oft im Code aufgerufen werden. 

• Zusätzlich zum oftmaligen Aufruf ist auch die ausführbare Codemenge von 

Funktionen ein Thema: Es sollen ausschließlich Funktionen als inline 

deklariert werden, die einen sehr kurzen Funktionsrumpf besitzen. Bei 

“langen” Funktionen ist inline sinnlos. 

• Wenn eine Funktion als inline deklariert wird, sollte man sofort anhand 

von Tests überprüfen, ob sich tatsächlich der gewünschte Laufzeitgewinn 

eingestellt hat. Wenn nicht, dann sollte man die inline Deklaration wieder 

rückgängig machen, weil sie in diesem Fall nichts bringt. 

Ein kurzer Exkurs zum Thema Optimierung: Es ist mit inline Funktionen 

nun eine Maßnahme bekannt, wie man eine gewisse Laufzeitoptimierung 

erreichen kann. Jedoch muss ich unbedingt noch ein paar allgemeine 

Worte zum Thema Performancesteigerung verlieren, denn gerade in diesem 

Bereich wird unheimlich viel verbrochen, was jeglichen Regeln vernünftiger 

Softwareentwicklung widerspricht. 

Prinzipiell gibt es zwei Kriterien, die Performance von Software zu beurteilen: 

Subjektive Performance: Bei der subjektiven Performance kommt es nur darauf 

an, wie schnell sich ein Programm anfühlt, nicht unbedingt, wie 

schnell es tatsächlich ist. Wenn man z.B. bei einem Programm lange 

warten muss, bis dann plötzlich eine vollständige Darstellung von etwas 

Komplexem angezeigt wird, so wird dies als unangenehm langsam 

empfunden. Wenn allerdings dasselbe Programm Stück für Stück dieses 

komplexe Etwas aufbaut, sodass man den Aufbau laufend mitverfolgen 

kann, so wird dies als schneller empfunden. Es kann sogar vorkommen, 

dass die Gesamtzeit, die das Programm bis zur fertigen Anzeige braucht, 

beim subjektiv langsameren System kürzer ist. Objektiv gesehen also 

wäre das als langsam empfundene System eigentlich das schnellere. 

Objektive Performance: Bei der objektiven Performance kommt es auf reine 

Fakten an, in unserem Fall eben Zeitmessungen. Die Geschwindigkeit der 

Abarbeitung einer Aufgabe ist ein direktes Produkt der Effizienz einer 

Lösung. 

Beide Aspekte, subjektive und objektive Performance summieren sich zum 

Gesamteindruck des Systems. Maßnahmen, die die subjektive Performance 

steigern, werden überall dort eingesetzt, wo man keine echte, also objektive 

Steigerung mehr erreichen kann.


Wenden wir uns aber jetzt der objektiven Performance zu, denn diese 

ist einerseits wichtiger, andererseits schwerer zu beherrschen, wenn man 

nicht sauber arbeitet. Insbesondere wirken sich hier Designfehler extrem aus! 

Falsch gewählte Datenstrukturen, die nicht für das zu lösende Problem geeignet 

sind, sind die ultimativen Killer. Genauso verhält es sich mit verworrenen 

Programmen, die nur so vor Seiteneffekten strotzen. In diesen werden z.B. 

dieselben Abfragen immer wieder durchgeführt, weil man sich nie sicher sein 

kann, ob sich seit der letzten Abfrage vielleicht nicht doch etwas “hinten 

herum” geändert hat. 

Um jetzt nicht gleich ein ganzes Buch zum Thema Optimierung zu schreiben, 

will ich nur ein paar Aspekte anführen, die man im Hinterkopf behalten 

sollte: 

• Der wichtigste Punkt bei der Optimierung ist, dass man niemals im Widerspruch 

zu den Grundregeln einer sauberen, intuitiven, wartbaren, erweiterbaren 

und modularen Softwarearchitektur stehen darf. Nur zu oft 

sieht man, dass Programme so lange “mit der Brechstange” optimiert werden, 

bis sich im Code niemand mehr auskennt. Bei der nächsten Änderung 

macht sich große Verzweiflung breit und vor lauter Seiteneffekten hat man 

das Resultat, das bereits zuvor angesprochen wurde: Die Software wird 

immer langsamer! 

• Ein altbekanntes Faktum bei der Optimierung ist, dass Speicherbedarfsund 

Rechenzeitoptimierung nur allzu oft im Widerspruch zueinander stehen. 

Es ist niemandem geholfen, wenn ein Programm ein wenig schneller 

wird, sich aber dafür als enormer Speicherfresser bemerkbar macht. Durch 

die Wahl geeigneter Datenstrukturen kann man allerdings eine gute Balance 

herstellen. 

• Bevor man überhaupt den Code angreift, um etwas zu optimieren, ist 

es notwendig zu wissen, was man eigentlich optimiert. Oftmals wird der 

Fehler gemacht, Programmteile auf Geschwindigkeit zu optimieren, die so 

selten aufgerufen werden, dass sie nur einen sehr kleinen Bruchteil der 

Gesamtrechenzeit benötigen. Damit hat man dann zwar sehr viel Arbeit 

investiert, nur der Erfolg lässt zu wünschen übrig. Es ist unbedingt 

notwendig, einen objektiven Test durchführen, um herauszufinden, welche 

Vorgänge im Programm insgesamt am meisten Laufzeit in Anspruch nehmen. 

Zumeist ist es so, dass zwischen 70% und 90% der Laufzeit von einer 

Handvoll Funktionen verbraucht werden, weil diese einfach so oft aufgerufen 

werden. Optimiert man an der richtigen Stelle, hat man auch schon 

mit kleinen Verbesserungen eine relativ große Steigerung der Gesamtperformance 

erreicht. 

• Am allerwichtigsten überhaupt ist es, die insgesamt ausgeführte Codemenge 

kurz zu halten. Dies kann man nur durch Wahl der geeigneten 

Datenstrukturen und Algorithmen erreichen. Gerade hierbei werden die 

gravierendsten Fehler gemacht, denn oft wird um wenige Zeilen Code ge-


feilscht (=lineare Ersparnis), obwohl ein Algorithmus mit Komplexität 

O(n 2 ) (=quadratischer Verlust) oder schlimmer im Einsatz ist. 

Um das Gesagte zu untermauern, möchte ich hier eine kleine Geschichte 

erzählen, die sich im Jahr 1990 ereignet hat: Es wurde ein Paket zur Berechnung 

einer speziellen Regression auf einer für damals sehr leistungsfähigen 

Unix-Workstation entwickelt. Leider war ein sehr naiver Entwickler 

am Werk, der keine Rücksicht auf die Beschaffenheit der Daten nahm 

und wahnwitzigste Matrix-Operationen, mit einer Laufzeitkomplexität von 

O(n 2 ) bis O(n 3 ), je nach Art der Berechnung, implementierte. 

Ergebnis: Ein Programmlauf dauerte im Durchschnitt zwei Tage. Der 

verzweifelte Entwickler investierte viel Zeit in sehr naive Laufzeitoptimierung 

(hier ein paar Statements, dort ein paar...), aber der Erfolg war nur 

minimal. Der beste Wert wurde mit 1 1/2 Tagen Laufzeit erreicht. 

Nachdem der mittlerweile völlig entnervte Entwickler aufgab, wurde das 

Programm auf seine Komplexität untersucht und einem entsprechenden 

kompletten Redesign unterzogen. Besonderes Augenmerk wurde hierbei 

auf interne Datenstrukturen gelegt. Der Zeitaufwand vom Beginn des 

Redesigns bis zur fertigen Implementation betrug weniger als die Hälfte 

der zuvor zur sinnlosen Optimierung investierten Zeit. Der Erfolg war 

aber durchschlagend: Die Komplexität aller Berechnungen lag nunmehr 

bei O(n). Damit wurde die Laufzeit des Programms, mit denselben Daten 

wie zuvor, auf weniger als eine Minute reduziert! 

Als kleines Detail am Rande wäre hier noch zu erwähnen, dass das sinnvoll 

optimierte Programm sauber und gut lesbar war. Ganz im Gegensatz zu 

dem Meisterwerk, das durch den verzweifelten ersten Optimierungsversuch 

entstand, denn dieses war durch das Herausquetschen der letzten kleinen 

Instruktionen einfach gar nicht mehr lesbar. 

• Damit Komplexitätsverbesserungen garantiert den gewünschten Effekt 

bringen, sollte man auf jeden Fall auch auf die worst-Case Komplexität 

eines Algorithmus losgehen, nicht nur auf den Durchschnitt (außer, man 

kann den worst-Case garantiert ausschalten). Das bekannteste Beispiel 

eines Algorithmus mit O(log(n)) average-Komplexität, die allerdings zu 

O(n 2 ) im worst-Case entarten kann, ist Quicksort. Wenn man diesem die 

“falschen” Daten füttert ist es ganz und gar nicht mehr so quick :-). 

• Performancetests sollten immer auch auf viel zu gering ausgestatteten Systemen 

mit gleichzeitig viel zu großer Belastung stattfinden. Auf diese Art 

lassen sich leichter unangenehme Effekte finden (auch sehr geeignet für den 

Test auf subjektive Performance!). 

• Während der Phase der Optimierungen muss man immer darauf achten, 

nur eine Sache auf einmal zu optimieren und dann einen Vergleichstest 

durchzuführen. Der Grund dafür ist einfach zu erkennen: Wenn man in 

einem Programm an mehreren Baustellen gleichzeitig arbeitet, lässt sich 

nicht mehr sagen, von welcher der Maßnahmen nun welcher Effekt ausgeht.


Es kann sogar passieren, dass sich die Effekte verschiedener Maßnahmen 

gegenseitig aufheben und damit hat man viel Arbeit umsonst investiert! 

• Wann ist nun der Zeitpunkt für Optimierungen gekommen? Prinzipiell 

bereits beim Design, denn dieses entscheidet über die Komplexität des Codes. 

Weitere Performancetests und Optimierungsschritte sollten bei sehr 

oft verwendeten Basis- und Utility-Klassen möglichst früh stattfinden. Module, 

die bereits einen sehr hohen Abstraktionslevel haben, kann man zum 

Schluss der Entwicklung optimieren.

6. Pointer und References 

C ist schon berühmt und nicht minder berüchtigt für seine Pointer, die ein 

unheimlich mächtiges aber auch gleichzeitig gefährliches Werkzeug darstellen. 

C ++ hat nicht nur die Pointer von seiner Urmutter C übernommen, 

sondern auch den schlechten Ruf, der ihnen anlastet. Ich kann allerdings nur 

immer wieder betonen, dass nicht die Existenz von Pointern das Problem ist, 

sondern dass Unwissenheit und Unverständnis sowie Leichtsinn bei der 

Verwendung von Pointern die wahren Schuldigen an deren schlechtem Ruf 

sind. Bei Fehlverwendung von Pointern eröffnen sich ungeahnte und besonders 

heimtückische Fehlermöglichkeiten! Probleme, die durch die 

Fehlverwendung von Pointern entstehen, sind üblicherweise außerordentlich 

schwer zu lokalisieren, denn nur zu oft hat der Fehler selbst noch keine sofort 

merkbaren Auswirkungen. Die Katastrophe tritt nicht selten erst viel 

später, zu irgendeinem völlig unbestimmten Zeitpunkt, ans Tageslicht. Dann 

nämlich, wenn ein Programm endgültig seinem durcheinander gekommenen 

Heap ohne einen direkt erkennbaren Grund zum Opfer fällt und entweder 

sinnlose Ergebnisse produziert oder abstürzt. 

Neben den altbekannten Pointern bietet C ++ auch die sogenannten References 

an, die es in C nicht gibt. Man könnte References auch salopp als 

versteckte Pointer bezeichnen. In jedem Fall sind References wunderbar als 

Einstieg in die Welt der Adressen geeignet und werden daher in der Folge 

zuerst behandelt, bevor wir uns den Pointern in ihrer Hardcore-Variante 

zuwenden. 

6.1 References 

Wie C, so unterstützt auch C ++ bei Funktionsaufrufen ausschließlich callby-value 

zur Parameterübergabe. Manchmal will man allerdings auch einen 

call-by-reference erreichen, also einen übergebenen Parameter nachhaltig im 

aufrufenden Programmteil verändern. Die einzige Möglichkeit, dies zu bewerkstelligen, 

ist der Umweg über eine Adresse, die auf die Originalvariable 

verweist, auf die sich der Parameter bezieht. 

Neben einem gewollten nachhaltigen Verändern von Variablen gibt es auch 

noch einen anderen Grund, der einen call-by-reference notwendig macht: Ein 

call-by-value z.B. mit einer struct als Parameter führt sehr oft zu einem

104 6. Pointer und References 

gewaltigen Laufzeit-Overhead, denn es muss ja der gesamte Inhalt der struct 

kopiert werden und das kann eine ganze Menge sein. Selbiges gilt für den 

return-Wert. Es ist also auch in diesem Fall sehr sinnvoll, einfach über eine 

Adresse Bezug auf das Original zu nehmen. 

All das, was ich hier gerade angeführt habe, macht man in C mit Pointern 

“per Hand”. In C ++ hat man aus mehreren Gründen, die uns z.T. im OO-Teil 

noch begegnen werden, den expliziten Pointern ein weiteres Konstrukt zur 

Seite gestellt, die sogenannten References. Diese stellen, wenn man so will, 

implizite Pointer dar, bei denen man sich nicht als Entwickler selbst um die 

Dereferenzierung bei der Zuweisung kümmern muss. Diese passiert versteckt 

hinter den Kulissen. Auch gibt es bei References keine Pointerarithmetik. 

Genehmigen wir uns zum Einstieg ein erstes kleines Beispiel, das die Verwendung 

von References demonstriert (first_reference_demo.cpp): 

1 // f i r s t r e f e r e n c e d e m o . cpp − demo o f r e f e r e n c e s in C++ 

2 



5 



8 

9 void changeVariable ( int32 &var ) ; 

10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


13 { 

14 int32 my var = 12; 

15 int32 &my ref = my var ; 

16 

17 // my var and my ref r e f e r to the same int32 in memory 

18 // t h e r e f o r e they share the same value . . . 

19 cout

46 void changeVariable ( int32 &var ) 

47 { 

48 var /= 2; 

49 } 

6.1 References 105 

Der Output dieses Programms zeigt sehr schnell, was es mit References so 

auf sich hat: 

my var : 1 2 , my ref : 1 2 

my var : 2 4 , my ref : 2 4 

my var : 4 8 , my ref : 4 8 

my var : 2 4 , my ref : 2 4 

my var : 1 2 , my ref : 1 2 

Beginnen wir mit der Analyse des Programms in Zeile 14: Dort wird eine 

ganz normale int32 Variable namens my_var definiert. In der folgenden Zeile 

15 allerdings findet sich eine Variablendefinition, die uns bisher noch nicht 

untergekommen ist. Genau dies ist die Definition einer Reference. Um eine 

Variable als Reference Variable zu definieren, wird dem Variablennamen bei 

der Definition ein & vorangestellt. Worauf die Reference zeigt, wird durch deren 

Initialisierung festgelegt. In unserem Fall referenziert my_ref die Variable 

my_var, das bedeutet, beide Variablen beziehen sich auf denselben Platz im 

Speicher! 

In den Zeilen 19–30 sieht man, dass man tatsächlich beide Variablen alternativ 

verwenden kann. Egal, was man mit einer von ihnen macht, das 

Ergebnis ist immer in der jeweils anderen auch zu sehen. Was auch sonst, 

beziehen sich die beiden doch auf dieselbe Speicherstelle. Das Schöne im Gegensatz 

zu “echten” Pointern ist hierbei, dass man sich überhaupt nicht um 

die Dereferenzierung kümmern muss. Eine Reference Variable wird einfach 

ganz gleich im laufenden Code verwendet wie eine normale Variable, der Rest 

passiert hinter den Kulissen. 

Für Entwickler, die bisher nur mit C zu tun hatten, mag dieses Verhalten 

ungewohnt sein, vor allem liest sich z.B. die Zeile 15 für solche Entwickler etwas 

komisch. Dort wird my_ref im Prinzip auf eine Adresse initialisiert, aber 

die Schreibweise suggeriert irgendwie, dass eine Zuweisung des Inhalts stattfindet. 

Dieses komische Gefühl verschwindet allerdings sehr schnell, wenn 

man sich erst einmal an die Arbeit mit den wirklich sehr praktischen References 

gewöhnt hat. 

Vielfach ist in der Literatur erwähnt, dass es sich bei References im Prinzip 

um alternative Namen handelt. Betrachtet man unser Beispiel, so versteht 

man auch sehr schnell, wieso es zu dieser Bezeichnung kommt. Jedoch 

verschleiert der Begriff der alternativen Namen völlig, dass ja eigentlich eine 

Reference Variable viel mehr als nur quasi ein Alias ist. Sie ist tatsächlich 

eine alternative Zugriffsmöglichkeit. Aus diesem Grund möchte ich allen 

Lesern ans Herz legen, den Begriff der alternativen Namen nicht zu verwenden. 

In den Zeilen 46–49 ist eine Funktion definiert, die von einer Reference 

Gebrauch macht, um einen call-by-reference, also ein nachhaltiges Verändern


einer Variable beim Aufrufenden zu erreichen. Wie man in Zeile 33 sieht, 

funktioniert dies auch wie erwartet. Dass man auch eine Reference einem 

call-by-reference übergeben kann und dass dabei nicht plötzlich eine Doppel- 

Reference mit schlimmen Folgen daraus wird, sieht man in Zeile 38. 

Obwohl es aus der Besprechung des Beispielprogramms eigentlich klar 

sein sollte, möchte ich es hier trotzdem explizit erwähnen, um keine Missverständnisse 

aufkommen zu lassen: Kein einziger Operator wirkt auf 

eine Reference selbst! Egal, welche Operatoren man auf eine Reference 

Variable anwendet, sie wirken immer ausschließlich auf den 

Inhalt, der sich hinter der Reference verbirgt! Es gibt also keine 

Möglichkeit, z.B. so etwas wie Pointerarithmetik (wird später noch genau 

erklärt) mit References durchzuführen. 

In der Natur von References liegt auch, dass man sie nicht einfach z.B. 

mit einem Zahlenwert initialisieren kann. References sind ja quasi versteckte 

Zeiger auf einen Speicherplatz. Aus diesem Grund muss die Initialisierung 

immer mit einem sogenannten lvalue erfolgen, denn nur dieser garantiert 

ja, dass dahinter auch Speicherplatz existiert, der beschrieben werden kann. 

Und genau diese Eigenschaft führt uns zu einem weiteren Punkt: References 

müssen unbedingt immer bei ihrer Definition explizit initialisiert 

werden!. Der Grund ist einfach: Es wurde bereits erwähnt, dass kein einziger 

Operator auf die Reference wirkt, sondern alle nur auf den Inhalt. Das 

bedeutet auch, dass es ja gar keine Möglichkeit gibt, das Ziel der Referenz 

nachträglich zu verändern, denn eine Zuweisung will ja den Inhalt und nicht 

die Referenz zuweisen! Also kommt der expliziten Initialisierung einer Referenz 

eine besondere Rolle zu: Sie ist der einzige Zeitpunkt, zu dem man in 

der Lage ist, ihr Ziel zu setzen. 

Ein kleines Detail am Rande: Es war bereits davon die Rede, dass unter 

dem Begriff der expliziten Initialisierung das Setzen eines Wertes bei der 

Definition gemeint ist und nicht das Zuweisen eines Wertes irgendwann nach 

der Definition. Am Verhalten der Initialisierung von References sieht man 

eindeutig, dass auch der Compiler intern eine explizite Initialisierung ganz 

anders interpretiert als eine Zuweisung. Ansonsten wäre es nämlich nicht 

möglich, eine Referenz überhaupt auf eine Speicherstelle zeigen zu lassen, 

denn die Zuweisung bewirkt ja etwas gänzlich Anderes! 

Vorsicht Falle: Leider sieht man immer wieder, dass durch Unwissenheit 

oder Schlamperei besonders tolle Zeitbomben wie die folgende implementiert 

werden (reference_problems_demo.cpp): 

1 // reference problems demo . cpp − p o s s i b l e problems with r e f e r e n c e s 

2 



5 

6 int32 &returnDeadVariable ( ) ; 

7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


10 { 

11 int32 my var = returnDeadVariable ( ) ; 

12 int32 &my ref = returnDeadVariable ( ) ; 

13 

14 return ( 0 ) ; 

15 } 

16 


17 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

18 int32 &returnDeadVariable ( ) 

19 { 

20 int32 a n a u t o v a r i a b l e = 17; 

21 

22 return ( a n a u t o v a r i a b l e ) ; // NEVER ! ! ! ! ! ! ! ! ! ! ! ! ! ! 

23 } 

Ein Blick auf die Funktion, die in den Zeilen 18–23 implementiert wird, zeigt, 

was man niemals tun darf: In Zeile 22 wird die Reference auf eine Variable 

als return-Wert geliefert, bloß hat diese Variable zum Zeitpunkt des Rücksprungs 

ihre Lifetime bereits hinter sich! Welchen Wert die Variable my_var 

in Zeile 11 zugewiesen bekommt, steht in den Sternen. Leider passiert es 

sehr häufig, dass der Speicher, der von der mittlerweile “toten” Variable 

benutzt wurde, noch nicht überschrieben wurde. Dementsprechend wird in 

vielen Fällen my_var tatsächlich noch den beabsichtigten Wert (in unserem 

Fall 17) enthalten. Dies ist keinesfalls garantiert! Jedoch suggeriert ein solches 

durch Zufall entstandenes Verhalten, dass das Programm vermeintlich 

fehlerlos funktioniert – das tut es aber nicht! 

Viel Schlimmeres noch passiert in Zeile 12: Dort wird tatsächlich die Reference 

auf eine tote Variable einer anderen Reference Variable zugewiesen. Damit 

hat man gut versteckt einen Pointer auf “irgendetwas”. Hat man Glück, 

dann verabschiedet sich das Programm beim ersten Zugriffsversuch auf diesen 

Speicher mit einer Segmentation Violation. Hat man Pech, was leider auch 

relativ oft der Fall ist, dann gehört der falsch referenzierte Speicher irgendeiner 

anderen Variable im eigenen Programm. Damit sieht das Betriebssystem 

keine Veranlassung, eine wie auch immer geartete Schutzverletzung zu melden. 

Und schon hat man die tollste Zeitbombe in ein Programm eingebaut, 

die man sich vorstellen kann. Zu irgendeinem völlig unvorhersagbaren Zeitpunkt 

wird sich das Programm an irgendeiner völlig unvorhersagbaren Stelle 

sehr komisch benehmen und die nächste schlaflose Nacht zur Fehlersuche 

kündigt sich an. 

Das schlimmste Problem bei solchen Fehlern ist, dass Ursache und Auswirkung 

in keinem erkennbaren Verhältnis zueinander stehen. Daher sind 

sie auch außerordentlich schwer zu lokalisieren! Zum Glück warnen heutige 

Compiler bei solchen bombigen Programmen, dass eine Reference auf eine 

lokale Variable als return-Wert vielleicht gar keine so gute Idee ist. Bloß, was 

hilft die beste Warning, wenn sie von Entwicklern ignoriert wird? 

Sehr sinnvoll einsetzbar sind References auch, wenn man eine struct bei 

einem Funktionsaufruf als Parameter übergeben will. In C ++ findet bekannterweise 

immer ein call-by-value statt. Das bedeutet, dass eine Kopie einer


struct gemacht werden muss, um einen solchen durchführen zu können. Neben 

großen Einbußen bei der Performance kann man dabei auch leicht über 

das deep- und shallow-clone Problem stolpern. Mit den hier besprochenen 

References kann man diese Probleme sehr elegant in den Griff bekommen, 

wie das folgende Beispiel zeigt (struct_reference_demo.cpp): 

1 // s t r u c t r e f e r e n c e d e m o . cpp − demo how to use s t r u c t s as params 

2 



5 



8 


10 { 

11 int32 a member ; 

12 int32 another member ; 

13 } ; 

14 

15 void show ( struct TestStruct & t h e s t r u c t ) ; 

16 void changeStruct ( struct TestStruct & t h e s t r u c t ) ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


20 { 

21 struct TestStruct a s t r u c t ; 

22 

23 a s t r u c t . a member = 17; 

24 a s t r u c t . another member = 20; 

25 

26 show ( a s t r u c t ) ; 

27 changeStruct ( a s t r u c t ) ; 

28 show ( a s t r u c t ) ; 

29 

30 return ( 0 ) ; 

31 } 

32 

33 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

34 void show ( struct TestStruct & t h e s t r u c t ) 

35 { 

36 cout


werden müsste, um den Funktionsaufruf durchzuführen. Dementsprechend 

findet der Aufruf dieser Funktion, z.B. in Zeile 26, ohne jegliche explizite 

Pointerkonstrukte einfach nur durch Übergabe der entsprechenden struct 

Variable statt. 

Obwohl dies allein schon eine merkliche Verbesserung im Vergleich zu C 

darstellt, ist es allerdings noch immer nicht der Weisheit letzter Schluss, wie 

uns die Funktion changeStruct in den Zeilen 41–45 zeigt: Hier wird der 

Inhalt der übergebenen Structure nachhaltig verändert. Dies funktioniert 

natürlich, weil wir es ja mit einem call-by-reference zu tun haben. Dadurch, 

dass es sich um eine Funktion mit dem Namen changeStruct handelt, ist 

auch für alle Entwickler zu erwarten, dass sich etwas ändert und dementsprechend 

ist dieses Verhalten noch intuitiv. Wer aber hindert z.B. die Funktion 

show daran, die Structure zu verändern? Müssen sich alle Entwickler ab jetzt 

bei jedem Aufruf einer Funktion, die einen struct Parameter nimmt, Sorgen 

machen, dass etwas nachhaltig geändert wird, auch wenn sie es nicht erwarten? 

Hoffentlich nicht, denn damit würden Unmengen an Code geschrieben 

werden müssen, um auf diesen Umstand auch entsprechend Rücksicht zu nehmen. 

Tatsächlich gibt es eine Möglichkeit, wie man eine unerwartete Veränderung 

verhindern kann: Man verwendet eine explizit konstante Referenz. Wie 

das geht, zeigt das folgende Beispiel (struct_ref_clean_demo.cpp): 

1 // s t r u c t r e f c l e a n d e m o . cpp − demo f o r clean use o f s t r u c t r e f s 

2 



5 



8 


10 { 



13 } ; 

14 

15 void show ( const struct TestStruct & t h e s t r u c t ) ; 

16 

17 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


19 { 

20 struct TestStruct a s t r u c t ; 

21 



24 

25 show ( a s t r u c t ) ; 

26 return ( 0 ) ; 

27 } 

28 

29 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

30 void show ( const struct TestStruct & t h e s t r u c t ) 

31 { 

32 cout


Bei der Deklaration von show in Zeile 15 und bei der Definition dieser Funktion 

in den Zeilen 30–34 sieht man, wie man ein ungewolltes nachhaltiges 

Verändern des Inhalts einer Variable verhindern kann: Man deklariert den 

Reference Parameter als const. Dadurch teilt man dem Compiler mit, dass 

keine Änderung stattfinden wird und jeder Versuch eines schreibenden Zugriffs 

auf diesen Parameter wird entsprechend mit einer Fehlermeldung quittiert. 

Leider stehen viele Entwickler immer noch auf dem Standpunkt, dass 

const nicht notwendig ist, denn “sie verändern ja sowieso nichts”. Dieser 

Standpunkt ist sehr schlecht, denn durch die Deklaration als const signalisiert 

man diese Absicht explizit und dadurch kann es auch bei späteren 

Änderungen zu keinen Missverständnissen kommen. 

Vom Compiler wird eine const Reference tatsächlich als etwas völlig 

Verschiedenes zu einer normalen Reference gesehen, wie folgendes Demoprogramm 

zeigt (const_ref_demo.cpp): 

1 // const ref demo . cpp − demo f o r const r e f e r e n c e s 

2 



5 



8 


10 { 



13 } ; 

14 

15 void show ( const struct TestStruct & t h e s t r u c t ) ; 

16 void changeStruct ( struct TestStruct & t h e s t r u c t ) ; 

17 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


21 { 


23 const int32 & f i r s t c o n s t r e f = my var ; 

24 // the f o l l o w i n g d e f i n i t i o n works , but i s deprecated 

25 const int32 & s e c o n d c o n s t r e f = 12; 

26 // t h i s i n i t i a l i z a t i o n r e s u l t s in a compiler e r r o r 

27 int32 & t h i r d c o n s t r e f = s e c o n d c o n s t r e f ; 

28 // t h i s bad hack i s p o s s i b l e , but . . . 

29 int32 & h a c k c o n s t r e f = const cast(s e c o n d c o n s t r e f ) ; 

30 

31 cout



44 

45 show ( a s t r u c t ) ; 

46 


47 // assignment of r e f e r e n c e i s f a s t e r than copying s t r u c t 

48 struct TestStruct & a s s i g n e d s t r u c t = a s t r u c t ; 

49 

50 // t h i s assignment i s ok 

51 const struct TestStruct & c o n s t s t r u c t r e f = a s t r u c t ; 

52 

53 // t h i s one r e s u l t s in a compiler e r r o r 

54 struct TestStruct & a n o t h e r s t r u c t r e f = c o n s t s t r u c t r e f ; 

55 

56 return ( 0 ) ; 

57 } 

58 

59 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

60 void show ( const struct TestStruct & t h e s t r u c t ) 

61 { 

62 struct TestStruct &bad hack = 

63 const cast(t h e s t r u c t ) ; 

64 

65 bad hack . a member = 3; 

66 

67 cout


Compiler legt hinter den Kulissen eine temporäre Variable an, deren Lifetime 

genau der Lifetime der Reference entspricht, initialisiert diese Variable 

auf den angegebenen Wert und initialisiert die Reference so, dass sie auf 

die temporäre Variable zeigt. 

Jetzt stellt sich natürlich die Frage, warum der Compiler bei const References 

so etwas macht, bei normalen References aber in so einem Fall 

einen Fehler meldet. Die Antwort ist simpel: Es wurde bei der Definition 

von C ++ befunden, dass im Fall von normalen References dieses Verhalten 

fehleranfällig und gefährlich ist. 

Meine Meinung dazu ist allerdings noch etwas pragmatischer, denn ich stehe 

auf dem Standpunkt, dass die Sinnhaftigkeit von compilergenerierten 

temporären Variablen sowieso sehr fraglich ist. Deshalb wurde dieser Fall 

auch im Demoprogramm als deprecated (wörtl.: missbilligt) gekennzeichnet. 

• In Zeile 27 sieht man, was man in jedem Fall nicht machen darf: Man darf 

eine “normale” Reference natürlich nicht mit einer const Reference initialisieren, 

denn damit würde man ja den Schreibschutz aufheben. Dagegen 

hat dann der Compiler ein wirksames Mittel, nämlich eine Fehlermeldung. 

• Zeile 29 zeigt eindrucksvoll zwei Dinge: Erstens, dass sich immer Mittel 

und Wege finden, wie man durch einen bösen Hack den Compiler überreden 

kann, etwas doch zu übersetzen. Zweitens, dass tatsächlich eine temporäre 

Variable hinter der in Zeile 25 definierten const Reference existiert, denn 

sonst könnte man die Zuweisung in Zeile 35 nicht ungestraft durchführen. 

Wie bereits erwähnt, kann man mittels eines const_cast eine schreibgeschützte 

Variable zwanglos von ihrem Schreibschutz befreien. Diese 

Möglichkeit sollte man allerdings nur sehr wohl überlegt und so selten 

wie möglich in Anspruch nehmen. Die Verwendung, wie sie in diesem 

Beispiel gezeigt wird, ist absolut katastrophal und hat in keinem vernünftigen 

Programm etwas verloren. 

• Bereits erwähnt wurde gerade Zeile 35 des Programms. Durch den bösen 

Hack des Eliminierens des Schreibschutzes ist es tatsächlich möglich, eine 

Konstante zu verändern! Hier wurde dieses Konstrukt ausschließlich 

deswegen verewigt, weil sich damit demonstrieren lässt, dass sich hinter 

second_const_ref tatsächlich eine temporäre Variable versteckt. Der 

Output aus den Zeilen 37–39 zeigt es (wenn man zuerst die richtigen Zeilen 

auskommentiert, damit das Programm überhaupt compiliert werden 

kann). Niemals darf so etwas in einem vernünftigen Programm in dieser 

Form vorkommen!!! 

Vorsicht Falle: Auf das hier beschriebene Verhalten, dass sich hinter 

einer Konstanten eine temporäre Variable versteckt, darf man sich keinesfalls 

verlassen. Obwohl das Verhalten so im Standard niedergeschrieben 

ist, kann es, je nach Compiler, sein, dass sich das Programm in diesem 

Punkt anders verhält, als hier beschrieben. Grundsätzlich lässt sich für die


alltägliche Praxis sagen, dass das Resultat dieses bösen Hacks undefiniert 

ist. 

Ich habe diesen Hack hier vor allem deswegen demonstriert, weil ich bereits 

in vielen Programmen gesehen habe, dass durch eine unvorsichtige Anwendung 

des const_cast solche Operationen unabsichtlich vorkommen. 

• Eine weitere angenehme Seite von References ist in Zeile 48 zu sehen: Führt 

man eine Referenzzuweisung einer struct durch, so ist dies natürlich deutlich 

effizienter, als eine Kopie der gesamten struct zu machen, was bei 

einer Wertzuweisung passieren würde. Jedoch muss man sich in diesem 

Fall immer dessen bewusst sein, dass jeder schreibende Zugriff auch eine 

Veränderung des Originals hervorruft! Ist dies nicht erwünscht, so ist die 

Reference entsprechend als const zu deklarieren, wie dies in Zeile 51 zu 

sehen ist. 

• Zeile 54 demonstriert, dass der Compiler sehr wohl const ernst nimmt, 

denn er weigert sich, diese Zuweisung einer const Structure auf eine normale 

durchzuführen, obwohl hinter der const Structure ja eine normale 

steht und diese nur durch die Zuweisung zu const mutiert ist. 

• In den Zeilen 62–63 sieht man denselben Hack, der uns bereits zuvor begegnet 

ist: Hier wird bösartigerweise durch einen const_cast der Schreibschutz 

von the_struct aufgehoben. Sehr, sehr selten gibt es Fälle, wo dies 

aus der Programmlogik heraus legitim ist. Der hier demonstrierte Fall ist 

eindeutig keiner davon! Wir werden später im OO-Teil noch einige wenige 

Fälle kennen lernen, wo dieser Cast seine Berechtigung hat. 

Vorsicht Falle: Auch wenn sich References bei ihrer Verwendung im Code 

sehr ähnlich anfühlen wie normale Variablen, so verstecken sich dahinter 

doch Pointer, die auf eine Adresse zeigen. Damit kann man natürlich auch 

die entsprechenden Fehler machen, wie sie z.B. in unserem vorigen Demoprogramm 

gezeigt wurden. Ich kann also nur sehr nachdrücklich den Tipp 

geben, References vorsichtig und vorausschauend zu verwenden. Das Wichtigste 

bei References ist, den Mechanismus, der dahintersteckt, genauestens 

verstanden zu haben, um nicht in eine böse Falle zu tappen. 

Vorsicht Falle: Obwohl der const_cast erfunden wurde, um den Schreibschutz 

aufzuheben, der z.B. über eine Reference mittels const verhängt wurde, 

verbergen sich dahinter ungeahnte Fehlermöglichkeiten. Welcher Entwickler 

ist denn schon darauf gefasst, dass sich plötzlich eine als const deklarierte 

Variable bzw. ein Parameter nachhaltig verändert? Ein solches 

Verhalten führt garantiert zu vielen Nachtschichten, die mit Fehlersuche zugebracht 

werden, weil sich ein Programm plötzlich außerordentlich komisch 

verhält. 

Deshalb hier eine lebensnotwendige Grundregel beim Arbeiten mit 

const_cast: Der Einsatz von const_cast ist dann und NUR DANN


gestattet, wenn sich aus der äußeren Sicht am Inhalt eines als const 

deklarierten Objekts nichts verändert! 

Eine typische Anwendung für eine versteckte Veränderung, die “außenstehende” 

Entwickler nicht bemerken, ist z.B. das Caching von Daten hinter 

den Kulissen. Je nachdem, was man genau bezwecken will, gibt es auch noch 

die alternative Möglichkeit, einzelne Variablen als mutable zu deklarieren. 

Dies wird in Abschnitt 15.1 noch genauer behandelt. 

Vorsicht Falle: Wo auch immer sich aufgrund der Semantik einer Funktion 

an einem Parameter nach außen hin nichts ändern soll, aber aus technischen 

Gründen die Verwendung einer Reference wünschenswert oder notwendig ist 

(z.B. bei einer Structure als Parameter), soll man diesen Parameter immer als 

const deklarieren. Damit signalisiert man nach außen, dass man nicht beabsichtigt, 

etwas zu verändern. Deklariert man einen solchen Parameter nicht 

als const, so werden sich alle Entwickler, die diese Funktion verwenden, auf 

eine mögliche Änderung einstellen und auf diese Art unnötig komplizierten 

Code erzeugen. 

Es gibt den noch schlimmeren Fall, dass man eine Funktion, die einen Parameter 

irrtümlich nicht als const deklariert hat, gar nicht verwenden kann, 

weil man selbst nur eine const Reference in Händen hält. Das Schlimmste, 

was dann herauskommen kann, ist die notgedrungene Verwendung eines 

const_cast, um den Aufruf überhaupt tätigen zu können. Haben allerdings 

einmal solche bösen Hacks in den Code Eingang gefunden, dann bahnen sich 

viele unabwendbare Katastrophen an, denn wer soll sich noch auskennen, 

welches const ernst gemeint ist und welches nicht? 

6.2 Pointer 

Nach der Diskussion über References sind wir nun endgültig bei der Hardcore 

Variante des Hantierens mit Adressen angekommen, nämlich bei den Pointern. 

Pointer sind im Prinzip etwas unheimlich Einfaches: Es sind Variablen, 

deren Inhalt eine Adresse ist. Genau diese Einfachheit macht sie auch so 

mächtig, man kann nämlich damit auf quasi beliebige Inhalte im Speicher 

zeigen. Diese Inhalte können verschiedenster Natur sein, nämlich sowohl 

Speicherstellen für Daten als auch Einsprungadressen von Funktionen bzw. 

Methoden. Natürlich kann man mit Adressen auch beliebig rechnen und auf 

diese Art Blöcke verwalten. 

Dieselbe Einfachheit, die Pointer so mächtig macht, macht sie gleichzeitig 

auch so gefährlich in den Händen ungeübter und/oder unvorsichtiger Entwickler. 

Wie bereits bei den Datentypen diskutiert wurde, ist intern in einem 

Computer praktisch alles einfach nur Interpretationssache. Im Fall von 

Pointern wird die Interpretation dessen, worauf die Adresse zeigt, noch bei

6.2 Pointer 115 

weitem stärker den Entwicklern überlassen, als dies bei anderen Datentypen 

der Fall ist. 

Neben der Möglichkeit, gezielt über Adressen Daten ansprechen zu können, 

bietet die Arbeit mit Pointern noch ein ganz besonderes Feature, das ohne 

Pointer (bzw. zumindest ein sehr ähnliches Konstrukt) gar nicht realisierbar 

wäre: Die dynamische Speicherverwaltung. Es ist möglich, zur Laufzeit eines 

Programms zu entscheiden, wie viel Speicher man für gewisse Aufgaben 

braucht, diesen Speicher anzufordern und auch wieder freizugeben. Diese 

Möglichkeit ist für praktisch alle real-World Anwendungen lebensnotwendig 

und ohne diese Möglichkeit ist es nicht denkbar, vernünftig funktionierende 

Software zu entwickeln. Eines muss man aber bei dynamischem Memory- 

Management in C ++ unbedingt immer im Hinterkopf behalten: Man darf 

nicht nur einfach Speicher zur Laufzeit dynamisch anfordern, man muss auch 

unbedingt die Verantwortung für die saubere Verwaltung übernehmen! Der 

Compiler und das Betriebssystem unterstützen Entwickler hierbei nur sehr 

rudimentär. 

Nachdem bekannt ist, was man mit Pointern machen kann und bevor ich zur 

genauen Beschreibung komme, wie man das machen kann, möchte ich gerne 

allen Lesern die Gewissensfrage nach ihren Vorkenntnissen zu Pointern in C 

stellen. Denen, die sich nur rudimentär etwas darunter vorstellen können, 

möchte ich eindringlichst raten, dass sie Kapitel 10 aus Softwareentwicklung 

in C genauestens lesen! Dort wird anfängergerecht und akribisch auf den sauberen 

Umgang mit Pointern eingegangen und es werden alle möglichen Fehler 

skizziert, die bei unsachgemäßer Handhabung passieren können. Einiges was 

dort beschrieben wird, wird in C ++ bereits durch References abgedeckt, das 

bedeutet aber nicht, dass es für das Verständnis nicht ebenso wichtig wäre! 

Natürlich werde ich hier in der Folge den Umgang mit Pointern und alle 

Stolpersteine nochmals aufzeigen. Jedoch muss ich gerade bei Pointern 

erfahrungsgemäß den Standpunkt vertreten: Doppelt hält besser! 

6.2.1 Pointer und Adressen 

Wie bereits erwähnt, speichert eine Pointervariable eine Adresse. Diese 

Adresse zeigt auf eine Speicherstelle, genauer gesagt wird sie so interpretiert, 

dass sie auf die Startadresse eines Speicherblocks zeigt. Nehmen wir 

beispielsweise einen int32, der bei uns ja so definiert ist, dass er 4 Bytes 

belegt. Ein Pointer, der auf diesen int32 zeigt, zeigt also in Realität auf das 

erste der vier für ihn reservierten Bytes. 

Was sagt uns das? Egal, ob wir nun auf einen int8, int32, int64, double, 

eine Structure oder sonst etwas einen Pointer zeigen lassen, er speichert immer 

nur die Startadresse! Die Interpretation, was an dieser Stelle steht, ist 

mehr oder weniger den Entwicklern überlassen. Dies bringt uns auch gleich 

zu einer sehr wichtigen Eigenschaft von Pointern: Es gibt keine Möglichkeit, 

zur Laufzeit herauszufinden, wie viel Speicher an der Stelle,


auf die ein Pointer zeigt, regulär reserviert ist! Es gibt nicht einmal 

die Möglichkeit, zur Laufzeit herauszufinden, ob ein Pointer 

überhaupt auf eine reguläre Adresse zeigt! 

Vorsicht Falle: Schlamperei beim Entwickeln und daraus resultierende 

Pointer, die entweder auf Speicherstellen zeigen, auf die sie nicht zeigen sollen 

oder auch Fehlinterpretationen von Datentypen, gehören zu den schlimmsten 

Fehlern, die man machen kann. Schlimm sind diese Fehler aus zwei Gründen: 

Erstens, weil sie sich nur allzu oft nicht sofort bemerkbar machen. Zweitens, 

weil im Normalfall kein direkter Zusammenhang zwischen Ursache und Wirkung 

erkennbar ist. Gerade Typ-Fehlinterpretationen sind außerordentlich 

schwer in einem fehlerhaften Programm zu lokalisieren. 

Als erstes Beispiel zum Thema Pointer versuchen wir einmal, den Mechanismus 

der References, den wir bereits kennen gelernt haben, quasi “zu Fuß” 

zu implementieren. In C wäre diese Art der Implementation sogar notwendig, 

denn C kennt keine References (first_pointer_demo.cpp): 

1 // f i r s t p o i n t e r d e m o . cpp − small demo o f p o i n t e r s in C++ 

2 



5 



8 

9 void changeVariable ( int32 ∗ var ) ; 

10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


13 { 


15 int32 ∗ my ptr = &my var ; 

16 

17 // my var and my ptr r e f e r to the same int32 in memory 

18 // t h e r e f o r e they share the same value . . . 

19 cout

41 ” , ∗ my ptr : ”


auslesen kann, sondern ebensogut auf diesem Weg einen Wert zuweisen kann, 

zeigt sich in den Zeilen 29–31. 

Auch einen call-by-reference kann man mittels Pointern “zu Fuß” machen, 

wie Zeile 34 beweist: Die Funktion changeVariable nimmt als Parameter 

einen Pointer, der mittels &my_var übergeben wird. Damit zeigt der Parameter 

var der Funktion changeVariable auf die Speicherstelle von my_var 

und jede Änderung des Inhalts innerhalb der Funktion wirkt sich natürlich 

auch außerhalb aus. 

Eines sieht man an diesem Programm allerdings auch: Alle Konstrukte, 

bei denen es im Prinzip nur auf die Referenzierung von Speicherstellen ohne 

Aspekte dynamischer Speicherverwaltung ankommt, sind mit References bei 

weitem eleganter lösbar. Deshalb rate ich in solchen Fällen unbedingt dazu, 

für diese Aufgaben Pointer nicht zu verwenden, auch wenn man sie aus C 

gewohnt ist. 

Vorsicht Falle: Auf eine besondere Falle möchte ich hier auch noch aufmerksam 

machen, die wir bereits bei den References besprochen haben. Es 

hat auch bei Pointern katastrophale Auswirkungen, wenn ein Pointer als 

return-Wert aus einer Funktion geliefert wird, der auf eine Variable zeigt, die 

ihre Lifetime bereits hinter sich hat. 

Vorsicht Falle: Es wird dringend angeraten, einen Pointer, den man nicht 

mehr in Verwendung hat, sofort explizit auf 0 zu setzen. Da 0 per Definition 

garantiert keine gültige Adresse repräsentiert, führt jeder Versuch des Dereferenzierens 

eines solchen Pointers garantiert zu einer Segmentation Violation. 

Damit bemerkt man auf jeden Fall sofort, wenn man einen Programmfehler 

eingebaut hat. Ohne explizites Setzen auf 0 ist dies nicht garantiert! 

Konvention: NULL vs. 0. Leser, die Erfahrung mit C haben, werden sich 

gefragt haben, warum ich hier 0 als ungültige Adresse erwähne und nicht 

NULL, wie es in C üblich ist. Das NULL Macro, das sich in C eingebürgert 

hat, kann in C ++ ein paar größere oder kleinere Problemchen verursachen: 

Im Macro ist nämlich NULL vom Typ her als void * definiert. Ein C ++ 

Compiler mit seinen, im Vergleich zu C, besseren Typüberprüfungs- und 

Umwandlungsstrategien sieht das dann so: 

• Die Zuweisung von 0 (also der Zahl 0) ist problemlos möglich, denn hierbei 

kann eine implizite Umwandlung stattfinden. Es ist nämlich keine Konversion 

von einem Pointertyp auf einen anderen notwendig. 

• Die Zuweisung von NULL würde eine implizite Umwandlung von einem 

Pointer-Typ auf einen anderen mit sich bringen. Dies wird definitiv als 

gefährlich erachtet.


Wenn man aus guter alter Gewohnheit die Finger nicht vom NULL Macro 

lassen kann, so sollte man NULL einfach als 0 definieren (sollte dies nicht 

ohnehin bereits in einem der Headers zum C ++ Compiler geschehen sein). 

6.2.2 Dynamische Memory Verwaltung 

Nach der Kurzbesprechung des Referenzmechanismus “zu Fuß”, der nun wirklich 

nicht das Berauschendste ist, wofür man in C ++ Pointer verwenden kann 

bzw. soll, wenden wir uns jetzt dem Thema zu, das im Prinzip die allerwichtigste 

Anwendung von Pointern in Programmen darstellt: Die dynamische 

Memory Verwaltung. 

Unter dem Begriff der dynamischen Memory Verwaltung versteht man 

das Anfordern, Verwalten und Freigeben von Speicher je nach Bedarf zur 

Laufzeit. Ok, je nach Bedarf stimmt vielleicht nicht ganz, jedem Computer 

geht einmal der Speicher aus :-). 

Ich möchte gleich zu Beginn auf einen ganz wichtigen Unterschied 

zwischen C und C ++ hinweisen: In C wurden die Funktionen malloc, realloc 

und free im Rahmen der dynamischen Memory Verwaltung verwendet. Aus 

sehr guten Gründen soll man genau von diesen Funktionen in C ++ tunlichst 

die Finger lassen, außer für ganz spezielle Anwendungen. Dann muss man 

allerdings sehr genau wissen, was man tut! Eine Abhandlung zu diesem 

Thema findet sich in Abschnitt 12.3. 

Als Ersatz stehen in C ++ die Operatoren new und delete zur Verfügung, 

die wir in Kürze genau unter die Lupe nehmen werden. 

An einem kurzen Beispiel lässt sich jedenfalls am einfachsten erklären, wie 

man prinzipiell mit dynamischer Memory Verwaltung umgeht 

(first_dynamic_memory_demo.cpp): 

1 // first dynamic memory demo . cpp − p r i n c i p l e s o f dynamic memory 

2 // management in C++ 

3 



6 



9 

10 void show ( const int32 array [ ] , uint32 length ) ; 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


14 { 

15 // request memory f o r a s i n g l e element 

16 int32 ∗ dyn var = new int32 ; 

17 ∗dyn var = 10; 

18 cout


24 // f r e e memory again using the s i n g l e v e r s i o n d e l e t e 

25 delete dyn var ; 

26 

27 dyn var = 0; 

28 

29 const uint32 ARRAY LENGTH = 10; 

30 

31 // request memory f o r the array with new 

32 int32 ∗ dyn array = new int32 [ARRAY LENGTH] ; 

33 

34 for ( uint32 count = 0; count < ARRAY LENGTH; count++) 

35 dyn array [ count ] = count ; 

36 

37 show ( dyn array ,ARRAY LENGTH) ; 

38 

39 int32 ∗ i t e r a t i o n p t r = dyn array ; 

40 cout


bei unseren kleinen Testprogrammen der Speicher nicht ausgehen wird 

und lassen diesen Aspekt außer Acht. 

C Programmierern, die noch malloc gewohnt sind, das die Größe in 

Bytes gesagt bekommen muss, wird new zu Beginn etwas ungewohnt 

vorkommen. Aber damit lernt man schnell zu leben, weil es doch eine 

deutliche Verbesserung darstellt. 

Vorsicht Falle: Der new Operator ist in seiner Standard-Implementation 

so definiert, dass eine implizite Initialisierung des Speichers nicht 

garantiert ist! Das bedeutet, dass unbedingt immer eine explizite Zuweisung 

eines Wertes erfolgen muss, da man es sonst mit irgendeinem 

zufälligen Wert zu tun hat. Dies erfolgt z.B. für unseren in Zeile 16 

angeforderten Speicher für einen int32 in Zeile 17. 

Vorsicht Falle: Entwicklern, die im Umgang mit Pointern ungeübt 

sind, passiert es leider nur zu gerne, dass sie den dereference Operator, 

also den *, bei einer Zuweisung eines Wertes vergessen. Schreibt man 

z.B. in Zeile 17 das Statement dyn_var = 10;, so führt das zu einem 

Compilerfehler. Diese Zuweisung würde nämlich bedeuten, dass man 

dem Pointer dyn_var die Adresse 10 zuweisen will und das ist nicht 

zulässig. 

Zeile 20: Speicher, den man dynamisch mittels new anfordert, bleibt so lange 

für das Programm reserviert, bis er explizit wieder freigegeben wird (ich 

klammere hier eine mögliche Implementation von C ++ mittels Garbage- 

Collector bewusst aus). Das bedeutet, dass man sich unbedingt immer 

selbst darum kümmern muss, dass alle angeforderten Speicherblöcke dem 

System auch wieder durch Aufruf des delete Operators zurückgegeben 

werden. In unserem Fall bewirkt der Aufruf delete dyn_var das Freigeben 

des zuvor angeforderten int32. 

Vorsicht Falle: Der Operator delete ist so definiert, dass er natürlich 

nur Speicher wieder freigeben kann, der mit new angefordert wurde. Daher 

darf man delete nur mit einem Base-Pointer aufrufen, den man von 

new bekommen hat. Ruft man delete mit irgendeinem anderen als einem 

von new erhaltenen Base-Pointer auf, so endet dieser Aufruf mit 

einer Segmentation Violation. 

Vorsicht Falle: Niemals darf man den Base-Pointer eines Speicherblocks 

verlieren! Sollte dies passieren, so kann der Speicher nicht mehr 

freigegeben werden (womit sollte man denn delete aufrufen?) und damit 

wächst das Programm beständig! Wie bereits erwähnt: Speicher, der mit 

new angefordert wird, wird vom System nicht automatisch wieder freigegeben! 

Vergisst man ein delete, so gammelt der betreffende Block bis


zum Beenden des Programms im Speicher herum. So ein Beenden des 

Programms kann dann natürlich auch passieren, weil kein Speicher mehr 

da ist und das Programm deshalb vom System abgewürgt wird :-). 

Vorsicht Falle: In C ++ ist delete so definiert, dass man es auch mit 

einem 0 Pointer ungestraft aufrufen darf. In diesem Fall passiert einfach 

gar nichts. Allerdings... manche (zum Glück wenige) Compiler bzw. 

Laufzeitumgebungen sehen das anders. In solchen Fällen endet delete 

auf einen 0 Pointer mit einer Segmentation Violation! 

Das bedeutet, dass ein Aufruf von delete ohne vorherige Abfrage auf 

0 auf der jeweiligen Plattform aus Sicherheitsgründen getestet werden 

muss. Aus diesem Grund habe ich in diesem Buch dort, wo keine besondere 

Unübersichtlichkeit dadurch entsteht, die Abfragen auf 0 in den 

Beispielen verewigt. In der Praxis wird dies normalerweise nicht gemacht. 

Zeile 22: Hier sieht man, dass man natürlich eine Pointer Variable beliebig 

oft verwenden kann. Nachdem der Speicher, der sich hinter dyn_var versteckt 

hat, freigegeben wurde, kann man auch wieder neuen anfordern. 

Die Anforderung mittels new sieht allerdings hier etwas anders aus, als 

zuvor in Zeile 16! Hier wird eine Anforderung von Speicher mit einer expliziten 

Initialisierung kombiniert. Der Wert, auf den initialisiert werden 

soll, wird dem Datentyp in runden Klammern nachgestellt. Dies ist auch 

die von mir empfohlene Art der Speicheranforderung, da hierbei immer 

garantiert ein initialisierter Speicherblock geliefert wird. Der Output, 

der in Zeile 23 generiert wird, beweist, dass die Initialisierung erfolgreich 

war. 

Zeile 27: Hier sieht man, was man unbedingt tun soll, wenn eine Pointer Variable 

nicht mehr auf einen existenten Speicherblock zeigt: Man setzt 

den Pointer explizit auf 0! Damit ist garantiert, dass jeglicher Zugriff, 

schreibend oder lesend, zu einer Segmentation Violation führt. Ansonsten 

könnte es sein, und das ist gar nicht so selten, dass man unbeabsichtigt 

irgendwann “irgendeinen” Speicher verändert. Solche Fehler zu 

finden ist, wie schon öfter besprochen, der größte Spaß im Alltag von 

Entwicklern. 

Zeile 32: Wenn man schon dynamisch Speicher anfordern will, dann natürlich 

nicht immer nur Element für Element, das wäre absurd. Sehr oft braucht 

man Platz für viele Elemente auf einmal. Dies funktioniert natürlich 

auch, indem man gleich ein ganzes Array anfordert. Der entsprechende 

Aufruf von new[] ist intuitiv: Man stellt einfach die Anzahl der 

gewünschten Elemente des Arrays in eckigen Klammern dem Datentypen 

nach. Der Base-Pointer, der von new geliefert wird, zeigt dann auf 

den Anfang des dynamischen Arrays, also auf das erste Element desselben.


Zeilen 34–35: Hier sieht man, dass man mit einem dynamischen Array, das 

durch einen Pointer repräsentiert wird, gleich umgehen kann, wie es schon 

von einem statischen Array bekannt ist: Man kann zum Zugriff auf ein 

bestimmtes Element einfach den Index dieses Elements in eckigen Klammern 

dem Pointer nachstellen. 

Nicht nur, dass sich ein Pointer und eine (statische) Array-Variable in 

dieser Beziehung gleich verhalten, sie werden intern tatsächlich beide 

durch einen Pointer realisiert! Man kann also eine (statische) Array- 

Variable auch einfach einem Pointer zuweisen, sofern dieser den korrekten 

Typ hat. Durch diese Zuweisung zeigt dann der Pointer direkt auf das 

statische Array. Sehr oft sieht man vor allem bei Parameterlisten, dass 

die beiden Arten von Arrays vom Typ her beliebig austauschbar sind. 

Vorsicht Falle: Auch wenn sich statische und dynamische Arrays gleich 

verhalten und intern gleich repräsentiert werden, gibt es einen riesigen 

Unterschied, wie (und auch wo) der Speicher für sie bereitgestellt wird. 

Es darf dementsprechend niemals versucht werden, den Speicher, der für 

ein statisches Array allokiert ist, mittels delete freizugeben, denn dies 

führt geradewegs ins Verderben. 

Vorsicht Falle: Es gibt keine Möglichkeit, zur Laufzeit herauszufinden, 

für wie viele Elemente nun Speicher angefordert wurde! Daher muss man 

selbst Sorge dafür tragen, dass man nicht über die Grenzen eines Arrays 

hinausschreibt. 

Zeilen 39–41: Auch die Pointer-Arithmetik funktioniert in C ++ ganz gleich 

wie in C: Wenn man zu einem Pointer eine Zahl addiert, dann bewirkt 

man, dass der Pointer um genau so viele Elemente (nicht Bytes!!!) im 

Array vorrückt, wie die Zahl besagt. Subtrahiert man eine Zahl, dann 

geht das Spielchen natürlich in die Gegenrichtung. In Zeile 41 machen 

wir uns dies zunutze, indem einfach der Wert 5 zum iteration_ptr 

addiert wird, woraufhin der Pointer auf das sechste Element (also das 

mit Index 5) zeigt. Dereferenziert man diese Adresse, so kommt man 

zum dahinterstehenden Wert. 

Vorsicht Falle: Oft wird von Neulingen der Fehler gemacht, eine Anweisung 

wie *(iteration_ptr + 5) nicht zu klammern, also stattdessen 

*iteration_ptr + 5 hinzuschreiben. Diese zwei Statements haben allerdings 

eine grundverschiedene Bedeutung: 

*(iteration_ptr + 5) bedeutet, dass zuerst der Pointer um 5 Elemente 

versetzt wird und danach der dort gespeicherte Wert dereferenziert wird. 

*iteration_ptr + 5 bedeutet im Gegensatz dazu, dass zuerst der Pointer 

dereferenziert wird und danach zu diesem Wert 5 addiert wird.


Zeile 44: Egal, ob man ein einzelnes Element oder ein Array anfordert, man 

muss sich um die Freigabe des Speichers kümmern, wenn er nicht mehr 

gebraucht wird. Und hier besteht ein kleiner Unterschied zwischen einem 

dynamisch angeforderten Einzelelement und einem Array: Bei einem Array 

muss der delete[] Operator aufgerufen werden, wie in Zeile 44 zu 

sehen. 

Vorsicht Falle: Nicht nur von Neulingen wird oft der Unterschied zwischen 

delete und delete[] ignoriert. Dies geht auch zumeist ohne 

gröbere Probleme ab, jedoch kann das nicht garantiert werden! Hinter 

den beiden Formen von delete verstecken sich nämlich tatsächlich 

verschiedene Implementationen, die auch von den Entwicklern selbst im 

Zuge eines Overloadings geschrieben sein könnten. 

Deshalb möchte ich hier eine sehr eindringliche Warnung aussprechen, 

auch wenn mancherorts in der Literatur (unrichtigerweise) Gegenteiliges 

behauptet wird: delete und delete[] sind nicht äquivalent 

und dürfen auch nicht als äquivalent angesehen werden, obwohl 

sie sich oberflächlich von außen betrachtet gleich zu verhalten 

scheinen. Durch die Verwendung von delete wird das Freigeben 

eines Einzelelements veranlasst, durch die Verwendung von 

delete[] wird das Freigeben eines Arrays veranlasst. Wo auch 

immer ein einfaches new verwendet wird, muss der Speicher 

auch mit einem einfachen delete freigegeben werden. Bei Verwendung 

eines new ...[...] muss der Speicher auch mit einem 

delete[]freigegeben werden. 

Vorsicht Falle: Genauso, wie man nicht feststellen kann, wie viel Speicher 

allokiert wurde, lässt sich auch nicht feststellen, ob nun ein Array 

oder nur ein Einzelelement allokiert wurde. Das bedeutet, dass man ohne 

selbst gemerkte Zusatzinformation zur Laufzeit nicht mehr herausfinden 

kann, welche der delete Varianten man nun nehmen muss. 

Vorsicht Falle: Nicht nur Neulinge sitzen manchmal einem folgenschweren 

Irrtum auf: Ob etwas nun für den Compiler bzw. zur Laufzeit ein Array 

darstellt oder nicht, ist durch die Art der Anforderung bestimmt, 

nicht durch die Anzahl der Elemente! Auch wenn new int32[1] nur 

Speicher für ein Element liefert, stellt das Ergebnis doch ein dynamisches 

Array dar und muss mit delete[] gelöscht werden! Auch hier ist 

die Verwendung des einfachen delete nicht zulässig! 

Zeile 45: Hier treffen wir wieder Altbekanntes: Auch für Pointer, die ein 

dynamisches Array repräsentieren, gilt, dass sie nach Gebrauch auf 0 

gesetzt werden sollten.


Zeilen 51–56: Die Funktion show, die hier definiert, ist demonstriert die Austauschbarkeit 

von Pointer- und Array Variablen. Hier wird als erster 

Parameter ein Array entgegengenommen (const, denn wir wollen ja daran 

nichts ändern!). In Zeile 54 wird durch dieses Array einfach mittels 

Pointerarithmetik durchgegangen. 

Der Grund, warum ein Array-Parameter genommen wurde, liegt auf der 

Hand: Man will damit signalisieren, dass man den Parameter wie ein 

Array behandelt, auch wenn dieses eventuell nur die Länge 1 hätte. 

Der Grund, warum Pointerarithmetik trotzdem funktioniert, ist die bereits 

erwähnte Austauschbarkeit von statischen Arrays und Pointern, da 

auch ein statisches Array hinter den Kulissen als Pointer dargestellt wird. 

Der Ausdruck *array++ bedeutet: Dereferenziere zuerst den Pointer und 

liefere damit seinen Wert. Danach zähle den Pointer (nicht den Wert!!!) 

um ein Element weiter. Dadurch wird das Array Schritt für Schritt durchgegangen. 

Der Grund, warum eine Veränderung des Parameters array funktioniert, 

obwohl er durch const mit einem Schreibschutz versehen wurde, ist einfach: 

const bezieht sich auf den Inhalt, der sich hinter dem Pointer 

verbirgt, nicht auf die Pointervariable, die ja nur eine Kopie der Adresse 

enthält (call-by-value!). Wollte man einem Element des übergebenen Arrays 

einen neuen Wert zuweisen, dann würde sich natürlich der Compiler 

beschweren. 

6.2.3 Strings 

In C ++ werden, gleich wie in C, Strings einfach durch statische oder dynamische 

char Arrays repräsentiert. Eine besondere Eigenschaft von Strings 

ist hierbei allerdings wichtig: Sie müssen immer mit einem ’\0’ Character 

abgeschlossen werden! 

Im Prinzip war das auch schon alles, was es dazu zu sagen gibt und ich 

halte mich derzeit noch bewusst bedeckt mit weiteren Ausführungen und 

einem Demoprogramm dazu, denn gerade Strings sind eine der ganz typischen 

Anwendungen, bei denen uns durch die Objektorientiertheit von C ++ 

die Arbeit deutlich erleichtert wird und die Gefahr von Fehlern deutlich verringert 

wird. Eine saubere, zeitgemäße OO-Repräsentation von Strings wird 

in Abschnitt 16.5 besprochen. 

6.2.4 Funktionspointer 

Wie bereits erwähnt wurde, kann man mit Pointern nicht nur auf Daten 

zugreifen, sondern man kann auch Pointer auf Funktionen zeigen lassen. Auf 

Umweg über solche Pointer kann man diese Funktionen dann aufrufen. 

Funktionspointer sind allerdings nicht ganz ungefährlich. Genau deswegen 

möchte ich hier nur erwähnen, dass es Funktionspointer gibt, dass jedoch


durch die Objektorientierung von C ++ im Gegensatz zu C nur noch sehr wenige 

Einsatzgebiete derselben existieren. Es gibt viel sauberere Konstrukte, 

die dieselbe Aufgabe erfüllen. Salopp gesagt sollte man eigentlich im normalen 

Entwicklungsalltag die Finger von Funktionspointern lassen. Deshalb 

wurde die Diskussion über sie auch sehr weit nach hinten verlegt, nämlich in 

Abschnitt 15.3 :-). 

6.2.5 Besondere Aspekte von Pointern 

Pointer sind prinzipiell mit einem hohen Fehlerrisiko verbunden, aber sie sind 

aus vielerlei Gründen in C ++ nicht wegzudenken. Was auch immer bisher zu 

Pointern gesagt wurde und in der Folge noch gesagt wird, gehört zum täglichen 

Brot von C ++ Entwicklern. Allerdings möchte ich an dieser Stelle noch 

unbedingt darauf hinweisen, dass im OO-Teil des Buchs einige Möglichkeiten 

besprochen werden, wie man potentielle Fehlerquellen eliminieren kann, indem 

man Pointer sauber in Classes kapselt, anstatt sie “wild” im laufenden 

Programmcode zu verwenden. Trotz aller Warnungen möchte ich trotzdem 

alle Leser dazu motivieren, sich mit Pointern ausgiebig zu spielen, denn dies 

ist die beste Möglichkeit, ein gutes Gefühl dafür zu bekommen. Es sollten 

jedoch die derzeitigen “Spielereien” der Leser nicht in wichtigen (also produktmäßigen) 

Programmcode einfließen. Ok, genug gewarnt, kommen wir 

wieder zurück zum Thema der besonderen Aspekte von Pointern. 

Call-by-reference auf Pointer. Auch Pointervariablen können natürlich 

Teilnehmer an einem call-by-reference sein, der den Inhalt des Pointers selbst, 

also die Adresse auf die er zeigt, nachhaltig verändert. Wie das typisch 

für C ++ mittels References gelöst wird, sieht man an folgendem Programm 

(ptr_call_by_ref_demo.cpp): 

1 // p t r c a l l b y r e f d e m o . cpp − c a l l by r e f e r e n c e with p o i n t e r s 

2 



5 



8 

9 void assignClone ( int32 ∗& dst , const int32 s r c [ ] , uint32 length ) ; 

10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


13 { 

14 const uint32 ARRAY LENGTH = 10; 

15 int32 ∗ s r c a r r a y = new int32 [ARRAY LENGTH] ; 

16 int32 ∗ d s t a r r a y = 0; 

17 

18 for ( uint32 count = 0; count < ARRAY LENGTH; count++) 

19 s r c a r r a y [ count ] = count ; 

20 

21 assignClone ( d s t a r r a y , s r c a r r a y ,ARRAY LENGTH) ; 

22 

23 int32 ∗ s r c i t e r a t i o n p t r = s r c a r r a y ; 

24 int32 ∗ d s t i t e r a t i o n p t r = d s t a r r a y ;

25 for ( uint32 count = 0 ; count < ARRAY LENGTH; count++) 

26 cout


4. src wird um ein Element weitergerückt. 

5. dst wird um ein Element weitergerückt. 

Und nun zum negativen Aspekt... 

Vorsicht Falle: Weil wir es bei dst mit einer Reference zu tun haben, 

dürfen wir diese natürlich niemals direkt bei unseren Kopierschritten in Zeile 

49 verwenden. Damit würden wir nämlich auch die Adresse im Original 

nachhaltig verändern (was ja in einem anderen Zusammenhang, nämlich bei 

der Zuweisung des angeforderten Speichers, erwünscht ist). Also müssen wir 

eine lokale Kopie davon machen, was in Zeile 47 passiert. 

Vorsicht Falle: Noch etwas wird bei solcherlei Konstrukten leider nur viel zu 

gern vergessen: Der Speicher, der in der Funktion assignClone angefordert 

wird, muss natürlich auch irgendwo wieder freigegeben werden, wenn er nicht 

mehr gebraucht wird. Dass das nur irgendwo beim Aufrufer stattfinden kann, 

ist auch klar. Dass das aber wirklich unbedingt auch dort stattfinden muss, 

wird gerne einfach unter den Tisch gekehrt... natürlich nur in Programmen 

anderer Leute :-). Bei uns wird explizit der Speicher für den Clone in Zeile 31 

wieder freigegeben. 

Die Zeile 36, in der beide eben freigegebenen Pointer auf 0 gesetzt werden, 

erscheint hier als Overkill. Jedoch tut die Zeile niemandem weh und 

außerdem kann es ja sein, dass durch eine spätere Programmänderung nach 

Zeile 33 noch einiges an Code dazukommt, der eventuell diese beiden Variablen 

irrtümlich versuchen würde zu verwenden, im Glauben, dass dahinter 

noch Speicher allokiert ist. Eine solche “unnötige” Zeile kann also eine wertvolle 

Zukunftsinvestition sein! 

Mehrfachpointer. Wie bereits bei Arrays gezeigt wurde, dass diese mehrdimensional 

sein können, so verhält es sich natürlich auch bei den Pointern. 

Um dies zu demonstrieren, schnappen wir uns einfach das letzte Demoprogramm 

und ändern es dergestalt ab, dass wir es mit einer Matrix zu tun 

haben (multi_ptr_demo.cpp): 

1 // multi ptr demo . cpp − a short demo f o r multi−p o i n t e r s 

2 



5 



8 

9 void assignClone ( int32 ∗∗& dst , const int32 ∗ const ∗ s r c , 

10 uint32 num rows , uint32 num cols ) ; 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


14 { 

15 const uint32 NUMROWS = 5;

16 const uint32 NUM COLS = 7; 

17 


18 int32 ∗∗ src matrix = new int32 ∗ [NUMROWS] ; 

19 for ( uint32 row count = 0; row count < NUMROWS; row count++) 

20 { 

21 src matrix [ row count ] = new int32 [NUM COLS] ; 

22 for ( uint32 col count = 0; col c o unt < NUM COLS; col c o unt++) 

23 src matrix [ row count ] [ col count ] = 

24 ( ( row count + 1) ∗ 100) + c o l c o unt + 1; 

25 } 

26 

27 int32 ∗∗ dst matrix = 0; 

28 

29 assignClone ( dst matrix , src matrix ,NUMROWS,NUM COLS) ; 

30 

31 for ( uint32 row count = 0; row count < NUMROWS; row count++) 

32 { 

33 for ( uint32 col count = 0; col c o unt < NUM COLS; col c o unt++) 

34 cout


für sich hält dann die Reihen. Bleiben wir aber bei unserer ersten Definition, 

denn diese wurde im Programm implementiert. 

In Zeile 18 wird einmal das Array angelegt, das die Reihen repräsentiert. 

Wenn man sich überlegt, dass eine Reihe quasi ein Array von int32 Werten 

ist, also ein int32* dann ergibt sich für die Reihen, dass diese vom Typ ein 

int32**, also ein Pointer auf (viele) Pointer auf int32 ist. 

In der äußeren Schleife, deren Kopf in Zeile 19 zu finden ist, wird für jede 

einzelne Reihe einmal ein Array angelegt, das die Werte halten kann, also die 

Spalten. Dies passiert in Zeile 21. In der inneren Schleife von Zeile 22–24 

werden nur noch den einzelnen Zellen Werte zugewiesen. 

Lassen wir kurz noch die Funktion außer Acht, die den Clone erzeugt und 

wenden wir uns den Zeilen zu, die den von der Matrix belegten Speicher dann 

auch wieder freigeben. Dies passiert immer von innen nach außen. Zuerst 

werden die einzelnen Reihen in einer Schleife freigegeben. Danach erst wird 

das Array freigegeben, das die einzelnen Reihen gehalten hat. Dass dies nur 

in dieser Reihenfolge geht, lässt sich leicht nachvollziehen, denn wenn man 

das äußere Array freigibt, dann hat man die Base-Pointer für die inneren 

Arrays damit verloren. 

Vorsicht Falle: Einer der ganz typischen Fehler von Neulingen ist es, anzunehmen, 

dass ein delete[] auf das äußerste Array automatisch auch die 

einzelnen inneren Arrays löscht, also quasi alles aufräumt. Dies ist keineswegs 

der Fall! Vergisst man, die einzelnen inneren Arrays zu löschen, dann 

erzeugt man ein tolles Programm, das nach genügend langer Laufzeit zu einem 

guten Test wird, wie sich ein Rechner verhält, dem langsam aber sicher 

der Speicher ausgeht :-). 

Wenn wir uns nun noch kurz der assignClone Funktion in Zeile 51 zuwenden, 

die im Prinzip genau nach dem Prinzip funktioniert, das bereits 

zuvor zum Anlegen der Matrix beschrieben wurde, dann fällt uns noch eine 

Besonderheit auf: Der zweite Parameter, also das src Array ist nun wirklich 

sehr komisch deklariert. Was um alles in der Welt soll der Ausdruck 

const int32 *const *src 

bedeuten? Überlegen wir einmal ganz kurz, was es z.B. mit einem Pointer 

auf einen int32 so auf sich hat. Im Prinzip sind ja daran zwei verschiedene 

Typen beteiligt, nämlich einerseits ein Pointer und andererseits der int32, 

auf den er zeigt. Um die volle Kontrolle zu haben, will man jeden Teil für 

sich konstant machen können oder auch nicht. Und genau dies ist in C ++ 

auch möglich, denn eine Variable 

const int32 *var; 

stellt einen (nicht konstanten) Pointer auf einen konstanten int32 dar. Dagegen 

stellt eine Variable 

int32 *const var;


einen konstanten Pointer auf einen (nicht konstante) int32 dar. Wenn man 

dies weiterspinnt, ist naturgemäß eine Variable 

const int32 *const var; 

ein konstanter Pointer auf einen konstanten int32. Genau so etwas brauchen 

wir hier, nur dass var selbst ein Array ist. Wir wollen ja einen Doppelpointer 

an die Funktion übergeben, bei dem weder die einzelnen Werte, die er hält, 

also die Reihen, noch die Werte, die von diesen gehalten werden, also die 

tatsächlichen Zellen, verändert werden können. Also haben wir es hier mit 

einem Pointer auf ein konstantes Array auf konstante Werte zu tun. 

Da ich weiß, dass viele Entwickler ein kleines Problem damit haben, const 

korrekt in komplizierteren Konstrukten einzusetzen, wie z.B. References auf 

Pointer-Variablen, etc. Deshalb hier ein kleiner Tipp: const ist linksbindend, 

soll heißen, es bezieht sich prinzipiell immer auf den links von ihm stehenden 

Teil des Typs. Dass man const auch quasi rechtsbindend verwenden kann, ist 

nur eine Konvention, die der verbesserten Lesbarkeit dienen soll. Sollte also 

nach dieser Konvention const ganz links stehen, so wird es so ausgewertet, 

als ob es rechts neben dem ersten Ausdruck vorkommen würde. Verwirrend? 

Kein Problem, mit einem kleinen Beispiel ist alles klar: 

Der Ausdruck 

const int32 *var 

ist äquivalent zu 

int32 const *var 

und sollte, wenn man ganz korrekt sein will, auch so geschrieben werden. 

Nur hat sich in Entwicklerkreisen über lange Zeit die erstere Schreibweise 

eingebürgert, deshalb möchte ich, wo es nicht notwendig ist, damit auch 

nicht brechen. 

Vorsicht Falle: Von Neulingen, aber auch leider von erfahreneren Entwicklern, 

werden immer wieder völlig unzulässige Annahmen über die Kompatibilität 

von Mehrfacharrays und Mehrfachpointern getroffen. Diese beiden 

Typen sind nicht notwendigerweise gegeneinander austauschbar, denn es 

gibt keine genaue Definition, wie mehrdimensionale Arrays nun intern speichermäßig 

organisiert sind. 

Vorsicht Falle: Eines sieht man am Beispiel mit den Mehrfachpointern sehr 

deutlich: Es ist wirklich nicht allzu schwierig, Fehler bei deren Behandlung 

einzubauen! Aus diesem Grund sind auch solche Konstrukte im laufenden Code 

von C ++ Programmen verpönt und sollten unbedingt durch entsprechende 

Classes ersetzt werden, die solches Verhalten kapseln. Zu diesem Thema 

werde ich im OO-Teil noch mehr als nur ein paar Worte verlieren :-). 

Pointer und Typecasts. Pointer halten per Definition einfach Adressen. 

Dass auch noch ein Typ mit angegeben wird, hat damit zu tun, dass man 

sie richtig behandeln will. Man will ja im Fall eines indizierten Zugriffs das


richtige Element erwischen und nicht einfach irgendein Byte. Selbiges gilt 

für die Pointerarithmetik, bei der auch elementweise und nicht byteweise 

gerechnet wird. 

Adressen sind immer gleich, denn dem Computer ist es vollkommen egal, 

ob eine Adresse nun auf einen int32, double oder sonst etwas zeigt. Die Interpretation 

bleibt dem Programm überlassen. Was sagt uns das? Nun, ganz 

einfach: Mittels Typecasts können wir sehr einfach eine Neuinterpretation 

des dahinterstehenden Werts erreichen. Allerdings hat der Compiler definitiv 

etwas dagegen, dass man einfach wild Pointer eines Typs Pointern eines 

anderen Typs zuweist, weil er ja die Gefahr der Fehlinterpretation kennt. Das 

Statement 

uint8 *my_ptr = your_ptr; 

wird vom Compiler nur dann übersetzt, wenn auch your_ptr ein uint8 * ist. 

Ist er das nicht, sondern z.B. ein int32 *, dann quittiert das der Compiler 

mit einer netten Meldung, dass man doch aufpassen soll, was man tut. Es 

wird von einem C ++ Compiler z.B. nicht einmal ein impliziter Cast zwischen 

einem char*, unsigned char* und einem signed char* durchgeführt, da ja 

nicht definiert ist, ob nun ein char signed oder unsigned ist. 

Wie allerdings schon bekannt ist, gibt es Mittel und Wege, den Compiler 

zu überreden, gewisse Dinge zu akzeptieren, nämlich entsprechende Casts. 

Im Prinzip kann man damit fast beliebigste Neuinterpretationen erzwingen, 

nur muss man wirklich ganz genau wissen, was man macht! Sehen wir uns 

einfach einmal ein Standardbeispiel an, das zeigt, wie man zu den einzelnen 

Bytes eines “größeren” Ganzzahlenwertes, also z.B. eines int32 kommt 

(bytes_of_int32_demo.cpp): 

1 // bytes of int32 demo . cpp − e x t r a c t the s i n g l e bytes o f an int32 

2 



5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


11 { 

12 int32 num for extraction = 4; 

13 uint8 ∗ i n t 3 2 i t e r a t o r = 

14 reinterpret cast(&num for extraction ) ; 

15 for ( uint32 count = 0; count < 4; count++) 

16 cout


Auf einer Sun würde die Reihenfolge der Bytes genau umgekehrt sein. Dies 

hängt mit den internen Architekturen dieser Rechner zusammen, denn einem 

Intel liegt eine little Endian und einer Sun eine big Endian Byte Order 

zugrunde. 

Ich möchte mich hier nicht näher über little- und big Endian auslassen, wohl 

aber möchte ich erwähnen, dass dieses Wissen sehr wichtig sein kann! Leser, 

die mit diesen Begriffen nichts anfangen können, möchte ich auf Kapitel 13 

von Softwareentwicklung in C verweisen, wo ein sehr ähnliches Beispiel mit 

genauerer Erklärung gebracht wird. 

Nach diesem kleinen Exkurs in die Prozessorarchitekturen zurück zum eigentlichen 

Thema, nämlich dem Erzwingen einer anderen Interpretation eines 

Datums als der, die der Typ eigentlich vorgeben würde. Wir haben bereits 

den reinterpret_cast kennen gelernt und dabei erfahren, dass durch diesen 

eine Neuinterpretation “ohne Rücksicht auf Verluste” und ohne jeglichen 

Umwandlungsversuch von Seiten des Compilers stattfindet. Das machen wir 

uns in den Zeilen 13–14 zunutze, denn dort erzwingen wir eine Neuinterpretation 

eines int32* als uint8*. Dies bedeutet intern, dass die Adresse, 

die die Variable int32_iterator hält auf num_for_extraction zeigt. Allerdings 

wird der Inhalt dieser Speicherstelle nicht als int32 interpretiert, 

sondern als uint8. Das bedeutet, dass nur ein einziges Byte genommen und 

als uint8 interpretiert wird anstatt aller 4 Bytes, die gemeinsam die Variable 

num_for_extraction ausmachen. 

Wenn man nun also in einer Schleife, wie in den Zeilen 15–18 gezeigt, die 

4 Bytes des int32 hintereinander ausliest, dann hat man genau das erreicht, 

was man wollte. Natürlich ist in Zeile 17 wieder ein static_cast des uint8 

auf uint32 notwendig, denn ansonsten würde keine Zahl, sondern irgendein 

kryptischer Character am Bildschirm dargestellt werden. 

Es gibt genügend Fälle, bei denen zur Compiletime noch gar nicht bekannt 

ist, welcher Pointertyp dann zur Laufzeit als Parameter an eine Funktion 

übergeben wird. Im OO-Teil werden uns solche mehrfach begegnen. 

Jetzt wissen wir aber, dass der Compiler beim impliziten Umwandeln recht 

restriktiv ist und uns damit das Leben schwer machen kann, welchen Parametertyp 

wir denn jetzt eigentlich für unsere Funktion deklarieren. Dafür gibt 

es in C ++ einen ganz besonderen untypisierten Pointer, nämlich den void *. 

Dieser Pointertyp ist so definiert, dass jeder beliebige Pointer vom Compiler 

ohne Fehlermeldung oder Warning implizit in ihn umgewandelt werden kann. 

In unserer Funktion können wir dann zur Laufzeit (sofern wir wissen, womit 

wir zu tun haben :-)) mittels eines reinterpret_cast wieder die gewünschte 

Interpretation herstellen. 

Dass ohne expliziten Cast bei einem void * keine Index-Operationen und 

auch keine Pointerarithmetik möglich sind, versteht sich von selbst. Diese 

Operationen sind ja so definiert, dass sie immer auf Elementbasis und nicht 

auf Bytebasis rechnen. Wenn man aber nicht weiß, welches Element sich


dahinter versteckt, dann kann man auch nicht rechnen. Entsprechend wird 

sich der Compiler bei einem Versuch der Anwendung von Pointerarithmetik 

oder Indizierung auf einen void * beschweren. Ebenso verhält es sich mit 

delete: Es ist nicht auf einen void * aufrufbar. Die Gründe dafür werden 

in Abschnitt 10.2.3 noch kurz erläutert. 

Vorsicht Falle: Das Spielchen mit dem Erzwingen der Neuinterpretation 

mittels reinterpret_cast kann man nicht nur bei Pointern spielen, sondern 

sogar unglückseligerweise zwischen Pointern und Ganzzahlentypen. Ist im 

Prinzip auch irgendwie logisch, denn eine Adresse ist ja auch nur irgendeine 

Ganzzahl. Nur leider funktioniert das mit dem Cast zwischen z.B. int 

und Pointern nicht so toll, denn wer garantiert uns, dass ein int auf einer 

bestimmten Plattform gleich lang ist, wie ein Pointer? Leider gibt es immer 

noch ziemlich viel (zumeist historische) Software, die diese Annahme einfach 

als gegeben hinnimmt. Allerdings ist das grundfalsch! 

Deshalb ist es unbedingt notwendig, folgende Regel einzuhalten: Es darf 

niemals zwischen einem Pointer und einem, wie auch immer gearteten 

Ganzzahldatentyp, z.B. int gecastet werden! Dies ergibt nämlich 

unter Garantie Software mit einer wunderbar einprogrammierten Zeitbombe.

7. Der Preprocessor 

In C ++ kommt dem Preprocessor eine viel kleinere Rolle zu, als dies noch in C 

der Fall war. Viele alltägliche Dinge, die noch in C mit Preprocessor Macros 

erledigt werden mussten, sind in C ++ in der Sprache selbst enthalten, z.B. 

Konstanten, inline Funktionen, etc. Es hat auch sehr gute Gründe, warum 

diese Konstrukte in die Sprache selbst Einzug gehalten haben. Deshalb muss 

ich gleich vorausschicken, dass man auf Preprocessor Macros nur so spärlich 

wie möglich zurückgreifen sollte, um nicht die Robustheit und Wartbarkeit 

des Codes aufs Spiel zu setzen. 

Prinzipiell ist der Preprocessor etwas ganz Einfaches: 

• Er ist ein eigenes Programm, das vor dem Compiler aufgerufen wird. 

• Der Preprocessor geht den Source durch und nimmt in ihm textuelle 

Ersetzungen nach gewissen Regeln vor. Der Output des Preprocessors ist 

selbst C ++ Source-Code, der dann dem Compiler zur Übersetzung gegeben 

wird. 

• Der Preprocessor weiß nichts über Typen, Scope, Lifetime und andere sprachimmanente 

Regeln von C ++. Aus diesem Grund entstehen auch Probleme 

mit der Robustheit und Wartbarkeit von Code, wenn man sich unnötig 

auf Spielchen mit Preprocessor Macros einlässt. 

Anweisungen, die für den Preprocessor gedacht sind, beginnen immer mit einem 

# in der ersten Spalte einer Zeile. Ein Beispiel für eine solche Anweisung 

ist die 

#include 

Anweisung, die wir bereits verwendet haben. Auffällig bei dieser Anweisung 

ist, dass sie nicht durch einen Strichpunkt abgeschlossen wird. Auch dies ist 

eine Eigenheit des Preprocessors: Preprocessor Anweisungen werden nicht 

mit einem Strichpunkt abgeschlossen, sondern enden mit dem Ende der Zeile! 

Sollte eine Anweisung zu lang werden, sodass man einen Zeilenumbruch 

machen will oder muss, so funktioniert das, indem man den Zeilenumbruch 

“escaped”. Dies geschieht durch einen Backslash als letztes Zeichen der Zeile. 

In der Folge werden die Features des Preprocessors genauer beleuchtet, 

die man im Programmieralltag braucht. Auf besondere Anweisungen, die 

z.B. erlauben, inline Assemblercode einzubinden oder die besondere compilerspezifische 

Dinge veranlassen (Stichwort #pragma), wird bewusst verzichtet. 

Erstens sind diese Anweisungen abhängig vom verwendeten Compiler

136 7. Der Preprocessor 

und der Zielplattform, zweitens sollte man sie wirklich nur in sehr speziellen 

Fällen verwenden, die im “normalen” Alltag eines Softwareentwicklers 

außerordentlich selten vorkommen. 

Leser, die bisher noch gar nichts mit dem Preprocessor in C zu tun hatten, 

möchte ich an dieser Stelle kurz auf Kapitel 16 von Softwareentwicklung in C 

hinweisen. 

7.1 Include Files 

Die Preprocessor Anweisung zum Einfügen von Include Files haben wir bereits 

gleich zu Beginn des Buchs kennen gelernt und durchgehend in unseren 

Programmen verwendet: 

#include file_identifier 

Statt dem Begriff des Files habe ich hier absichtlich den Begriff 

file_identifier verwendet, denn wir haben es hier mit zwei verschiedenen 

Formen zu tun, wie man Files einfügt. Einerseits gibt es die sogenannten 

System Headers, also solche, die im Suchpfad des Compilers gefunden werden. 

Zu diesen gehören in jedem Fall alle Standard Headers für eine Plattform. 

Je nach Projekt kann man natürlich auch eines der Projekt Include- 

Subdirectories in den Suchpfad aufnehmen. Damit werden die dort enthaltenen 

Headers auch als System Headers gefunden. Neben diesen Headers 

gibt es auch noch die Project Headers, also solche, die nicht im Suchpfad des 

Compilers stehen. 

Folgende Konventionen gibt es für die entsprechenden #include Anweisungen: 

System Headers: Diese werden inkludiert, indem man den Filenamen des 

Headers in spitze Klammern einfasst. Außerdem ist in C ++ die Konvention, 

dass man bei System Headers die Extension .h nicht angibt, 

wie bereits in Abschnitt 2.3 genauer erklärt wurde. Die Anweisung 

#include 

bewirkt also ein Einfügen des Files iostream aus dem Suchpfad des Compilers 

an der Stelle im File, an der das #include Statement steht. Es ist 

allerdings nicht gesagt, dass das File einfach nur iostream heißt, obwohl 

dies zumeist der Fall ist. Der Compiler könnte auch intern mit Headers 

mit beliebigen Extensions arbeiten, die er selbst verwaltet. 

Project Headers: Diese werden inkludiert, indem man den Filenamen des 

Headers in doppelte Anführungszeichen einfasst. Bei diesen Headers darf 

die Extension .h nicht weggelassen werden. Auch dazu kennen wir bereits 

einen Kandidaten: 

#include "user_types.h" 

bewirkt also ein Einfügen des Files user_types.h an der Stelle im File, 

an der das #include Statement steht. Project Headers werden immer

7.2 Bedingte Übersetzung 137 

im aktuellen Subdirectory gesucht und unterliegen nicht der Suche im 

Systempfad. 

Wie bereits erwähnt, nimmt der Preprocessor einzig und allein textuelle Ersetzungen 

vor. Das bedeutet also, dass tatsächlich an der Stelle, an der 

eine #include Anweisung steht, das inkludierte File textuell eingesetzt wird. 

Dadurch ergibt sich zweierlei: 

1. Unnötige #include Anweisungen sind zu vermeiden, da sie die Compiletime 

sehr verlängern können. 

2. In Headers dürfen ausschließlich Deklarationen vorkommen, da bei Definitionen 

die Gefahr der duplicate Definition besteht. Solche dürfen nur 

in .cpp Files vorkommen, die dann zum Programm dazugelinkt werden. 

7.2 Bedingte Übersetzung 

Der Preprocessor unterstützt auch drei verschiedene Anweisungen zum Überprüfen 

von Bedingungen: 

#if constant 

true-code 

#else 

false-code 

#endif 

Mit dieser Anweisung wird die Zahlenkonstante constant auf einen Wert ungleich 

0 überprüft. Falls dies zutrifft, wird der Code im Programm belassen, 

der oben durch true-code bezeichnet ist und false-code wird entfernt. Falls 

dies nicht zutrifft, dann wird true-code entfernt und false-code wird im Programm 

belassen. Das #else und false-code sind optional, #endif ist allerdings 

unbedingt vonnöten, um das Ende der #if Anweisung anzuzeigen. Die 

Anweisung 

#ifdef identifier 

true-code 

#else 

false-code 

#endif 

überprüft, ob das Preprocessor Macro identifier bereits definiert wurde (siehe 

unten). Wenn ja, bleibt true-code im Programm, ansonsten false-code. 

Auch hier wieder ist der #else Zweig optional. Analog dazu verhält sich die 

Anweisung 

#ifndef identifier 

true-code 

#else 

false-code 

#endif

138 7. Der Preprocessor 

Hier wird allerdings überprüft, ob identifier noch nicht definiert wurde. 

Die letzte Anweisung wird auch verwendet, um Headers vor unbeabsichtigter 

Doppelinklusion und daraus resultierenden Fehlermeldungen des Compilers 

zu schützen. Header-Files sollten immer durch die folgenden Preprocessor 

Anweisungen eingefasst sein: 

#ifndef filename_h___ 

#define filename_h___ 

... complete code of header ... 

#endif 

Hier steht filename_h___ für den spezifischen Namen des Headers. Im Fall 

unseres Files user_types.h würde also das entspechende Konstrukt folgendermaßen 

aussehen: 

#ifndef user_types_h___ 

#define user_types_h___ 

... complete code of header ... 

#endif 

7.3 Macros 

Die Macros werden hier absichtlich an letzter Stelle bei der Behandlung des 

Preprocessors erwähnt, da sie in C ++ nur noch eine untergeordnete Bedeutung 

besitzen. Prinzipiell gibt es drei Arten von Macros. Eine einfache 

Definition eines Identifiers haben wir bereits zuvor kennen gelernt, nämlich 

die Anweisung 

#define user_types_h___ 

Diese bewirkt, dass ein Identifier namens user_types_h___ definiert wird. 

Dieser ist dann mit #ifdef bzw. #ifndef überprüfbar. Neben dieser einfachen 

Definition eines Identifiers gibt es auch die Definition von nicht parametrisierten 

Macros. Z.B. definiert die Anweisung 

#define MAX_LENGTH 255 

eine Constant namens MAX_LENGTH, die den Wert 255 besitzt. Überall im 

Code, wo der Compiler auf eine Verwendung von MAX_LENGTH stößt, wird 

diese textuell durch den Wert 255 ersetzt. Allerdings ist diese Art der Konstantendefinition 

in C ++ verpönt, denn es gibt das typensichere Konstrukt 

der const Variablen, die stattdessen verwendet werden sollen. 

Weiters gibt es auch noch die Möglichkeit, parametrisierte Macros zu 

definieren. Z.B. wird durch 

#define SWAP(a,b) { int swap = a; a = b; b = swap; } 

ein Macro, das das Vertauschen zweier Variableninhalte veranlasst. Jedoch 

wird auch von dieser Verwendung von Macros in C ++ abgeraten, da es das 

typensichere Konstrukt der inline Funktionen als Alternative gibt. 

Vorsicht Falle: Das zuvor gezeigte SWAP Macro ist sogar recht bösartig, 

denn wenn man die Klammerung der Ausdrücke zu einem Block vergisst,

7.3 Macros 139 

dann kann man nette Überraschungen erleben! Lesern, denen nicht geläufig 

ist, warum dies der Fall ist, möchte ich wärmstens die Lektüre von Abschnitt 

16.1.2 aus Softwareentwicklung in C ans Herz legen!

Teil II 

Objektorientierte Konzepte von C++

8. Objektorientierung Allgemein 

Ich habe ganz bewusst bisher im Buch kein umfangreicheres Beispiel besprochen, 

da die wichtigsten Features, die C ++ eigentlich erst ausmachen, in der 

Objektorientierung der Sprache liegen. Um nicht manche Leser dazu anzuregen, 

imperatives C ++ zu programmieren anstatt sauberes, echt objektorientiertes 

C ++, wollte ich mit einem größeren Beispiel abwarten, bis zumindest 

die wichtigsten OO-Konstrukte von C ++ bekannt sind. 

Eines möchte ich gleich vorausschicken: Zu wissen, wie man Klassen und 

Objekte definiert und wie man technisch gesehen damit arbeitet, macht noch 

lange keine Objektorientierung! Objektorientierung ist ein Denkmodell, das 

von C ++ unterstützt wird. Durch diese Unterstützung kann man ein sauberes 

OO-Design auch elegant in C ++ implementieren. Das bedeutet aber keineswegs, 

dass Code, der irgendwelche OO-Features verwendet, auch wirklich 

sauberer objektorientierter Code ist! 

Genau aus diesem Grund finde ich es wichtig, erst einmal die Grundgedanken 

der Objektorientierung zu diskutieren und Beispiele dafür zu bringen, 

bevor wir überhaupt dazu kommen, wie diese Grundgedanken von der Sprache 

unterstützt werden. Keine Aktivität im gesamten Entwicklungszyklus 

beeinflusst ein Produkt so stark, wie das Erstellen der Architektur und des 

Designs. Im Prinzip ist dies eine Binsenweisheit, wenn man sich überlegt, 

wie seit Jahrtausenden Bauwerke entstehen: Zuerst wird ein Plan gemacht, 

der die Basis für das Bauwerk darstellt. Der Plan ergibt sich daraus, dass die 

Anforderungen für ein Bauwerk in puncto Platzbedarf, Verwendungszweck, 

Stabilität, u.v.m. in eine Architektur umgesetzt werden. Die Ästhetik des 

Bauwerks ist ein direktes Produkt aus seinem Design mit den gegebenen 

Randbedingungen. Erst wenn der Plan gezeichnet und baustatische Berechnungen 

erfolgreich verlaufen sind, wird mit dem tatsächlichen Bau begonnen. 

Die gesamte Struktur des Bauwerks steht zu diesem Zeitpunkt vollständig 

fest! 

Software steht vom Komplexitätsgrad einem Bauwerk in keinster Weise 

nach. Wieso also wird hier genau die wichtigste Phase des Designs und 

des Entwurfs der Architektur so oft nur äußerst rudimentär durchgeführt? 

Eine mögliche Antwort und für mich bisher die einzig logische Erklärung ist 

folgende:

144 8. Objektorientierung Allgemein 

Dadurch, dass man beim Schreiben eines Programms mit Text zu tun 

hat, den man in den Computer eintippt und den man nach Bedarf ändern 

kann, wird suggeriert, dass Änderungen problemlos sind und dass man jederzeit 

fehlende Teile ergänzen und fehlerhafte Teile ausbessern kann. Beim 

Bau eines Gebäudes ist jedem klar, dass es nachträglich nicht möglich ist, 

einfach mitten aus dem Gebäude ein Stockwerk herauszunehmen und durch 

ein anderes zu ersetzen. 

Jedoch wird bei Betrachtungen zur leichten Änderbarkeit von Software 

ein Faktum übersehen: Bei einem Computerprogramm verhält es sich nicht 

grundlegend anders als bei einem Gebäude! Will man an einem Konzept eines 

Programms etwas ändern, dann sind nicht einfach nur ein paar Zeilen Text 

auszubessern! Es kann passieren, dass sich eine Konzeptänderung durch ein 

gesamtes Programm zieht! Hat man also beim Entwickeln die Planung vernachlässigt, 

so passiert es nur allzu oft, dass am Fundament etwas geändert 

werden muss, wodurch man alles destabilisiert, was auf dem “alten” Fundament 

aufbaut. Führt man die Änderung nicht durch, ist das Fundament 

auch instabil, denn die notwendige Änderung wurde ja nicht einfach zum 

Spaß erfunden. Somit kommt man in ein Dilemma, aus dem sich so leicht 

kein Ausweg finden lässt, denn ein komplettes Redesign und ein Neuaufbau 

der bisher existierenden Software wäre oftmals die einzig sinnvolle Lösung, 

ist aber mitunter viel zu zeitaufwändig. 

Jede Applikation, die man entwickelt, besteht aus vielen verschiedenen 

Abstraktionsschichten. Die oberste Schicht ist diejenige, die die Anwender 

zu sehen bekommen. Betrachten wir diese oberste Schicht einmal als die 

tatsächliche Applikation (z.B. eine Textverarbeitung) und betrachten wir die 

darunter liegenden Schichten als deren Fundament (z.B. Datenspeicherung, 

Netzwerk-Kommunikation, etc.). Bleiben wir weiters beim nahe liegenden 

Vergleich zwischen Software und Gebäuden. Dann würde sich sauber entworfene 

Software mit klarer und in sich abgeschlossener Architektur ähnlich 

wie in Abbildung 8.1 visualisieren lassen, wobei die einzelnen Kästchen für 

die entworfenen Module stehen. 

Applikation 

Abbildung 8.1: Saubere und robuste Softwarearchitektur

8. Objektorientierung Allgemein 145 

Jedoch liegt nur allzu vielen Softwarepaketen diese saubere Architektur 

nicht zugrunde (auch wenn nur die Allerwenigsten dies zugeben)! Die Architektur 

einer Lösung, bei der in der Designphase gespart wurde und die daher 

entsprechend viele kleine und größere Konzeptänderungen während der Entwicklung 

erfahren hat, mutiert zu einem instabilen Monster, bestehend aus 

wild angeordneten Pseudo-Modulen, wie es in Abbildung 8.2 skizziert ist. 

Applikation 

Abbildung 8.2: Mangelhafte (oft reale!) Softwarearchitektur 

Ich würde wirklich nur allzu gern sagen, dass Abbildung 8.2 nur Polemik 

meinerseits ist und dass ich hier die Realität stark überzeichnet habe. Leider 

aber ist das nicht der Fall, manchmal ist es sogar noch etwas schlimmer. Sogar 

sehr namhafte Softwarefirmen produzieren teure Lösungen, deren Architektur 

genau wie in Abbildung 8.2 dargestellt aussieht. Und das trotz aller ISO- und 

anderer Qualitätsrichtlinien, die sie sich auf die Fahnen heften. 

Nun stellt sich natürlich die Frage, wie man es besser machen kann und 

wie man verhindern kann, dass es zu solchen Auswüchsen kommt. Ich kann 

hier nur raten, wirklich ausreichend viel Zeit auf die Design- und Architekturphase 

zu verwenden und diese Phase erst abzuschließen, wenn das Design 

vollkommen schlüssig ist und keine Fragen mehr offen lässt. Weiters ist zum 

Erstellen eines guten Designs auch sehr viel Erfahrung nötig. Um diese zu 

sammeln, braucht man viel Zeit und der Weg dorthin ist oft ein steiniger. 

Häufig wird man Designs verwerfen müssen, weil sie nicht tragfähig sind, 

aber das liegt in der Natur eines jeden Lernprozesses. Ich kann in der Folge 

die Grundprinzipien des OO-Designs so abhandeln, wie ich glaube, dass 

sie am leichtesten verständlich und nachvollziehbar sind. Damit können Leser, 

die sich bisher noch nicht allzu ausführlich mit OO-Design beschäftigt 

haben, die ersten Einstiegshürden leichter meistern. Ich möchte jedoch alle 

Leser bitten, eines im Hinterkopf zu behalten: Es gibt keine Kochrezepte, 

die man einfach befolgen kann und die zwingend zu einem guten Ergebnis 

führen! Der Entwurf einer sauberen Architektur ist der schwierigste und


kreativ anspruchsvollste Prozess im gesamten Zyklus der Softwareentwicklung 

und gehört entsprechend lang und sorgfältig geübt! 

8.1 Module und Abläufe 

Der wichtigste Teil, der ganz am Anfang des Designprozesses steht und sich 

in verschiedenen Ausprägungen durch den Prozess zieht, ist das Erfassen des 

Problems mit all seinen Abläufen und Randbedingungen. Schafft man es, 

ein Problem so lange in immer allgemeinere Gruppen von Teilproblemen zu 

zerlegen, bis man auf einer vollkommen abstrakten Ebene angekommen ist, 

hat man eine gute Chance, dass das Konzept tragfähig ist und dass man 

das gesamte System sehr sauber in Module zerlegen kann. Sehr oft gibt es 

vor allem bei Neulingen Probleme, einen Prozess wirklich vollständig zu 

beschreiben und gleichzeitig auf einer Abstraktionsebene zu bleiben. Ich 

möchte an dieser Stelle keine lange theoretische Abhandlung über diese Prinzipien 

schreiben und ich möchte vor allem nicht formal oder technisch werden 

und mich schon gar nicht auf eine Programmiersprache festlegen. Stattdessen 

möchte ich einfach an einem völlig alltäglichen Beispiel die Phase der Analyse 

der Abläufe und der Identifikation von Modulen demonstrieren. Bevor ich 

dazu komme noch ein Tipp an alle Leser: Alles, was in der Folge beschrieben 

wird, klingt unglaublich banal, wenn man einfach jetzt nur weiterliest. 

Dass es banal klingt, wenn man das Ergebnis liest, bedeutet aber keineswegs, 

dass der Weg zu diesem Ergebnis ebenso banal ist! Mein Ratschlag 

wäre, das folgende Beispiel zuerst selbst einmal mittels Papier und Bleistift 

durchzuspielen und dann das Ergebnis mit dem hier abgedruckten zu vergleichen. 

Mit ein wenig Selbstkritik werden sicherlich einige Leser erkennen, 

dass sie bei der Analyse etwas vergessen haben, Abstraktionsebenen nicht 

eingehalten haben (soll heißen, im Detailliertheitsgrad der Beschreibung unregelmäßig 

arbeiten) oder vielleicht sogar falsche Annahmen über die Natur 

gewisser Gegebenheiten getroffen haben. 

8.1.1 Der Weg zum Arbeitsplatz – ein kleines Beispiel 

In diesem Abschnitt soll ein ganz einfacher Prozess analysiert werden und 

alle Beteiligten (Personen und Dinge) sowie die Zusammenhänge zwischen 

ihnen herausgearbeitet werden. Der einfache Prozess, um den es geht, ist 

ein typischer Ablauf, den die meisten Leser täglich hinter sich bringen: Der 

Beginn eines Arbeitstages, vom Klingeln des Weckers weg bis zur Ankunft am 

Arbeitsplatz. 

Ein erster schneller Durchgang liefert uns einmal eine ganz grobe Beschreibung 

der Beteiligten und Abläufe: 

1. Der Wecker geht ab und weckt (hoffentlich :-)) die arbeitswütige Person 

viel zu früh am Morgen auf.

8.1 Module und Abläufe 147 

2. Die aufgeweckte Person versucht verzweifelt, den lästigen Wecker abzustellen 

und schafft dies auch nach einigen kleineren Fehlschlägen. 

3. Mit langsamen, vorsichtigen Bewegungen steigt die mittlerweile gar nicht 

mehr so arbeitswütige Person aus dem Bett und tappt in Richtung Badezimmer. 

4. Im Badezimmer findet die allmorgendliche Prozedur statt, um sich frisch 

zu machen. 

5. Nach der Morgentoilette schon in etwas zurechnungsfähigerem Zustand 

macht sich unsere Person daran, in die Küche zu gehen und ein Frühstück 

zu richten. 

6. Das Frühstück wird hastig verschlungen, weil es wieder einmal ein wenig 

zu spät ist, um es in Ruhe zu sich zu nehmen. 

7. Die Person macht sich auf den Weg zum Arbeitsplatz. Hier gibt es mehrere 

verschiedene Möglichkeiten, prinzipiell passiert dies entweder zu Fuß 

oder mit einem wie auch immer gearteten Fahrzeug. 

8. Beim Gebäude angekommen, geht unsere arbeitswillige Person hinein 

und steuert zielstrebig den Arbeitsplatz an. 

Vorsicht Falle: Einige Leser werden es schon bemerkt haben, aber ich 

bin mir sicher, dass es nicht allen aufgefallen ist: Die arbeitswillige Person 

verbreitet am Arbeitsplatz knisternde Erotik, denn sie kommt nackt dort 

an :-). Wie man sieht, ist es also wirklich auch bei denn banalsten Abläufen 

möglich, böse Schlampigkeitsfehler zu begehen. 

Aus diesem groben Ablauf kann man nun relativ einfach auch die direkten 

offensichtlichsten Beteiligten mit ihren Eigenschaften extrahieren: 

Person: In unserem Beispiel ist die Person der agierende Teil und sie hat 

(bezogen auf unser Beispiel) folgende Eigenschaften: 

• Sie kann schlafen oder munter sein. 

• Sie kann sitzen, liegen, stehen, gehen und sich auch mit einem Fahrzeug 

fortbewegen. 

• Sie kann Frühstück machen und Essen zu sich nehmen. 

• Sie kann den Wecker abstellen und sich frisch machen. 

Wecker: Bezogen auf das Beispiel ist ein Wecker ein Ding, das läuten kann 

und dessen Läuten man abstellen kann. 

Badezimmer: Das Badezimmer ist ein Raum, in dem man sich frisch machen 

kann. 

Küche: Die Küche ist ein Raum, in dem man sich etwas zu essen richten 

kann. Eventuell kann man in ihr auch essen, oder man muss dazu in 

einen anderen Raum gehen. 

Frühstück: Das Frühstück ist eine Mahlzeit mit folgenden Eigenschaften: 

• Man nimmt sie nach dem Aufstehen ein. Ich habe jetzt bewusst nicht 

in der Früh geschrieben, denn das Empfinden, was das nun in puncto 

Uhrzeit bedeutet, ist sehr subjektiv :-).


• Sie besteht aus mehreren verschiedenen festen und flüssigen Nahrungsmitteln 

in verschiedenen Zuständen (z.B. warm/kalt). Die Zusammenstellung 

ist beliebig. 

Fahrzeug: Die Beteiligung des Fahrzeugs wird hier erwähnt für den Fall, 

dass die Person nicht zu Fuß zur Arbeit geht. Es gibt verschiedenste 

Ausprägungen von Fahrzeugen, z.B. Fahrrad, Auto, Bus, etc., die alle 

ganz verschiedene Eigenschaften haben. Eine Eigenschaft ist ihnen allen 

gemeinsam: sie sind Fortbewegungshilfen, die man entsprechend ihrer 

anderen Eigenschaften verwenden kann. 

Gebäude: Ein Gebäude ist ein beliebiges Bauwerk mit vielen möglichen Eigenschaften. 

Eine der Grundeigenschaften ist, dass es einen oder mehrere 

Räume beinhaltet und (hoffentlich...) zumindest einen Ein- bzw. Ausgang 

hat. 

Arbeitsplatz: Obwohl der Arbeitsplatz zuvor implizit in ein Gebäude verlegt 

wurde, muss das natürlich nicht sein. Ein Arbeitsplatz ist ein beliebiger 

Platz mit der einzigen Eigenschaft, dass man dort zumindest zeitweise 

seine Arbeit verrichtet. 

Ich habe zuvor bewusst ganz einfach hingeschrieben, dass man in das 

Gebäude hineingeht und den Arbeitsplatz ansteuert, um zu zeigen, wie 

leicht man einen Designfehler begehen kann! Würde man diese Analyse 

hier nicht durchführen, kann es nur allzu leicht passieren, dass eine Eigenschaft 

eines Arbeitsplatzes ist, dass er in einem Gebäude liegt. Das 

ist ganz einfach falsch! Man stelle sich vor, dass eine solche Fehlannahme 

Eingang in eine Softwarearchitektur findet und plötzlich muss man 

mittels dieser Architektur einen Förster modellieren, der seine Arbeit im 

Wald verrichtet... womit sofort die nächste Fehlannahme auffällt: Es 

wurde auch impliziert, dass der Weg zur Arbeit zu einem Gebäude führt. 

Das ist aber auch nicht zwingend! 

Vorsicht Falle: Man sieht, selbst bei einer sehr groben Modellierung eines 

völlig alltäglichen Ablaufs kann es schon zu Fehlern kommen. Je detaillierter 

man Abläufe beschreibt, umso mehr Chancen hat man, solche Fehler auch 

wirklich sofort zu lokalisieren und zu korrigieren. Dies macht man so lange, 

bis man im Groben einmal ein schlüssiges Modell von Beteiligten und Interaktionen 

zwischen diesen hat. Die Abstraktionsebene darf man dabei nicht 

verändern, man steht immer noch als Beobachter außerhalb des Problems 

und analysiert das Gesamtmodell. 

Im Normalfall modelliert man auch nicht nur einen einzelnen Ablauf, wie 

es hier der Fall ist, sondern man modelliert eine ganze Reihe von sogenannten 

Use-Cases. Jeder Use-Case ist ein ganz bestimmter Prozess, der mit bzw. in 

einem System durchführbar sein muss. Aus der Analyse aller dieser Use- 

Cases ergibt sich dann das grobe Gesamtmodell. 

Sobald das Modell schlüssig ist, geht man einen Schritt in die Tiefe. 

Je nach Problemstellung gibt es verschiedene Interpretationen, was nun ein


Schritt ist und was in die Tiefe bedeutet. In den allermeisten Fällen funktioniert 

es wunderbar, wenn man sich die einzelnen Aktoren vornimmt und 

Abläufe der Reihe nach, detailliert aus ihrer Sicht heraus, beschreibt. Durch 

die Verfeinerung in der Beschreibung der Abläufe findet man wieder eine 

Fülle neuer Aktoren, die in dieser Abstraktionsebene Wichtigkeit besitzen. 

Um nun nicht gleich ein gesamtes Buch darüber zu schreiben, wie man in der 

Früh aufsteht und zur Arbeit kommt, möchte ich den Ablauf des sich frisch 

Machens aus Punkt 4 oben als Teilbeispiel herausgreifen. 

Die Vorbedingung in unserem groben Ablauf war, dass man sich im Badezimmer 

frisch macht. Das bedeutet, dass man dieses einmal betreten muss. 

Genau damit haben wir eine wichtige Eigenschaft des Badezimmers gefunden, 

die in Wirklichkeit eine Eigenschaft aller Räume ist: sie sind abgegrenzt 

und es gibt eine Möglichkeit, sie zu betreten. Die Abgrenzung eines Raumes 

ist im Normalfall eine Mauer, die Möglichkeit, ihn zu betreten, ist eine 

Öffnung. Eine Mauer kann wiederum aus verschiedenen Materialien bestehen, 

verschieden dick, groß und gefärbt sein, eine Öffnung in der Mauer kann 

durch eine Tür verschlossen sein, diese kann wiederum verschiedenste Ausprägungen 

haben, etc. 

Man kann leicht erkennen, dass man nur durch den kleinen Aspekt, dass 

man einen Raum betreten muss, einen Use-Case gefunden hat, der bereits 

wieder das Herausarbeiten vieler verschiedener Beteiligter mit ihren Eigenschaften 

zur Folge hat, die im übergeordneten groben Fall noch keine direkte 

Rolle gespielt haben. Diesen Prozess, der sich über viele Ebenen zieht, nennt 

man schrittweise Verfeinerung des Modells und genau diese schrittweise Verfeinerung 

wendet man in der Analyse und Designphase von Software so lange 

an, bis man auf einem Level angelangt ist, der keine weitere Verfeinerung 

mehr zulässt oder benötigt. 

Vorsicht Falle: Auch diesen Exkurs habe ich gerade absichtlich gemacht, 

um zu zeigen, wie schnell man ein Ziel aus den Augen verlieren kann. Die 

Absicht war eben noch, den Prozess des sich frisch Machens zu beschreiben. 

Bereits beim ersten kleinen Teilaspekt dieses Prozesses, nämlich dem Betreten 

des Badezimmers, habe ich die gerade dort noch gültige Abstraktionsebene 

verlassen und begonnen, über Räume, Mauern und Türen zu philosophieren. 

Man sieht also, dass die schrittweise Verfeinerung sicherlich die Vorgangsweise 

der Wahl sein wird, um das Gesamtproblem in den Griff zu bekommen. 

Jedoch sieht man auch, dass Disziplin eine der wichtigsten Eigenschaften 

ist, die man braucht, um sinnvoll und zielgerichtet zu arbeiten. Man darf 

erst den nächsten Schritt in der Verfeinerung tun, wenn man eine Ebene 

abgehandelt hat, sonst verliert man sich in Details und verliert damit den 

Überblick über das zu lösende Problem. 

Also – zurück zum Ausgangspunkt! Wie macht man sich morgens frisch: 

1. Man betritt das Badezimmer. 

2. Man duscht sich.


3. Man trocknet sich ab. 

4. Man putzt sich die Zähne. 

5. Man verlässt das Badezimmer. 

Was erkennt man aus dieser groben Beschreibung: 

• Eine Eigenschaft einer Person ist es offensichtlich, dass sie Zähne hat, denn 

was sollte man denn sonst putzen. 

• Eine Eigenschaft des Badezimmers ist, dass darin ein Handtuch vorhanden 

ist, sonst kann man sich nicht abtrocknen. Damit ist nicht ausgesagt, dass 

das Handtuch eine Eigenschaft des Badezimmers ist, denn man könnte es 

ja auch beim Betreten mit hinein genommen haben. Im Prinzip ist nicht 

einmal gesagt, dass zum Abtrocknen ein Handtuch notwendig ist, denn 

man könnte ja auch so lange stehen bleiben, bis man trocken ist. Der 

Ablauf des Abtrocknens verdient also im Modellierungsprozess noch eine 

nähere Betrachtung, was die Anforderungen betrifft. 

• Eine Eigenschaft unseres Badezimmers ist, dass es eine Dusche gibt... oje... 

wieder ein Fehldesign. Es gibt auch Badezimmer ohne Dusche! Dort funktioniert 

der gerade angeführte Prozess zwar nicht mehr vollständig, weil 

man sich nicht duschen, sondern nur ein Vollbad nehmen kann oder sich 

überhaupt nur waschen kann. Trotzdem darf man aus der Prozessbeschreibung 

nicht zwingend schließen, dass auch alles Geforderte eine Eigenschaft 

von beteiligten Parteien ist! 

Um wirklich einen sinnvollen Verfeinerungsschritt vollziehen zu können, werden 

die einzelnen Prozesse, die vom Betreten bis zum Verlassen des Badezimmers 

stattfinden, einmal alle einzeln verfeinert, denn mehr Information als 

gerade eben lässt sich aus dem groben Ablauf nicht extrahieren. Beispielhaft 

für die anderen Teilprozesse nehmen wir uns einfach das Zähne Putzen zur 

Brust: 

1. Man nimmt die Zahnbürste in die Hand. Wichtig hierbei ist, dass man 

keine direkte Aussage treffen kann, wo die Zahnbürste hergenommen 

wird. Sie könnte einfach daliegen oder auch in einem eigenen Kästchen 

sein. Egal, wie es auch immer ist, der Aufenthaltsort der Zahnbürste ist 

keine Eigenschaft der Zahnbürste selbst. Entsprechend ist auch hier ein 

eigener Prozess zu modellieren, der in Bezug zum Aufenthaltsort steht. 

2. Man nimmt das Behältnis mit der Zahnpasta. Hier ist wieder zu bedenken, 

dass es keine Eigenschaft ist, dass Zahnpasta in einer Tube vorhanden 

ist. Auch andere Behältnisse sind möglich! Wie schon bei der 

Zahnbürste, so wird auch hier wieder keine Annahme getroffen, wo die 

Zahnpasta zu finden ist. 

3. Man schmiert Zahnpasta auf die Zahnbürste. Wie dies genau stattfindet, 

ist abhängig vom Behältnis. Wenn wir als Beispiel eine Tube nehmen, 

dann muss diese zuerst geöffnet werden, danach wird die Zahnpasta herausgedrückt 

(und landet hoffentlich auf der Zahnbürste und nicht am 

Boden :-)) und danach wird die Tube wieder verschlossen.


4. Man befeuchtet die Zahnbürste mit der inzwischen darauf befindlichen 

Zahnpasta. Dazu braucht man Wasser, also muss es irgendwo eine Wasserleitung 

geben. Wie man diese nun wieder zu bedienen hat, damit man 

auch wirklich Wasser bekommt, ist eine der Eigenschaften der spezifischen 

“Implementation” der Wasserleitung mit entsprechendem Wasserhahn. 

5. Man öffnet den Mund. 

6. Man steckt die Zahnbürste in den Mund und putzt. Das Putzen allein ist 

wieder ein eigens zu beschreibender Prozess, denn dabei sind genau betrachtet 

viele Schritte vonnöten: Zahnbürste auf und ab bewegen, Stelle 

der Bewegung ändern, Mund weiter öffnen und die Innenseite putzen, 

etc. 

7. Nach dem Putzen spült man den Mund mit Wasser aus. Auch dieser Prozess 

wird wieder extra beschrieben, denn auch hier spielt die Bedienung 

des Wasserhahns eine Rolle, sowie auch, ob man einen Zahnputzbecher 

benutzt oder nicht. 

8. Man reinigt die Zahnbürste mit Wasser. 

9. Man stellt die Zahnbürste zurück. 

Vorsicht Falle: Welche Leser haben es bemerkt? Ich habe zu Demonstrationszwecken 

wieder einen Fehler in den obigen Ablauf eingebaut... 

Nach der obigen Beschreibung nämlich geht unsere Person mit der Zahnpasta 

in der Hand in die Arbeit, denn nach Schritt 3 fehlt schlicht und 

ergreifend das Zurückstellen der Zahnpasta an ihren Platz. 

Wichtig bei den einzelnen Prozessbeschreibungen ist nämlich, dass Vorund 

Nachbedingungen eingehalten werden. Die Vor- und Nachbedingungen 

bei genau dieser Beschreibung des Zähne Putzens sind einfach, dass die 

Person vorher weder Zahnbürste noch Zahnpasta in der Hand hat, dass es 

Zahnbürste und Zahnpasta überhaupt gibt, dass die Zahnpasta nicht leer ist 

und dass nach dem Putzen wieder alles aus der Hand gelegt wird. Weiters 

ist natürlich eine Vorbedingung, dass die Person zumindest eine Hand frei 

haben muss. 

Man sieht, dass es auch bei den banalsten Prozessen eine Fülle von Vorund 

Nachbedingungen gibt. Wenn man diese alle explizit in die Prozessbeschreibung 

aufnimmt, dann wird alles sehr schnell sehr unübersichtlich. Aus 

diesem Grund ist eine der üblichen Vorgehensweisen, dass man die Bedingungen 

explizit vor der Prozessbeschreibung anführt und dann den Prozess 

auf die Einhaltung dieser Bedingungen überprüft. 

Durch die genauere Beschreibung des Zähne Putzens haben wir wieder 

neue Beteiligte mit ihren Eigenschaften identifiziert: 

Zahnbürste: Ob diese nun elektrisch ist oder nicht, spielt in unserer Betrachtung 

hier keine besondere Rolle. In jedem Fall hat sie wie auch immer 

geartete Borsten, die zum Putzen dienen und ist irgendwie vernünftig


genug mit der Hand angreifbar, dass man sie auch wirklich zum Putzen 

verwenden kann. 

Zahnpasta: Die Zahnpasta ist eine wie auch immer geartete Substanz, die 

entweder zäh bis dickflüssig oder pulverförmig sein muss, ansonsten eignet 

sie sich nicht zum Putzen der Zähne. Natürlich muss sie auch sonstige, 

dem Putzvorgang zuträgliche Eigenschaften haben, die sie als Reinigungssubstanz 

auszeichnen. Schuhcreme ist vielleicht nicht die geeignetste 

Substanz zum Zähne putzen, obwohl sie die Eigenschaft erfüllt, 

zäh zu sein :-). 

Behälter: In unserem Beispiel haben wir einen Behälter identifiziert, in dem 

man Zahnpasta aufbewahren kann. Dieser muss entsprechend dicht sein 

und weiters einen Verschluss besitzen, um ihn zu öffnen. Die Öffnung 

muss sinnvoll genug an die Eigenschaften des Behälters und der Zahnpasta 

angepasst sein, dass man auch Zahnpasta entnehmen kann. Ich 

möchte mir hier nähere Eigenschaften eines allgemeinen Behälters ersparen, 

da wir in Kürze noch darauf kommen werden, was es damit auf sich 

hat. 

Tube: Eine Tube ist ein besonderer Behälter. Je nach Größe der Tube kann 

man darin sinnvoll Zahnpasta aufbewahren und diese auch je nach Verschluss 

dosiert entnehmen. 

Kästchen: Eine Möglichkeit, wo man Zahnbürste und Zahnpasta aufbewahren 

kann, ist ein Kästchen. Bei genauerer Überlegung ist auch ein 

Kästchen ein Behälter, nur eben mit anderen Eigenschaften als der, den 

wir für die Zahnpasta brauchen. 

Wasser: Wasser ist eine Flüssigkeit mit besonderen Eigenschaften. Ich 

möchte hier nicht näher darauf eingehen, welche Eigenschaften dies jetzt 

sind. In jedem Fall ist es eine Flüssigkeit. 

Wasserleitung: Dies ist eine allgemeine Leitung, durch die (üblicherweise) 

Flüssigkeit geleitet wird, mit den entsprechenden Eigenschaften, dass sie 

dicht ist, dass sie auch verzweigt sein kann, etc. und vor allem, dass sie 

auf das Leiten von Wasser ausgelegt ist. 

Wasserhahn: Dieser befindet sich an zumindest einer Wasserleitung und zwar 

immer am Ende einer Verzweigung jeder der beteiligten Leitungen. Er 

besitzt die Eigenschaften, dass er auf- und zugedreht sein kann, im Falle 

mehrerer Wasserleitungen (z.B. kalt/warm) besitzt er auch die Mischer- 

Eigenschaft, etc. 

Mund: Bisher haben wir identifiziert, dass es Zähne gibt, die geputzt werden 

müssen. Jetzt haben wir auch explizit identifiziert, dass diese im Mund 

zu finden sind und dass eine Person einen Mund besitzt. Abgesehen von 

anderen Eigenschaften kann man den Mund öffnen und schließen und 

zwar stufenlos. 

Ich glaube, es ist beim Durchspielen des Beispiels klar geworden, wie man 

Schritt für Schritt Abläufe analysiert, Beteiligte identifiziert, Eigenschaften 

findet und weiter schrittweise verfeinert. An dieser Stelle möchte ich den


Begriff des Moduls einführen, der in der Informatik (und nicht nur dort) 

folgendermaßen definiert ist: 

• Ein Modul ist eine vollkommen in sich abgeschlossene Einheit mit genau 

definierter Funktionalität. 

• Für diese Funktionalität gilt ausnahmslos die Regel, dass ein Modul immer 

nur eine einzige, seinem Abstraktionslevel entsprechende Aufgabengruppe 

erledigen darf. 

Anm.: Es ist hier absichtlich von Aufgabengruppen die Rede und nicht 

von Einzelaufgaben, zu diesen kommen wir noch in einem anderen Zusammenhang. 

• Ein Modul besitzt eine genau definierte Schnittstelle zur Außenwelt, über 

die (und ausschließlich nur über die!!!) andere Module mit ihm kommunizieren 

können. 

• Die Schnittstelle des Moduls darf immer nur exakt seinem Aufgabengebiet 

innerhalb seines Abstraktionslevels entsprechen und niemals Implementationsdetails 

nach außen preisgeben, die in diesem Level belanglos sind. 

Anders betrachtet beschreibt die Modulschnittstelle, was man mit ihm 

machen kann, niemals aber, wie dies implementiert ist. 

• Durch den Begriff der vollkommen in sich abgeschlossenen Funktionalität 

ist zwar schon alles gesagt, aber weil es so wichtig ist, möchte ich es hier 

noch einmal anführen: Ein Modul darf keine direkte Abhängigkeit zu besonderen 

Implementationen von Codeteilen außerhalb des Moduls haben. 

Es ist ausschließlich die Verwendung von anderen Modulen über ihre definierten 

Schnittstellen erlaubt. 

• Ein Modul kann aus beliebig vielen Submodulen bestehen, die in ihrem 

Abstraktionslevel um eine Stufe tiefer liegen. Das impliziert, dass alle 

Module immer hierarchisch nach ihren Abstraktionslevels strukturiert sind. 

Nehmen wir zur Demonstration das Teilbeispiel des Zähneputzens und betrachten 

die dort identifizierten Beteiligten und Abläufe. Wenn wir den hier 

definierten Modulbegriff auf dieses Konglomerat anwenden (soll heißen, wir 

suchen Funktionalitätsgruppen), so ergibt sich Folgendes: 

Zahnpflege-Modul: In diesem ist alle Funktionalität zu finden, die mit der 

Zahnpflege zu tun hat. Dies beinhaltet, wie man eine Zahnbürste gebraucht, 

dass es Zahnpasta gibt und wie man mit ihr umgeht, etc. 

Behälter-Modul: Dieses Modul fasst alle Funktionalität zusammen, die mit 

Behältern zu tun hat, nämlich, welche es gibt (Tube, Becher, Kasten), 

wie man mit ihnen umgeht, etc. 

Wasserversorgungs-Modul: Dieses Modul fasst alles zusammen, was man zur 

Wasserversorgung an Funktionalität braucht, also Wasserleitung, Wasserhahn, 

wie man diesen bedient, etc. 

Mensch: Dieses Modul fasst das gesamte Zusammenspiel der Einzelteile des 

Menschen (Hände, Mund, etc.) zusammen und auch, wie ein Mensch mit 

seiner Umwelt umgeht (greifen, sehen, etc.).


Die Schnittstellen und Abhängigkeiten der einzelnen Module sind auch leicht 

identifizierbar, wie am Beispiel des Menschen und der Zahnpflege kurz demonstriert 

werden soll: 

• Ein Mensch verwendet das Zahnpflege-Modul und das Wasserversorgungs- 

Modul, um sich die Zähne zu putzen. Die Schnittstelle des Menschen zur 

Außenwelt sind seine Sinnesorgane, die Hände zum Greifen, die Beine und 

Füße zum Gehen, etc. 

• Das Zahnpflege-Modul stellt als Schnittstelle nach außen eine Zahnbürste 

und die Zahnpasta zur Verfügung. Weiters ist eine der Randbedingungen 

zur richtigen Verwendung dieses Moduls, dass es ein Wasserversorgungs- 

Modul geben muss, denn sonst funktioniert die Zahnpflege nicht vernünftig. 

Auch diese Bedingung ist im Prinzip ein Teil der Modulschnittstelle, 

obwohl damit nicht direkt irgendwelche möglichen Aufrufe verbunden sind. 

Um nicht das Ziel aus den Augen zu verlieren – was haben wir bisher eigentlich 

erreicht, außer dass wir wissen, dass man sich in der Früh die Zähne 

putzt und wie das funktioniert? Wir haben das Problem in überschaubare 

Teilprobleme und Abläufe zerlegt. Das notwendige Wissen bei einer weiteren 

Zerlegung jedes gefundenen Moduls beschränkt sich nur noch darauf, dass 

es auch andere Teile gibt, die etwas zur Verfügung stellen (=Module mit 

Schnittstellen), nicht aber, wie diese das intern machen. Man will ja auch 

nicht genau wissen, wie ein Wasserhahn intern konstruiert ist, wenn man nur 

das Wasser aufdrehen will. Es genügt, dass man weiß, dass man am Hahn 

dreht und dann rinnt Wasser heraus. Ok, ich weiß schon, es gibt auch Einhandmischer, 

bei denen kein Hahn mehr zum Drehen existiert, aber das ist 

jetzt nicht Thema der Diskussion :-). 

So nett das mit den überschaubaren Teilproblemen auch klingt und so 

hilfreich diese Vorgangsweise auch ist, irgendwie kann das aber trotzdem noch 

nicht alles gewesen sein. Bei der Softwareentwicklung will man ja nicht nur 

ein Problem analysieren, sondern man will ja auch ein informatisches Modell 

bilden, in dem man die Abläufe implementiert. Am schönsten wäre es, wenn 

man die reale Welt gleich direkt im Computer nachbilden könnte, denn dann 

ist das informatische Modell sicher am leichtesten zu verstehen und auch zu 

implementieren. Am schönsten wäre es doch, wenn man im Computer gleich 

die zu Beginn auf Seite 147 identifizierten Beteiligten modellieren könnte 

und diese direkt miteinander interagieren lassen könnte. Dann nämlich hätte 

man gleich in der Analysephase des Problems ein Modell geschaffen, das ohne 

weitere “Übersetzung” implementierbar ist. Versuchen wir einmal ein kurzes 

Brainstorming, wie man sich so ein Modell vorstellen könnte: 

• Es gibt einen Menschen. 

– Ein Mensch hat einen Kopf. 

• Im Kopf gibt es ein Gehirn. 

• Im Kopf gibt es Augen, mit denen der Mensch sieht.

8.2 Klassen und Objekte 155 

• Im Kopf gibt es einen Mund, durch den ein Mensch Nahrung zu sich 

nehmen kann, atmen kann und sprechen kann. 

· Im Mund gibt es Zähne. Diese sind hart und man kann mit ihnen 

beißen. 

· Im Mund gibt es eine Zunge. Diese ist beweglich, usw. 

· etc. 

• etc. 

– Ein Mensch hat einen Rumpf. 

– Ein Mensch hat Arme. 

– Ein Mensch hat Hände, wobei diese durch die Arme mit dem Rumpf 

verbunden sind. 

– Ein Mensch hat Beine. 

– Ein Mensch hat Füße, wobei diese durch die Beine mit dem Rumpf 

verbunden sind. 

– Die Tätigkeiten eines Menschen werden zentral gesteuert. 

• Die Steuerung erfolgt durch Signale aus dem Gehirn. 

• Das Gehirn kann direkt mit allen einzelnen Bestandteilen des Menschen 

kommunizieren. Dabei können Bewegungen hervorgerufen werden, 

etc. 

• etc. 

– Ein Mensch kann gehen. 

– etc. 

• Es gibt Gebäude. 

– Ein Gebäude ist unterteilt in Räume. 

– etc. 

• etc. 

Ich habe bewusst das Wort Brainstorming verwendet, denn dieses Modell 

ist noch nicht vollständig tragfähig für eine Implementation, weil es nicht 

sauber genug strukturiert ist. Unter dem Begriff der sauberen Strukturierung 

wird im Sinne der Objektorientiertheit eine saubere semantische Strukturierung 

nach Einzelteilen, Eigenschaften, Tätigkeiten und verschiedenartigen 

Zusammenhängen verstanden, die einen gemeinsamen Abstraktionslevel besitzen. 

In welchen Kategorien und Modellen hierbei die Erfinder von OO Programmiersprachen 

gedacht haben und welche Ausdrucksmittel dabei zur Modellierung 

zur Verfügung stehen, ist das Thema des folgenden Abschnitts, der 

uns damit endlich wirklich zum Kern der OO Softwareentwicklung bringt. 

8.2 Klassen und Objekte 

In der Natur der menschlichen Denkweise liegt das Begreifen der Welt als 

eine Ansammlung von einzelnen Objekten, die Eigenschaften haben und miteinander 

in irgendwie gearteter Verbindung stehen. Bei den Eigenschaften


unterscheidet man im täglichen Leben völlig intuitiv zwischen solchen, die 

in der Natur eines Objekts liegen (z.B. hat ein Mensch einen Kopf, einen 

Rumpf, Arme, Beine, etc.) und solchen, die derzeitig gültige, besondere Ausprägungen 

von möglichen naturgegebenen Eigenschaften sind (z.B. gute oder 

schlechte Laune). Objekte können Aktionen ausführen, entweder selbsttätig 

oder in Verbindung mit anderen Objekten (z.B. ein Mensch fährt mit einem 

Auto). Um eine Aktion auszuführen gibt es Voraussetzungen, z.B. kann nur 

jemand mit einem Auto fahren, der auch weiß, wie man das tut. Das bedeutet, 

dass die Fähigkeit, mit einem Auto zu fahren, keine naturgegebene 

Eigenschaft eines jeden Menschen ist. 

Abstrahiert man diese Betrachtungen und versucht ein allgemeines Ausdrucksmittel 

für solche Denkmuster zu finden, dann landet man prinzipiell 

einmal bei folgendem Ergebnis: 

• Es gibt Klassen. Diese fassen allgemein alle naturgegebenen Möglichkeiten 

einer bestimmten Gruppe von Objekten zusammen. 

• Es gibt Objekte. Diese sind einzelne Instanzen von bestimmten Klassen 

mit einem bestimmten Status. Damit stellt ein Objekt eine besondere 

Ausprägung der durch die Klasse vorgegebenen Möglichkeiten dar. 

Nach diesem Begriff wäre zum Beispiel ein Mensch aus dem zuvor besprochenen 

Beispiel eine Klasse, die alle seine naturgegebenen Eigenschaften und 

Fähigkeiten beschreibt. Die Person, die in der Früh aufsteht und zur Arbeit 

geht bzw. fährt, ist ein eine Instanz eines Menschen, also ein Objekt. Die besonderen 

Eigenschaften, die diese Person aus der Fülle der Möglichkeiten des 

Menschen hat, sind durch die Instanz bestimmt. Zum Beispiel kann sich unsere 

Person (hoffentlich :-)) die Zähne putzen. Auch ein neugeborenes Kind 

ist eine Person und damit der Klasse Mensch zugehörig. Mit dem Zähne 

putzen ist es allerdings beim Neugeborenen noch nicht so weit her. 

Damit wären wir nun endlich bei den Grundkonstrukten von OO Programmiersprachen 

gelandet, die es erlauben, eine für den Menschen natürliche 

Modellbildung vorzunehmen. In allen OO Programmiersprachen gibt es 

Klassen und Objekte mit genau der Bedeutung, wie sie soeben besprochen 

wurde. 

Vorsicht Falle: Leider zieht sich durch die gesamte Literatur eine völlig 

verwaschene Definition durch, in der die Begriffe Klasse und Objekt nur allzu 

oft als Synonym verwendet werden. Dies ist grundfalsch! Ich möchte 

eindringlichst davor warnen, die Begriffe Klasse und Objekt miteinander zu 

vermischen, denn in diesen Begriffen liegt wichtige Semantik, die sich im Programmdesign 

niederschlägt und damit ein völlig falsches bzw. unverständliches 

Design ergibt! 

Wenn eine Klasse eine Eigenschaft hat, so ist dies etwas Naturgegebenes, 

was alle ihre Instanzen, also Objekte, in ihren Grundanlagen besitzen. 

Wenn ein Objekt eine Eigenschaft hat, so ist dies eine besondere Ausprägung 

bzw. ein Status, der sich nur auf diese eine Instanz bezieht. Eine


solche Ausprägung folgt immer den naturgegebenen Möglichkeiten, die eine 

Klasse vorgibt. 

Umgelegt auf programmiersprachliche Ebene kann man auch folgende Definition 

geben: 

• Eine Klasse entspricht einem Datentyp. 

• Ein Objekt entspricht einer Variable. 

OO Software folgt dem Modell, dass es in einem Programm beliebig viele 

Objekte und Interaktionen zwischen diesen Objekten gibt. Durch die Interaktionen 

wird der Programmfluss bestimmt. Alle grundsätzlich möglichen 

Interaktionen mit einem Objekt sind durch seine Klasse vorgegeben. Um 

jetzt nicht gleich eine ganze Person zu modellieren, wie sie im obigen Beispiel 

vorkam, nehmen wir als kleines und einfaches Beispiel mein Telefon am 

Schreibtisch: 

Mein Telefon am Schreibtisch ist ein Objekt, nämlich eine Instanz einer 

allgemeinen Klasse Telefon. Diese Klasse, die die Eigenschaften eines Telefons 

und die möglichen Interaktionen mit einem solchen bestimmt, kann 

vereinfacht folgendermaßen aussehen: 

Bestandteile des Telefons: 

• Ein Telefon besitzt einen Telefonhörer. 

• Ein Telefon besitzt eine Gabel, auf der der Telefonhörer liegt. 

• Ein Telefon besitzt einen numerischen Tastenblock. 

• Ein Telefon besitzt eine Leitung zum Telefonnetz. 

• Ein Telefon besitzt eine Klingel. 

Mögliche Interaktionen mit dem Telefon aus Benutzersicht: 

• Man kann eine Nummer wählen, die man anrufen will. Das geschieht 

über den numerischen Ziffernblock. Damit das Telefon eine Wahl auch 

akzeptiert, darf der Hörer nicht auf der Gabel liegen. 

• Man kann angerufen werden. In diesem Fall macht sich das Telefon 

lautstark bemerkbar. Dies geschieht über die Klingel. 

• Man kann einen Anruf annehmen. Dazu hebt man den Hörer von der 

Gabel. 

• Man kann mit jemandem sprechen. Dies geschieht über den Telefonhörer, 

der in diesem Fall nicht auf der Gabel liegen darf. 

• Man kann ein Gespräch beenden. Dies geschieht, indem man den Telefonhörer 

auf die Gabel legt. 

Andere mögliche Interaktionen mit dem Telefon: 

• Das Telefon interagiert mit dem Telefonnetz. Mögliche Interaktionen 

sind sowohl die Nummernwahl als auch ein Signal für einen eingehenden 

Anruf, sowie das Gespräch selbst. 

• Das Telefon interagiert mit dem Hörer. Eingehende Sprachsignale vom 

Telefonnetz werden an ihn weitergeleitet und Sprachsignale vom Hörer 

werden an das Telefonnetz weitergereicht.


• Das Telefon interagiert mit dem Ziffernblock. Für jede gedrückte Taste 

wird ein eindeutiger Impuls empfangen. 

• Das Telefon interagiert mit der Gabel, die sich als einfacher ein/aus 

Schalter präsentiert. 

• Das Telefon interagiert mit der Klingel. Es kann diese zum Läuten 

veranlassen. 

Vorsicht Falle: Ich kann es einfach nicht lassen... Weil sich alles so banal 

liest und dazu verleitet, das Geschriebene als sowieso klar hinzunehmen, 

musste ich schon wieder einen groben Designfehler einbauen, der sich im 

Lauf einer Entwicklung als echte Zeitbombe entpuppen kann. 

Im Beispiel wird davon ausgegangen, dass der Hörer nicht auf der Gabel 

liegen darf, wenn man mit dem Gegenüber spricht oder eine Nummer wählen 

will. Das stimmt zwar, aber es ist nicht die ganze Wahrheit: In Wirklichkeit 

darf die Gabel nicht gedrückt sein, egal ob durch den Hörer, den Finger 

des Telefonierenden, den Fuß des Telefonierenden, der gerade am Tisch liegt, 

oder sonst etwas. Modelliert man die Klasse so, dass nur der Hörer dafür 

verantwortlich zeichnet, dass die Gabel gedrückt ist, dann ist das ein glattes 

Fehldesign, das der Realität nicht entspricht. Wir wollen in unserem Modell 

aber die Realität nachbilden! 

Solcherart Fehler schleichen sich nur allzu leicht in ein Design ein und 

müssen später teuerst mit Programmänderungen oder irgendwelchen Workarounds 

wieder korrigiert werden. Zumeist aber werden bei solchen Korrekturen 

später nur Spezialfälle korrigiert, die gerade wichtig sind. Damit ist zwar 

ein zu dieser Zeit wichtiger Fall abgedeckt, aber leider entfernt sich das Modell 

noch weiter von der Realität, was die nächsten gröberen Probleme dann 

gleich nach sich zieht. Aus diesem Grund kann ich nur einen ganz wichtigen 

Ratschlag geben: 

Das erarbeitete Modell muss laufend mit der Realität verglichen werden, 

ob es nicht vielleicht von dieser abweicht. Jede Abweichung muss sofort korrigiert 

werden, denn Fehler im Programmdesign potenzieren sich im Lauf der 

Zeit. Vor allem verliert man die Vorteile des OO Ansatzes, denn man muss 

plötzlich beginnen, von der Realität auf das Modell zu übersetzen, anstatt eine 

direkte Abbildung zu haben! 

Nach Korrektur des Designfehlers lesen sich die entsprechenden Punkte 

folgendermaßen: 

Mögliche Interaktionen mit dem Telefon aus Benutzersicht: 

• Man kann eine Nummer wählen, die man anrufen will. Das geschieht 

über den numerischen Ziffernblock. Damit das Telefon eine Wahl auch 

akzeptiert, darf die Gabel nicht gedrückt sein. 

• Man kann einen Anruf annehmen. Dazu hebt man den Hörer ab. Die 

Gabel darf nicht gedrückt sein.


• Man kann mit jemandem sprechen. Dies geschieht über den Telefonhörer. 

Die Gabel darf nicht gedrückt sein. 

• Man kann ein Gespräch beenden. Dies geschieht, indem man die Gabel 

drückt. 

Zurück zum Ausgangspunkt – wir haben jetzt eine primitive Klasse Telefon. 

Davon wird eine Instanz erzeugt, also ein Objekt, das das Telefon auf meinem 

Schreibtisch darstellt. Damit diese eine Instanz funktioniert, müssen folgende 

Dinge passieren: 

• Das Telefon muss an das Telefonnetz angeschlossen werden. Und schon 

haben wir den nächsten Fehler im Design der Telefonklasse entdeckt: Es 

fehlt eine Interaktionsmöglichkeit, die es erlauben würde, dass man das 

Telefon ans Netz anschließt. Diese Möglichkeit muss im Design der Klasse 

ergänzt werden. 

• Das Telefon wird auf den Schreibtisch gestellt. Das bedeutet, dass wir 

eine Instanz eines Schreibtischs brauchen, die genau meinen Schreibtisch 

repräsentiert. Diese Instanz ist von der Klasse Schreibtisch, die wiederum 

auf jeden Fall eine Interaktion “stelle ein beliebiges Objekt darauf” unterstützt. 

Dass das darauf gestellte Objekt zu schwer sein könnte und der 

Schreibtisch dann als Reaktion alle vier Beine von sich streckt, lassen wir 

im Augenblick einmal außer Acht. Im Design des Schreibtischs gehört eine 

solche Randbedingung allerdings sehr wohl modelliert! 

• Das Telefonnetz muss wissen, welche Nummer meinem Telefon zugeordnet 

wird und wo dieses genau am Netz hängt, damit es einen Anruf korrekt 

durchleitet. 

Vorsicht Falle: Nein, diesmal habe ich keinen Designfehler eingebaut. Allerdings 

möchte ich vor einem solchen warnen, der nur allzu leicht passiert, 

wenn man ungeübt ist: Neulinge (und leider auch manchmal erfahrene Entwickler) 

begehen gerne den Fehler, dass die Telefonnummer nicht dem Telefonnetz 

bekannt ist, wie oben beschrieben, sondern dem Objekt des speziellen 

Telefons selbst zu eigen ist. Es ist allerdings keine Eigenschaft der Klasse Telefon, 

dass es eine Nummer besitzt. Vielmehr ist es eine Eigenschaft der 

Klasse Telefonnetz, dass jedem Telefon eine Nummer zugeordnet ist! Die 

Verantwortlichkeit liegt also beim Netz und niemals beim Telefon. 

Wozu es führt, wenn man einen so folgenschweren Fehler begeht, lässt sich 

leicht erkennen, wenn man sich überlegt, dass man ein gesamtes Netz mit 

vielen daran hängenden Telefonen modellieren soll: Wie ruft man jemanden 

an? Man wählt eine Nummer und teilt diese dem Netz mit. Und was tut 

das Netz dann? Wenn jedes Telefon seine eigene Nummer selbst weiß, dann 

muss das Netz der Reihe nach alle Telefone um die Nummern fragen, bis 

es das richtige gefunden hat. Dass das nicht funktionieren kann, ist leicht 

einzusehen.


Es ist also zwingend notwendig, dass man während des gesamten Designprozesses 

immer einen klaren Blick für die Verantwortlichkeiten der einzelnen 

Klassen und Objekte hat und diese auch immer wieder auf ihre Sinnhaftigkeit 

überprüft. 

Eine Kleinigkeit fehlt uns allerdings noch, um sinnvoll OO Design betreiben 

zu können. Es lässt sich leicht überlegen, das es recht mühsam und vor 

allem unnötig sein kann, für jeden unterschiedlichen Telefontyp eine eigene 

Klasse zu designen, die im Grunde genommen fast dasselbe tut wie alle anderen 

speziellen Telefonklassen, nur dass ein paar Kleinigkeiten verändert sind. 

Stellen wir uns einfach vor, dass auf einem anderen Schreibtisch ein Telefon 

steht, das zusätzlich zum numerischen Block noch einen weiteren frei programmierbaren 

Tastenblock besitzt. Es wäre doch wirklich nicht besonders 

sinnvoll, nur deswegen alles incl. Hörer, Ziffernblock, Kabel zum Telefonnetz, 

etc. vollständig neu zu designen, bloß weil ein Teil dazugekommen ist. 

Genauso sinnlos wäre es, das gesamte Design des einfacheren Telefons zu 

kopieren und beim komplizierteren Telefon dann die noch fehlende Funktionalität 

zu ergänzen. Man stelle sich nur einmal vor, das Design wurde oft 

genug kopiert und plötzlich ergibt sich aus welchen Gründen auch immer eine 

Änderung im Design der Grundfunktionalität eines Telefons. Dann müssten 

alle Telefonklassen überarbeitet werden (von realen Implementationen und 

den dabei in der Natur der Sache liegenden Fehlerbehebungen will ich hier 

noch gar nicht sprechen :-)). 

Was man sich wünschen würde wäre folgende Möglichkeit: 

• Man entwirft ein Design für eine Klasse Telefon, das die Minimalversion 

eines Telefons beschreibt, wie wir das zuvor gemacht haben. 

• Sollte man ein anderes Telefon wünschen, also z.B. eines mit einem zusätzlichen 

Tastenblock oder mit einem Display oder mit beidem, dann verwendet 

man die bereits existente Klasse und erweitert sie nur um die zusätzlichen 

Eigenschaften und Interaktionsmöglichkeiten. 

Diese Art der Wiederverwendbarkeit ist, wie zu erwarten, eines der essentiellen 

Konzepte der OO Softwareentwicklung und wird durch den Mechanismus 

der Ableitung realisiert. Eine solche Ableitung funktioniert folgendermaßen: 

• Es gibt eine Basisklasse, die eine Grundfunktionalität definiert, die allen 

Vertretern dieser Klasse zu eigen ist. Im Falle unseres Telefons ist dies 

die minimale Funktionalität, die alles zum Thema anrufen und angerufen 

werden zur Verfügung stellt. 

• Es kann beliebig viele Klassen geben, die von der Basisklasse abgeleitet 

sind. Durch die Ableitung erben sie automatisch die Eigenschaften der 

Basisklasse. Genau dadurch erspart man sich das Kopieren. 

Anm.: In der Fachliteratur findet sich sehr oft der englische Begriff Inheritance 

für die Vererbung.

8.3 Richtige Verwendung der OO Mechanismen 161 

• Abgeleitete Klassen erben nicht nur die Eigenschaften der Basisklasse, sie 

können auch deren Eigenschaften anpassen oder neue Eigenschaften hinzufügen. 

Ich spreche hier absichtlich von hinzufügen, denn es ist prinzipiell 

im OO Modell nicht vorgesehen, Eigenschaften wegzunehmen. Technisch 

wäre dies zwar je nach verwendeter OO Programmiersprache mehr schlecht 

als recht machbar, aber es ist absolut unsauber und auch wirklich sinnlos. 

Denn wenn man Eigenschaften wegnehmen muss, dann hat man bereits in 

der Basisklasse einen Designfehler und sollte diesen dort schnellstens korrigieren! 

Polemisch formuliert: Man verwendet ja auch nicht einen Ferrari 

als Basismodell für ein Auto und montiert dann die entsprechenden Teile 

ab, um daraus einen Kleinwagen zu bauen. 

Im Falle eines Telefons mit einem zusätzlichen frei programmierbaren Ziffernblock 

kann man dieses von der Basisklasse eines Telefons ableiten und 

der abgeleiteten Klasse einfach die Eigenschaft des zusätzlichen Ziffernblocks 

spendieren. Damit erhält man ohne großes Neudesign das gewünschte 

verbesserte Telefon. Das abgeleitete Telefon funktioniert also, was die 

Grundeigenschaften betrifft, gleich wie jedes andere Telefon auch, nur kann 

es durch das Hinzufügen des Ziffernblocks noch etwas mehr als das Standardmodell. 

• Es ist nicht notwendig, dass man immer von einer Basisklasse ableitet. 

Man kann auch von bereits abgeleiteten Klassen weiter ableiten. Auf diese 

Art kann man schrittweise, je nach Notwendigkeit, Eigenschaften anpassen 

und hinzufügen. 

• Im Sinne der Allgemeinheit ist es möglich, dass eine Klasse nicht nur von 

einer einzigen Klasse abgeleitet ist (=single Inheritance), sondern gleichzeitig 

von mehreren Klassen. Dies wird als Mehrfachvererbung (=multiple 

Inheritance) bezeichnet. C ++ unterstützt multiple Inheritance, manche 

andere Programmiersprachen (z.B. Java) nicht. Der Grund, warum nicht 

alle OO Programmiersprachen multiple Inheritance unterstützen, ist die 

große Gefahr, die bei Fehlverwendung von diesem Konstrukt ausgeht. Im 

weiteren Verlauf dieses Buchs werden potentielle Stolpersteine durch multiple 

Inheritance noch mehrfach diskutiert werden. Als kleine Vorwarnung 

möchte ich hier nur sagen: Multiple Inheritance, vorsichtig und gezielt eingesetzt, 

eröffnet sehr elegante Möglichkeiten, zu einem sauberen Design zu 

kommen. Jedoch führen schon die kleinsten Unachtsamkeiten sehr schnell 

zu riesigen, schwer korrigierbaren Katastrophen. 

Um niemanden vorzeitig in Versuchung zu führen, erspare ich mir an dieser 

Stelle ein Beispiel, wie man Mehrfachvererbung einsetzen könnte :-). 

8.3 Richtige Verwendung der OO Mechanismen 

Das Schwierigste bei der OO Softwareentwicklung ist die semantisch richtige 

Verwendung der Mechanismen, die gerade im Rahmen der Klassen und Objekte 

erklärt wurden. Um ein wirklich sauberes Modell zu entwickeln, das die


Realität in ein Design abbildet, ohne die zur Verfügung stehenden Mechanismen 

missbräuchlich zu verwenden oder gar völlig zu vergewaltigen, braucht 

es sehr viel Erfahrung. In der Folge möchte ich deshalb ein paar Eckpfeiler 

als Startpunkt für das Sammeln von Erfahrung diskutieren um den Lernprozess 

diesbezüglich ein wenig zu beschleunigen. Ich möchte jedoch zum 

wiederholten Male darauf hinweisen, dass Übung im Umgang mit OO Softwareentwicklung 

das Wichtigste überhaupt ist und durch keine Erklärung der 

Welt zu ersetzen ist! 

Fassen wir einmal kurz alles zusammen, was bisher bekannt ist und 

ergänzen die notwendigen Puzzleteilchen, die noch fehlen, um die Mechanismen 

in der Praxis anwenden zu können: 

• Module sind in sich abgeschlossene funktionale Einheiten. Sie enthalten 

eine Sammlung von Klassen, die diese Einheit aufspannen. 

• Klassen sind eine Möglichkeit, die Eigenschaften eines Objekttyps in der 

realen Welt zu modellieren. Zur Modellierung stehen folgende Mechanismen 

zur Verfügung: 

– Klassen bestimmen, welche Daten ein Objekt dieses Typs hält. Dies geschieht 

durch die Möglichkeit der Deklaration von sogenannten Member- 

Variablen, also Variablen, die einer Instanz dieser Klasse zu eigen sind. 

Member-Variablen sind prinzipiell innerhalb eines Objekts gekapselt und 

von außen nicht direkt zugreifbar. Welche Möglichkeiten man dabei hat, 

die Kapselung zu beeinflussen, ist von Programmiersprache zu Programmiersprache 

leicht verschieden. Für das Grundprinzip ist dies derzeit 

allerdings noch belanglos. 

– Klassen bestimmen, welche Daten allen Objekten dieses Typs gemeinsam 

sind. Dies geschieht durch die Möglichkeit der Definition (nicht 

Deklaration!) von sogenannten Class-Member-Variablen. Solche Class- 

Members haben die Eigenschaft, dass sich alle Instanzen ein und dieselbe 

Variable “teilen” und gemeinsam darauf zugreifen. Zum Beispiel kann 

es aus verschiedenen Gründen interessant sein, wie viele Instanzen einer 

Klasse zu einem gewissen Zeitpunkt gerade im System existieren. Dazu 

kann man einen Class-Member definieren, der einen Counter darstellt. 

Jede Instanz, die erzeugt wird, inkrementiert diesen und jede Instanz, 

die wieder zerstört wird, dekrementiert diesen. 

Anm.: Vorsicht ist in multithreaded Umgebungen geboten, damit man 

bei der Verwendung von Class-Members nicht in Synchronisationsprobleme 

läuft. 

– Klassen bestimmen, welche Interaktionen ein Objekt dieses Typs unterstützt. 

Dies geschieht durch die Deklaration von sogenannten Methoden 

oder auch Zugriffsmethoden. Eine Methode ist, salopp gesprochen, 

eine Funktion, die einer Instanz einer Klasse eigen ist und direkt über 

eine Instanz dieser Klasse aufgerufen wird. Manchmal werden Methoden 

auch als Member-Funktionen bezeichnet, allerdings ist der Begriff der 

Methode der häufiger verwendete, deshalb möchte ich dabei bleiben.


– Wie es bei den Daten die Class-Members gibt, so gibt es bei den Interaktionen 

die Class-Methods. Diese haben dieselbe Eigenschaft wie 

Class-Members, nämlich, dass sie sich nicht auf eine bestimmte Instanz 

beziehen, sondern losgelöst von den Einzelobjekten sind. Wie leicht einzusehen 

ist, kann mittels Class-Methods auch nur auf Class-Members zugegriffen 

werden und nicht auf die instanzbezogenen Member-Variablen, 

denn es fehlt ja der Bezug zu einer bestimmten Instanz einer Klasse. 

• Klassen können von einer oder mehreren sogenannten Elternklassen abgeleitet 

sein. Damit erben sie deren Eigenschaften und können selbst neue 

hinzufügen bzw. die geerbten Eigenschaften nach Bedarf (sinnvoll!) modifizieren. 

Die entstehende Ableitungshierarchie kann beliebig tief sein. 

• Objekte sind Instanzen von Klassen. Damit ergibt sich automatisch, dass 

jede Instanz einer Klasse einen eigenen Satz von Member-Variablen besitzt, 

wie sie durch die Klasse deklariert wurden. Außerdem beziehen sich die 

Methoden, die in der Klasse deklariert wurden, immer auf ein bestimmtes 

Objekt. Sie sind quasi lokal zum Objekt in dem Sinn, dass sie immer mit 

dem Variablensatz der Instanz arbeiten, auf der sie aufgerufen werden. 

Ich weiß schon – Einsteiger in die OO Programmierung wünschen sich gerade 

die Instanz Klaus Schmaranz der Klasse Buchautor, die abgeleitet von der 

Klasse Mensch ist, um auf diesem Objekt die Methode rückt ihm den Kopf 

zurecht aufzurufen. Mit einem kleinen Beispiel ist die Verwirrung aber schnell 

zu beheben, also sehen wir uns einfach an, wie das Modell aussieht, das es 

unterstützt, meinen Kopf zurechtzurücken: 

• Es gibt eine Klasse Head. Unter anderem hat diese Klasse folgende Eigenschaften: 

– Eine der Membervariablen, die darin deklariert sind, ist in_place und 

diese ist vom Typ bool. 

– Eine der Methoden, die darin deklariert sind, ist putInPlace. Aufruf 

derselben bewirkt ein Zurechtrücken, falls dies notwendig ist. 

• Es gibt eine Klasse Human. Unter anderem hat diese Klasse folgende Eigenschaften: 

– Eine der Membervariablen, die darin deklariert sind, ist name und diese 

hält den Namen des Menschen. 

– Eine weitere der Membervariablen, die darin deklariert sind, ist the_head 

und diese ist von der Klasse Head. 

– Eine der Methoden, die darin deklariert sind, ist putHeadInPlace. Aufruf 

derselben bewirkt ein Zurechtrücken des Kopfs, falls dies nötig ist. 

– Einer der Class-Members, die darin definiert sind, ist instance_counter. 

Dieser hält die derzeitige Anzahl von derzeit existierenden Menschen. 

• Es gibt eine Klasse Author, die von Human abgeleitet ist. In ihr werden 

die zusätzlichen Members (Variablen und Methoden) deklariert, die einen 

Menschen zum Buchautor machen. Auch wenn böse Zungen behaupten, 

dass diese Klasse nun zu Unrecht die Eigenschaft von Human geerbt hat,


einen Kopf zu besitzen – ich habe bereits erwähnt, dass es nicht möglich 

ist, Eigenschaften einfach wegzudefinieren :-). 

• Neben vielen anderen Instanzen von Author gibt es auch irgendwo eine 

Instanz, die Klaus Schmaranz entspricht, was sich durch den entsprechenden 

Eintrag im name Member äußert. Auf dieser Instanz ruft man 

putHeadInPlace auf, was alle notwendigen Schritte setzt, um wieder Hoffnung 

zu schöpfen. 

Um dieses Kapitel nun endgültig abzurunden, möchte ich hier noch die zwingenden 

Grundregeln zur Verwendung der OO Mechanismen angeben: 

In unseren Beispielen haben wir gesehen, dass eine spezielle Telefonklasse 

von einer allgemeinen Klasse Telefon abgeleitet ist. Ebenso war ein Buchautor 

von einer Klasse Mensch abgeleitet. Klingt auch logisch, denn das 

spezielle Telefon ist ein Telefon, nur mit Zusätzen und ein Autor ist auch 

sicher ein Mensch, nur mit zusätzlichen Eigenschaften. Das genau ist auch 

die semantische Bedeutung einer Ableitung: 

Eine Ableitung einer Klasse repräsentiert eine IS-A Relation. 

Wir haben auch gesehen, dass der Kopf eines Menschen in einer Membervariable 

gespeichert wurde und das genau entspricht auch deren semantischer 

Bedeutung: 

Eine Membervariable repräsentiert eine HAS-A Relation. 

Diese beiden Definitionen gelten natürlich auch als Umkehrschluss: 

• Wenn etwas durch IS-A im Modell beschreibbar ist, dann ist eine 

Ableitung das korrekte semantische Mittel zur Modellierung. 

• Wenn etwas durch HAS-A im Modell beschreibbar ist, dann ist 

eine Membervariable das korrekte semantische Mittel zur Modellierung. 

• Zu diesen beiden Regeln gibt es keine einzige Ausnahme! Jeder 

einzelne Verstoß gegen eine dieser beiden Regeln führt unweigerlich 

zur Katastrophe!!! 

Vorsicht Falle: Nicht nur von Neulingen wird allzu oft der Fehler begangen, 

Ableitungen falsch einzusetzen, nämlich in der Art, dass so etwas wie 

eine IS-LIKE-A Relation modelliert wird. Ein solches Konstrukt stellt einen 

groben Designfehler dar, der sich im Lauf der Designphase und später bei 

der Implementierung bitter rächt. 

Nur um ein Beispiel zu nennen, das ich leider sogar in der Literatur als 

sinnvolle Ableitung erwähnt gefunden habe: 

• Es gibt eine Klasse Array, die eine saubere Implementation eines dynamischen 

Arrays darstellt. 

• Es wird eine Klasse Stack entworfen. Weil es gerade so gut dazupasst, 

dass man die Elemente des Stacks in einem Array speichert, wird Stack 

von Array abgeleitet.


Dieses Design sagt also aus, dass ein Stack ein Array ist, und genau das 

ist vollkommener Nonsens! Ein Stack verwendet ein Array zur Speicherung, 

also darf hier niemals eine Ableitung herangezogen werden! Der Stack bekommt 

einfach eine Membervariable der Klasse Array, die er zur Speicherung 

verwendet. 

Die wahnwitzige Idee, einen Stack von einem Array abzuleiten, führt dazu, 

dass der Stack alle Eigenschaften eines Arrays erbt, also auch solche, die 

überhaupt nicht in seiner Natur liegen, wie z.B. indizierte Zugriffe auf die 

einzelnen Elemente. Damit wird dann noch vielleicht mit viel Würgen dem 

Stack die unerwünschte Funktionalität mittels Vergewaltigung von OO Konzepten 

abgewöhnt und schon ist der Wald-und-Wiesen-Hack perfekt, der einem 

spätestens bei der nächsten Änderung der Array Klasse um die Ohren 

fliegt.

9. Klassen in C++ 

Nachdem nun zumindest in der Theorie bekannt ist, was wir von Klassen 

und Objekten erwarten, wird es Zeit zu zeigen, wie diese Konzepte in C ++ 

umgesetzt sind. 

Vorsicht Falle: Obwohl ich noch nicht einmal begonnen habe, die technischen 

Details von Klassen zu besprechen, möchte ich schon den ersten Hinweis 

auf die gefährlichste Falle überhaupt geben, die sich C ++ Neulingen auftut. 

Leider zeigt die Erfahrung, dass sehr viele Entwickler nur Teile der Konzepte 

verinnerlicht haben, die C ++ bietet. Speziellere Konstrukte werden als 

“das brauche ich nicht” abgetan und einfach ignoriert. Nur eines von vielen 

typischen Beispielen für dieses Problem ist das Ignorieren der Existenz 

von virtual Ableitungen, zu denen wir später noch kommen werden, mit 

entsprechend absolut fatalen Folgen. 

Die große Gefahr dabei, die sogenannten Spezialitäten zu ignorieren, ist, 

dass dadurch oftmals Code entsteht, der aus technischen Gründen später wieder 

gravierend geändert oder sogar vollständig verworfen werden muss. Prominente 

Vertreter von kommerziell ausgelieferten Libraries, bei denen solche 

Pannen passiert sind, gibt es einige, allerdings möchte ich hier keinen davon 

namentlich nennen. Es genügt, zu wissen, dass es von praktisch allen wirklich 

großen Herstellern von Software und Entwicklungsumgebungen solche 

Wunderwerke gab und, leider muss man auch das sagen, immer noch gibt. 

Ich möchte also alle Leser ausdrücklichst bitten, alle in der Folge vorgestellten 

Konstrukte wirklich genauestens anzusehen und auch zu begreifen. 

Erst wenn man wirklich den Sinn hinter allem verstanden hat, ist man 

in der Lage, echtes C ++ zu schreiben, ohne in technische Fallen zu stolpern! 

Man kann nicht nur im Design vieles falsch machen, auch in der Umsetzung 

lauern noch mannigfaltige Gefahren!!! 

Um nun niemanden zu entmutigen: Es ist absolut erwünscht und sehr 

wichtig, sich mit allem einmal zu spielen und entsprechende Fehler zu machen. 

Aus Fehlern lernt man (manchmal sogar nur aus Fehlern). Solche Fehler 

sollen allerdings im Rahmen der Lern- und Spielphase passieren und nicht 

bei ernsthaften Projekten!

168 9. Klassen in C++ 

9.1 Besonderheiten von Structures in C++ 

Aus Abschnitt 2.4.2 sind Structures als Mittel zur Zusammenfassung von 

Daten zu einem Aggregat-Datentypen bekannt. Es wurde auch bereits darauf 

hingewiesen, dass sich noch mehr hinter Structures versteckt, als dort 

behandelt wurde. Genau dieses Mehr möchte ich hier als Überleitung zum 

allgemeinen Konzept der Classes in C ++ verwenden. Sehen wir uns dazu 

gleich ein kleines Beispiel an, das uns auf den Weg zu den Prinzipien der 

OO Entwicklung in C ++ bringt (struct_method_demo.cpp): 

1 // struct method demo . cpp − small demo , how methods can be 

2 // implemented f o r s t r u c t u r e s 

3 


5 #include < c s t r i n g> 

6 



9 

10 struct Name 

11 { 

12 char ∗ f i r s t n a m e ; 

13 char ∗ last name ; 

14 

15 void i n i t ( const char ∗ f i r s t n a m e , const char ∗ last name ) ; 

16 void setFirstName ( const char ∗ f i r s t n a m e ) ; 

17 void setLastName ( const char ∗ last name ) ; 

18 const char ∗ getFirstName ( ) ; 

19 const char ∗ getLastName ( ) ; 

20 } ; 

21 

22 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

23 void Name : : i n i t ( const char ∗ f i r s t n a m e , const char ∗ last name ) 

24 { 

25 i f ( ! f i r s t n a m e ) 

26 f i r s t n a m e = 0; 

27 else 

28 { 

29 f i r s t n a m e = new char [ s t r l e n ( f i r s t n a m e ) + 1 ] ; 

30 strcpy ( f i r s t n a m e , f i r s t n a m e ) ; 

31 } 

32 i f ( ! last name ) 

33 last name = 0; 

34 else 

35 { 

36 last name = new char [ s t r l e n ( last name ) + 1 ] ; 

37 strcpy ( last name , last name ) ; 

38 } 

39 } 

40 

41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 void Name : : setFirstName ( const char ∗ f i r s t n a m e ) 

43 { 

44 i f ( f i r s t n a m e ) 

45 delete [ ] f i r s t n a m e ; 

46 i f ( ! f i r s t n a m e ) 

47 f i r s t n a m e = 0; 

48 else 

49 { 

50 f i r s t n a m e = new char [ s t r l e n ( f i r s t n a m e ) + 1 ] ; 

51 strcpy ( f i r s t n a m e , f i r s t n a m e ) ; 

52 }

53 } 

54 

9.1 Besonderheiten von Structures in C++ 169 

55 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

56 void Name : : setLastName ( const char ∗ last name ) 

57 { 

58 i f ( last name ) 

59 delete [ ] last name ; 

60 i f ( ! last name ) 

61 last name = 0; 

62 else 

63 { 

64 last name = new char [ s t r l e n ( last name ) + 1 ] ; 

65 strcpy ( last name , last name ) ; 

66 } 

67 } 

68 

69 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

70 const char ∗Name : : getFirstName ( ) 

71 { 

72 return ( f i r s t n a m e ) ; 

73 } 

74 

75 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

76 const char ∗Name : : getLastName ( ) 

77 { 

78 return ( last name ) ; 

79 } 

80 

81 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


83 { 

84 Name one name ; 

85 one name . i n i t ( ”John” , ”Doe” ) ; 

86 

87 Name another name ; 

88 another name . i n i t ( ”Joe” , ”Smith” ) ; 

89 

90 cout


se Art der Deklaration macht aus einer allgemein aufrufbaren Funktion eine 

auf die Structure bezogene Methode. Der Begriff auf die Structure bezogen 

bedeutet, dass eine solche Methode auch nur direkt auf eine Instanz einer 

solchen Structure aufgerufen werden kann. Wie ein solcher Aufruf funktioniert, 

lässt sich leicht erraten, wenn wir daran denken, wie Member-Variablen 

einer struct angesprochen werden. Es wird einfach der Punkt-Operator dazu 

herangezogen (bzw. im Falle von Pointern natürlich der Pfeil-Operator). 

Die entsprechenden Aufrufe der Methoden sieht man in Zeile 85 und in der 

Folge. Zum Beispiel bedeutet das Statement in Zeile 85: Rufe die Methode 

init auf der Variable one_name mit den Parametern "John" und "Doe" auf. 

Ein Unterschied zu C fällt in Zeile 83 auf: Anstatt in gewohnter Manier 

für den Typ struct Name zu schreiben, steht hier einfach Name als Datentyp. 

Dies funktioniert in C ++ und es macht das sonst in C zur leichteren Lesbarkeit 

in diesem Zusammenhang verwendete typedef überflüssig. 

Ein wichtiges Detail zu Methoden wurde noch nicht besprochen: Die Deklaration 

derselben erfolgt innerhalb der struct, wie aber definiert man sie? 

Stellen wir uns vor, es gäbe in unserem Programm neben der struct Name 

auch noch eine struct Address. Stellen wir uns weiters vor, dass sinnvollerweise 

die Initialisierung bei beiden über die Methode init erfolgt. Wie teilen 

wir dann dem Compiler mit, welche der Definitionen der init Methoden nun 

zu welcher struct gehört? Dass man dies nicht über verschiedene Parameterlisten 

realisieren kann, versteht sich von selbst, denn das würde eine grobe 

Einschränkung darstellen. 

Des Rätsels Lösung zeigt sich z.B. in Zeile 23: Man verwendet den sogenannten 

Scope-Operator (::), der folgendermaßen funktioniert: Man gibt 

den Namen der struct an, gefolgt von ::, gefolgt vom Namen der Methode. 

Damit liest sich Zeile 23 so: Die Funktion init mit dem Scope auf 

die struct Name und den entsprechenden Parametern sieht folgendermaßen 

aus... Das bedeutet, dass man mittels des Scope Operators die entsprechende 

Zuordnung bei der Definition vornimmt. Bei der Deklaration ist diese Zuordnung 

natürlich nicht notwendig, denn durch das Auftreten der Deklaration 

innerhalb der struct ist dem Compiler die Zugehörigkeit sowieso klar. 

Für Leser, denen der Coding Standard, der diesem Buch zugrunde liegt, 

noch nicht geläufig ist, mag die Deklaration der Members in den Zeilen 12 und 

13 etwas komisch anmuten. Jedoch schreibt der Coding Standard vor, dass 

Member Variablen mit einem Unterstrich enden, um sie sofort als Members 

identifizieren zu können und von auto Variablen auf einen Blick unterscheiden 

zu können. Sieht man sich Zeile 26 an, so sieht man auch gleich, was 

es mit Members so auf sich hat. In der Definition der Methode Name::init 

werden die beiden Members first_name_ und last_name_ verwendet, als ob 

sie innerhalb des Scopes der Methode definiert wären. Genau das ist auch 

der Fall und das ist eine weitere Eigenschaft des Scope-Operators. Dadurch, 

dass init zum Scope von struct Name gehört, gehören auch die Members der 

struct Name zum aktuellen Scope und können daher ohne weitere Umschwei-

9.2 Einfache Klassen 171 

fe direkt angesprochen werden. Zeile 26 bedeutet also Folgendes: Weise dem 

Member first_name_ der struct Name den Wert 0 zu. 

Vorsicht Falle: Ein Teil der gängigen Praxis, die aus dem Coding Standard 

dieses Buchs resultiert, ist, dass es problemlos vorkommen kann, dass 

Parameter und Members quasi denselben Namen haben, nur dass eben Members 

durch einen Unterstrich am Ende gekennzeichnet sind. Wenn man den 

Coding Standard gewohnt ist, dann ist dies ein sehr angenehmes Feature, 

denn man muss nicht mit Gewalt einen neuen Namen für einen Parameter 

erfinden, der dann vielleicht ein wenig holprig ausfällt. 

Der Stolperstein bei dieser Praxis, der sich am Anfang auftut, ist, dass 

man noch nicht intuitiv beim Lesen auf den Unterstrich triggert und somit 

z.B. die Zeile 30 durch schlampiges Lesen auf den ersten Blick komisch 

aussieht. Der erste Parameter von strcpy, also first_name_, bezeichnet 

nämlich den entsprechenden Member und der zweite Parameter, also 

first_name, bezeichnet den Übergabeparameter der init Methode. 

Ich kann allerdings versichern, dass die Gewöhnungsphase an diesen Coding 

Standard, in der man solche Flüchtigkeitsfehler beim Lesen macht, sehr 

kurz ist. Ich kenne viele Leute, die genau nach diesem Coding Standard 

arbeiten und die sehr bald nicht das geringste Problem mehr beim Lesen 

solcher Programmzeilen hatten, weil der Underline am Ende in Fleisch und 

Blut übergegangen ist. 

Ich möchte nun an dieser Stelle keine näheren Ausführungen mehr über 

Structures bringen, da wir alles, was hier gesagt werden könnte, bei “echten” 

Classes wieder treffen werden. Structures sind in C ++ tatsächlich Classes, bei 

denen alle Members standardmäßig public sind. Was das bedeutet, sehen 

wir im kommenden Abschnitt, in dem wir uns endlich offiziell den Klassen und 

Objekten, mit all ihren Stärken (und auch Stolpersteinen), in C ++ zuwenden. 

9.2 Einfache Klassen 

Klassen in C ++ realisieren das Konzept, dass Entwickler neue Datentypen 

erstellen können, die genauso einfach und sinnvoll verwendet werden können, 

wie eingebaute Datentypen (z.B. int). Hinter allen Datentypen steckt immer 

ein Gesamtkonzept, z.B. gehören zu einem int natürlich auch die entsprechenden 

Operationen +, -, *, /, etc. Weiters ist definiert, wie ein int z.B. in 

einen float oder double umgewandelt werden kann. Solche Gesamtkonzepte 

lassen sich vollständig auch mit Klassen verwirklichen. 

Um nun nicht die üblichen Datums-, Vektor-, Matrix- und andere Klassen 

zur Erklärung heranzuziehen, die in verschiedensten Formen in mannigfaltigen 

Büchern und Tutorials zu Tode diskutiert wurden, möchte ich die 

Grundprinzipien an einem durchgehenden Beispiel aufbauend erklären. Die-


ses Beispiel soll in der Folge das allseits bekannte Spiel Memory sein. Für 

Leser, die dieses Spiel nicht kennen, ist es einfach erklärt: 

• Es gibt ein rechteckiges Gesamtspielfeld mit c Spalten und r Reihen, womit 

sich eine schachbrettartige Aufteilung in c ∗ r Einzelfelder ergibt. 

• Auf jedem Einzelfeld liegt eine Karte, die auf ihrer Vorderseite ein gewisses 

Symbol zeigt. Die Rückseiten aller Karten sind gleich und machen eine 

Unterscheidung der Karten unmöglich, wenn sie mit der Rückseite nach 

oben zu liegen kommen. 

• Die Symbole aller Karten zusammen, die auf dem Gesamtspielfeld zu liegen 

kommen, sind so aufgeteilt, dass es jeweils genau zwei Karten mit 

demselben Symbol gibt. 

• Die Verteilung der Karten auf das Gesamtspielfeld ist zufällig, es können 

also die jeweils zwei zusammengehörigen Symbolkarten auf beliebigsten 

Einzelfeldern zu liegen kommen. 

• Ein Spiel besteht nun aus folgenden Schritten: 

1. Genau so viele Karten wie es Einzelfelder gibt, werden zufällig mit der 

Rückseite nach oben auf das Gesamtspielfeld verteilt. 

2. Danach werden alle Karten am Gesamtspielfeld für einen kurzen Zeitraum 

umgedreht, sodass die Symbole auf ihren Vorderseiten zu sehen 

sind. Die Spielerin bzw. der Spieler hat in diesem kurzen Zeitraum 

Gelegenheit, sich die Symbole auf den einzelnen Feldern einzuprägen. 

3. Nach dieser kurzen Einprägephase werden alle Karten erneut umgedreht, 

sodass sie wieder ihre nicht unterscheidbaren Rückseiten zeigen. 

4. Die Spielerin bzw. der Spieler muss nun immer paarweise Karten aufdecken 

(=umdrehen), die das gleiche Symbol zeigen sollten. 

5. Zeigt ein aufgedecktes Paar auf beiden Karten das gleiche Symbol, so 

bleibt es aufgedeckt liegen. 

6. Zeigt ein aufgedecktes Paar zwei verschiedene Symbole, so werden beide 

Karten wieder umgedreht. 

• Ziel ist es, in so wenigen Schritten wie möglich, alle zusammengehörigen 

Paare gefunden zu haben und damit alle Karten umgedreht zu haben. 

Ich möchte nun an dieser Stelle keine ausführliche und eingehende Analyse der 

gesamten Problemstellung machen, da dies hier eher stören als nützen würde. 

Jedoch sei darauf hingewiesen, dass diese Analyse sehr wohl gemacht wurde 

und auch bei der Entwicklung gemacht werden muss, um auf ein vernünftiges 

Ergebnis zu kommen. Diese Gesamtanalyse folgt zur Wiederholung des 

Gelernten in Kapitel 10. Im Augenblick werden einfach die einzelnen Teile 

häppchenweise vorgestellt, die sich aus der Analyse ergeben haben. Ich 

möchte auch alle Leser bitten, die in der Folge vorgestellten Häppchen als 

noch nicht perfekt im Sinne von C ++ hinzunehmen. Der Grund dafür ist der, 

dass wirklich alle C ++ Mechanismen bekannt sein müssen, um alles so sauber 

wie möglich zu schreiben.


Zurück zum Thema: Betrachten wir als erste identifizierte Klasse eine 

Karte. Eine Möglichkeit, diese in C ++ zu modellieren, mit der entsprechenden 

Deklaration des gefundenen Modells, findet sich in folgendem Beispiel 

(memory_game_card.h): 

1 // memory game card . h − d e c l a r a t i o n o f the c l a s s MemoryGameCard 

2 

3 #ifndef memory game card h 

4 #define memory game card h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ 

8 ∗ MemoryGameCard 

9 ∗ 

10 ∗ model of a card as used in the game ”memory” 

11 ∗ 

12 ∗/ 

13 

14 class MemoryGameCard 

15 { 

16 protected : 

17 char ∗ symbol ; 

18 public : 

19 MemoryGameCard( const char ∗ symbol ) ; 

20 ˜MemoryGameCard ( ) ; 

21 

22 const char ∗ getSymbol ( ) ; 

23 void changeSymbol ( const char ∗ symbol ) ; 

24 } ; 

25 

26 

27 #endif // memory game card h 

Ganz bewusst wurde hier gleich der richtige Weg eingeschlagen, eine Klasse 

in einem Header File zu deklarieren und die Definition in ein eigenes cpp 

File zu verlegen, anstatt alles gemeinsam in ein File zu verpacken. Um eine 

Klasse verwenden zu können, muss dann nur noch der entsprechende Header 

inkludiert werden, wie wir weiter unten sehen werden. Wenden wir uns aber 

lieber den wichtigeren Dingen zu, die hier zu finden sind. 

In den Zeilen 14–24 sieht man, wie man eine Klasse deklariert. Dies 

geschieht gleich, wie die Deklaration einer Structure, nur dass statt des Keywords 

struct das Keyword class verwendet wird. Wir deklarieren hier also 

eine Klasse MemoryGameCard, die genau unter diesem Namen als Datentyp in 

Programmen verwendet werden kann. Wie das genau passiert und was dabei 

abläuft, wird später noch näher beleuchtet werden. 

Dass man in einer Klasse Member-Variablen und Methoden deklarieren 

kann und dass dies gleich passiert, wie wir es bei einer struct bereits kennen 

gelernt haben, versteht sich von selbst. Viel interessanter sind da schon 

die Zeilen 16 und 18. In diesen Zeilen werden durch die besonderen Labels 

protected: bzw. public: die Zugriffsrechte auf die einzelnen Members 

(Variablen wie auch Methoden) definiert. Für diese besonderen Labels ist 

auch der Name Access Specifiers gebräuchlich. Folgende Access Specifiers 

mit entsprechender Bedeutung sind in C ++ definiert:


private: Es dürfen ausschließlich Methoden der eigenen Klasse und friend 

Funktionen bzw. Klassen, zu denen wir noch später kommen werden, 

zugreifen. Der Zugriff von außen, sowie der Zugriff aus von dieser Klasse 

abgeleiteten Klassen heraus, ist verboten. 

protected: Es dürfen Methoden der eigenen Klasse, friend Funktionen 

bzw. Klassen, sowie Methoden aus abgeleiteten Klassen zugreifen. Der 

Zugriff für außenstehende Methoden und Funktionen ist nicht gestattet. 

public: Es dürfen alle Funktionen und Methoden, egal in welchem Verhältnis 

sie zur Klasse stehen, zugreifen. 

Sollte kein Access Specifier explizit angegeben sein, dann gilt alles bis zum 

Auftreten des ersten als private. Dies ist auch einer der Unterschiede zwischen 

Classes und Structures: Bei Classes gilt alles grundsätzlich als private, 

ist also nicht von außen zugreifbar, bei Structures gilt alles grundsätzlich als 

public, ist also von außen uneingeschränkt zugreifbar. 

Mir ist schon bewusst, dass bei der Beschreibung der Access Specifiers einige 

Dinge vorkommen, die bisher noch nicht bekannt sind. Bitte keine Panik 

deswegen, sobald wir zu den entsprechenden Konstrukten kommen, wird eine 

genauere Besprechung folgen. Ich wollte nur bereits hier ein vollständiges 

Bild der Möglichkeiten schaffen, um zu vermitteln, was es überhaupt gibt. 

Die Gültigkeitsbereiche von Access Specifiers sind so definiert, dass ein 

Specifier vom Punkt, an dem er steht, bis zum nächsten auftretenden Access 

Specifier bestimmend ist. Es ist auch möglich, dieselben Access Specifiers 

mehrfach innerhalb einer Klasse zu verwenden. Z.B. kann man zuerst einen 

private Block haben, danach einen public Block, gefolgt von einem erneuten 

private Block, etc. Der Grund für diese Regelung ist, dass man den 

Entwicklern Freiraum für die eigene Anordnung ihrer Deklarationen lässt und 

somit die Lesbarkeit erhöht. 

Eine Einschränkung möchte ich aus Gründen der Lesbarkeit allerdings 

unbedingt zum Standard erheben: Member-Variablen werden immer oben 

und Methoden immer erst danach deklariert. Eine Mischung, in der zuerst 

ein paar Variablen, danach ein paar Methoden und dann wieder ein paar 

Variablen deklariert werden, ist absolut unleserlich! Als Entwickler will man 

in jedem Fall auf einen Blick erfassen können, welche Variablen und Methoden 

es gibt, ohne gleich die gesamte Klassendeklaration vollständig durchsuchen 

zu müssen und vielleicht dabei etwas zu übersehen. 

Durch das Wissen um die Gültigkeitsbereiche der Access Specifiers ergibt 

sich also nun folgendes Bild: 

Die Member-Variable symbol_ ist nur innerhalb der eigenen Klasse und 

für abgeleitete Klassen zugreifbar (und natürlich auch für Friends). Alle 

Methoden in den Zeilen 19, 20, 22 und 23 sind für die Öffentlichkeit verfügbar. 

Sie definieren damit das sogenannte Public Interface der Klasse, also die 

Schnittstelle, über die man mit der Klasse regulär arbeiten kann. 

Ein Blick auf die Zeilen 19 und 20 legt allerdings bei manchen Lesern die 

Vermutung nahe, dass bei mir im Laufe des Schreibens ein gewisser Zustand


geistiger Umnachtung eingesetzt hat. Irgendwie sehen die beiden Konstrukte 

aus wie Deklarationen von Methoden, andererseits aber fehlt Entscheidendes, 

nämlich die Deklaration des return-Values. Vor allem hat sich in Zeile 20 

obendrein noch ein völlig unmotiviertes BIT-NOT vor dem Methodennamen 

eingeschlichen, das hier doch gar nicht erlaubt ist, oder??? 

Zu meiner Verteidigung kann ich nur sagen, dass ich vollkommen unschuldig 

bin! Diese beiden Methoden, nämlich Konstruktor in Zeile 19 und 

Destruktor in Zeile 20 sind tatsächlich genau so zu deklarieren. Per Definition 

wird der Konstruktor so deklariert (und definiert), dass er den Klassennamen 

als Methodennamen hat und die entsprechende Parameterliste, die zum 

Konstruieren eines Objekts dieses Typs notwendig ist. Der Destruktor hat 

den Klassennamen mit ~ als Präfix als Methodennamen und besitzt (sinnigerweise) 

eine leere Parameterliste. 

Der Konstruktor wird automatisch aufgerufen, wenn eine Instanz dieser 

Klasse erzeugt wird (also eine Variable angelegt wird), der Destruktor, wenn 

diese Instanz wieder zerstört wird (also eine Variable ihre Lifetime beendet 

hat). In Abschnitt 9.2.1 werden wir uns diesem Thema noch ein wenig 

eingehender widmen, derzeit genügt dieses Wissen für unsere weiteren Betrachtungen. 

Von außen betrachtet bietet ein Objekt vom Typ MemoryGameCard also 

folgende Funktionalität: 

• Man kann eine neue Karte erzeugen. Bei der Erzeugung muss man gleich 

ein entsprechendes Symbol mitgeben. Diese Eigenschaft ist gefordert, da 

es nur einen Konstruktor mit einem Symbol als Parameter gibt. Eine leere 

Karte ist also nicht erzeugbar. 

• Das Symbol, das zu einer Karte gehört, ist in unserem Fall einfach ein 

String. Zugegeben, dieses Verhalten ist nicht das tollste, aber für Demonstrationszwecke 

bleiben wir einmal dabei. 

• Man kann eine Karte nach dem Symbol fragen. 

• Man kann das Symbol einer Karte ändern. Je nach Anwendungszweck 

kann man natürlich nun darüber streiten, ob es überhaupt sehr klug ist, 

dies zuzulassen. Aber das ist eine andere Diskussion :-). 

Was explizit durch protected verboten ist, ist ein direkter Zugriff von außen 

auf die Member-Variable symbol_. Dadurch ist gewährleistet, dass symbol_ 

immer nur mittels Zugriffsmethoden oder von abgeleiteten Klassen heraus 

direkt angegriffen werden darf, was eventuelle Inkonsistenzen verhindert. Zugegeben, 

bei dieser Klasse erscheint dies etwas pingelig, aber wir werden noch 

genügend Fälle kennen lernen, in denen ein solcher Schutz lebensnotwendig 

sein kann. 

Die Implementation der einzelnen Methoden, die in der Klasse deklariert 

wurden, erfolgt getrennt im File memory_game_card.cpp:


1 // memory game card . cpp − d e f i n i t i o n o f the methods o f MemoryGameCard 

2 

3 #include ”memory game card . h” 

4 


6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 /∗ constructor of MemoryGameCard 

9 ∗ 

10 ∗ @param symbol the symbol represented by t h i s card 

11 ∗/ 

12 

13 MemoryGameCard : : MemoryGameCard( const char ∗ symbol ) 

14 { 

15 i f ( ! symbol ) 

16 { 

17 symbol = 0; 

18 return ; 

19 } 

20 symbol = new char [ s t r l e n ( symbol ) + 1 ] ; 

21 strcpy ( symbol , symbol ) ; 

22 } 

23 

24 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

25 /∗ d e s t r u c t o r of MemoryGameCard 

26 ∗/ 

27 

28 MemoryGameCard : : ˜ MemoryGameCard( ) 

29 { 

30 i f ( symbol ) 

31 delete [ ] symbol ; 

32 } 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 /∗ 

36 ∗ @return the symbol that t h i s card r e p r e s e n t s 

37 ∗/ 

38 

39 const char ∗MemoryGameCard : : getSymbol ( ) 

40 { 

41 return ( symbol ) ; 

42 } 

43 

44 

45 

46 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

47 /∗ 

48 ∗ @param symbol the symbol represented by t h i s card 

49 ∗/ 

50 

51 void MemoryGameCard : : changeSymbol ( const char ∗ symbol ) 

52 { 




56 { 


58 return ; 

59 } 



62 }


Im Prinzip treffen wir in diesem File nur alte Bekannte, dementsprechend 

erübrigt sich eine genaue Diskussion über die Interna. Wie man sieht, wird 

der Scope Operator bei Klassen genau gleich angewandt, wie wir ihn schon 

bei Structures kennen gelernt haben, um die Zugehörigkeit einer Methode zu 

einer Klassendefinition zu signalisieren. Auch hier gelten dieselben Regeln für 

den default Scope der Methode, wie man z.B. in Zeile 17 sieht: Die Zuweisung 

auf symbol_ bezeichnet natürlich eine Zuweisung auf den Member symbol_ 

der entsprechenden Instanz der Klasse. 

Wie man jetzt mit unserer fertig deklarierten, definierten und implementierten 

Klasse arbeiten kann, zeigt das folgende kleine Testprogrämmchen 

(memory_game_card_test.cpp): 

1 // memory game card test . cpp − simple t e s t program f o r MemoryGameCard 

2 


4 #include ”memory game card . h” 

5 



8 


10 { 

11 MemoryGameCard t e s t c a r d ( ”Symbol A” ) ; 

12 

13 cout


hinter sich hat, also beim Verlassen des Blocks durch das return Statement 

in Zeile 20. 

Um das Testprogramm ordnungsgemäß übersetzen zu können, müssen 

die beiden C ++ Source Files compiliert und die resultierenden Object-Files 

zu einem Executable gelinkt werden. Dass es nicht so toll ist, dies “zu Fuß” 

zu machen, versteht sich von selbst. Dementsprechend wird das Tool make 

mit dem folgenden Makefile verwendet (MemoryGameCardTestMakefile): 

1 OBJS = memory game card test . o \ 

2 memory game card . o 

3 CC = g++ 

4 LD = g++ 

5 EXTRA CCINCLUDES = 

6 CC FLAGS = −c $ (EXTRA CCINCLUDES) −Wall 

7 EXTRA LIBDIRS = 

8 EXTRA LIBS = 

9 EXECUTABLE = memory game card test 

10 LD FLAGS = −o $ (EXECUTABLE) $ (EXTRA LIBDIRS) $ (EXTRA LIBS) 

11 

12 memory game card test : $ (OBJS) 

13 $ (LD) $ (LD FLAGS) $ (OBJS) 

14 

15 memory game card test . o : memory game card test . cpp \ 

16 memory game card . h 

17 $ (CC) $ (CC FLAGS) memory game card test . cpp 

18 

19 memory game card . o : memory game card . cpp \ 

20 memory game card . h 

21 

22 a l l : memory game card test 

23 

24 clean : 

25 rm $ (OBJS) $ (EXECUTABLE) 

Lesern, denen die Funktionsweise von make und das Erstellen von Makefiles 

nicht geläufig ist, möchte ich kurz die Lektüre von Kapitel 15 aus Softwareentwicklung 

in C empfehlen. Dort werden alle notwendigen Schritte genau 

diskutiert. 

Wenn alles glatt gegangen ist und wir das Programm starten, dann 

beglückt es uns mit folgendem, unglaublich tollen Output: 

t e s t c a r d a f t e r construction : Symbol A 

t e s t c a r d a f t e r changeSymbol : Symbol B 

9.2.1 Konstruktor und Destruktor genauer beleuchtet 

Da die Aufrufe des Konstruktors und des Destruktors vom Compiler implizit 

eingesetzt werden, möchte ich an dieser Stelle etwas Licht auf die Vorgänge 

hinter den Kulissen werfen. Sehen wir uns dazu einmal ganz kurz den Lebenszyklus 

einer beliebigen Variable an:


1. Es wird Speicher für die Variable reserviert. Die Größe des Speichers 

ist bestimmt durch den Typ der Variable und durch gewisse andere systeminterne 

Gegebenheiten. In jedem Fall wird garantiert, dass genug 

reserviert wird, um die Daten dem verwendeten Typ gemäß zu halten. 

2. Nach der Reservierung des Speichers folgt die Initialisierung der Variable. 

3. Mit der fertig initialisierten Variable kann man ab jetzt arbeiten, wie es 

durch ihren Typ vorgegeben ist. 

4. Wenn eine Variable ihre Lifetime beendet hat, wird sie “weggeräumt”. 

Der erste Schritt beim “Wegräumen” ist, dass eventuell notwendige explizite 

“Aufräumarbeiten” durchgeführt werden. 

5. Wenn alle notwendigen “Aufräumarbeiten” beendet sind, wird der Speicher, 

der von der Variable belegt war, wieder freigegeben. 

Genau die Punkte 2 und 4 sind es, die beim Arbeiten mit Klassen und 

Objekten für uns hier interessant sind. Es wird nämlich bei Punkt 2 vom 

Compiler der Aufruf des entsprechenden Konstruktors eingesetzt, der der 

gewünschten Initialisierung entspricht. Bei Punkt 4 wird der Aufruf des 

Destruktors eingesetzt. Haben wir es also mit einfachen (=nicht abgeleiteten) 

Klassen zu tun, so sieht der Lifecycle eines Objekts dieser Klasse genau 

folgendermaßen aus: 

1. Speicher reservieren. 

2. Entsprechenden Konstruktor aufrufen. 

3. Objekt lebt und mit ihm kann gearbeitet werden. 

4. Zu Ende der Lifetime Destruktor aufrufen. 

5. Speicher freigeben. 

Das Prinzip des Overloadings gilt natürlich nicht nur für Funktionen in C ++, 

sondern auch für Methoden. Da der Konstruktor eine solche darstellt, ist 

selbstverständlich auch hier ein Overloading möglich. Man kann also verschiedene 

Konstruktoren mit verschiedenen Parametersätzen zur Verfügung 

stellen, die entsprechend sinnvollen Initialisierungsbedürfnissen entsprechen. 

Eine gewisse Sonderstellung nimmt hierbei der sogenannte default Konstruktor 

ein, also der Konstruktor, der keinen Parameter entgegennimmt. Im 

weiter unten folgenden Beispiel werden wir diesen noch kurz genauer kennen 

lernen. 

Vorgreifend möchte ich auch noch erwähnen, dass eine ähnliche Sonderstellung 

vom sogenannten Copy Konstruktor eingenommen wird. Dieser wird 

gesondert in Abschnitt 9.2.2 behandelt um hier nicht für Verwirrung zu sorgen. 

Im Gegensatz zum Konstruktor ist ein Overloading des Destruktors nicht 

möglich. Es kann ausschließlich immer nur genau einen Destruktor geben, 

nämlich den, der keine Parameter entgegennimmt. Warum das so ist, ist 

auch leicht einzusehen: Der Aufruf des Destruktors wird vom Compiler am 

Ende der Lifetime eines Objekts eingesetzt. Bei einer auto-Variable also 

beim Verlassen des Blocks, in dem sie definiert wurde. Wie soll nun der


Compiler wissen, welche von verschiedenen Möglichkeiten des Destruktors 

er dort einsetzen soll? Vor allem gibt es ja auch keine Möglichkeit, ihm 

mitzuteilen, welche Parameterwerte überhaupt eingesetzt werden müssten, 

sollte ein Destruktor irgendwelche Parameter entgegennehmen können. Der 

Compiler bestimmt ja, wann die Lifetime einer Variable zu Ende ist, dies wird 

(außer bei dynamischer Memory Verwaltung) niemals von den Entwicklern 

explizit angegeben. 

Wie im Rahmen des Life-Cycles eines Objekts die Aufrufe von Konstruktoren 

und Destruktor passieren, lässt sich am einfachsten an einem Beispiel 

demonstrieren 

(simple_constr_destr_demo.cpp): 

1 // simple constr destr demo . cpp − constructor and d e s t r u c t o r demo 

2 


4 



7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ 

10 ∗ SimpleConstrDestrDemo 

11 ∗ 

12 ∗ Simple demo c l a s s f o r c o n s t r u c t o r s and d e s t r u c t o r 

13 ∗ 

14 ∗/ 

15 

16 class SimpleConstrDestrDemo 

17 { 

18 private : 

19 int j u s t a n i n t v a l u e ; 

20 const char ∗ j u s t a s t r i n g v a l u e ; 

21 public : 

22 SimpleConstrDestrDemo ( ) ; 

23 SimpleConstrDestrDemo ( int a param ) ; 

24 SimpleConstrDestrDemo ( const char ∗ a param ) ; 

25 ˜SimpleConstrDestrDemo ( ) ; 

26 } ; 

27 

28 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

29 /∗ d e f a u l t constructor 

30 ∗/ 

31 

32 SimpleConstrDestrDemo : : SimpleConstrDestrDemo ( ) 

33 { 

34 cout

49 } 

50 


51 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

52 /∗ 

53 ∗ @param a param j u s t a s t r i n g parameter f o r demo purposes 

54 ∗/ 

55 

56 SimpleConstrDestrDemo : : SimpleConstrDestrDemo ( const char ∗ a param ) 

57 { 

58 cout


Objekt, das zuletzt angelegt wurde, als Erstes zerstört wird. Dies ist auch das 

normale Verhalten, das praktisch alle Compiler zeigen werden, denn die auto- 

Variablen liegen ja auf dem Stack und werden entsprechend beim Abbauen 

desselben zerstört. 

Noch ein kleiner Exkurs: Aus Gründen der Übersichtlichkeit habe ich 

hier die Deklaration der Klasse zusammen mit der Definition der Methoden 

gemeinsam in ein Source File gesteckt. Dies ist im Entwickleralltag natürlich 

keinesfalls nachzuahmen. Dort ist eine saubere Aufteilung in .h (für die Klassendeklaration) 

und .cpp Files (für die Definition der Methoden) in jedem 

Fall vorzunehmen. 

Nach diesen beiden kleinen Exkursen zurück zum Thema: In den Zeilen 

22–24 des Programms findet man die Deklarationen der verschiedenen 

möglichen Konstruktoren für die Klasse SimpleConstrDestrDemo. Man kann 

also Objekte auf eine der dadurch festgelegten Arten anlegen: 

• Ohne Parameter, wobei der default Konstruktor aus Zeile 22 aufgerufen 

wird. 

• Mit einem int Parameter, wobei der Konstruktor aus Zeile 23 aufgerufen 

wird. 

• Mit einem char * als Parameter, wobei der Konstruktor aus Zeile 24 aufgerufen 

wird. 

Die Konstruktoren werden gemäß den Regeln des Overloadings, die wir bereits 

in Kapitel 5 kennen gelernt haben, vom Compiler ausgewählt. Sollte 

sich keine sinnvolle Übereinstimmung ergeben, dann führt dies natürlich zu 

einem Fehler. 

Es ist aufgrund des zuvor skizzierten Lifecycles von Objekten garantiert, 

dass ein Konstruktor erst aufgerufen wird, wenn auf jeden Fall schon der 

Speicher für das Objekt reserviert wurde. Man hat es also innerhalb des 

Konstruktors mit einem angelegten, aber nicht initialisierten Objekt zu tun. 

Es wurde bereits erwähnt, dass der default Konstruktor eine gewisse Sonderstellung 

einnimmt. In Zeile 78 sieht man auch, was es damit auf sich hat: 

Man legt einfach eine Variable der gewünschten Klasse an, ohne irgendwelche 

runden Klammern dahinter zu schreiben. Im Gegensatz dazu gibt man 

bei Initialisierungen mittels anderer Konstruktoren die Initialisierungsparameter 

in runden Klammern hinter dem Variablennamen an, wie man in den 

Zeilen 79 und 80 sieht. 

Vorsicht Falle: Die Sonderbehandlung des default Konstruktors, der ohne 

runde Klammern geschrieben wird, stellt eine kleine Inkonsistenz bezüglich 

der Intuitivität und der Einheitlichkeit von Code dar. Aus diesem Grund 

passiert es C ++ Neulingen nur allzu leicht, dass sie Statements wie z.B. das 

folgende schreiben: 

SimpleConstrDestrDemo testvar1();


Leider wird dies aber vom Compiler nicht so interpretiert, dass man eine 

Variable testvar1 anlegen will und dazu den default Konstruktor verwenden 

will. Stattdessen interpretiert dies der Compiler als Funktionsdeklaration und 

entsprechend sehen dann auch die Fehlermeldungen sowohl des Compilers 

als auch danach des Linkers aus. Diese Fehlermeldungen sind auch zumeist 

kryptisch genug, dass man nicht sofort auf den tatsächlichen Fehler kommt, 

nämlich, dass die runden Klammern nicht angebracht waren. 

Der default Konstruktor hat noch eine weitere Sonderstellung in C ++: Es 

gibt auch die Möglichkeit, für eine Klasse keinen einzigen Konstruktor zu 

deklarieren und definieren. In diesem Fall wird vom Compiler implizit ein 

default Konstruktor erzeugt, der folgende Eigenschaften hat: 

• Für alle Members, denen selbst benutzerdefinierte Datentypen (=Klassen) 

zugrunde liegen (also keine primitiven Datentypen wie z.B. int, etc.) wird 

die default Konstruktion veranlasst und damit kommt es zu einer Initialisierung 

derselben. 

• Für alle Members, die primitive Datentypen sind, wird keine implizite 

Initialisierung vorgenommen. Diese Members enthalten also damit 

rein zufällige Werte. Der Grund für dieses Verhalten ist die Angst vor 

unnötigem Runtime-Overhead durch Initialisierungsschritte. Meiner Meinung 

nach allerdings ist der entstehende Overhead ein viel geringeres Problem 

als die Gefahr, die man sich durch das Fehlen einer Initialisierung 

einhandelt. 

Vorsicht Falle: Es wird als guter Programmierstil angesehen, jeder Klasse 

einen default Konstruktor zu spendieren, der auf jeden Fall alle Members 

dieser Klasse korrekt initialisiert. Verlässt man sich auf den vom Compiler 

eingesetzten default Konstruktor, so kann es aus den zuvor genannten 

Gründen zu bösen Überraschungen kommen! 

Obwohl bereits implizit gesagt, möchte ich eine Eigenschaft des vom Compiler 

eingesetzten default Konstruktors hier noch einmal explizit festhalten: 

Er wird ausschließlich dann erzeugt, wenn für eine Klasse überhaupt kein 

Konstruktor deklariert wurde. Sollte auch nur ein einziger Konstruktor deklariert 

worden sein, egal, welche Parameter dieser nimmt, dann wird der 

default Konstruktor nicht erzeugt. Dadurch erreicht man, dass man als 

Designer von Klassen Entwickler zwingen kann, eine explizite Initialisierung 

vorzunehmen. Je nach Anwendungsfall kann dies auch ausgesprochen notwendig 

sein. 

Was für den default Konstruktor gilt, gilt auch für den Destruktor: Wird 

explizit kein Destruktor deklariert und definiert, so wird vom Compiler einer 

eingesetzt. Auch hier wird einfach nur Code erzeugt, der dafür sorgt, dass 

Members benutzerdefinierter Datentypen korrekt inklusive Destruktoraufrufen 

zerstört werden. Primitive Datentypen werden nicht angegriffen. Hat


man also einen Member, der dynamisch allokierten Speicher hält, so wird 

dieser nicht automatisch freigegeben. 

Es wird garantiert, dass der Destruktor aufgerufen wird, solange für das 

Objekt noch vollständig Speicher reserviert ist. Das Freigeben des Speichers 

erfolgt erst danach. Damit kann man auf jeden Fall innerhalb des Destruktors 

gefahrlos auf alle Members des Objekts zugreifen. 

Vorsicht Falle: Es wird als guter Programmierstil angesehen, jeder Klasse 

auf jeden Fall einen Destruktor zu spendieren, auch wenn dieser im schlimmsten 

Fall leer ist. Durch einen leeren Destruktor hat man zumindest offiziell 

festgelegt, dass nichts Besonderes zu tun ist. Vergisst man z.B. das explizite 

Aufräumen von dynamisch allokiertem Speicher, dann bekommt man 

ein wachsendes Programm, was wiederum für einige schlaflose Nächte der 

Entwickler sorgt. Wenn man sich angewöhnt, immer einen Destruktor zu 

deklarieren und definieren, dann erinnert einen ein solcher bei einer späteren 

Änderung des Klassencodes (z.B. Einführen einer neuen dynamischen 

Variable) sofort beim Ansehen der Klassendeklaration daran, dass hier noch 

etwas zu tun wäre. Somit ist die Gefahr des Vergessens auf jeden Fall etwas 

geringer :-). 

Nur für Leser, die diese Falle im Zuge des Nachschlagens lesen, ein kurzer 

Vorgriff (alle anderen können diesen Hinweis übergehen): Wir werden 

in späterer Folge noch eine besondere Eigenschaft des Destruktors kennen 

lernen, nämlich, dass dieser unbedingt virtual sein muss. Auch dies ist in 

jedem Fall zu beachten, denn die reine Existenz eines Destruktors garantiert 

noch kein vollständig korrektes und funktionsfähiges Programm! 

Der Vollständigkeit halber möchte ich hier noch erwähnen, dass man sowohl 

Konstruktor als auch Destruktor nicht unbedingt public machen muss, 

sondern dass man sehr wohl auch andere Access Specifiers für diese verwenden 

kann. Wir werden später noch im Zuge von Beispielen mehrere sehr 

sinnvolle Anwendungen dafür kennen lernen. Derzeit allerdings würde eine 

Diskussion darüber den Rahmen sprengen. 

9.2.2 Der Copy Konstruktor 

Um die Sonderstellung des sogenannten Copy Konstruktors zu erkennen, sehen 

wir uns einmal folgenden Code an: (implicit_copy_constr_demo.cpp): 

1 // implicit copy constr demo . cpp − demo f o r an i m p l i c i t copy 

2 // constructor 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

11 /∗ 

12 ∗ JustAClass 

13 ∗ 

14 ∗ j u s t a dummy c l a s s f o r demo purposes 

15 ∗ 

16 ∗/ 

17 

18 class JustAClass 

19 { 

20 uint32 a v a l u e ; 

21 public : 

22 JustAClass ( ) ; 

23 JustAClass ( uint32 value ) ; 

24 ˜JustAClass ( ) ; 

25 

26 uint32 getValue ( ) ; 

27 } ; 

28 


29 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

30 /∗ d e f a u l t constructor 

31 ∗/ 

32 JustAClass : : JustAClass ( ) 

33 { 

34 cout


77 

78 cout

25 ˜JustAClass ( ) ; 

26 

27 uint32 getValue ( ) ; 

28 } ; 


Ich habe hier bewusst nicht noch einmal das gesamte Programm abgedruckt, 

sondern möchte nur auf die Änderungen eingehen. In Zeile 24 sieht man, wie 

ein Copy Konstruktor definiert ist: Er nimmt als Parameter eine Referenz auf 

ein Objekt vom “eigenen” Typ. Dass dieser Referenzparameter sinnigerweise 

eine const Referenz sein muss, ist auch einleuchtend, denn wie sollte sonst 

eine Kopie eines konstanten Objekts erstellt werden? Die Implementation 

des Copy Konstruktors sieht dann natürlich so aus: 

51 JustAClass : : JustAClass ( const JustAClass & s r c ) 

52 { 

53 cout


Die Antwort, warum das passiert, findet sich in der Tatsache, dass in 

C ++ Aufrufe von Methoden ja mittels call-by-value stattfinden. Das bedeutet, 

dass bei der Übergabe des Objekts eine Kopie erstellt wird! Hierbei 

wird natürlich mangels eines expliziten Copy Konstruktors der implizite, vom 

Compiler generierte, eingesetzt. 

Diese mörderische Gefahrenquelle lässt sich in ihren verschiedensten Ausprägungen 

einzig und allein durch konsequentes Einhalten der folgenden Konvention 

in den Griff bekommen: 

• Jede Klasse muss einen expliziten Copy Konstruktor besitzen!!!!! 

• Sollte es absolut nicht erwünscht sein, dass der Copy Konstruktor 

aufgerufen wird, so ist dieser private zu deklarieren. Keinesfalls 

darf er aber weggelassen werden! 

Um nun bösen Kommentaren vorzubeugen, dass ich mich in diesem Buch 

selbst nicht an diese Konvention halten würde: Je nachdem, was ein Codebeispiel 

in diesem Buch demonstrieren soll, habe ich immer versucht, mich 

auf das Wesentliche zu beschränken, das der Demonstration dient. Hierbei 

wurde in einigen Fällen auf gewissen Ballast verzichtet, um nicht unnötige 

Verwirrung zu stiften. Manchmal war auch der Copy Konstruktor ein solcher 

Ballast. In der Praxis allerdings bin ich bei solchen Konventionen tatsächlich 

immer konsequent :-). 

9.2.3 Initialisierung vs. Zuweisung 

Manche Leser mögen schon manchmal den Kopf darüber geschüttelt haben, 

dass ich so pingelig auf dem Begriff der Initialisierung herumreite und betone, 

dass eine Initialisierung nicht dasselbe ist, wie eine Zuweisung. Am 

folgenden Beispiel lässt sich sehr einfach erkennen, dass der Compiler meine 

Meinung teilt und ebenso pingelig ist :-). Nehmen wir wieder unsere Klasse 

JustAClass von zuvor (die Variante incl. Copy Konstruktor) und schreiben 

main folgendermaßen um (initialization_demo.cpp): 


77 { 

78 JustAClass t e s t v a r 1 = 10; 

79 JustAClass t e s t v a r 2 = t e s t v a r 1 ; 

80 

81 cout


diese beiden Zeilen überhaupt so hinschreiben kann, verrät uns der Output 

des Programms: 

JustAClass : constructor with uint32 

JustAClass : copy constructor 

The values stored in the v a r i a b l e s are : 

t e s t v a r 1 : 1 0 

t e s t v a r 2 : 1 0 

JustAClass : d e s t r u c t o r 

JustAClass : d e s t r u c t o r 

Zeile 78 resultiert in einem Aufruf unseres speziellen Konstruktors mit dem 

uint32 Parameter und Zeile 79 resultiert im Aufruf unseres Copy Konstruktors. 

Der Compiler sucht also definitiv bei einer Initialisierung nach einem 

entsprechenden Konstruktor. Gibt es einen solchen, so wird er eingesetzt, gibt 

es ihn nicht, dann resultiert dies in einem Compilerfehler! Wir können also 

bei Konstruktoren, die nur einen Parameter nehmen, wahlweise die Klammer- 

Schreibweise oder die = Schreibweise verwenden. Das Resultat ist dasselbe. 

Im Rahmen des Operator Overloadings wird der Unterschied zwischen Initialisierung 

und Zuweisung noch einmal in einem anderen Kontext aufgegriffen 

(siehe Abschnitt 12.1). 

9.2.4 Deklarieren von Konstruktoren als explicit 

Es gibt Fälle, in denen das implizite Einsetzen eines bestimmten Konstruktors 

im Rahmen einer Initialisierung mittels = als zu gefährlich und fehlerträchtig 

erscheint. Das folgende Beispiel demonstriert diesen Umstand 

(implicit_constructor_problem.cpp): 

1 // i m p l i c i t c o n s t r u c t o r p r o b l e m . cpp − demo f o r problems with 

2 // i m p l i c i t c o n s t r u c t o r s 

3 




7 



10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

12 /∗ 

13 ∗ DummyString 

14 ∗ 

15 ∗ j u s t a dummy s t r i n g c l a s s f o r demo purposes 

16 ∗ 

17 ∗/ 

18 

19 class DummyString 

20 { 

21 char ∗ s t r i n g ; 

22 uint32 l e n g t h ; 

23 public : 

24 DummyString( uint32 length ) ; 

25 DummyString( const char ∗ s t r ) ; 

26 DummyString( const DummyString & s r c ) ; 

27 ˜DummyString ( ) ; 

28 } ;


29 

30 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

31 /∗ s p e c i a l constructor 

32 ∗/ 

33 DummyString : : DummyString( uint32 length ) 

34 { 

35 cout


String auch einfach mit einem char initialisieren kann. Der Compiler hat 

sich auch in keinster Weise darüber beschwert, der Output des Programms 

zeigt jedoch, dass hier nicht wirklich das passiert, was man gerne hätte: 

DummyString : constructor with s t r i n g 

DummyString : copy constructor 

DummyString : constructor with length 

DummyString : d e s t r u c t o r 



Sieht man sich die dritte Zeile des Outputs an, so wird doch glatt hier der 

Konstruktor aufgerufen, der als Parameter die Länge des Strings enthält! 

Was aber wahrscheinlich beabsichtigt war, war die Initialisierung des Strings, 

so dass er einfach ein x enthalten sollte. Der Compiler, der von der Absicht 

der Entwickler keine Ahnung hat, hat das allerdings ganz anders gesehen: Er 

hat einen Konstruktor gesucht, der als Datentyp einen char nimmt. Diesen 

gibt es nicht. Sehr wohl aber gibt es einen Konstruktor, der dazu kompatibel 

ist, nämlich den Konstruktor, der die Länge als Parameter nimmt. Ein char 

ist ja eine Ganzzahl und der Konstruktor nimmt eine Ganzzahl. Also ist mit 

einer kleinen Typumwandlung alles bestens – oder, wie in unserem Fall hier, 

ganz und gar nichts mehr in Ordnung. 

Zum Glück gibt es einen sauberen Weg, es gleich gar nicht zu einer solchen 

Gefahr kommen zu lassen: Man kann dem Compiler mitteilen, dass 

bestimmte Konstruktoren niemals implizit eingesetzt werden sollen, sondern 

nur explizit aufgerufen werden dürfen. Das Zauberwort dazu nennt sich intuitiverweise 

explicit. Vorausschauende Entwickler würden also die String 

Klasse folgendermaßen deklarieren (forcing_explicit_constructor.cpp): 

19 class DummyString 

20 { 

21 char ∗ s t r i n g ; 

22 uint32 l e n g t h ; 

23 public : 

24 explicit DummyString( uint32 length ) ; 

25 DummyString( const char ∗ s t r ) ; 

26 DummyString( const DummyString & s r c ) ; 

27 ˜DummyString ( ) ; 

28 } ; 

In Zeile 24 wurde der gefährliche Konstruktor als explicit deklariert. Wie 

man an folgender Implementation von main sieht, ist hiermit die Fehlverwendung 

unterbunden, denn Zeile 81 würde in einem Compilerfehler resultieren: 


77 { 

78 DummyString s t r i n g 1 = ” otto ” ; 

79 DummyString s t r i n g 2 = s t r i n g 1 ; 

80 // the f o l l o w i n g l i n e would r e s u l t in a compiler e r r o r 

81 // DummyString s t r i n g 3 = ’ x ’ ; 

82 

83 // t h i s works , because of the e x p l i c i t c a l l 

84 DummyString s t r i n g 4 ( 1 2 ) ;


85 

86 return ( 0 ) ; 

87 } 

Zeile 84 jedoch, die einen expliziten Konstruktoraufruf enthält, funktioniert 

wie geplant. Es sollte also beim Deklarieren von Konstruktoren für eine Klasse 

bei allen Lesern immer daran gedacht werden, unter welchen Umständen 

der Compiler für ein Objekt einen impliziten Konstruktoraufruf einsetzt: 

• Bei Verwendung von = zur Initialisierung mit einem Wert wird ein passender 

Konstruktor gesucht. 

• Bei Übergabe als Parameter an eine Methode oder Funktion aufgrund des 

call-by-value Mechanismus wird der Copy Konstruktor aufgerufen. 

• Bei Verwendung in einem return Statement wird der Copy Konstruktor 

aufgerufen, denn auch der return-Value wird ja by-value geliefert. 

• Bei Verwendung als Exception wird der Copy Konstruktor aufgerufen (dazu 

kommen wir noch in Kapitel 11). 

Sollte in irgendeinem dieser Fälle der implizite Aufruf gefährlich sein, so muss 

ein Konstruktor als explicit deklariert werden. 

9.2.5 Object- und Class-Members 

In Abschnitt 8.3 wurde bereits erwähnt, dass es auch sogenannte Class- 

Members gibt. Dies sind solche Members, die allen Instanzen einer Klasse 

gemeinsam sind, anstatt für jedes Objekt extra zu existieren. Solche Members 

(Variablen oder auch Methoden) deklariert man dadurch, dass man sie 

static setzt, wie folgende kleine Veränderung unserer Kartenklasse für das 

Memory Spiel zeigt. Diese protokolliert selbsttätig mit, wie viele Karten 

eigentlich im Programm insgesamt existieren (memory_game_card_v2.h): 

1 // memory game card v2 . h − extension o f c l a s s MemoryGameCard 

2 

3 #ifndef memory game card v2 h 

4 #define memory game card v2 h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ 


9 ∗ 


11 ∗ 

12 ∗/ 

13 

14 class MemoryGameCard 

15 { 


17 static unsigned num instances ; 

18 char ∗ symbol ; 

19 public : 

20 MemoryGameCard( const char ∗ symbol ) ; 

21 ˜MemoryGameCard ( ) ;

22 

23 const char ∗ getSymbol ( ) ; 

24 void changeSymbol ( const char ∗ symbol ) ; 

25 static unsigned getNumInstances ( ) ; 

26 } ; 

27 

28 

29 #endif // memory game card v2 h 


In Zeile 17 sieht man, wie man eine Variable durch eine static Deklaration 

zum Class-Member macht. Wie allerdings bereits aus dem Begriff Deklaration 

klar hervorgeht, dient Zeile 17 nur zur Beruhigung des Compilers. Man 

sagt ihm, dass es einen Class-Member gibt und dass dieser schon irgendwo definiert 

sein würde. Die tatsächliche Definition muss man natürlich an irgendeiner 

Stelle im Programm auch noch hinschreiben. Dass dies natürlich nicht 

im Header geschehen darf, versteht sich von selbst. Ansonsten würde man 

ja Mehrfachdefinitionen provozieren, auf die der Linker gar nicht so freundlich 

zu sprechen ist. Also wird die Definition sinnigerweise im zur Klasse 

gehörigen .cpp File stattfinden, wie wir in der Folge noch sehen werden. 

Auf num_instances_ kann man aus allen Methoden heraus in altbekannter 

Manier einfach zugreifen. Egal, aus welcher Instanz der Klasse heraus 

man zugreift, der Wert ist immer derselbe. Jedoch kann es passieren, dass 

man nicht immer eine Instanz einer Klasse zur Verfügung hat, um eine Methode 

darauf aufzurufen. Vielleicht will man einfach an irgendeiner Stelle im 

Programm wissen, wie viele Karten existieren, obwohl man an dieser Stelle 

gar keine Instanz der Karte in der Hand hat. Zu diesem Zweck deklariert 

man dann eine Class Member Methode. Diese ist, wie der Name schon sagt, 

auch nicht an eine Instanz gebunden, sondern nur an die Klasse selbst. Intuitiverweise 

deklariert man eine solche Methode gleich, wie es schon von 

der Variable her bekannt ist, als static. Dies sieht man in Zeile 25 unseres 

Programms. 

Was wir an unserer Implementation der Kartenklasse ändern müssen, um 

die Anzahl der Instanzen auch wirklich zu zählen und in Zugriff zu haben, 

sehen wir an den folgenden Ausschnitten von memory_game_card_v2.cpp: 

7 unsigned MemoryGameCard : : num instances = 0; 

Wie bereits erwähnt, muss der static Member nicht nur deklariert, sondern 

auch definiert werden. Dies geschieht, wie zu erwarten, indem man einfach 

die Variable mit dem entsprechenden Scope versieht und damit die Definition 

vornimmt. Hierbei wird allerdings das Keyword static nicht mehr geschrieben, 

denn der Compiler weiß bereits aus der Deklaration um die Natur des 

Members und static würde einer weiteren Deklaration entsprechen. Wir 

wollen allerdings eine Definition erreichen. Dass in diesem Statement eine 

explizite Initialisierung auf 0 vorgenommen wird, soll nur demonstrieren, wie 

man eine Initialisierung auf einen speziellen Wert erreicht. In diesem Fall


ist sie nicht notwendig, da der Compiler bei Fehlen derselben implizit eine 

Initialisierung auf 0 einsetzt, wie bereits aus Abschnitt 2.2 bekannt ist. 

Um nun tatsächlich die Anzahl der vorhandenen Instanzen zu zählen, werden 

Konstruktor und Destruktor entsprechend modifiziert. Wir wissen bereits, 

dass bei Erstellen einer neuen Instanz gesichert der Konstruktor aufgerufen 

wird. Also kommt ihm die Aufgabe zu, den Wert von num_instances_ 

zu inkrementieren, wie man in der Folge in Zeile 17 sieht: 

15 MemoryGameCard : : MemoryGameCard( const char ∗ symbol ) 

16 { 

17 num instances ++; 


19 { 


21 return ; 

22 } 



25 } 

Wir wissen auch, dass beim Zerstören eines Objekts der Destruktor gesichert 

aufgerufen wird. Dementsprechend kommt ihm nun die Aufgabe zu, den 

Instanzenzähler zu dekrementieren, wie man in der Folge in Zeile 35 sieht: 


32 { 



35 num instances −−; 

36 } 

Wie bereits besprochen, wollen wir auch auf die Anzahl der Instanzen zugreifen 

können, ohne dass wir direkt ein Objekt vom Typ MemoryGameCard 

in der Hand haben. Dazu haben wir eine static Methode deklariert. Die 

Definition derselben im .cpp File sieht dann aus wie folgt: 

73 unsigned MemoryGameCard : : getNumInstances ( ) 

74 { 

75 return ( num instances ) ; 

76 } 

Man kann leicht erkennen, dass für static Methoden dasselbe gilt, wie für 

static Variablen: Das Keyword static wird bei der Definition nicht mehr 

geschrieben. 

Wie man unsere modifizierte Klasse verwenden kann, zeigt das folgende 

Demoprogramm (memory_game_card_v2_test.cpp): 

1 // memory game card v2 test . cpp − t e s t program f o r MemoryGameCard 

2 

3 #include

4 #include ”memory game card v2 . h” 

5 



8 


10 { 

11 MemoryGameCard t e s t c a r d ( ”Symbol A” ) ; 

12 

13 cout


number o f cards ( with : : operator ) : 1 

number o f cards ( c a l l e d on n e x t t e s t c a r d ) : 2 

number o f cards ( c a l l e d on t e s t c a r d ) : 2 

Der Vollständigkeit halber möchte ich noch erwähnen, dass das entsprechende 

Makefile zum Erstellen des Programms auf der beiliegenden CD-ROM 

mitgeliefert wird und MemoryGameCardTestV2Makefile heißt. 

Mit diesem Beispiel wurden nun einmal in einem ersten Durchgang die 

Grundmechanismen der Deklaration, Definition und Verwendung von einfachen 

Klassen erklärt. Bevor wir zu weiteren Features, wie z.B. Operator 

Overloading kommen, möchte ich das Bild im Sinne der Abhandlungen aus 

Kapitel 8 abrunden und das Prinzip der Ableitung näher erläutern. Jedoch 

möchte ich für alle C ++ Neulingen an dieser Stelle die Empfehlung aussprechen, 

das bisher Gelernte durch Ausprobieren an kleinen Beispielen wirklich 

zu verinnerlichen. Ansonsten ist die Gefahr sehr groß, sich in der Folge in 

Details zu verlieren und den Überblick nicht mehr bewahren zu können. 

Der Phantasie, was man ausprobieren könnte, sind keine Grenzen gesetzt. 

Z.B. könnte man sich an einer kleinen Klasse zum Speichern eines Datums, 

einer allgemeinen Array Klasse, einer kleinen String Klasse, die die so fehleranfällige 

direkte Verwendung des char * kapselt oder an mannigfaltigen 

andere kleinen Helferchen versuchen. 

Vorsicht Falle: Bei aller Eindringlichkeit, mit der ich Leser zum Spielen und 

Probieren anregen möchte, soll eine große Gefahr nicht unerwähnt bleiben: 

Es fehlt mit dem bisher vermittelten Wissen noch sehr viel und sehr wichtiges 

Handwerkszeug, das man für eine “echte” und saubere OO Entwicklung in 

C ++ braucht. 

Keinesfalls also sollen sich Leser nun nach dem Motto “Ich weiß, wie 

das funktioniert” bereits jetzt an Utilities heranmachen, deren Einsatz in 

auslieferbaren Produkten geplant ist. Mit dem bisher Gelernten geht ein 

solches Unterfangen unter Garantie schief! 

9.3 Abgeleitete Klassen 

Wie in Kapitel 8 besprochen, kann man Klassen von anderen Klassen ableiten 

und erbt damit ihre Eigenschaften. Dieser Mechanismus hilft, um 

entsprechend der Natur der in Software modellierten Welt Klassifikationsund 

Abstraktionsebenen einzuziehen. Bleiben wir bei unserem begonnenen 

Memory Spiel und werfen einen Blick auf die dortigen Gegebenheiten: 

• Karten werden nicht nur bei Memory verwendet, es gibt mannigfaltige 

Spiele, bei denen man es mit Karten zu tun hat. 

• Je nach Spiel haben die Karten verschiedene Eigenschaften. Grundsätzlich 

liegt allerdings eines in der Natur von Karten: Sie haben eine Vorder- und 

eine Rückseite, wie diese auch immer beschaffen sind.

9.3 Abgeleitete Klassen 197 

• Man kann naturgemäß Karten auf die Vorderseite oder auf die Rückseite 

legen und man kann sie auch umdrehen. Was sich hierbei verändert, ist 

einfach die Seite, die sie zeigen. Aus Gründen der Einfachheit ignoriere 

ich hier einmal, dass man auch Kartenhäuser bauen kann und damit beide 

Seiten sieht :-). 

• Im Fall unseres Memory Spiels wissen wir, dass wir eine spezielle Art von 

Karten verwenden, nämlich solche, die auf der Vorderseite ein Symbol tragen 

und die alle gleich aussehen, wenn man die Rückseite betrachtet. 

Es wäre also nett, wenn man das folgende wirklichkeitsnahe Modell in Software 

gießen könnte: 

• Es gibt Karten. 

• Karten kann man hinlegen und zwar sowohl auf die Vorder- als auch auf 

die Rückseite. 

• Was man von den Karten zu sehen bekommt, hängt von der Seite ab, auf 

der sie liegen. 

• Man kann Karten umdrehen. 

• Es gibt für das Memory Spiel spezielle Karten. 

• Die speziellen Karten haben alle Eigenschaften der allgemeinen Karten, 

wie sie zuerst beschrieben wurden. 

• Die speziellen Karten haben auf der Vorderseite ein Symbol. 

• Die speziellen Karten haben alle ein und dieselbe Rückseite (dass das mit 

derselben Rückseite besser von außen bestimmt wird, als zu einer Klasseneigenschaft 

zu werden, ist eine eigene Geschichte :-)). 

Nach den Prinzipien aus Kapitel 8 sieht das Modell also folgendermaßen aus: 

• Es gibt eine Klasse Karten mit den zuvor erwähnten Eigenschaften. 

• Es gibt eine Klasse Memory Karten. Diese sind Karten (=IS-A Relation) 

mit besonderen Zusatzeigenschaften. 

Was liegt also näher, als eine allgemeine Klasse Karte zu schreiben und danach 

eine spezielle Klasse Memory Karte zu implementieren, die von dieser 

allgemeinen Klasse abgeleitet ist? In dieser speziellen Klasse findet dann die 

Memory spezifische Funktionalität Platz, die zuvor erwähnt wurde. Sehen 

wir uns eine solche Art der Implementation also einfach einmal in C ++ an, 

um herauszufinden, wie diese Modellierung von der Sprache unterstützt wird. 

Unser Startpunkt ist die Deklaration der Basisklasse (game_card.h): 

1 // game card . h − d e c l a r a t i o n of a general card f o r games 

2 

3 #ifndef game card h 

4 #define game card h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ 

8 ∗ GameCard 

9 ∗


10 ∗ a general c l a s s f o r a card f o r games 

11 ∗ 

12 ∗/ 

13 

14 class GameCard 

15 { 


17 unsigned v i s i b l e s i d e ; 

18 public : 

19 // constants f o r the v i s i b l e s i d e 

20 static const unsigned FRONT SIDE = 0 x01 ; 

21 static const unsigned BACK SIDE = 0x02 ; 

22 

23 GameCard(unsigned v i s i b l e s i d e ) ; 

24 ˜GameCard ( ) ; 

25 

26 void turnCard ( ) ; 

27 void putFrontSideUp ( ) ; 

28 void putBackSideUp ( ) ; 

29 unsigned g e t V i s i b l e S i d e ( ) ; 

30 const char ∗ getDisplayRep ( ) ; 

31 } ; 

32 

33 

34 #endif // game card h 

Die einzige Neuigkeit, die hier zu finden ist, ist die Deklaration von Konstanten 

in den Zeilen 20 und 21. Diese werden als static const Members deklariert. 

So weit wäre das alles ja noch nicht besonders verwunderlich. Warum 

aber wird ihnen hier gleich ihr Wert zugewiesen, wo es sich doch nur um eine 

Deklaration handelt und nicht um eine Definition? Diese Art der Initialisierung 

funktioniert, wenn es sich um static const Members, also praktisch 

um reine Konstanten handelt, denn bei diesen ist klar, dass sich deren Wert 

ja niemals ändern darf. Damit hat der Compiler sogar die Möglichkeit, direkt 

die entsprechenden Werte in den Code einzusetzen, anstatt immer über 

einen Speicherzugriff zu arbeiten. Wie wir in der Folge sehen werden, darf 

aber trotzdem nicht auf die entsprechende Definition im zugehörigen .cpp 

File vergessen werden, sonst ist der Linker gar nicht glücklich mit dem Programm, 

da er die entsprechenden Referenzen nicht auflösen kann. Diese direkte 

Wertvergabe im Header ist ausschließlich für static const Members 

zulässig. Sollte ein Member entweder nicht static oder nicht const oder 

beides nicht sein, dann führt eine solche Initialisierung zu einem Compilerfehler, 

weil dieser dann den Member nicht mehr als echte, unveränderbare 

Konstante betrachtet. In solchen Fällen muss die Initialisierung wie gewohnt 

im Rahmen der Definition stattfinden. 

Diese Art der Definition von Konstanten, die Members einer Klasse sind, 

ist die sauberste Möglichkeit, Namenskonflikte zwischen verschiedenen Konstanten 

in verschiedenen Klassen zu verhindern. Ansprechbar sind solche 

Konstanten dann wie zu erwarten über direkte Angabe der Klasse mittels 

Scope Operator, also z.B. als 

GameCard::FRONT_SIDE


Die deklarierten Methoden der Klasse repräsentieren, was man mit einer 

Karte machen kann. Man kann sie umdrehen, man kann die Vorderseite 

oder die Rückseite explizit nach oben drehen, man kann erfahren, welche die 

gerade sichtbare Seite ist (und bekommt eine der vordefinierten Konstanten 

geliefert) und man kann um einen String zur Darstellung bitten. Der String 

zur Darstellung wird natürlich entweder die Repräsentation der Vorder- oder 

der Rückseite sein, je nachdem, welche gerade nach oben zeigt. 

Die Implementation von GameCard sieht dann folgendermaßen aus 

(game_card.cpp): 

1 // game card . cpp − implementation o f GameCard 

2 

3 #include ”game card . h” 

4 

5 // s t a t i c const member d e f i n i t i o n 

6 const unsigned GameCard : : FRONT SIDE; 

7 const unsigned GameCard : : BACK SIDE; 

8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ constructor 

11 ∗/ 

12 

13 GameCard : : GameCard(unsigned v i s i b l e s i d e ) 

14 { 

15 // no good p r a c t i c e to a s s i g n without check , but f o r demo . . . 

16 v i s i b l e s i d e = v i s i b l e s i d e ; 

17 } 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 /∗ d e s t r u c t o r 

21 ∗/ 

22 

23 GameCard : : ˜ GameCard( ) 

24 { 

25 // nothing to be done here 

26 } 

27 

28 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

29 /∗ turns the card around 

30 ∗/ 

31 

32 void GameCard : : turnCard ( ) 

33 { 

34 v i s i b l e s i d e = ( v i s i b l e s i d e == FRONT SIDE) ? 

35 BACK SIDE : FRONT SIDE; 

36 } 

37 

38 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

39 /∗ l a y s the card down with the f r o n t s i d e up 

40 ∗/ 

41 

42 void GameCard : : putFrontSideUp ( ) 

43 { 

44 v i s i b l e s i d e = FRONT SIDE; 

45 } 

46 

47 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

48 /∗ l a y s the card down with the back s i d e up 

49 ∗/ 

50 

51 void GameCard : : putBackSideUp ( )


52 { 

53 v i s i b l e s i d e = BACK SIDE; 

54 } 

55 

56 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

57 /∗ returns the v i s i b l e (=up ) s i d e o f the card 

58 ∗/ 

59 

60 unsigned GameCard : : g e t V i s i b l e S i d e ( ) 

61 { 

62 return ( v i s i b l e s i d e ) ; 

63 } 

64 

65 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

66 /∗ 

67 ∗ @return the d i s p l a y r e p r e s e n t a t i o n o f the card 

68 ∗/ 

69 

70 const char ∗GameCard : : getDisplayRep ( ) 

71 { 

72 // very bad p r a c t i c e , but the way to handle t h i s c o r r e c t l y 

73 // i s not known yet ! 

74 return ( 0 ) ; 

75 } 

In den Zeilen 6 und 7 sieht man, dass die static const Members der Klasse 

sehr wohl definiert werden müssen, um den Linker zu beruhigen, dass aber 

hierbei keine explizite Initialisierung auf bestimmte Werte mehr stattfindet. 

Die Initialwerte sind ja bereits im Header vorgegeben. Würde man sie hier 

nochmals explizit hinschreiben, dann würde sich der Compiler mittels Fehlermeldung 

beschweren, dass man ihn doch bitte in Ruhe lassen soll, denn er 

weiß ja sowieso schon, welche Werte die Konstanten zu bekommen haben. 

Die Implementation der Methode getDisplayRep in den Zeilen 70–75 

retourniert einen 0-Pointer, denn die Basisklasse besitzt keine Darstellung 

und wüsste dementsprechend auch nicht, was sie darstellen sollte. Diese Art 

der Implementation ist absolut nicht für die Praxis geeignet und im Prinzip 

ein böser Hack, jedoch ist bisher der Mechanismus noch nicht bekannt, durch 

den dies vermieden werden kann. 

Bisher haben wir nicht viel Neues kennen gelernt, vor allem noch immer 

nicht, wie man eigentlich eine Ableitung von einer Klasse in C ++ realisiert. 

Das ändert sich jetzt mit der speziellen Klasse von Karten für das Memory 

Spiel, die von der Basis GameCard abgeleitet ist. Deren Deklaration sieht 

folgendermaßen aus (memory_game_card_v3.h): 

1 // memory game card v3 . h − derived implementation o f MemoryGameCard 

2 



5 

6 #include ”game card . h” 

7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ 


11 ∗ 

12 ∗ model of a card as used in the game ”memory”

13 ∗ 

14 ∗/ 

15 

16 class MemoryGameCard : public GameCard 

17 { 


19 char ∗ front symbol ; 

20 char ∗ back symbol ; 

21 public : 

22 MemoryGameCard( const char ∗ front symbol , 

23 const char ∗ back symbol = 0 ) ; 


25 


26 const char ∗ getDisplayRep ( ) ; // o v e r r i d e o f base c l a s s method 

27 } ; 

28 


In Zeile 16 zeigt sich des Pudels Kern, wie eine Ableitung zu formulieren ist: 

Man schreibt einfach einen Doppelpunkt hinter den Klassennamen der neu 

deklarierten Klasse und hinter dem Doppelpunkt führt man die Basisklasse 

an, also in unserem Fall GameCard. Und wofür steht der Access Specifier 

public nun in diesem Kontext? Ganz einfach: Wenn man ableitet, dann spezifiziert 

man auch, ob Entwickler, die die Klasse verwenden, die Basisklasse 

überhaupt explizit zu Gesicht bekommen oder nicht. Es wurde bereits diskutiert, 

dass Ableiten bedeutet, dass man alle Eigenschaften der Basisklasse 

erbt. Unsere Klasse MemoryGameCard erbt also in diesem Fall alle Methoden 

und Membervariablen und ist damit automatisch eine vollständige GameCard. 

Wenn man, so wie hier, public ableitet, dann werden auch alle Methoden 

der Basisklasse mit ihren dort definierten Sichtbarkeiten nach außen weitergereicht. 

Es ist also z.B. möglich, die Methode turnCard auf einem Objekt vom 

Typ MemoryGameCard von außen aufzurufen. Würde die Ableitung nun nicht 

public, sondern private erfolgen, dann ginge dies nicht mehr. Denn damit 

ist es zwar innerhalb der Klasse MemoryGameCard möglich, diese Methoden 

aufzurufen, mitnichten aber von außen. Natürlich ist nicht nur public und 

private möglich, man kann ebenso protected ableiten. Erwartungsgemäß 

bekommen dann die weiteren abgeleiteten Klassen von dieser Klasse den vollen 

Zugriff auf die Basis, aber niemand außerhalb der Ableitungshierarchie. 

Vorsicht Falle: Als default Wert für den Access der Basisklasse bei einer 

Ableitung wird von C ++ private angenommen, falls nichts anderes explizit 

angegeben wurde. Oft unterläuft Neulingen der Fehler, den Access Specifier 

zu vergessen. Dann beginnt das Rätselraten, warum denn eine geerbte Methode 

nicht aufgerufen werden kann, sondern dies vom Compiler bemängelt 

wird. In solchen Fällen hilft ein schneller Blick auf die Deklaration der Klasse, 

ob man auch mit dem richtigen Access Specifier abgeleitet hat. 

Wie bereits in Kapitel 8 erwähnt, leitet man ab, um die Natur von Objekten 

zu erben und kann dann besondere zusätzliche Features in der abgeleiteten 

Klasse dazu implementieren. In unserem Fall sind das die Vorder- und


die Rückseite der Karte in den entsprechenden Members in den Zeilen 19–20. 

Damit aber nicht genug: Unsere besondere Karte implementiert auch einen 

besonderen Konstruktor, der andere Parameter nimmt als der, der von der 

Basis vorgegeben ist. In unserem Fall wollen wir ja sowohl die Darstellung der 

Vorder- als auch die Rückseite der Karte von außen vorgegeben bekommen. 

Weil das noch nicht alles war, was wir erreichen wollen, definieren wir in 

der abgeleiteten Klasse noch eine Methode getDisplayRep. Diese Deklaration 

allerdings bewirkt etwas, was wir bisher noch nicht kennen gelernt haben: 

Wenn man sich die Deklaration von getDisplayRep in MemoryGameCard ansieht 

und mit der Deklaration in GameCard vergleicht, dann fällt auf, dass 

diese beiden Deklarationen tatsächlich vollkommen identisch sind! Nun haben 

wir aber beim Overloading gesagt, dass so etwas gar nicht sein darf, weil 

der Compiler dann nicht auseinander halten kann, welche Implementation er 

nun einsetzen soll! 

Um die Verwirrung perfekt zu machen: Im Falle von Ableitungen darf 

es doch sein und es nennt sich Overriding. Dies bedeutet, dass eine genau 

äquivalente Deklaration (und natürlich auch Definition) in einer abgeleiteten 

Klasse die ursprüngliche Definition, die der Basisklasse zugrunde lag, 

versteckt. Ruft man also auf der Klasse MemoryGameCard die Methode 

getDisplayRep auf, so wird die Definition aus der abgeleiteten Klasse genommen 

und nicht die aus der Basisklasse GameCard, da diese durch die 

Neudeklaration und Definition zugedeckt wurde. Um ein Overriding zu erreichen, 

muss die Deklaration genau gleich aussehen, wie die ursprüngliche, 

ansonsten kommt es nur zu einem Overloading, es würden also beide Methoden 

friedlich nebeneinander existieren. 

Dasselbe, was für Methoden gilt, gilt natürlich auch für Membervariablen. 

Auch hier kann man eine Variable in einer abgeleiteten Klasse definieren, die 

denselben Namen hat wie die in einer ihrer Basisklassen (direkt oder weiter 

oben in der Ableitungshierarchie). Damit wird, wie zu erwarten, die Variable 

der Basisklasse versteckt, existiert aber parallel zur hier definierten. 

Vorsicht Falle: In der Literatur werden leider nur allzu oft die Begriffe 

Overloading und Overriding verwechselt oder sogar austauschbar verwendet. 

Dies ist aber absolut falsch und sorgt leider immer wieder für große 

Verwirrung und Missverständnisse. 

Overloading bezeichnet das gleichzeitige Existieren mehrerer Funktionen 

oder Methoden nebeneinander, die verschiedene Parametersätze haben. 

Overriding bezeichnet das Verstecken einer Methode bzw. Variable in 

einer Ableitungshierarchie durch eine Methode bzw. Variable mit genau derselben 

Deklaration. Das bedeutet, dass ein Overriding Einfluss auf den Scope 

von Methoden und Variablen nimmt. Wie wir später noch sehen werden, ist 

trotz Overriding ein Zugriff auf die dadurch versteckten Definitionen mittels 

Scope Operator möglich.


Die Implementation der einzelnen Methoden der Klasse MemoryGameCard 

sieht folgendermaßen aus (memory_game_card_v3.cpp): 

1 // memory game card v3 . cpp − Version 3 d e f i n i t i o n s o f MemoryGameCard 

2 


4 


6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 /∗ constructor of MemoryGameCard 

9 ∗ 

10 ∗ @param front symbol the f r o n t symbol o f t h i s card 

11 ∗ @param back symbol the back symbol o f t h i s card 

12 ∗/ 

13 

14 MemoryGameCard : : MemoryGameCard( const char ∗ front symbol , 

15 const char ∗ back symbol ) : 

16 GameCard(BACK SIDE) 

17 { 

18 i f ( ! front symbol ) 

19 front symbol = 0; 

20 else 

21 { 

22 front symbol = new char [ s t r l e n ( front symbol ) + 1 ] ; 

23 strcpy ( front symbol , front symbol ) ; 

24 } 

25 

26 i f ( ! back symbol ) 

27 back symbol = 0; 

28 else 

29 { 

30 back symbol = new char [ s t r l e n ( back symbol ) + 1 ] ; 

31 strcpy ( back symbol , back symbol ) ; 

32 } 

33 } 

34 

35 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

36 /∗ d e s t r u c t o r of MemoryGameCard 

37 ∗/ 

38 


40 { 

41 i f ( front symbol ) 

42 delete [ ] front symbol ; 

43 i f ( back symbol ) 

44 delete [ ] back symbol ; 

45 } 

46 

47 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

48 /∗ 

49 ∗ @return the symbol that t h i s card r e p r e s e n t s 

50 ∗/ 

51 

52 const char ∗MemoryGameCard : : getDisplayRep ( ) 

53 { 

54 return ( ( v i s i b l e s i d e == FRONT SIDE) ? 

55 front symbol : back symbol ) ; 

56 } 

In den Zeilen 14–16 stoßen wir hier auf ein Konstrukt, das wir bisher noch 

nicht kennen gelernt haben: ein Doppelpunkt gefolgt von einem sehr abstrusen 

Aufruf, den es eigentlich gar nicht geben kann – oder doch? Überlegen


wir kurz: Unsere abgeleitete Klasse hat einen Konstruktor mit 2 Parametern, 

die Basisklasse hat nur einen mit einem Parameter. Wie also soll nun 

der Compiler wissen, wie er den Konstruktor der Basisklasse aufruft? Genau 

das ist es, was wir mit diesem Konstrukt erreichen, nämlich dass wir explizit 

den Aufruf eines bestimmten Konstruktors mit einem bestimmten von uns 

vorgegebenen Parameter veranlassen. In diesem Fall bewirken wir den Aufruf 

des Konstruktors auf die Art, dass die Rückseite der Karte nach dem 

Konstruieren sichtbar ist. 

Die Regel, die der Compiler beim impliziten Einsetzen von Konstruktoraufrufen 

befolgt, ist einfach: Er sucht in der Basisklasse immer nach einem 

Konstruktor mit genau demselben Parametersatz, wie ihn der Konstruktor 

der abgeleiteten Klasse besitzt. Gibt es einen solchen, kann der Compiler 

den impliziten Aufruf einsetzen, wenn nicht, dann führt dies zu einem Fehler. 

Dann sind wir also zum expliziten Aufruf gezwungen. 

Vorsicht Falle: Neulinge und Entwickler, die aus der Java-Welt kommen, 

sitzen oft dem Irrtum auf, dass der Compiler implizit immer nur den default 

Konstruktor aufruft, falls ein solcher existiert. Dies ist falsch! Eine solche 

Fehlannahme kann natürlich zu ganz interessanten Fehlern führen, die man 

lange sucht :-). 

Um hier nicht zu stark vom Thema abzukommen, möchte ich eine genauere 

Diskussion über den Aufruf von Konstruktoren und Destruktoren auf 

später verlegen, ebenso wie eine Abhandlung, was man nach diesem ominösen 

Doppelpunkt noch so alles tun kann. Im Augenblick genügt es, zu wissen, 

dass man auf diese Art den Compiler zufrieden stellen kann und er den richtigen 

Konstruktor mit unseren gewünschten Parametern aufrufen wird. 

Vorsicht Falle: Ein oftmaliger Fehler von Neulingen in C ++ besteht darin, 

dass der explizite Hinweis auf den aufzurufenden Konstruktor fehlt, die 

Basisklasse aber keinen entsprechenden Konstruktor zur Verfügung stellt, 

der implizit eingesetzt werden könnte. Darüber beschwert sich natürlich der 

Compiler und will das Programm partout nicht fertig übersetzen. Ein kurzer 

Blick auf die Implementation der Konstruktoren schafft hier Klarheit. Abhilfe 

in Form eines expliziten Hinweises an den Compiler lässt diesen dann in 

puncto Fehlermeldungen weniger lautstark ans Werk gehen :-). 

Interessant ist auch noch das Testprogramm, denn darin sieht man, wie 

man eigentlich überhaupt mit abgeleiteten Klassen umgeht 

(memory_game_card_v3_test.cpp): 

1 // memory game card v3 test . cpp − t e s t program f o r MemoryGameCard 

2 



5 

6 using std : : cout ;


8 


10 { 

11 MemoryGameCard t e s t c a r d ( ”Symbol A” , ”back” ) ; 

12 


13 cout


Die sinnvolle und richtige OO Vorgangsweise wäre also, eine Basisklasse 

Karte zu definieren, die alle Eigenschaften einer Karte in sich vereint. 

Außerdem definiert man noch eine Basisklasse anzeigbares Objekt, die alle 

Eigenschaften anzeigbarer Objekte in sich vereint. Die Basis-Karte ist selbst 

noch nicht anzeigbar, denn man will ja nicht notwendigerweise voraussetzen, 

dass eine Karte immer um jeden Preis angezeigt werden muss. Man denke 

sich nur, dass man z.B. ein Programm schreiben will, in dem zwei Computer 

gegeneinander ein Kartenspiel spielen. Dazu braucht man nicht notwendigerweise 

eine Anzeige der Karten. 

Versuchen wir uns also an einem Redesign der Karte für das Memory 

Spiel zusammen mit den dazugehörigen Basisklassen, um einmal wirklich 

zu einer sauberen Trennung zu kommen, wie sie auch in der Praxis 

geistreicherweise eingesetzt werden soll. Nehmen wir uns zuerst eine Klasse 

vor, die eine primitive Version von anzeigbaren Objekten repräsentiert 

(displayable_object.h): 

1 // d i s p l a y a b l e o b j e c t . h − base c l a s s f o r o b j e c t s that can be 

2 // displayed . 

3 

4 #ifndef d i s p l a y a b l e o b j e c t h 

5 #define d i s p l a y a b l e o b j e c t h 

6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 /∗ 

9 ∗ DisplayableObject 

10 ∗ 

11 ∗ base f o r an o bject that i s d i s p l a y a b l e 

12 ∗ 

13 ∗/ 

14 

15 class DisplayableObject 

16 { 

17 public : 

18 const char ∗ getDisplayRep ( ) ; 

19 } ; 

20 

21 

22 #endif // d i s p l a y a b l e o b j e c t h 

Ich gebe schon zu, dass eine Klasse mit nur einer einzigen Methode, ohne 

Daten und ohne besondere Funktionalität, nicht gerade berauschend ist. 

Im Normalfall würde diese Klasse auch nicht so aussehen, sondern würde 

ziemlich viel besondere Funktionalität enthalten, die ein darstellbares Objekt 

auszeichnet, z.B., ob ein Objekt nun sichtbar oder versteckt ist, die 

Bildschirmposition, Verschiebeoperationen, etc. Allerdings würde dies den 

Blick für das Wesentliche hier verschleiern und dementsprechend belassen 

wir es dabei. Ebenfalls nur als Gründen der Übersichtlichkeit wurde darauf 

verzichtet Konstruktor und Destruktor hier explizit zu implementieren. 

Genauso toll wie die Deklaration der Klasse liest sich auch die Definition 

der einzigen Methode (displayable_object.cpp):


1 // d i s p l a y a b l e o b j e c t . cpp − implementation o f DisplayableObject 

2 

3 #include ” d i s p l a y a b l e o b j e c t . h” 

4 

5 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

6 /∗ 

7 ∗ @return the d i s p l a y rep of the o b j e c t 

8 ∗/ 

9 

10 const char ∗ DisplayableObject : : getDisplayRep ( ) 

11 { 

12 // t h i s i s not clean , but the mechanism how to implement 

13 // t h i s in a clean way i s not known yet . 

14 return ( 0 ) ; 

15 } 

Weil diese Implementation nun wirklich keine weiteren Kommentare benötigt, 

sehen wir uns auch gleich an, wozu unsere Basisklasse GameCard mutiert, 

um der hier vollzogenen Auftrennung der Eigenschaften gerecht zu werden 

(game_card_v2.h): 

1 // game card v2 . h − d e c l a r a t i o n o f a general card f o r games 

2 

3 #ifndef game card v2 h 

4 #define game card v2 h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ 

8 ∗ GameCard 

9 ∗ 

10 ∗ a general c l a s s f o r a card f o r games 

11 ∗ 

12 ∗/ 

13 


15 { 


17 unsigned v i s i b l e s i d e ; 

18 public : 

19 // constants f o r the v i s i b l e s i d e 

20 static const unsigned FRONT SIDE = 0 x01 ; 

21 static const unsigned BACK SIDE = 0x02 ; 

22 

23 GameCard(unsigned v i s i b l e s i d e ) ; 

24 ˜GameCard ( ) ; 

25 

26 void turnCard ( ) ; 

27 void putFrontSideUp ( ) ; 

28 void putBackSideUp ( ) ; 

29 unsigned g e t V i s i b l e S i d e ( ) ; 

30 } ; 

31 

32 

33 #endif // game card v2 h 

Wie sich leicht erkennen lässt, ist die einzige Veränderung gegenüber unserer 

ersten Version, dass die Methode getDisplayRep weggefallen ist. Aus diesem 

Grund erspare ich auch allen Lesern das Einbinden der dazugehörigen


Implementation (game_card_v2.cpp), denn diese ist bis auf das Fehlen der 

entsprechenden Definition von getDisplayRep identisch zur Erstversion. 

Unsere Klasse MemoryGameCard verändert sich durch das Auftrennen der 

beiden semantischen Aspekte in zwei Basisklassen zu folgender Deklaration 

(memory_game_card_v4.h): 

1 // memory game card v4 . h − multiple i n h e r i t a n c e f o r MemoryGameCard 

2 



5 

6 #include ”game card v2 . h” 

7 #include ” d i s p l a y a b l e o b j e c t . h” 

8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 


12 ∗ 


14 ∗ 

15 ∗/ 

16 

17 class MemoryGameCard : public GameCard , 

18 public DisplayableObject 

19 { 




23 public : 


25 const char ∗ back symbol = 0 ) ; 


27 

28 const char ∗ getDisplayRep ( ) ; // o v e r r i d e o f base c l a s s method 

29 } ; 

30 


Wie sich unschwer erkennen lässt, ist die einzige Veränderung hier, dass 

MemoryGameCard nun von zwei Klassen zugleich abgeleitet ist. Dies geschieht 

intuitiverweise dadurch, dass man die Ableitungen der beiden Klassen durch 

Beistrich getrennt angibt. Die Zeilen 17–18 demonstrieren dies. Man sieht 

auch, dass die Access Specifiers für jede einzelne der Ableitungen getrennt 

angegeben werden. Dadurch kann man bestimmte Basisklassen nach außen 

zugänglich machen und andere nicht. 

Durch diese Deklaration ist nun unsere Klasse eine besondere Karte, die 

auch noch gleichzeitig ein anzeigbares Objekt darstellt. Genau das ist auch 

die semantische Bedeutung der Ableitung von mehreren Klassen gleichzeitig: 

Eine Klasse, die Gebrauch von Mehrfachvererbung macht, ist alles 

zusammen, was die einzelnen Basisklassen für sich allein sind. Die abgeleitete 

Klasse erbt also alle Members, Methoden wie auch Variablen, die in 

jeder einzelnen der Basisklassen deklariert (und definiert) sind. Die Methode 

getDisplayRep ist also in unserem Fall ein Override der gleichnamigen Me-


thode aus DisplayableObject und nicht, wie in unserer ersten Version aus 

GameCard. 

Die Implementation dieser Version (memory_game_card_v4.cpp) ist im 

Prinzip vollkommen äquivalent zur vorherigen Implementation. Die einzige 

Ausnahme ist das Inkludieren von memory_game_card_v4.h. Aus diesem 

Grund erspare ich mir hier das Abdrucken des Source Codes. Auch das Testprogramm 

(memory_game_card_v4_test.cpp) hat sich bis auf ein geändertes 

Inkludieren nicht verändert. Ebenso wurde auch das dazugehörige Makefile 

(MemoryGameCardTestV4Makefile) nur entsprechend adaptiert, um auch 

displayable_object.cpp korrekt zu compilieren. Also möchte ich auch mit 

diesen Files nicht sinnlos Seiten im Buch füllen. 

Wie leicht einzusehen ist, ist Mehrfachvererbung eine sehr saubere 

OO Möglichkeit, um verschiedene, voneinander unabhängige Eigenschaften 

in verschiedenen Ableitungshierarchien getrennt voneinander zu modellieren. 

Sollte eine Klasse mehrere Eigenschaften in sich vereinen, dann kann dies 

durch multiple Inheritance sehr elegant gelöst werden. Eine solchermaßen 

abgeleitete Klasse erbt alle Eigenschaften aller verschiedenen Basisklassen. 

Jedoch kann es dabei auch zu ein paar technischen Problemen kommen, 

wenn man nicht aufpasst! Wenden wir uns einmal einem leicht zu lösenden 

Problem zu, bevor wir in Abschnitt 9.4 zu den harten Brocken kommen: Was 

passiert, wenn beide Basisklassen ein- und dieselbe Methode implementieren? 

Der Begriff ein- und dieselbe bezieht sich natürlich auf die vollständige Signatur, 

also auch den Parametersatz. Würde der Parametersatz verschieden 

sein, so würde sich ja einfach eine problemlos aufzulösende Overloading Situation 

ergeben. Haben wir also wirklich komplette Gleichheit, welche der 

Implementationen wird nun bei einem Aufruf vom Compiler eingesetzt? Wie 

sich unschwer erraten lässt, keine der beiden! Der Compiler wird sich einfach 

beschweren, dass er eine Ambiguität im Aufruf entdeckt hat und damit 

das weitere Übersetzen verweigern. Das bedeutet also, dass die Entwickler 

die Ambiguität per Hand auflösen müssen, um den Compiler zu beruhigen. 

Wie dies passiert, sehen wir uns am besten an einem kleinen Beispiel an 

(method_ambiguity_problem.cpp). Die erste Betrachtung gilt zwei Klassendeklarationen 

in diesem Progrämmchen: 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

12 /∗ 

13 ∗ DisplayableObject 

14 ∗ 

15 ∗ A simple d i s p l a y a b l e o bject 

16 ∗ 

17 ∗/ 

18 

19 class DisplayableObject 

20 { 


22 char ∗ s t r i n g r e p ; 

23 DisplayableObject ( const char ∗ s t r i n g r e p ) ; 

24 public : 

25 ˜ DisplayableObject ( ) ; 

26 const char ∗ getStringRep ( ) ;


27 } ; 

28 

29 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

30 /∗ 

31 ∗ PrintableObject 

32 ∗ 

33 ∗ A simple p r i n t a b l e o bject 

34 ∗ 

35 ∗/ 

36 

37 class PrintableObject 

38 { 


40 char ∗ s t r i n g r e p ; 

41 PrintableObject ( const char ∗ s t r i n g r e p ) ; 

42 public : 

43 ˜ PrintableObject ( ) ; 

44 const char ∗ getStringRep ( ) ; 

45 } ; 

Abgesehen davon, dass in Realität natürlich für anzeigbare sowie für druckbare 

Objekte bei weitem mehr vonnöten ist als eine einfache Methode 

getStringRep, ist die Intention hinter diesen beiden Klassen im Prinzip recht 

nett: Sie speichern die Repräsentation und liefern sie direkt auf Anfrage. 

Klassen, die von einer der beiden ableiten, müssen also nur im Konstruktor 

die anfängliche Repräsentation mitgeben und danach bei Bedarf ändern 

(über die Member Variable string_rep_), sofern sich der anzeigbare Inhalt 

geändert hat. Der Rest wird von der Basis übernommen. 

Jetzt aber wollen wir eine Klasse schreiben, die sowohl anzeigbar als auch 

druckbar ist. Sinnigerweise leiten wir diese Klasse von beiden ab und alles 

funktioniert wunderbar... oder auch nicht! Sagen wir, eine Klasse MyObject 

würde einfach folgendermaßen aussehen: 

1 class MyObject : public DisplayableObject , 

2 public PrintableObject 

3 { 

4 public : 

5 MyObject ( ) ; 

6 ˜MyObject ( ) ; 

7 } ; 

Abgesehen davon, dass diese Klasse nicht viel darstellt, aber das tut hier 

nichts zur Sache, was würde passieren, wenn man irgendwo im Programm 

z.B. die folgenden beiden Zeilen stehen hat? 

MyObject my_object; 

my_object.getStringRep(); 

Richtig erkannt! Die Ambiguität ist nicht auflösbar, denn woher soll der 

Compiler denn wissen, ob die Implementation aus DisplayableObject oder 

die aus PrintableObject nun die gewünschte ist. Damit endet der Versuch 

der Übersetzung mit einem Fehler. Irgendwie muss man also dafür sorgen, 

dass der Compiler wieder beruhigt wird und weiß, was er tun soll. Die einzige 

Möglichkeit, das zu erreichen, besteht darin, dass es in der Klasse MyObject


selbst eine Deklaration ebendieser Methode getStringRep gibt, die die entsprechenden 

Maßnahmen setzt. Eine mögliche Deklaration dieser Klasse sieht 

dann folgendermaßen aus: 

47 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

48 /∗ 

49 ∗ MyObject 

50 ∗ 

51 ∗ A simple c l a s s that i s d i s p l a y a b l e and p r i n t a b l e 

52 ∗ 

53 ∗/ 

54 

55 class MyObject : public DisplayableObject , 

56 public PrintableObject 

57 { 

58 public : 

59 MyObject ( ) ; 

60 ˜MyObject ( ) ; 

61 const char ∗ getStringRep ( ) ; 

62 } ; 

Wenn man nun getStringRep auf einer Variable vom Typ MyObject aufruft, 

dann wird auf jeden Fall die hier deklarierte genommen, denn diese ist 

nach dem Prinzip des Overridings die für den Compiler sichtbare. Dadurch 

ist der Konflikt einmal für den Compiler behoben und die Verantwortung 

übergeben. Nun braucht man nur noch getStringRep in MyObject korrekt 

implementieren und alles funktioniert wieder wie geplant – nun ja, zumindest 

fast wie geplant, aber dazu kommen wir weiter unten noch. Sehen wir uns 

einmal die Implementation der Klasse DisplayableObject an: 

64 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


66 ∗ 

67 ∗ @param s t r i n g r e p the s t r i n g r e p r e s e n t a t i o n o f the o b j e c t 

68 ∗/ 

69 

70 DisplayableObject : : DisplayableObject ( const char ∗ s t r i n g r e p ) 

71 { 

72 i f ( ! s t r i n g r e p ) 

73 { 

74 s t r i n g r e p = 0; 

75 return ; 

76 } 

77 s t r i n g r e p = new char [ s t r l e n ( s t r i n g r e p ) + 1 ] ; 

78 strcpy ( s t r i n g r e p , s t r i n g r e p ) ; 

79 } 

80 

81 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

82 /∗ d e s t r u c t o r 

83 ∗/ 

84 

85 DisplayableObject : : ˜ DisplayableObject ( ) 

86 { 

87 i f ( s t r i n g r e p ) 

88 delete [ ] s t r i n g r e p ; 

89 } 

90 

91 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

92 /∗


93 ∗ @return the s t r i n g to be displayed 

94 ∗/ 

95 

96 const char ∗ DisplayableObject : : getStringRep ( ) 

97 { 

98 return ( s t r i n g r e p ) ; 

99 } 

Die Implementation der Klasse PrintableObject ist im Prinzip äquivalent 

dazu: 

107 PrintableObject : : PrintableObject ( const char ∗ s t r i n g r e p ) 

108 { 

109 i f ( ! s t r i n g r e p ) 

110 { 

111 s t r i n g r e p = 0; 

112 return ; 

113 } 

114 s t r i n g r e p = new char [ s t r l e n ( s t r i n g r e p ) + 1 ] ; 

115 strcpy ( s t r i n g r e p , s t r i n g r e p ) ; 

116 } 

117 

118 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

119 /∗ d e s t r u c t o r 

120 ∗/ 

121 

122 PrintableObject : : ˜ PrintableObject ( ) 

123 { 

124 i f ( s t r i n g r e p ) 

125 delete [ ] s t r i n g r e p ; 

126 } 

127 

128 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

129 /∗ 


131 ∗/ 

132 

133 const char ∗ PrintableObject : : getStringRep ( ) 

134 { 

135 return ( s t r i n g r e p ) ; 

136 } 

Zu guter Letzt sieht die Klasse MyObject nach unseren Betrachtungen von 

oben folgendermaßen aus: 

138 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


140 ∗ 

141 ∗ @param s t r i n g r e p the s t r i n g r e p r e s e n t a t i o n o f the o b j e c t 

142 ∗/ 

143 

144 MyObject : : MyObject ( ) : DisplayableObject ( ” ( disp ) j u s t a s t r i n g rep ” ) , 

145 PrintableObject ( ” ( p r i n t ) j u s t a s t r i n g rep ” ) 

146 

147 { 

148 } 

149 

150 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

151 /∗ d e s t r u c t o r 

152 ∗/ 

153

154 MyObject : : ˜ MyObject ( ) 

155 { 

156 } 

157 


158 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

159 /∗ 


161 ∗/ 

162 

163 const char ∗ MyObject : : getStringRep ( ) 

164 { 

165 return ( DisplayableObject : : getStringRep ( ) ) ; 

166 } 

Und damit das Programm auch einen Output liefert, gibt’s natürlich noch 

ein main dazu: 

168 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


170 { 

171 MyObject t e s t o b j e c t ; 

172 

173 cout


Bei der Implementation von MyObject wurde entschieden, dass 

DisplayableObject entscheidend für die Speicherung und das Liefern der 

String Repräsentation ist. Was passiert nun allerdings, wenn ein Objekt der 

Klasse PrintableObject intern mit seiner eigenen string_rep_ mehr macht, 

als sie nur zu speichern und auf Anfrage herzugeben? In unserem Fall wird 

dann alles inkonsistent, denn die Implementation von MyObject ignoriert das 

PrintableObject vollkommen, mit Ausnahme des Konstruktoraufrufs, zu 

dem es gezwungen ist. Neben diesen möglichen Inkonsistenzen gibt es noch 

einen zweiten Aspekt, der zu sehr ungewollten Resultaten führen kann: Es 

ist möglich, dass von außen tatsächlich die Methode getStringRep aus der 

Basisklasse PrintableObject aufgerufen wird, anstatt die Implementation 

aus MyObject heranzuziehen. Wie das absichtlich (oder auch ungewollt!) 

passieren kann, wird noch später in Abschnitt 9.4 besprochen. Im Augenblick 

ist es ausreichend, zu wissen, dass es vorkommen kann. Das bedeutet, 

dass man bei der Auflösung von Ambiguitäten niemals einfach eine der Basisklassen 

ignorieren darf, sondern sich immer darum kümmern muss, dass 

alle Basisklassen gleichermaßen konsistent behandelt werden. 

Der Designfehler bei unseren Klassen liegt darin versteckt, dass beide Basisklassen 

den Entwicklern Arbeit abnehmen wollen, indem sie die String Repräsentation 

speichern und auf Abruf den gespeicherten String liefern. Nun 

wissen diese beiden Klassen aber naturgemäß nicht, was im String enthalten 

sein soll, denn dies ist Aufgabe der abgeleiteten Klasse. Würde das Design 

so aussehen, dass einfach die Methode getStringRep in den Basisklassen 

existiert und mittels Override von der abgeleiteten Klasse implementiert werden 

muss, sodass die abgeleitete Klasse selbst die Repräsentation speichert 

und liefert, dann kommt es erst gar nicht zu diesem Problem. Denn damit 

ist dann wieder eine einzige speichernde Stelle definiert und Inkonsistenzen 

werden verhindert. Bevor nun jemand die Klassen entsprechend umschreibt, 

möchte ich noch kurz darauf hinweisen, dass in Abschnitt 9.4 ein paar zusätzliche 

Aspekte diskutiert werden, die bei einer solchen Implementation sehr 

hilfreich und sogar z.T. unabdingbar sind. 

Vorsicht Falle: Nicht nur von Neulingen wird sehr oft der Fehler begangen, 

dass Klassen “zu viel wissen”, obwohl dieses Wissen nicht in ihrer ursächlichen 

Natur liegt. Man will den Entwicklern Arbeit abnehmen, indem man 

etwas besonders schön implementiert und erreicht leider damit das Gegenteil, 

nämlich dass man ihnen das Leben besonders schwer macht. Um nicht 

in diese Falle zu tappen, die im vorangegangenen Beispiel skizziert wurde, 

muss man sich unbedingt an das folgende Designprinzip halten: 

Ein Objekt darf niemals “weil es gerade so praktisch ist” Daten 

speichern, die es nicht selbst unter Kontrolle hat! Wenn solche Daten 

benötigt werden, dann müssen sie ausnahmslos über Methodenaufrufe von 

den tatsächlichen speichernden Objekten angefordert werden. Wie man das 

genau erreicht, wird in Abschnitt 9.4 besprochen.

9.3.2 Konstruktoren und Destruktoren 


Bei den einfachen Klassen wurde bereits besprochen, dass beim Erzeugen eines 

Objekts der Konstruktor aufgerufen wird und bei dessen Zerstörung der 

Destruktor. Bei abgeleiteten Klassen, egal ob mittels Einfach- oder Mehrfachvererbung, 

sind nun zwangsweise mehrere Konstruktoren und Destruktoren 

im Spiel, denn alle Klassen in der Ableitungshierarchie besitzen solche. 

Wie diese Konstruktoren und Destruktoren nun intern behandelt und aufgerufen 

werden, betrachten wir am besten gleich an einem simplen Beispiel 

(derived_constr_destr_demo.cpp): 

1 // derived constr destr demo . cpp − demo program to show what 

2 // happens with c o n s t r u c t o r s and d e s t r u c t o r s in derived c l a s s e s 

3 


5 



8 

9 class RootClass 

10 { 

11 public : 

12 RootClass ( ) ; 

13 ˜RootClass ( ) ; 

14 } ; 

15 

16 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

17 class DerivedClassLevelOne : public RootClass 

18 { 

19 public : 

20 DerivedClassLevelOne ( ) ; 

21 ˜ DerivedClassLevelOne ( ) ; 

22 } ; 

23 

24 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

25 class DerivedClassLevelTwo : public DerivedClassLevelOne 

26 { 

27 public : 

28 DerivedClassLevelTwo ( ) ; 

29 ˜DerivedClassLevelTwo ( ) ; 

30 } ; 

31 

32 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

33 RootClass : : RootClass ( ) 

34 { 

35 cout


51 DerivedClassLevelOne : : ˜ DerivedClassLevelOne ( ) 

52 { 

53 cout


Um nun nicht in begriffliche Probleme für unsere weiteren Betrachtungen 

hineinzulaufen, möchte ich folgende Konvention festlegen, wie sie in der 

OO Softwareentwicklung üblich ist: 

In einer Ableitungshierarchie steht die Basisklasse oben und abgeleitete 

Klassen stehen entsprechend unter ihr. Die Aufrufe der Konstruktoren 

erfolgen also von oben nach unten in der Hierarchie und die Aufrufe der 

Destruktoren erfolgen entsprechend umgekehrt von unten nach oben. 

Was bedeutet dieses Verhalten nun für Softwareentwickler? Ganz einfach: 

Man kann sich immer darauf verlassen, dass ein Konstruktor erst dann aufgerufen 

wird, wenn die darüber liegenden Klassen in der Ableitungshierarchie 

bereits vollständig konstruiert wurden. Dementsprechend kann man bereits 

im Konstruktor auf die Funktionalität und die Daten der darüber liegenden 

Klassen zugreifen, ohne befürchten zu müssen, dass man auf noch uninitialisierte 

Werte stößt. Ok, ich geb’s ja zu – natürlich stimmt das nur dann, 

wenn die Konstruktoren der darüber liegenden Klassen korrekt implementiert 

wurden, aber davon gehen wir hier einmal aus. 

Im Falle einer einfachen Vererbungshierarchie ist also alles klar. Was 

passiert nun bei Mehrfachvererbung? Auch das ist wieder am leichtesten an 

einem Beispiel demonstriert (multiple_inher_constr_destr_demo.cpp): 

10 class RootClassA 

11 { 

12 public : 

13 RootClassA ( ) ; 

14 ˜RootClassA ( ) ; 

15 } ; 

16 

17 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

18 class RootClassB 

19 { 

20 public : 

21 RootClassB ( ) ; 

22 ˜RootClassB ( ) ; 

23 } ; 

24 

25 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

26 class DerivedClassLevelOneA : public RootClassA 

27 { 

28 public : 

29 DerivedClassLevelOneA ( ) ; 

30 ˜DerivedClassLevelOneA ( ) ; 

31 } ; 

32 

33 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

34 class DerivedClassLevelOneB : public RootClassB 

35 { 

36 public : 

37 DerivedClassLevelOneB ( ) ; 

38 ˜DerivedClassLevelOneB ( ) ; 

39 } ; 

40 

41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 class DerivedClassLevelTwo : public DerivedClassLevelOneA , 

43 public DerivedClassLevelOneB 

44 { 

45 public :


46 DerivedClassLevelTwo ( ) ; 

47 ˜DerivedClassLevelTwo ( ) ; 

48 } ; 

Ich habe bewusst nur den Ausschnitt des Programms mit der Deklaration der 

entsprechenden Klassen hier abgedruckt, die Implementation ist im Prinzip 

äquivalent mit dem vorherigen Beispiel: Konstruktoren und Destruktoren 

der einzelnen Klassen geben bei Aufruf eine Meldung aus. 

Die in diesem Programm modellierte Ableitungshierarchie hat zwei Wurzeln, 

von denen jeweils eine Klasse abgeleitet ist. Die Klasse 

DerivedClassLevelTwo schließlich ist von diesen beiden Klassen gemeinsam 

abgeleitet. In Abbildung 9.1 ist die Ableitungshierarchie dieses Beispiels visualisiert. 

RootClassA RootClassB 

DerivedClassLevelOneA DerivedClassLevelOneB 

DerivedClassLevelTwo 

Abbildung 9.1: Ableitungshierarchie des Mehrfachvererbungs-Beispiels 

Die Konstruktoraufrufe beim Erzeugen und die Destruktoraufrufe beim 

Zerstören dieser Klasse erfolgen dann so, wie man es in folgendem Output 

sieht: 

constructor of RootClassA 

constructor of DerivedClassLevelOneA 

constructor of RootClassB 

constructor of DerivedClassLevelOneB 

constructor of DerivedClassLevelTwo 

∗∗∗∗∗ now the o bject i s a l i v e 

d e s t r u c t o r of DerivedClassLevelTwo 

d e s t r u c t o r of DerivedClassLevelOneB 

d e s t r u c t o r of RootClassB 

d e s t r u c t o r of DerivedClassLevelOneA 

d e s t r u c t o r of RootClassA 

Zuerst wird also der linke Teil der Ableitungshierarchie (siehe Abbildung 9.1) 

konstruiert, danach der rechte Teil und zu guter Letzt das endgültige Objekt 

der Klasse DerivedClassLevelTwo, die von beiden Teilen abgeleitet ist. 

Die Reihenfolge der Konstruktion der Basisklassen, also zuerst der linke und 

dann der rechte Teil, ist durch die Reihenfolge der Angabe bei der Ableitung

9.4 Weitere wichtige technische Aspekte 219 

abhängig. Würde in den Zeilen 42–43 DerivedClassLevelOneB vorher angegeben 

sein, dann würde sich damit auch die Reihenfolge der Konstruktoraufrufe 

umdrehen. Es ist nicht möglich, durch explizite Angabe der Konstruktoren 

die Reihenfolge zu beeinflussen. Hätte man z.B. folgenden Konstruktor 

für DerivedClassLevelTwo: 

DerivedClassLevelTwo::DerivedClassLevelTwo() : 

DerivedClassLevelOneB(), DerivedClassLevelOneA() 

{ 

//... 

} 

dann würde dies bestenfalls zu einer Warnung des Compilers führen, dass er 

die “verkehrte” Aufrufreihenfolge der Konstruktoren wieder umgedreht und 

damit korrigiert hat. 

Sehen wir uns die Reihenfolge der Aufrufe der Destruktoren an, so ist 

leicht zu erkennen, dass dieselbe Regel gilt wie bei einfacher Vererbung: Die 

Destruktoren werden garantiert genau in umgekehrter Reihenfolge zu den 

Konstruktoren aufgerufen. Es wird also zuerst die “Hauptklasse”, danach 

der rechte Zweig der Ableitungshierarchie von unten nach oben und zum 

Schluss der linke Zweig der Ableitungshierarchie destruiert. 

9.4 Weitere wichtige technische Aspekte 

Bisher ist bekannt, wie man mit Klassen sowie einfacher und mehrfacher 

Vererbung arbeitet. Allerdings ist das noch nicht die ganze Wahrheit, denn 

es gibt einige sehr wichtige technische Aspekte, die die Funktionalität von 

Objekten erheblich beeinflussen! Genau um diese Aspekte geht es in der 

Folge. 

9.4.1 Static und Dynamic Binding 

Zu einer sehr wichtigen oder vielleicht sogar zur wichtigsten Eigenschaft von 

Objekten überhaupt, die saubere OO Programme erst wirklich ermöglicht, 

habe ich mich bisher noch überhaupt nicht ausgelassen: Hat man es mit 

einem Objekt zu tun, dem als Datentyp eine abgeleitete Klasse zugrunde liegt, 

dann kann man dieses Objekt auch einfach so behandeln, als ob es einfach 

den Typ der Basisklasse hätte. 

Was das nun wieder bedeutet, lässt sich leicht überlegen: Erinnern wir 

uns daran, dass in unserer bisher letzten Version 4 der Karte für das Memory 

Spiel diese Karte sowohl von einer allgemeinen Kartenklasse als auch 

von einer allgemeinen “anzeigbaren” Klasse abgeleitet war. Nehmen wir 

nun an, es gibt ein allgemeines Anzeigemodul in einem Programm, das so 

definiert ist, dass es immer nur mit “anzeigbaren” Objekten umgeht, egal 

welche genaue Natur diese jetzt haben. Wozu sollte dieses Modul sich


auch darum kümmern, ob es jetzt mit einer Karte oder einer Schachfigur 

oder einfach nur mit irgendeinem Text arbeitet. Solange sie “anzeigbar” 

ist, soll es der Klasse recht sein. Unsere MemoryGameCard im Beispiel war 

(auch) abgeleitet von DisplayableObject. Da eine Ableitung ja eine IS- 

A Relation darstellt, bedeutet das, dass MemoryGameCard tatsächlich ein 

DisplayableObject ist, also einfach als solches behandelt werden kann, weil 

die Typenkompatibilität gegeben ist. Sehen wir uns das einmal am Beispiel 

an (virtual_method_demo.cpp): 

1 // virtual method demo . cpp − demo f o r the use o f v i r t u a l methods 

2 


4 



7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ 

10 ∗ Displayable 

11 ∗ 

12 ∗ base c l a s s f o r a l l d i s p l a y a b l e o b j e c t s 

13 ∗ 

14 ∗/ 

15 

16 class Displayable 

17 { 

18 public : 

19 virtual const char ∗ getDisplayRep ( ) const ; 

20 } ; 

21 

22 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

23 /∗ 

24 ∗ OneClass 

25 ∗ 

26 ∗ j u s t a d i s p l a y a b l e c l a s s 

27 ∗ 

28 ∗/ 

29 

30 class OneClass : public Displayable 

31 { 

32 public : 


34 } ; 

35 

36 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

37 /∗ 

38 ∗ OneClass 

39 ∗ 

40 ∗ j u s t another d i s p l a y a b l e c l a s s 

41 ∗ 

42 ∗/ 

43 

44 class AnotherClass : public Displayable 

45 { 

46 public : 


48 } ; 

49 

50 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

51 /∗ 

52 ∗ DisplayHandler 

53 ∗


54 ∗ the handler that i s r e s p o n s i b l e f o r d i s p l a y i n g o b j e c t s 

55 ∗ 

56 ∗/ 

57 

58 class DisplayHandler 

59 { 

60 public : 

61 static void displayObject ( const Displayable & o b j e c t ) ; 

62 } ; 

63 

64 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

65 /∗ 


67 ∗/ 

68 

69 const char ∗ Displayable : : getDisplayRep ( ) const 

70 { 

71 return ( ” d i s p l a y rep of Displayable ” ) ; 

72 } 

73 

74 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

75 /∗ 


77 ∗/ 

78 

79 const char ∗ OneClass : : getDisplayRep ( ) const 

80 { 

81 return ( ” d i s p l a y rep of OneClass” ) ; 

82 } 

83 

84 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

85 /∗ 


87 ∗/ 

88 

89 const char ∗ AnotherClass : : getDisplayRep ( ) const 

90 { 

91 return ( ” d i s p l a y rep of AnotherClass” ) ; 

92 } 

93 

94 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

95 /∗ 

96 ∗ @param o bject the o bject to be displayed 

97 ∗ @return 

98 ∗/ 

99 

100 void DisplayHandler : : displayObject ( const Displayable & o b j e c t ) 

101 { 

102 cout


Der Output dieses Progrämmchens zeigt, dass wir auf jeden Fall einmal erreicht 

haben, was wir wollten: Egal welches Objekt wir anzeigen wollen, es 

wird korrekt angezeigt, ohne dass der genaue Typ bekannt sein müsste. Es 

genügt, dass ein Objekt Displayable ist. 

d i s p l a y i n g object . . . 

d i s p l a y rep o f OneClass 

d i s p l a y i n g object . . . 

d i s p l a y rep o f AnotherClass 

Ein Blick auf den Code, z.B. auf Zeile 19 eröffnet Erklärungsbedarf: Was 

bedeutet virtual und wozu steht hinter der Methode das Keyword const? 

Ich möchte zuerst die zweite Frage beantworten, denn diese Antwort ist 

einfacher zu verdauen: Das Keyword const hinter einer Methode bedeutet, 

dass es sich hierbei um eine sogenannte konstante Methode handelt, also um 

eine, die bei Aufruf nichts am Inhalt eines Objekts ändert. Sollte man innerhalb 

einer solchen Methode versuchen, irgendeine Member Variable eines 

Objekts zu verändern, dann regt sich der Compiler darüber auf. Und damit 

haben wir endlich auch die letzte Antwort, wozu ein const_cast noch gebraucht 

werden kann: Gesetzt den Fall, ein Objekt würde sich nach außen 

hin durch den Aufruf einer Methode nicht verändern, allerdings intern quasi 

versteckt und damit für niemanden bemerkbar trotzdem eine Statusänderung 

vornehmen, dann wird eine solche Methode als const deklariert und 

die zu ändernden Variablen in der Methode durch einen const_cast von 

ihrem Schreibschutz befreit. Dieses Verhalten braucht man z.B. manchmal, 

wenn man einen internen Cache implementiert. Alternativ zum const_cast 

kann man auch mit dem schöneren Konstrukt, nämlich den mutable Members 

arbeiten (siehe Abschnitt 15.1). 

Einen weiteren Aspekt von const gibt es noch, der in unserem Programm 

in der Methode displayObject in den Zeilen 100–104 zum Tragen kommt: 

Die Methode nimmt als Parameter eine const Reference. Auf dieser wird 

dann in Zeile 103 die Methode getDisplayRep aufgerufen. Wäre die Methode 

nicht selbst schon als const deklariert worden, so würde sich hier der 

Compiler beschweren, denn man riefe damit eine Methode, die etwas an einem 

Objekt verändern kann, auf einem konstanten Objekt auf. Das darf 

natürlich nicht sein! Durch die Deklaration der Methode als const ist der 

Compiler beruhigt. 

Nun zur ersten Frage: Was bedeutet virtual in Zeile 19? Um dies zu 

beantworten, muss ich etwas weiter ausholen und mich kurz über technische 

Details von Members im Allgemeinen auslassen. Wie bereits bekannt ist, 

werden beim Compilieren und endgültig beim darauf folgenden Linken alle 

Namen durch Adressen ersetzt, mit denen der Computer arbeiten kann. Eine 

Variable ist über ihre Adresse ansprechbar und dasselbe gilt auch für eine 

Methode (deswegen gibt es ja auch Funktionspointer). Schränken wir unsere 

Betrachtungen nun auf die Methoden ein, denn diese sind hier interessant: 

Was passiert intern, wenn man eine “normale” (also nicht virtual) Methode 

auf einem Objekt aufruft? Ganz einfach, es wird genau die Methode aufgeru-


fen, die für die Klasse des Objekts implementiert wurde, denn der Compiler 

hat beim Übersetzen die entsprechende Adresse eingesetzt. Dieses Einsetzen 

einer Adresse zur Compilezeit nennt man static Binding. Hierbei wird jeder 

Aufruf gleich beim Compilieren und Linken in eine direkte Adressreferenz 

umgesetzt. 

Allerdings ist dieses Verhalten nicht unbedingt immer erwünscht. Sehen 

wir einfach nur unser Beispiel an: Der Methode displayObject aus 

DisplayHandler wird immer nur ein Objekt vom Typ Displayable übergeben. 

Hätten wir es mit static Binding zu tun, dann würde der Aufruf 

getDisplayRep in Zeile 103 immer direkt diese Methode aus der Klasse 

Displayable aufrufen, ohne sich darum zu kümmern, dass ja eigentlich 

ein Overriding in einer Ableitung stattgefunden hat. Was wir wollen, 

ist aber etwas ganz Anderes: In unserem Beispiel soll immer die Methode 

getDisplayRep aus der abgeleiteten Klasse aufgerufen werden. Nur diese 

weiß ja, wie das tatsächliche Objekt sinnvoll dargestellt wird. Dazu brauchen 

wir offensichtlich einen anderen Mechanismus, denn zur Compilezeit ist nicht 

bekannt, um welches Objekt es sich bei einem Aufruf handelt, also kann auch 

keine endgültige Adresse für die Methode eingesetzt werden. Zum Beispiel 

soll in Zeile 112 ein Objekt vom Typ OneClass und in Zeile 113 ein Objekt 

vom Typ AnotherClass angezeigt werden. Für den Aufruf getDisplayRep 

in Zeile 103 kann also erst zur Laufzeit eine Entscheidung getroffen werden, 

welche Implementation von getDisplayRep nun aufgrund des Objekttyps 

zum Tragen kommt. Dieses Verhalten des Einsetzens des richtigen Aufrufs 

zur Laufzeit nennt man dynamic Binding. Um dem Compiler mitzuteilen, 

dass für eine bestimmte Methode dynamic Binding vorgenommen werden 

soll, verwendet man das ominöse Keyword virtual. 

Diese Eigenschaft, dass eine Klasse sich verschiedenartig verhalten kann, 

je nachdem, ob man es mit einer Ableitung zu tun hat oder auch, mit welcher 

Ableitung man es zu tun hat, wird auch als Polymorphismus bezeichnet. 

Alle Methoden, die als virtual deklariert werden, werden folgendermaßen 

behandelt: 

• Objekte haben zur Laufzeit eine sogenannte virtual Table zur Verfügung, 

in der alle virtual Methoden mit ihren aktuellen Adressen gemäß der 

Ableitungshierarchie vermerkt sind. 

• Bei einem Aufruf einer virtual Methode wird ihr Eintrag in der virtual 

Table nachgeschlagen und die korrekte Implementation, die dem tatsächlichen 

Objekt entspricht, aufgerufen. 

Kompliziert? Keine Sorge, es klingt schlimmer, als es in Wirklichkeit ist. Im 

folgenden Beispiel ist der Unterschied zwischen static und dynamic Binding 

schnell zu sehen (static_dynamic_binding_demo.cpp):


1 // static dynamic binding demo . cpp − demo f o r the d i f f e r e n c e 

2 // between s t a t i c and dynamic binding o f methods 

3 


5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 

11 ∗ Base 

12 ∗ 

13 ∗ j u s t a base c l a s s 

14 ∗ 

15 ∗/ 

16 

17 class Base 

18 { 

19 public : 

20 void staticallyBoundMethod ( ) const ; 

21 virtual void dynamicallyBoundMethod ( ) const ; 

22 } ; 

23 

24 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

25 /∗ 

26 ∗ JustAClass 

27 ∗ 

28 ∗ j u s t a demo c l a s s 

29 ∗ 

30 ∗/ 

31 

32 class JustAClass : public Base 

33 { 

34 public : 

35 void staticallyBoundMethod ( ) const ; 

36 virtual void dynamicallyBoundMethod ( ) const ; 

37 } ; 

38 

39 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

40 void Base : : staticallyBoundMethod ( ) const 

41 { 

42 cout

66 o b j ect . staticallyBoundMethod ( ) ; 

67 o b j ect . dynamicallyBoundMethod ( ) ; 

68 } 

69 


70 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


72 { 

73 JustAClass t e s t o b j e c t ; 

74 

75 cout


tatsächlich die Implementation aus JustAClass für den Aufruf herangezogen, 

denn diese ist in der virtual Table als endgültiges Overriding in der 

Hierarchie eingetragen. Es ist also in diesem Fall egal, ob eine virtual 

Methode auf der Basisklasse oder auf der endgültigen Klasse aufgerufen 

wird, das Ergebnis ist immer dasselbe. 

Vorsicht Falle: Oft wird von Neulingen der Fehler begangen, eine Methode 

nicht bei ihrem ersten Auftreten in der Basisklasse als virtual zu deklarieren, 

sondern dies erst weiter unten in der Ableitungshierarchie zu versuchen. Das 

funktioniert natürlich nicht und führt unweigerlich zu einem Compilerfehler, 

denn der Compiler kann nicht zuerst statisches Binding durchführen und 

danach für ein und dieselbe Methode plötzlich den Rest dynamisch binden. 

Sobald eine Methode in der Basisklasse als virtual deklariert ist, muss 

im Prinzip in abgeleiteten Klassen ein Overriding nicht mehr explizit als 

virtual deklariert werden. Der Compiler weiß durch die erste Deklaration 

in der Basis Bescheid und behandelt alle Overridings korrekt. Trotzdem wird 

es als sauberer Programmierstil angesehen, das Keyword virtual bei allen 

Overridings in der Ableitungshierarchie zum Signalisieren dieser Eigenschaft 

hinzuschreiben. 

Ganz wichtig im Zusammenhang mit dynamic Binding ist es, zu wissen, 

wie genau die virtual Table zur Laufzeit gebaut wird. In diesem Wissen 

nämlich liegen die Antworten auf viele Fragen und das Werkzeug zur Behebung 

schwerer Fehler, die leider nicht nur von Neulingen gemacht werden. 

Greifen wir am besten also gleich in die Tasten und erstellen ein kleines Testprogramm, 

das sich folgendermaßen liest (virtual_table_build_demo.cpp): 

1 // v i r t u a l t a b l e b u i l d d e m o . cpp − demo program to show how 

2 // the v i r t u a l t a b l e i s b u i l t during runtime 

3 


5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 

11 ∗ BaseA 

12 ∗ 

13 ∗ j u s t a base c l a s s 

14 ∗ 

15 ∗/ 

16 

17 class BaseA 

18 { 

19 public : 

20 BaseA ( ) ; 

21 virtual ˜ BaseA ( ) ; 

22 virtual void dynamicallyBoundMethod ( ) ; 

23 } ; 

24 

25 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

26 /∗

27 ∗ BaseB 

28 ∗ 

29 ∗ j u s t another base c l a s s 

30 ∗ 

31 ∗/ 

32 

33 class BaseB 

34 { 

35 public : 

36 BaseB ( ) ; 

37 virtual ˜ BaseB ( ) ; 


39 } ; 

40 


41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 /∗ 

43 ∗ DerivedA 

44 ∗ 


46 ∗ 

47 ∗/ 

48 

49 class DerivedA : public BaseA 

50 { 

51 public : 

52 DerivedA ( ) ; 

53 virtual ˜ DerivedA ( ) ; 


55 } ; 

56 

57 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

58 /∗ 

59 ∗ DerivedB 

60 ∗ 


62 ∗ 

63 ∗/ 

64 

65 class DerivedB : public BaseB 

66 { 

67 public : 

68 DerivedB ( ) ; 

69 virtual ˜ DerivedB ( ) ; 


71 } ; 

72 

73 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

74 /∗ 

75 ∗ DerivedC 

76 ∗ 


78 ∗ 

79 ∗/ 

80 

81 class DerivedC : public DerivedA , 

82 public DerivedB 

83 { 

84 public : 

85 DerivedC ( ) ; 

86 virtual ˜ DerivedC ( ) ; 


88 } ; 

89 

90 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

91 BaseA : : BaseA ( ) 

92 {


93 cout

159 { 

160 cout


BaseB : : dynamicallyBoundMethod c a l l e d 

constructor of DerivedB 

DerivedB : : dynamicallyBoundMethod c a l l e d 

constructor of DerivedC 

DerivedC : : dynamicallyBoundMethod c a l l e d 

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

∗∗∗∗∗ new t e s t o b j p t r ∗∗∗∗∗ 

constructor of BaseA 

BaseA : : dynamicallyBoundMethod c a l l e d 

constructor of DerivedA 

DerivedA : : dynamicallyBoundMethod c a l l e d 

constructor of BaseB 


constructor of DerivedB 


constructor of DerivedC 


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

∗∗∗∗∗ c a l l i n g method on t e s t o b j p t r ∗∗∗∗∗ 


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

∗∗∗∗∗ d e l e t e t e s t o b j p t r ∗∗∗∗∗ 

d e s t r u c t o r of DerivedC 


d e s t r u c t o r of DerivedB 


d e s t r u c t o r of BaseB 


d e s t r u c t o r of DerivedA 


d e s t r u c t o r of BaseA 


−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

∗∗∗∗∗ now t e s t o b j e c t ’ s l i f e t i m e ends ∗∗∗∗∗ 

d e s t r u c t o r of DerivedC 


d e s t r u c t o r of DerivedB 


d e s t r u c t o r of BaseB 


d e s t r u c t o r of DerivedA 


d e s t r u c t o r of BaseA 


Die erste Auffälligkeit in unserem Testprogrämmchen zeigt sich in Zeile 21: 

Der Destruktor von BaseA ist virtual! Ebenso sind alle Destruktoren aller 

anderen Klassen als virtual deklariert. Dies hat noch nichts mit dem Bauen 

der virtual Table an sich zu tun, sondern hat einen ganz anderen aber sehr 

wichtigen Grund. Dazu werfen wir einmal einen Blick auf die Zeilen 200– 

206. In diesen Zeilen wird ein Objekt vom Typ DerivedC dynamisch erzeugt, 

allerdings wird dieser Pointer in einer Variable vom Typ BaseA * gehalten. 

Dies ist, wie bereits bekannt ist, absolut zulässig und gängige Praxis, z.B. bei 

Parameterübergaben, wie wir sie schon kennen gelernt haben. In Zeile 204 

sieht man wieder, was sowieso schon bekannt ist: Beim Call einer virtual 

Methode wird zur Laufzeit entschieden, welche der Implementationen in der 

Ableitungshierarchie nun tatsächlich aufgerufen wird. 

Zeile 206 allerdings ist nun des Pudels Kern, was die ominösen virtuellen 

Destruktoren anbelangt: Stellen wir uns einfach vor, die Destruktoren


wären statisch und nicht dynamisch gebunden. Dadurch würde Furchtbares 

passieren, nämlich dass ausschließlich der Destruktor von BaseA aufgerufen 

wird. Der Compiler hat ja statisch diesen Aufruf eingefügt. Was allerdings 

passieren muss, damit das Programm korrekt funktioniert, ist, dass alle Destruktoren 

der einzelnen Klassen in der Ableitungshierarchie korrekt aufgerufen 

werden. Genau das erreicht man nur, wenn man mit dynamic Binding 

arbeitet, also den Destruktor virtual deklariert. Damit wird zur Laufzeit 

entschieden, welcher der “tiefste” Destruktor des vorliegenden Objekts ist 

und von diesem ausgehend werden die anderen Destruktoren, die höher in 

der Ableitungshierarchie liegen, korrekt aufgerufen. 

Vorsicht Falle: Die schweißtreibendsten Debug Sessions, an denen schon 

sehr viele Entwickler verzweifelt sind, ergeben sich bei der Suche nach völlig 

unerklärlichen Effekten, die durch einen statisch gebundenen Destruktor 

trotz dynamischer Verwendung von Objekten zustande kommen. Aus diesem 

Grund lautet die Grundregel Nummer eins beim Entwickeln von C ++ 

Programmen: 

Jede Klasse muss unbedingt einen virtual Destruktor besitzen! 

Auch wenn dies in manchen Fällen aufgrund der Verwendung als nicht 

notwendig erscheint, so ist man auf jeden Fall bei Einhalten dieser Regel 

immer auf der sicheren Seite. Vor allem passiert es oft genug, dass nach Programmänderungen 

Objekte polymorph verwendet werden, obwohl das zuvor 

beim Grunddesign der Klasse noch gar nicht der Fall und leider auch nicht 

mitgeplant war. Und genau dann kommt es garantiert zur Katastrophe. Zum 

Glück warnen moderne Compiler, wenn man in einer Klasse virtual Methoden 

hat, aber den Destruktor nicht virtual deklariert. 

Nun zum eigentlichen Thema unseres Testprogramms: Es galt, herauszufinden, 

wie die virtual Table aufgebaut (und auch wieder abgebaut) wird. 

Um festzustellen, welche Implementation der dynamisch gebundenen Methode 

gerade die “letzte aktive” in der virtual Table ist, wurden in die einzelnen 

Konstruktoren und in die einzelnen Destruktoren Outputs eingebaut. Betrachtet 

man den Output, der beim Erzeugen von test_object entsteht, so 

kann man Folgendes beobachten: 

• Im Konstruktor von BaseA wird dynamicallyBoundMethod aufgerufen. 

Der tatsächlich ausgeführte Call ist die Implementation, die durch BaseA 

gegeben ist. 

• Im Konstruktor der davon abgeleiteten Klasse DerivedA erfolgt, wie man 

sieht, ein Aufruf der Implementation, die durch DerivedA vorgegeben ist. 

• Selbiges passiert in allen anderen Konstruktoren, die der Reihe nach bis 

zum fertigen Objekt aufgerufen werden. 

Was sagt uns das in Bezug auf die virtual Table? Nun, ganz einfach: Die 

virtual Table wird sukzessive gemeinsam mit dem Aufruf der Konstruktoren


aufgebaut. Sobald ein Objekt konstruiert wird, wird ein Update der virtual 

Table vorgenommen, das die neuen Overridings reflektiert. Es kann also 

niemals passieren, dass für einen Methodenaufruf in einem Konstruktor aufgrund 

von dynamic Binding eine Methode eingesetzt wird, die aus einem Teil 

der Ableitungshierarchie kommt, der noch gar nicht konstruiert ist. Dies ist 

auch sehr gut so, denn stellen wir uns vor, was passieren würde, wenn die 

virtual Table vor dem Aufruf der einzelnen Konstruktoren bereits fertig erstellt 

worden wäre: Dann wird z.B. in BaseA unsere dynamisch gebundene 

Methode aufgerufen und es würde tatsächlich der Call der Implementation 

aus DerivedC eingesetzt. Dieser ist ja bei fertig konstruiertem Objekt das 

endgültig letzte Overriding. Aber damit würde dann eine Methode aus einem 

Objekt aufgerufen, das noch nicht einmal fertig konstruiert ist, denn der 

Konstruktoraufruf von DerivedC erfolgt ja erst viel später! 

Zugegeben, es gibt Situationen, in denen dieses Verhalten sogar recht gut 

einsetzbar wäre. Eine solche Situation wäre z.B. die Implementation eines 

Callbacks, über das man Daten aus abgeleiteten Klassen bekommt, die man 

im Konstruktor einer der Basisklassen benötigt. Allerdings lässt sich dieses 

Problem auch anders lösen und die Gefahr dieses Verhaltens ist bei weitem 

größer als der Nutzen. 

Spinnt man den Gedanken zu Ende, dass eine Methode nur auf einem 

“lebendigen” Objekt aufgerufen werden darf, um nicht ins offene Messer zu 

laufen, dann kann man sich auch sofort vorstellen, wie die virtual Table beim 

Aufruf der einzelnen Destruktoren wieder abgebaut wird. Sobald ein Destruktor 

ausgeführt wurde, wird ein Update der virtual Table vorgenommen, 

in dem die Overridings des nun zerstörten Objekts wieder entfernt werden. 

Auch das dient wieder der Sicherheit, denn wenn ein Objekt einmal destruiert 

wurde, dann darf natürlich keine Methode mehr darauf aufgerufen werden. 

Dieses Verhalten lässt sich auch im Output unseres Programms leicht erkennen. 

Die Methodenaufrufe in den einzelnen Destruktoren beziehen sich 

immer auf das “letzte noch lebendige” Objekt in der Hierarchie. 

9.4.2 Abstrakte Methoden und Klassen 

Bisher haben wir mehrfach kennen gelernt, dass man in einer Basisklasse verlangen 

will, dass eine abgeleitete Klasse eine Methode overrided, weil man in 

der Basisklasse gar keine vernünftige Implementation einer Methode schreiben 

kann. Nehmen wir nur das Beispiel mit dem Displayable Objekt her: 

Die Eigenschaft, Displayable zu sein, bedeutet, dass eine Klasse, die davon 

abgeleitet ist, eine Methode getDisplayRep zur Verfügung stellt. Die Basisklasse 

Displayable selbst weiß nichts über die von ihr abgeleiteten Klassen 

und kann dementsprechend gar keine vernünftige Implementation liefern. 

Was wir also haben wollen, ist eine Möglichkeit, in einer Basisklasse zu 

sagen: Die Methode getDisplayRep existiert und ist folgendermaßen aufrufbar. 

Sie muss allerdings immer in der abgeleiteten Klasse implementiert 

werden.


Eine solche Vorschrift nennt man eine abstrakte Methode. Von ihr ist 

in der Basis nur die Signatur (=das Interface) bekannt, aber es gibt dort 

noch keine Implementation davon. Klassen, die solche abstrakten Methoden 

enthalten, nennt man abstrakte Klassen. Im Extremfall kann es sogar sein, 

dass eine Klasse ausschließlich abstrakte Methoden enthält. Dann spricht 

man von rein abstrakten Klassen bzw. auch in Anlehnung an Java von reinen 

Interfaces. 

Die Realisierung unseres Wunsches nach einem solchen Konstrukt ist einfach, 

wie man an folgendem Beispiel sieht (abstract_displayable.h): 

1 // a b s t r a c t d i s p l a y a b l e . h − abstract d i s p l a y a b l e base c l a s s 

2 

3 #ifndef a b s t r a c t d i s p l a y a b l e h 

4 #define a b s t r a c t d i s p l a y a b l e h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ 

8 ∗ Displayable 

9 ∗ 

10 ∗ a bstract base c l a s s f o r d i s p l a y a b l e o b j e c t s 

11 ∗ 

12 ∗/ 

13 


15 { 

16 public : 

17 virtual ˜ Displayable ( ) { } 

18 

19 virtual const char ∗ getDisplayRep ( ) const = 0; 

20 } ; 

21 

22 

23 #endif // a b s t r a c t d i s p l a y a b l e h 

In dieser Klassendeklaration sind zwei kleine Neuigkeiten versteckt: 

• Zeile 19 zeigt, wie man eine abstrakte Methode deklariert: Man schreibt 

einfach = 0 hinter die Signatur. Wieso das so geschrieben wird, möchte ich 

hier einfach einmal salopp erklären: Eine Methode ist natürlich, wie auch 

eine Funktion, nach der Übersetzung durch den Compiler und Auflösung 

durch den Linker einfach ein Pointer, der die Einsprungadresse repräsentiert. 

Durch die Schreibweise = 0 teilt man dem Compiler einfach mit, dass 

diese Methode auf Adresse 0 zu liegen kommt, was bedeutet, dass sie nicht 

aufgerufen werden kann. Damit kann man sich natürlich auch die Implementation 

dazu sparen. Ich möchte noch dazu sagen, dass diese saloppe 

Erklärung nicht zu 100% den Tatsachen entspricht, da noch andere Dinge 

hier mit ins Spiel kommen, aber als Gedankenmodell ist sie in Ordnung. 

• In Zeile 17 sieht man, dass es nicht nur inline Funktionen, sondern logischerweise 

auch inline Methoden gibt. Bei diesen kann das Keyword 

inline, wie hier geschehen, auch weggelassen werden, denn das Vorkommen 

einer Implementation (hier einer leeren Implementation) innerhalb einer 

Klassendeklaration ist automatisch schon ein Kennzeichen für inline.


Das bringt uns auch gleich auf den Punkt, wie man eine inline Methode 

deklariert und gleichzeitig definiert: Man schreibt die Implementation 

direkt hinter die Deklaration. Den Strichpunkt hinter der schließenden 

Klammer der Implementation kann man sich natürlich sparen. 

Zu den abstrakten Methoden wäre noch zu erwähnen, dass klarerweise ausschließlich 

virtual Methoden abstrakt sein können. Ansonsten müsste ja 

static Binding mit einer nicht existenten Methode stattfinden. Dass das der 

Compiler nicht besonders toll findet und entsprechende Kommentare von sich 

gibt, lässt sich leicht vorstellen. Aus der Eigenschaft abstrakter Methoden, 

dass sie auf jeden Fall virtual sein müssen, resultiert auch noch ein anderer 

sehr gebräuchlicher Name für sie: Man nennt sie auch pure virtual Methods. 

Verwendet wird eine abstrakte Basisklasse erwartungsgemäß gleich, wie 

jede andere Klasse auch. Sehen wir uns diese Verwendung einmal an 

(abstract_displayable_demo.cpp): 

1 // abstract displayable demo . cpp − small demo program f o r the 

2 // a b s t r a c t Displayable c l a s s 

3 

4 #include ” a b s t r a c t d i s p l a y a b l e . h” 



7 



10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

12 /∗ 

13 ∗ TextObject 

14 ∗ 

15 ∗ j u s t a text o bject f o r demo purposes 

16 ∗ 

17 ∗/ 

18 

19 class TextObject : public Displayable 

20 { 


22 char ∗ t e x t ; 

23 public : 

24 TextObject ( const char ∗ text ) ; 

25 virtual ˜ TextObject ( ) ; 

26 

27 virtual const char ∗ getDisplayRep ( ) const 

28 { 

29 return ( t e x t ) ; 

30 } 

31 } ; 

32 

33 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


35 ∗ @param text the text held in t h i s o b j e c t 

36 ∗/ 

37 

38 TextObject : : TextObject ( const char ∗ text ) 

39 { 

40 i f ( ! text ) 

41 { 

42 t e x t = 0; 

43 return ;

44 } 

45 t e x t = new char [ s t r l e n ( text ) + 1 ] ; 

46 strcpy ( t e x t , text ) ; 

47 } 

48 


49 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

50 /∗ d e s t r u c t o r 

51 ∗/ 

52 

53 TextObject : : ˜ TextObject ( ) 

54 { 

55 i f ( t e x t ) 

56 delete [ ] t e x t ; 

57 } 

58 

59 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

60 void displayObject ( const Displayable & o b j e c t ) 

61 { 

62 cout


anderen Aspekt von dynamic Binding, der beim Design von Klassenhierarchien 

sehr wichtig ist: virtuelle Ableitungen. Nehmen wir an, wir wollten 

eine Klassenhierarchie, wie in Abbildung 9.2 dargestellt, modellieren. 

Displayable 

TextuallyDisplayable GraphicallyDisplayable 

Printable 

GameCard 

Abbildung 9.2: Eine etwas kniffligere Klassenhierarchie 

Die Klassenhierarchie in Abbildung 9.2 beruht auf folgendem Design: 

• Es gibt eine Klasse Displayable, die die Basis für alle anzeigbaren Objekte 

verkörpert, egal auf welchem Device oder wie diese dargestellt werden. 

• Von Displayable abgeleitet ist eine Klasse TextuallyDisplayable, die 

die Basis für alle Klassen verkörpert, die textuell dargestellt werden 

können. 

• Von Displayable abgeleitet ist eine Klasse GraphicallyDisplayable, die 

die Basis für alle Klassen verkörpert, die graphisch dargestellt werden 

können. 

• Von Displayable abgeleitet ist eine Klasse Printable, die die Basis für 

alle Klassen verkörpert, die ausgedruckt werden können (= am Drucker 

dargestellt werden können). 

• Eine Spielkarte ist nun so definiert, dass sie sowohl textuell als auch graphisch 

dargestellt und auch ausgedruckt werden kann. Damit ist GameCard 

von allen drei entsprechenden Klassen abgeleitet. 

Neben anderen Dingen sieht man an diesem Design auch, dass oft viele Wege 

nach Rom führen. Früher hatten wir es mit einem Design zu tun, in 

dem Printable und Displayable zwei voneinander unabhängige Basisklassen 

waren. Nun haben wir es mit der Interpretation zu tun, dass etwas, 

was druckbar ist, natürlich darstellbar ist, und zwar am Drucker. Selbiges 

gilt für die Textausgabe, denn sie ist semantisch in unserem Design etwas, 

was darstellbar ist, und zwar auf einem Textbildschirm. Analog dazu ist die 

Interpretation für etwas graphisch Darstellbares. 

Genau diese verschiedenen Interpretationsmöglichkeiten ein- und desselben 

Sachverhalts sind es auch, die Erfahrung und eine ausführliche Designphase 

bei der OO Softwareentwicklung so unabdingbar machen. Erfahrene 

und gute Softwareentwickler werden einerseits schon von Beginn an viele


Designaspekte im Hinterkopf haben, die sich positiv auf ein klares Design 

auswirken. Weiters werden solche Entwickler immer wieder überlegen, wie 

man ein- und denselben Sachverhalt vielleicht auch anders und damit schlüssiger 

und einfacher darstellen könnte. Auf diese Art finden sie das (hoffentlich) 

sinnvollste aus mehreren verschiedenen möglichen Modellen für eine Problemstellung. 

Unerfahrenere Entwickler (und auch schlimme Hacker) greifen gerne zum 

ersten Modell, das ihnen logisch erscheint und dieses wird dann ohne Rücksicht 

auf Verluste bis zum bitteren Ende durchgezogen. Dadurch werden allerdings 

Programme zumeist unglaublich kompliziert und das Resultat lässt 

jedes logische semantische Modell vermissen. Somit ist der böse Hack perfekt, 

den sich niemand mehr zu ändern traut, denn jede Änderung an einem 

Teil der Software wirkt sich mörderisch in anderen Teilen derselben aus. 

Ich weiß schon, dass hier wieder einmal ein bisschen der Missionar in 

puncto sauberes Design mit mir durchgegangen ist, aber die Gelegenheit war 

einfach zu gut :-). Also zurück zum Thema: Nehmen wir einfach einmal 

hin, dass die in Abbildung 9.2 skizzierte Klassenhierarchie für unser Problem 

das schlüssigste Modell darstellt. Nach dem bisherigen Wissensstand lässt 

es sich allerdings nicht in C ++ Code umsetzen, ohne dass sich der Compiler 

fürchterlich beschwert und die Übersetzung verweigert! Den Grund für diese 

Beschwerde finden wir im Speicherabbild, das der Compiler aus unseren 

einzelnen Klassen in der Ableitungshierarchie erzeugt: 

• Wir wissen, dass jede Klasse beim Ableiten alle Eigenschaften der Basis 

vollständig erbt. 

• Das bedeutet, dass beim Erzeugen der Instanz eines Objekts für alle einzelnen 

Teil-Objekte, die aus den Klassen in der Hierarchie resultieren, Speicher 

reserviert wird. Die Speicherbereiche bei Ableitungshierarchien kommen 

hintereinander zu liegen. 

• Nehmen wir nur die obersten beiden Ebenen der in Abbildung 9.2 skizzierten 

Hierarchie, so ergibt sich folgendes Bild: 

– Ein TextuallyDisplayable Objekt besteht aus zwei Teilobjekten. Es 

wird also Speicher für Displayable und weiters Speicher für alles Weitere 

reserviert, das TextuallyDisplayable noch an Members dazudefiniert. 

– Für GraphicallyDisplayable und auch für Printable gilt dasselbe. 

• Beziehen wir nun auch noch die dritte Ebene der Hierarchie in unsere Betrachtungen 

mit ein, dann vervollständigt sich das Bild dahingehend, dass 

für eine GameCard folgende Sub-Objekte ihren Speicherblock bekommen: 

– TextuallyDisplayable 

– GraphicallyDisplayable 

– Printable 

Und genau hier liegt das Problem: Zieht man in Betracht, dass jedes dieser 

drei Sub-Objekte selbst wieder Displayable als Sub-Objekt besitzt, dann


bedeutet das ja, dass Displayable gleich drei Mal in ein- und demselben 

Objekt vorkommt! Dass das nicht im Sinne des Erfinders sein kann, ist klar, 

denn eigentlich darf es nur einmal vorkommen, sonst ist keine Konsistenz 

mehr erzielbar! 

Abgesehen vom Speicheraspekt, den man auch mit besonderer Berücksichtigung 

beim static Binding in den Griff bekommen könnte, würden mit einer 

solchen Konstruktion noch weitere Probleme auftauchen, die nur noch 

durch dynamic Binding zu lösen sind, z.B., dass natürlich der Konstruktor 

der Basisklasse nur einmal und nicht drei Mal aufzurufen ist. 

Es ist also in einem solchen Fall notwendig, dass die Basisklasse nur einmal im 

Speicherabbild existiert und dass sich Member-Zugriffe und alle Methodenaufrufe 

incl. Konstruktor und Destruktor konsistent auf diese Basis beziehen. 

Mittels dynamic Binding ist dies möglich, da in diesem Fall erst zur Laufzeit 

die dann bekannten und korrekten Adressen eingesetzt werden. Die dafür 

notwendige virtuelle Ableitung erreicht man, indem man bei der Deklaration 

einer abgeleiteten Klasse das Keyword virtual zur Angabe der Basisklasse 

hinzufügt. Am besten, wir sehen uns eine mögliche minimale Implementation 

unserer in Abbildung 9.2 skizzierten Hierarchie an. Die folgende Implementation 

wird uns auch gleich Auskunft über eine Besonderheit beim Konstruktoraufruf 

geben. Da das Programm virtual_derivation_demo.cpp etwas 

lang ist, werden in der Folge nur die einzelnen Teile hier inkludiert und besprochen, 

die für unsere Betrachtungen Relevanz haben. Zuallererst sehen 

wir uns einmal die Deklaration von Displayable an: 


38 { 

39 public : 

40 Displayable ( ) ; 

41 Displayable ( int whatever ) ; 

42 virtual ˜ Displayable ( ) ; 

43 

44 virtual const DisplayRep &getDisplayRep ( ) const = 0; 

45 } ; 

Nur zu Demonstrationszwecken zum Thema Besonderheit beim Konstruktoraufruf 

wurden in den Zeilen 40–41 zwei verschiedene Konstruktoren deklariert. 

In Zeile 44 wird eine const Referenz auf ein Objekt vom Typ 

DisplayRep retourniert. Die Klasse DisplayRep entspricht einfach einer allgemein 

darstellbaren Repräsentation, von der dann wiederum die besonderen 

textuellen, graphischen, etc. Repräsentationen abgeleitet werden sollen. In 

unserem Testprogramm ist dies nicht implementiert, hier ist einfach eine 

Billig-Implementation verewigt, da eine sinnvolle Implementation nichts zu 

den hier im Programm demonstrierten Aspekten beiträgt. 

Stellvertretend für die verschiedenen Arten von anzeigbaren Klassen werfen 

wir einen Blick auf TextuallyDisplayable:


55 class TextuallyDisplayable : public virtual Displayable 

56 { 

57 public : 

58 TextuallyDisplayable ( ) ; 

59 virtual ˜ TextuallyDisplayable ( ) ; 

60 } ; 

In Zeile 55 erkennt man, wie man eine virtuelle Ableitung in C ++ formuliert. 

Ansonsten sind hier keine erwähnenswerten Besonderheiten zu finden. 

Die anderen direkt abgeleiteten Klassen, also GraphicallyDisplayable und 

Printable sind analog deklariert. Die Klasse GameCard, die schließlich von 

den drei verschiedenen darstellbaren Klassen abgeleitet ist, liest sich folgendermaßen: 

100 class GameCard : public TextuallyDisplayable , 

101 public GraphicallyDisplayable , 

102 public Printable 

103 { 


105 DisplayRep c u r r e n t d i s p l a y r e p ; 

106 public : 

107 GameCard ( ) ; 

108 virtual ˜GameCard ( ) ; 

109 

110 virtual const DisplayRep &getDisplayRep ( ) const ; 

111 } ; 

In den Implementationen der verschiedenen Konstruktoren und Destruktoren 

finden wir wieder den schon altbekannten Output, der uns anzeigt, wer nun 

wann aufgerufen wird. Stellvertretend für diese werfen wir einfach einen Blick 

auf Konstruktor und Destruktor von TextuallyDisplayable: 

140 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


142 ∗/ 

143 

144 TextuallyDisplayable : : TextuallyDisplayable ( ) 

145 { 

146 cout


198 GameCard : : GameCard ( ) : Displayable (17) 

199 { 

200 cout


schon den zweifelhaften Luxus solcher schweren Designfehler geleistet und 

als Konsequenz zahlreiche aufwändige Workarounds verursacht (z.B. durch 

einen solchen Fehler in einer GUI-Klassenbibliothek). Als Grundregel zur 

Verwendung von virtual bei einer Ableitung gilt: 

Leitet man getrennt voneinander mehrere Klassen von ein- und 

derselben Basis ab und gibt es eine sinnvolle Möglichkeit, dass 

Mehrfachvererbung mit diesen Klassen als Basis direkt oder indirekt 

stattfinden könnte, dann ist unbedingt virtuell abzuleiten. 

9.4.4 Downcasts von Klassen 

Es wurde bereits mehrfach erwähnt, dass abgeleitete Klassen vollständig kompatibel 

zu ihrer bzw. ihren Basisklassen sind und auch so angesprochen 

werden können. Aus diesem Grund gibt es ja auch den Mechanismus des 

dynamic Bindings von Methoden, um sicherzustellen, dass immer die “richtige” 

Methode, also die der letzten Ableitung, die ein Overriding vornimmt, 

aufgerufen wird. Diese impliziten oder expliziten Casts von Klassen auf eine 

ihrer Basisklassen werden auch als Upcasts bezeichnet. Der Name kommt 

daher, dass Basisklassen, wie bereits bekannt, als darüber liegend in Bezug 

auf die Ableitungshierarchie betrachtet werden. 

Spinnt man diesen Gedanken weiter, dann kommt man zur Erkenntnis, 

dass es ja auch das Gegenteil geben muss, nämlich einen Downcast. Wurde 

z.B. eine Referenz auf ein Objekt als Parameter bei einem Methodenaufruf 

übergeben, wobei der Typ der Referenz einer der Basisklassen entspricht, 

dann muss es doch möglich sein, über einen Downcast wieder auf den “richtigen” 

Typ zuzugreifen. Man müsste ja nur dem Compiler erklären, dass er 

es in Wirklichkeit sowieso nicht mit der Basis, sondern mit einem abgeleiteten 

Typ zu tun hat. Ich formuliere es einmal vorsichtig: Downcasts sind 

natürlich möglich und auch in verschiedenen Fällen sehr sinnvoll, aber nur, 

wenn man genau weiß, was man tut! Bevor ich mich aber jetzt über die 

Gefahren von Downcasts auslasse, die vor allem dann ganz besonders lauern, 

wenn man ein Fehldesign auf diese Art zu kaschieren versucht, sehen 

wir uns einfach einmal an einem Beispielchen an, wie dieser Mechanismus 

funktioniert (downcast_demo.cpp): 

1 // downcast demo . cpp − small example to demonstrate downcasts 

2 



5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 

11 ∗ Event 

12 ∗ 

13 ∗ base c l a s s f o r events


14 ∗ 

15 ∗/ 

16 

17 class Event 

18 { 


20 int32 event type ; 

21 public : 

22 static const int32 KEY EVENT = 0x1 ; 

23 static const int32 MOUSE EVENT = 0x2 ; 

24 

25 Event ( int event type ) { event type = event type ; } 

26 virtual ˜ Event ( ) { } 

27 

28 int32 getType ( ) const { return ( event type ) ; } 

29 } ; 

30 

31 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

32 /∗ 

33 ∗ KeyEvent 

34 ∗ 

35 ∗ c l a s s f o r Keyboard Events 

36 ∗ 

37 ∗/ 

38 

39 class KeyEvent : public Event 

40 { 


42 char key ; 

43 public : 

44 KeyEvent ( char key ) ; 

45 

46 char getKey ( ) const { return ( key ) ; } 

47 } ; 

48 

49 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

50 /∗ 

51 ∗ MouseEvent 

52 ∗ 

53 ∗ c l a s s f o r Mouse Events 

54 ∗ 

55 ∗/ 

56 

57 class MouseEvent : public Event 

58 { 


60 int32 x pos ; 

61 int32 y pos ; 

62 int32 button mask ; 

63 public : 

64 static const int32 RIGHT BUTTON = 0x1 ; 

65 static const int32 MIDDLE BUTTON = 0x2 ; 

66 static const int32 LEFT BUTTON = 0x4 ; 

67 

68 MouseEvent ( int32 x pos , int32 y pos , int32 button mask ) ; 

69 

70 int32 getXPos ( ) const { return ( x pos ) ; } 

71 int32 getYPos ( ) const { return ( y pos ) ; } 

72 bool isLeftButtonPressed ( ) const 

73 { 

74 return ( button mask & LEFT BUTTON) ; 

75 } 

76 } ; 

77 

78 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

79 /∗

80 ∗ EventHandler 

81 ∗ 

82 ∗ c l a s s f o r Event Handlers 

83 ∗ 

84 ∗/ 

85 

86 class EventHandler 

87 { 

88 public : 

89 virtual ˜ EventHandler ( ) { } ; 

90 

91 virtual void handleEvent ( const Event &event ) ; 

92 } ; 

93 

94 

95 const int32 Event : :KEY EVENT; 

96 const int32 Event : :MOUSE EVENT; 

97 

98 const int32 MouseEvent : :RIGHT BUTTON; 

99 const int32 MouseEvent : :MIDDLE BUTTON; 

100 const int32 MouseEvent : :LEFT BUTTON; 

101 


102 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

103 /∗ 

104 ∗ @param key the key that was pressed 

105 ∗/ 

106 

107 KeyEvent : : KeyEvent ( char key ) : Event (KEY EVENT) 

108 { 

109 key = key ; 

110 } 

111 

112 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

113 /∗ 

114 ∗ @param x pos the x p o s i t i o n of the mouse pointer 

115 ∗ @param y pos the y p o s i t i o n of the mouse pointer 

116 ∗ @param button mask the buttons that were pressed 

117 ∗/ 

118 

119 MouseEvent : : MouseEvent ( int32 x pos , int32 y pos , 

120 int32 button mask ) : Event (MOUSE EVENT) 

121 { 

122 x pos = x pos ; 

123 y pos = y pos ; 

124 button mask = button mask ; 

125 } 

126 

127 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

128 /∗ 

129 ∗ @param the event to be handled the event to be handled 

130 ∗ 

131 ∗/ 

132 

133 void EventHandler : : handleEvent ( const Event &event ) 

134 { 

135 switch ( event . getType ( ) ) 

136 { 

137 case Event : :KEY EVENT: 

138 { 

139 const KeyEvent &key event = 

140 dynamic cast(event ) ; 

141 cout


146 { 

147 const MouseEvent &mouse event = 

148 dynamic cast(event ) ; 

149 cout


Nun ist es aber so, dass der übergebene Parameter event vom Typ Event 

ist. Dort sind also die speziellen Methoden der davon abgeleiteten Klassen 

KeyEvent und MouseEvent noch nicht bekannt, denn diese werden ja erst 

in den abgeleiteten Klassen deklariert. Also können sie direkt auf event 

natürlich auch nicht aufgerufen werden. Der Compiler würde ja z.B. bei 

einem Aufruf 

event.getKey(); 

gar nicht sehr freundlich reagieren und anmerken, dass man sich gefälligst einmal 

die Deklaration der Klasse Event ansehen soll und nur Dinge verwenden 

soll, die tatsächlich dort deklariert sind. 

Jedoch ist aufgrund des Event-Typs, der in Zeile 135 abgefragt wird, sehr 

wohl bekannt, dass es sich z.B. wirklich um einen KeyEvent handelt, auch 

wenn dieser nur als Reference auf einen Event übergeben wurde. Also überzeugt 

man den Compiler, dass man schon weiß, was man tut und setzt einen 

expliziten Downcast auf KeyEvent ein, wie in den Zeilen 139–140 zu sehen ist. 

Und genau hier sehen wir zum ersten Mal die wahre Natur von dynamic_cast: 

Bei einem dynamic_cast wird zur Laufzeit eine Überprüfung vorgenommen, 

ob diese Umwandlung überhaupt zulässig ist. Wenn ja, dann 

wird die Umwandlung durchgeführt, wenn nein, dann endet das Programm 

in einem Fehler – nun ja, muss nicht sein, wenn man weiß, wie man das Ende 

des Programms verhindert. In Wahrheit wird eine Exception geworfen und 

zwar eine bad_cast Exception. Wie man mit solchen Exceptions umgeht, ist 

Thema von Kapitel 11. Was es ganz genau mit dieser besonderen Exception 

auf sich hat, wird in Abschnitt 15.6 noch näher besprochen. Zurück zum 

Thema: Nach einem zulässigen dynamic_cast, der nicht in einer Exception 

endet, haben wir also sichergestellt, dass wir es tatsächlich mit einem Objekt 

vom Typ KeyEvent zu tun haben und können damit auch getKey darauf 

aufrufen. 

Zu Beginn der Diskussion über Downcasts habe ich schon erwähnt, dass 

man wirklich genau wissen muss, was man tut. Leider gibt es nicht allzu 

wenige Entwickler, bei denen dieses Wissen eher rudimentär vorhanden ist, 

die aber trotzdem Datentypen mittels Downcasts munter durch die Gegend 

wandeln und so die schönsten Zeitbomben in ihre Software einbauen. In 

altbekannter Manier möchte ich daher die häufigsten Fehlerquellen in der 

Folge aufzeigen. 

Vorsicht Falle: Downcasts sollten prinzipiell nur dann verwendet werden, 

wenn sie unbedingt notwendig sind. Oft passiert es, dass bereits ein Fehldesign 

vorliegt, das auf die Schnelle durch einen Downcast versteckt werden 

kann (z.B. unnötig falscher Parameter in Methodenaufruf, etc.). Weil aber 

Downcasts prinzipiell eine Gefahr darstellen, sollte man darüber nachdenken, 

ob man vielleicht auch eine saubere Lösung ohne Downcasts finden kann. Das 

bedeutet natürlich nicht, dass man Downcasts auf Kosten der Modularität, 

Erweiterbarkeit und Allgemeinheit eines Programms vermeiden muss, aber


einen Gedanken ist es schon wert, ob man nicht eine genauso schöne Lösung 

ohne Downcasts findet. 

Vorsicht Falle: Nur allzu oft werden abstruseste Annahmen getroffen, dass 

“sowieso nur ein Objekt von genau diesem Typ” hier vorkommen kann. Solange 

dies allerdings nicht durch irgendeine Maßnahme (z.B. in unserem Beispiel 

das interne Speichern des Typs) sichergestellt ist, können durch Programmfehler 

oder nach Programmänderungen die tollsten Effekte eintreten. 

Und ein Programm nach Downcast-Fehlern zu durchsuchen, hat bei Entwicklern 

üblicherweise akute Magenschmerzen gepaart mit übertriebenem Haarausfall 

durch äußere Einwirkung von stark zupackenden und an den Haaren 

ziehenden Händen zur Folge. 

Vorsicht Falle: Auch wenn eine Maßnahme die korrekte Typwandlung 

quasi sicherstellt, ist man noch lange nicht vor “echten” Programmfehlern 

geschützt. Wer sagt, dass nicht aufgrund eines Fehlers einmal ein falscher Typ 

in der Variable vermerkt wird (typische Copy-and-Paste Folgeerscheinung)? 

Solche Fehler können nur durch ausführliches und sinnvolles Testen gefunden 

und behoben werden. Trotzdem muss ein entsprechender Fehlerbehandlungscode 

immer im Programm erhalten bleiben, denn auch ausführliches Testen 

schützt noch nicht zu 100%! 

Vorsicht Falle: Die Funktionsweise der verschiedenen Cast-Operatoren 

wird leider sehr oft nicht vollständig durchschaut, bzw. deren Existenz überhaupt 

ignoriert und mit dem “guten alten” C-Style Cast gearbeitet. Es gibt 

aber nicht von ungefähr die verschiedenen Cast-Operatoren. Durch den Einsatz 

der “falschen” Operatoren lassen sich herrliche Zeitbomben basteln. In 

der Folge wird der Unterschied zwischen den einzelnen Operatoren noch einmal 

genau umrissen. Als Grundregel für Downcasts möchte ich den Lesern 

Folgendes auf den Weg geben: 

Prinzipiell ist bei Downcasts ein dynamic_cast zu verwenden. 

Um das Bild abzurunden, hier noch einmal eine Zusammenfassung, was 

die einzelnen Cast-Operatoren genau tun. Ich lasse in dieser Zusammenfassung 

bewusst den const_cast und den C-Style Cast aus, denn diese sind 

für unsere Betrachtungen hier belanglos. Leser, die sich mittlerweile nicht 

mehr so sicher sind, was diese beiden tun, möchte ich auf Abschnitt 3.6.5 

und Abschnitt 3.6.6 verweisen. 

dynamic_cast: Dieser Cast überprüft zur Laufzeit des Programms, ob eine 

Umwandlung zum gewünschten Typ tatsächlich möglich ist. Wenn 

nein, dann bewirkt bereits die Anweisung mit der Anwendung des Casts 

einen Laufzeitfehler.


static_cast: Dieser Cast überprüft zur Compilezeit, ob eine Umwandlung 

zu einem gewünschten Typ theoretisch möglich sein könnte. 

Wenn ja, wird der entsprechende Code eingesetzt. Die Anwendung des 

Casts allein führt zur Laufzeit noch zu keinem Fehler. Erst falscher Zugriff 

auf Members (Variablen oder Methoden) eines illegal gewandelten 

Typs führen dann direkt zu einer Segmentation Violation. 

reinterpret_cast: Dieser Cast nimmt überhaupt keine Überprüfung 

vor, ob eine Umwandlung überhaupt möglich sein könnte. Entsprechende 

Fehlinterpretationen fallen zur Compilezeit sicherlich nicht auf und zur 

Laufzeit machen sie sich in gewohnter Manier durch eine Segmentation 

Violation bemerkbar. 

Genau in diesem Verhalten der Cast-Operatoren ist bedingt, dass ich zuerst 

die starke Empfehlung gegeben habe, bei Downcasts in jedem Fall einen 

dynamic_cast zu verwenden. Sollte es hier zum Problem kommen, dann 

passiert der Fehler genau dort, wo die Umwandlung stattfindet. Würde man 

stattdessen einen static_cast nehmen, dann überprüft der Compiler kurz 

die Ableitungshierarchie auf entsprechende Möglichkeiten. Sollte die Wandlung 

theoretisch möglich sein, so wird der entsprechende Code eingesetzt. Zur 

Laufzeit allerdings wird beim Umwandeln keine Überprüfung mehr vorgenommen 

und das Programm fällt dann unmotiviert bei irgendeiner scheinbar 

korrekten Anweisung auf die Nase. Das bedeutet also, dass man bei einem 

fehlgeschlagenen dynamic_cast Ursache und Auswirkung miteinander gekoppelt 

hat und solche Fehler daher leicht findet. Bei einem static_cast sind 

Ursache und Auswirkung entkoppelt und die Fehlersuche wird zum nächtlichen 

Vergnügen. 

9.4.5 Friends von Klassen 

Manchmal (wirklich nur manchmal!!!) gibt es Fälle, in denen trotz eines 

sauberen Designs die in C ++ verfügbaren Access-Specifiers nicht ausreichen, 

um eine vernünftige Kapselung des Zugriffs vorzunehmen. Solche Fälle treten 

dann auf, wenn z.B. eine besondere Funktion (nicht Methode!) oder 

alle Methoden einer bestimmten Klasse Zugriff auf Interna einer bestimmten 

Klasse erhalten sollen. Mittels public würde man den Zugriff für alle Außenstehenden 

freigeben, das will man nicht. Man will den Zugriff nur ganz 

gezielt erlauben. Hierzu gibt es in C ++ die sogenannten friend Deklarationen. 

Wie der Name schon sagt, erklärt man damit bestimmte Außenstehende 

zu freundlich Gesinnten, die schon nichts Böses anrichten werden und denen 

deshalb der Zugriff auch auf die privatesten Bereiche gestattet wird. 

Vorsicht Falle: Dass man mit der Annahme der freundlichen Gesinnung 

vorsichtig sein muss, versteht sich von selbst. Es gibt in der Softwareentwicklung, 

so wie auch im realen Leben, auch immer wieder falsche Freunde. 

Nichts lässt bei Entwicklern mehr Freude aufkommen, als wenn sie Fehler


suchen müssen, die von Außenstehenden verursacht werden, denen Zugriffe 

gestattet wurden, vor denen man sich üblicherweise aus gutem Grund 

schützt. 

Um für die Fälle, bei denen es wirklich unumgänglich ist, zu wissen, wie 

man den Zugriff für Außenstehende gestattet, werfen wir einen Blick auf das 

folgende Beispiel (friend_demo.cpp): 

1 // friend demo . cpp − demo f o r the use o f the f r i e n d d e c l . 

2 


4 



7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ 

10 ∗ MyClass 

11 ∗ 


13 ∗ 

14 ∗/ 

15 

16 class MyClass 

17 { 

18 friend class MyGoodFriend ; 

19 friend void myGoodFriendFunction ( MyClass &obj ) ; 

20 private : 

21 int my private member ; 

22 int myPrivateMethod ( ) { return ( my private member ) ; } 

23 public : 

24 MyClass ( ) { my private member = 2 0; } 

25 } ; 

26 

27 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

28 /∗ 

29 ∗ MyDerivedClass 

30 ∗ 

31 ∗ j u s t another demo c l a s s 

32 ∗ 

33 ∗/ 

34 

35 class MyDerivedClass : public MyClass 

36 { 

37 private : 

38 int really private member ; 

39 int reallyPrivateMethod ( ) { return ( really private member ) ; } 

40 public : 

41 MyDerivedClass ( ) { really private member = 7 0; } 

42 } ; 

43 

44 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

45 /∗ 

46 ∗ MyGoodFriend 

47 ∗ 

48 ∗ j u s t a demo f o r a f r i e n d c l a s s f o r MyClass 

49 ∗ 

50 ∗/ 

51 

52 class MyGoodFriend 

53 { 

54 public : 

55 void showAccessToMyClass ( MyClass &obj )


56 { 

57 cout


Betrachtet man die Zeilen 55–60 und die Zeilen 88–93, dann sieht man 

gleich, dass es für gute Freunde möglich ist, auch auf private Bereiche einer 

Klasse zuzugreifen. 

Eine sehr wichtige Einschränkung gilt allerdings für friend Deklarationen: 

Die Eigenschaft, ein friend zu sein, wird nicht an abgeleitete Klassen 

vererbt, wie man an der Klasse NotAGoodFriend in den Zeilen 71–82 sehen 

kann. Die dort auskommentierten Statements würden in einem Compilerfehler 

enden. 

Andersrum gesehen bleibt der Zugriff auf die Basis erhalten, auch wenn 

eine abgeleitete Klasse gewisse Freunde nicht mehr hat, wie man in den Zeilen 

107–109 sieht. Natürlich sind hierbei die Zugriffe nur auf die Bereiche der 

Basisklasse erlaubt, nicht auf private Bereiche der Ableitung. Dazu müsste 

die abgeleitete Klasse selbst bestimmte friend Deklarationen enthalten. 

9.4.6 Overloading von const und non-const Methoden 

Es wurde bereits besprochen, dass const Methoden einen Sonderstatus einnehmen, 

da bei Aufruf derselben das Objekt, auf dem sie aufgerufen werden, 

nicht verändert werden darf. Der Sonderstatus schlägt sich auch in der Signatur 

der Methoden nieder, denn const ist ein Teil derselben. Wenn man diesen 

Gedanken weiterspinnt, dann kann man leicht erkennen, dass ein Overloading 

einer const Methode durch eine non-const Methode mit genau demselben 

Parametersatz möglich ist. Der Compiler geht mit dieser Situation folgendermaßen 

um: 

• Wird eine Methode auf einem Objekt aufgerufen, das nicht durch const 

vor schreibendem Zugriff geschützt ist, so wird versucht, eine non-const 

Methode zu finden, die der Signatur des Aufrufs entspricht. 

• Wird keine solche non-const Methode gefunden, so wird nach einer entsprechenden 

const Methode gesucht. Dieses Verhalten ist auch vollkommen 

logisch, denn eine const Methode auf einem nicht konstanten Objekt 

aufzurufen ist natürlich kein Problem. 

• Wird eine Methode auf einem const Objekt aufgerufen, dann wird natürlich 

nur eine entsprechende const Methode akzeptiert. 

Es ist also möglich, Methoden in zwei verschiedenen Ausprägungen zu schreiben, 

die, je nachdem, ob ein Objekt selbst nun const ist, oder nicht, aufgerufen 

werden. Auf diese Art kann man in speziellen Fällen Optimierungsmaßnahmen 

implementieren. Im folgenden Beispiel sieht man, wie sich ein 

solches Overloading auswirkt (const_non_const_overloading_demo.cpp): 

1 // const non const overloading demo . cpp − demo f o r overloading 

2 // o f const and non−const methods 

3 



6



9 


10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ 

12 ∗ DummyClass 

13 ∗ 

14 ∗ j u s t a dummy f o r demo purposes 

15 ∗ 

16 ∗/ 

17 

18 class DummyClass 

19 { 

20 public : 

21 virtual void writeOutput ( ) const 

22 { 

23 cout


7 ∗ 

8 ∗ j u s t a c l a s s with only a non−d e f a u l t constructor 

9 ∗ 

10 ∗/ 

11 

12 class OneClass 

13 { 

14 public : 

15 OneClass ( int just for demo ) {} 

16 } ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 /∗ 

20 ∗ AnotherClass 

21 ∗ 

22 ∗ j u s t a c l a s s with only a non−d e f a u l t constructor 

23 ∗ 

24 ∗/ 

25 

26 class AnotherClass 

27 { 

28 OneClass just a member ; 

29 public : 

30 AnotherClass ( ) : just a member (17) {} 

31 } ; 

32 

33 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


35 { 

36 AnotherClass j u s t a v a r i a b l e ; 

37 return ( 0 ) ; 

38 } 

Man sieht, dass OneClass in den Zeilen 12–16 so deklariert ist, dass sie 

keinen default Konstruktor besitzt. Die Klasse AnotherClass in den Zeilen 

26–31 wiederum hat einen Member vom Typ OneClass. Jetzt stellt sich 

natürlich die Frage, welchen Code der Compiler beim Erzeugen einer Instanz 

dieses Members einsetzen soll, denn diese Instanz des Members wird ja automatisch 

beim Erstellen einer Instanz von AnotherClass erstellt. Irgendwo 

müssen wir dem Compiler also mitteilen, welchen Konstruktoraufruf er für 

just_a_member_ zu tätigen hat. Das geschieht nach altbekannter Manier 

im Konstruktor von AnotherClass, angegeben hinter dem obligatorischen 

Doppelpunkt, wie man in Zeile 30 sieht. Der Unterschied zum expliziten 

Konstruktoraufruf einer Basisklasse ist der, dass hier natürlich nicht der 

Klassenname der zu konstruierenden Klasse geschrieben wird, sondern der 

entsprechende Variablenname des zu initialisierenden Members. In unserem 

Fall also wird just_a_member_ mit dem Wert 17 als Parameter initialisiert. 

Sollte es einen default Konstruktor geben, dann hätte man theoretisch 

die Wahl zwischen dieser hier gezeigten Art, einen besonderen Konstruktor 

aufzurufen und der Möglichkeit, es beim default Konstruktor zu belassen und 

danach eine explizite Zuweisung im eigenen Konstruktor vorzunehmen. Es 

ist allerdings guter Programmierstil, die hier gezeigte Konstruktor Aufrufschreibweise 

zu verwenden, da dadurch explizit klar ist, dass es sich um eine 

Initialisierung handelt und nicht um eine “einfache Zuweisung”.


Vorsicht Falle: Bei Neulingen gibt es öfters großes Staunen, warum sich der 

Compiler beschwert, dass er einen Member einer Klasse nicht initialisieren 

kann. Sehr oft liegt der Grund darin, dass vergessen wurde, im Konstruktor 

der Klasse die notwendige explizite Initialisierung bei nicht-Vorhandensein 

eines default Konstruktors dieses Members anzugeben. Ein Blick auf die 

Deklaration der Klasse des problematischen Members lohnt sich zumeist, um 

hier Klarheit zu schaffen. 

An dieser Stelle muss noch erwähnt werden, dass die spezielle Schreibweise 

zur Initialisierung nicht nur für benutzerdefinierte Objekte funktioniert, 

sondern auch auf primitive Datentypen anwendbar ist. Aus Gründen der 

Einheitlichkeit und aus anderen, noch viel wichtigeren Gründen, die in Kapitel 

11 noch genauer beleuchtet werden, wird dringend empfohlen, diese 

Art der Initialisierung der einfachen Zuweisung innerhalb eines Konstruktors 

vorzuziehen. 

9.4.8 Temporäre Objekte 

Temporäre Objekte sind Objekte, die nicht über einen Variablennamen ansprechbar 

sind, sondern nur als Speicher für Zwischenergebnisse bei der Abarbeitung 

von Expressions dienen. Sobald die entsprechende Expression ausgewertet 

ist, werden diese temporären Objekte wieder verworfen. Wenn sie 

schon keine echten Variablen sind und auch nicht über einen Variablennamen 

angesprochen werden können, wie entstehen und verschwinden sie dann? 

Ganz einfach: Dafür ist einzig und allein der Compiler verantwortlich. Am 

leichtesten ist dies anhand der Auswertung von mathematischen Ausdrücken 

zu verstehen. Analysieren wir einfach einmal die schrittweise Abarbeitung 

der Expression 

result = var1 + var2 + (var3 + var4) * var5; 

Es ist belanglos, welchen Datentyp unsere einzelnen Variablen und das Ergebnis 

haben, der Compiler wertet den Ausdruck prinzipiell so aus: 

1. Es wird die Addition von var1 und var2 durchgeführt. Das Ergebnis 

dieser Addition wird in einem temporären Objekt abgelegt, nennen wir 

es einfach einmal temp1. Was sollte der Compiler auch sonst mit dem 

Ergebnis tun? Er darf weder var1 noch var2 verändern, also muss er 

das Ergebnis irgendwo anders zwischenspeichern. 

2. Im nächsten Schritt wird die Addition von var3 und var4 vorgenommen. 

Das Resultat landet zwangsweise wieder in einem temporären Objekt, das 

wir hier als temp2 bezeichnen wollen. 

3. Das temporäre Objekt temp2 wird mit var5 multipliziert, was erneut ein 

temporäres Objekt ergibt. Nennen wir dieses temp3. 

4. Nun werden temp1 und temp3 addiert, was erneut ein temporäres Objekt 

ergibt, das wir mit temp4 bezeichnen wollen.


5. Im letzten Schritt der Auswertung der Expression wird nun temp4 an 

result zugewiesen. 

6. Da jetzt die gesamte Expression fertig abgearbeitet ist, sorgt der Compiler 

dafür, dass die Geister, die er rief, nämlich die temporären Objekte, 

auch wieder aufgeräumt werden. 

Ich möchte hier noch anmerken, dass ich hier ganz bewusst den naiven Weg 

beschrieben habe und keinerlei Rücksicht auf eventuelle Optimierungsmaßnahmen 

des Compilers genommen habe. 

Soweit es also Expressions wie die gerade analysierte betrifft, haben Entwickler 

mit dem Erzeugen und dem Zerstören von temporären Objekten nicht 

wirklich sehr viel zu tun. Nun ja, beinahe – Wir werden dieses Thema in 

Kapitel 12 noch einmal kurz anreißen, und aus einem anderen Blickwinkel 

betrachten. Es gibt jedoch auch Fälle, in denen wir zwar dem Compiler die 

Aufsicht über die Lifetime eines temporären Objekts überlassen wollen, jedoch 

das temporäre Objekt selbst per Hand erzeugen wollen. Eine solche 

Situation ist an folgendem Beispiel zu sehen (temp_object_demo.cpp): 

1 // temp object demo . cpp − demo how to u t i l i z e temporary o b j e c t s 

2 



5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 

11 ∗ Message 

12 ∗ 

13 ∗ j u s t a dummy f o r demo purposes 

14 ∗ 

15 ∗/ 

16 

17 class Message 

18 { 


20 char ∗ message ; 

21 public : 

22 Message ( const char ∗ message ) ; 

23 Message ( const Message & s r c ) ; 

24 virtual ˜ Message ( ) ; 

25 

26 virtual char ∗ g e t S t r i n g ( ) 

27 { 

28 return ( message ) ; 

29 } 

30 } ; 

31 

32 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

33 Message : : Message ( const char ∗ message ) 

34 { 

35 cout

41 


42 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

43 Message : : Message ( const Message & s r c ) 

44 { 

45 cout


3. Im Zuge der Abarbeitung dieses Aufrufs wird das temporäre Message 

Objekt erzeugt. Dies sieht man am Output des entsprechenden Konstruktors. 

4. Auf diesem Objekt wird die Methode getString aufgerufen, die den 

entsprechenden String liefert. 

5. Der gelieferte String wird ausgegeben. 

6. Direkt auf den String folgend wird auch noch der Zeilenumbruch ausgegeben. 

7. Damit ist die Expression fertig abgearbeitet und das temporäre Objekt 

wird plangemäß in die ewigen Jagdgründe geschickt, wie man am Output 

des Destruktors erkennt.

10. Memory – ein kleines Beispiel 

Wie versprochen, möchte ich hier nach dem Kennenlernen der notwendigen 

Fakten zu Klassen in C ++ das Beispiel des Spiels Memory noch einmal aufgreifen 

und vollständig von Anfang an implementieren. Am konkreten Beispiel 

ist es einfacher, einmal alle Gedanken zu ordnen, die vielleicht zwischendurch, 

bei der Lektüre so einiger technischer Details, durcheinander gekommen sind. 

Zu einer sauberen Entwicklung gehört natürlich ein sauberes Konzept. Dieses 

wird in der Praxis dadurch erreicht, dass man zuerst alle einzelnen Use-Cases 

Stück für Stück ablaufmäßig erfasst und aus diesen die User-Requirements 

ableitet. Diese landen dann im URD (=User Requirements Document). Um 

nun niemanden zu sehr zu langweilen, erspare ich mir an dieser Stelle die 

Abhandlung, wie die Abläufe des Drückens auf eine Taste, des Umdrehens 

aller Karten, des Umdrehens einer einzelnen Karte, etc. aus Sicht des Endbenutzers 

aussehen. Auch das SRD (=Software Requirements Document) ist an 

dieser Stelle nicht besonders spannend. An dieser Stelle bedeutet in diesem 

Kontext hier im Buch. Im Rahmen einer Entwicklung (und ich meine jeder 

Entwicklung!) sind diese Dokumente sehr wohl spannend, um nicht zu sagen 

lebensnotwendig! 

Für die Beschreibung hier im Buch wird es beim ADD (=Architectural 

Design Document) wichtig. Dieses entsteht als Resultat aus URD und SRD 

und das ist auch genau der Punkt, an dem wir hier in die Entwicklung einsteigen. 

10.1 Das ADD 

Das ADD beschreibt im Prinzip die interne Architektur der zu erstellenden 

Software. Der wichtigste Teil der Arbeit bei der Erstellung einer tragfähigen 

Softwarearchitektur besteht darin, ein sauberes Modell zu finden, das 

modular und damit durchschaubar und beherrschbar ist. Mit durchschaubar 

und beherrschbar meine ich hier natürlich auch, dass diese Eigenschaften 

nicht nur bis zur ersten Version gegeben sind, sondern, dass sie über alle Stufen 

späterer Weiterentwicklung erhalten bleiben. Je nachdem, wie weit man 

vorausgedacht hat, sind bei späteren Anpassungen der Software auch Änderungen 

an der Architektur notwendig. Die in der Folge sehr kurz dargestellten 

Designentscheidungen entsprechen einer von vielen möglichen sauberen

258 10. Memory – ein kleines Beispiel 

Lösungen für eine Architektur für Memory. Es mögen aber bitte alle Leser im 

Hinterkopf behalten, dass wir hier noch nicht die ultimative Memory-Version 

entwickeln. Dazu würden noch einige Aspekte hinzukommen, die bisher nicht 

bekannt sind. 

Ich möchte nochmals betonen, dass ein ADD niemals in einem Stück von 

Anfang bis Ende geschrieben wird und dann einfach passt. Im Normalfall 

sind etliche Iterationsschritte vonnöten, um kleinere oder größere Probleme 

befriedigend in den Griff zu bekommen. Je größer und komplexer die zu entwickelnde 

Software ist, desto mehr solche Schritte müssen bis zum Erreichen 

des Ziels durchgeführt werden. Es sollten sich die Leser des Buchs also nicht 

erwarten, dass sie zu einer geforderten Software einfach ein ADD aus dem 

Ärmel schütteln und damit gleich alles bestens erfüllt haben. 

10.1.1 Identifikation der Grobmodule 

Ein wenig Überlegung über die internen Gegebenheiten und das Zusammenspiel 

verschiedener Faktoren im Programm ergibt einmal eine Identifikation 

funktionaler Module, die sich im Design wiederfindet: 

Input Handling: Das Input Handling besteht sinnigerweise daraus, dass Keyboard 

Eingaben der Benutzer entgegengenommen werden. Diese werden 

dann zuerst auf ihre Sinnhaftigkeit untersucht. Im Fall, dass sie unsinnig 

sind, werden sie mit einem entsprechenden Fehler quittiert, ansonsten 

werden Aktionen getriggert. Das Triggern von Aktionen erfolgt über das 

Modul Spielsteuerung. 

Spielsteuerung: Die Spielsteuerung übernimmt die gesamte Steuerung des 

Ablaufs einer Partie Memory. Sie triggert das Initialisieren des Spielfelds, 

das Auf- und Zudecken der Karten und alle Aktionen, die aufgrund von 

Benutzereingaben stattfinden. 

Output Handling: Das Output Handling übernimmt die Aufgabe, das Spielfeld 

bei Aufruf im aktuellen Zustand anzuzeigen. 

Memory Spielfeld: Das Spielfeld übernimmt die Aufgabe, die einzelnen Karten 

zu halten, die jedem Einzelfeld zugeordnet sind. 

Memory Karte: Es gibt im Spiel eine gewisse Anzahl von Memory Karten, 

die auf das Spielfeld verteilt werden. 

Commandline Handling: Dieses Modul ergibt sich aus einem Requirement, 

das bisher noch verschwiegen wurde. Die Größe des Spielfelds wird mittels 

zweier Parameter auf der Commandline beim Starten des Programms 

bestimmt. Der erste Parameter repräsentiert die Anzahl der Spalten 

(=Zellen pro Reihe), der zweite Parameter die Anzahl der Reihen. 

Man könnte (und sollte sogar) noch viel ausführlicher die Aufgaben der Grobmodule 

beschreiben, aber ich glaube, die Idee hinter dieser Aufteilung ist einigermaßen 

klar. Deshalb ist es sinnvoller, in der Folge die einzelnen Module 

Stück für Stück unter die Lupe zu nehmen und sie weiter zu zerlegen, um

10.1 Das ADD 259 

unserem eigentlichen Ziel, der Implementation des Spiels, schneller näher zu 

kommen. 

10.1.2 Weitere Zerlegung der einzelnen Grobmodule 

Betrachten wir nun die einzelnen Module getrennt voneinander, um ihre 

Schnittstellen, sowie ihre interne Aufteilung identifizieren zu können. Es ist 

in der Folge leicht erkennbar, dass durch die genauere Beschreibung gewisser 

Abläufe und Gegebenheiten leicht eine Liste von Anforderungen der Module 

untereinander identifiziert werden kann, durch die die Schnittstellen definiert 

bzw. auf ihre Sinnhaftigkeit überprüft werden können. 

Input Handling. Um eine vernünftige Analyse des Input Handlings machen 

zu können, muss ich hier etwas nachholen, was in der ursprünglichen Angabe 

zum Spiel verschwiegen wurde: Wie bedient man das Spiel eigentlich? Hierzu 

nehmen wir die einfachst mögliche Variante: 

• Das Programm wartet immer auf die Eingabe eines Zahlenpaares, wobei 

die erste Zahl die Reihe und die zweite Zahl die Spalte darstellt. 

• Nachdem immer zwei zusammengehörige Karten aufgedeckt werden sollen, 

ist die weitere Logik folgendermaßen: 

– Das erste Zahlenpaar wird an die Spielsteuerung weitergegeben. Diese 

hat dann die Aufgabe, die entsprechende Karte einmal aufzudecken und 

auf die Übermittlung des zweiten Zahlenpaars zu warten. 

– Das zweite Zahlenpaar wird an die Spielsteuerung weitergegeben. Dadurch 

wird die zweite Karte aufgedeckt. Sollten die beiden Karten dasselbe 

Symbol zeigen, dann werden beide aufgedeckt liegen gelassen, ansonsten 

werden sie beide wieder umgedreht. 

Wenn man weiter überlegt, dann sieht man, dass die Aufgabe des Input 

Handlings nicht wirklich viel mit dem Spiel direkt zu tun hat, denn dieses 

Modul soll ja allgemein verwendbar sein. Dasselbe Input Handling wie hier 

kann ja auch z.B. in einem Texteditor Verwendung finden. Dementsprechend 

beschränken wir die Aufgabe des Input Handlings darauf, Eingabeworte entgegenzunehmen 

und als Events an angemeldete Handlers weiterzureichen. 

Der bzw. die Handlers stellen die Schnittstelle zur Spielsteuerung dar. 

Spielsteuerung. Die Spielsteuerung wird über die eingehenden Keyboard 

Events informiert und triggert die entsprechenden Aktionen am Spielfeld. 

Das bedeutet, dass die gesamte Logik des Spiels, also, was zu welchem Zeitpunkt 

zu passieren hat, in diesem Modul steckt. Dies betrifft natürlich auch 

die Initialisierungsphase des Spiels. 

Dadurch, dass nur der Spielsteuerung die Abläufe bekannt sind, ist sie 

auch dafür verantwortlich, die Ausgabe des Spielfeldes durch das Output 

Handling zu veranlassen.


Output Handling. Das Output Handling ist dafür verantwortlich, die Ausgabe 

des gesamten Spielfeldes, respektive der einzelnen Karten auf ihm, zu 

steuern und dafür zu sorgen, dass diese am Bildschirm erscheinen. Weil 

auch dieses natürlich ein allgemeines Modul sein soll, wird hier das bereits 

mehrfach besprochene Prinzip mittels einer abstrakten darstellbaren Klasse 

Anwendung finden. 

Da die Randbedingungen hierfür bereits mehrfach aus verschiedenen Gesichtspunkten 

besprochen wurden, möchte ich den Lesern hier eine nochmalige 

genaue Beschreibung ersparen. 

Memory Spielfeld. Das Memory Spielfeld ist im Prinzip eine Matrix von 

Einzelfeldern, wobei jedes dieser Einzelfelder genau eine Karte halten kann. 

Im Prinzip gibt es hierfür eine besonders sinnvolle Konstruktion: Eine Matrix 

ist im Prinzip nichts anderes als ein Vektor von Vektoren. Die dadurch entstehenden 

Zellen halten jeweils eine Karte. Dazu lässt sich leicht ein besonders 

sauberes Design mittels allgemeiner Vektoren und Spezialisierung derselben 

auf bestimmte Daten beschreiben. Nur leider fehlen uns derzeit noch ein 

paar wichtige Konstrukte, die eine elegante Umsetzung dieses Designs auf 

C ++ Sprachebene ermöglichen. Aus diesem Grund bleiben wir zwar beim 

allgemeinen Design, die Implementation desselben sollte aber bitte nicht als 

Vorlage für ein professionelles Vektor-Design dienen. 

Memory Karte. Zu den Aspekten des Designs einer Memory Karte möchte 

ich mich hier auch nicht weiter auslassen, denn diese wurden bereits mehrfach 

aus verschiedenen Blickwinkeln besprochen. Eine Wiederholung an dieser 

Stelle wäre dementsprechend langweilig. 

Commandline Handling. Das Commandline Handling bekommt die dem 

Programm übergebenen Parameter überreicht und sorgt dafür, dass das entsprechende 

Bootstrapping des Systems stattfindet. Im Bootstrapping werden 

die entsprechenden notwendigen Instanzen der Klassen erzeugt und zwar in 

der Form, wie sie den eingegebenen Parametern (Zeilen, Spalten) entspricht. 

10.2 Das DDD 

Viele Entwickler empfinden die Erstellung eines DDD (=Detailed Design Document) 

als lästig und zeitraubend und deshalb wird diese Aufgabe oft nur 

sehr halbherzig gemacht oder einfach vollständig übersprungen. In Summe 

erspart man sich durch diese Herangehensweise aber keine Zeit, ganz im 

Gegenteil! Durch das Fehlen des DDD fallen viele Probleme erst beim Implementieren 

der Software auf und führen zu dementsprechend vielen kleineren 

und größeren Änderungen derselben in dieser Phase. Das Schlimmste bei 

diesen Änderungen ist, dass man es in Bezug auf die Schnittstellen mit einem 

moving Target zu tun hat. Dadurch werden mit wachsender Größe der 

Software die Fehler immer häufiger und schwerer zu lokalisieren, denn man

10.2 Das DDD 261 

kann sich sicher nicht immer ganz genau erinnern, wer jetzt eine Klasse wie 

verwendet hat. 

Allen Lesern, die sich bisher immer gesträubt haben, ein DDD zu erstellen, 

bevor sie zu implementieren begonnen haben, möchte ich in der Folge eine 

Kompromisslösung vorstellen, wie sie in kleinen Projekten recht brauchbar 

eingesetzt werden kann. Sie ist nicht vollkommen gleichwertig zu einem echten 

DDD, aber sie stellt zumindest eine deutliche Verbesserung im Vergleich 

zur Vorgehensweise dar, gar kein DDD zu schreiben. Außerdem bekommt 

man durch diese Methode einigermaßen dokumentierten Source Code, ohne 

hinterher mühsam dokumentieren zu müssen. 

10.2.1 Klassendiagramm 

Im ersten Schritt nimmt man das ADD zur Hand. Aus der darin umrissenen 

Architektur ergibt sich in der Folge durch mehrere Analyse- und Verfeinerungsschritte 

das grobe Klassendiagramm, wie es in Abbildung 10.1 dargestellt 

ist. Die Ableitungspfeile sind ja schon bekannt, die strichlierten Pfeile 

in diesem Diagramm stehen für entsprechende Referenzen der Klassen untereinander 

(=HAS-A Relationen). 

10.2.2 Klassendeklarationen 

Mit Hilfe des Klassendiagramms erstellt man die vollständigen Deklarationen 

für die einzelnen Klassen. Hierbei werden gleich die entsprechenden Headers 

geschrieben, die auch in der fertigen Implementation verwendet werden. Der 

Trick bei diesem Schritt ist, dass alle Variablen, Methoden und Funktionen 

gleich im Header genau beschrieben werden. Dadurch hat man erstens die 

Möglichkeit, zu prüfen, ob das Design funktionieren kann oder ob man vielleicht 

etwas vergessen hat. Auch fallen Fehldesigns sehr schnell auf, weil 

diese schon in der Beschreibung recht umständlich werden. Dadurch aber, 

dass man noch keinen Code geschrieben hat, sind Änderungen noch relativ 

problemlos möglich. Weil die in der Designphase geschriebenen Headers 

auch wirklich in der Implementation verwendet werden, sind in der hier abgedruckten 

Version auch ein paar Inline Methoden zu finden, die nicht aus 

der Designphase, sondern aus der Implementation kommen. 

Ein ganz großer Vorteil bei dieser Vorgehensweise ist auch, dass man die 

Headers an andere Entwickler zur Implementation weitergeben kann. Durch 

die genaue Beschreibung müssen diese dann nicht selbst alles noch einmal 

von vorn durchdenken (und dabei vielleicht das Design verletzen), sondern 

können nach genauer Vorgabe zur Implementation schreiten. Schreiten wir 

also zur Tat... 

Ein keiner Exkurs: Im Anschluss an die dokumentierten Klassendeklarationen 

finden sich noch ausgewählte Teile des Source Codes. Diese sollen


SimpleOutputHandling OutputContext 

Displayable GameCard 

TextOutputContext 

MemoryGameboard MemoryGameCard 

SimpleInputHandling 

EventHandler 

MemoryGameControl 

Event 

WordEvent 

MemoryCardSymbolGenerator 

MemoryCardpair 

CommandlineHandling ArgumentHandler 

MemoryCommandlineArgumentHandler 

Abbildung 10.1: grobes Klassendiagramm 

Vector 

used by many classes 

einerseits die internen Abläufe im Programm verdeutlichen, andererseits werden 

ein paar wichtige Details besprochen, über die man sonst im Programmieralltag 

stolpern könnte. Ich möchte deshalb wirklich allen Lesern nahe 

legen, die folgenden Teile aufmerksam zu lesen und zu versuchen, ein tieferes 

Verständnis für das Programm zu bekommen. Die Methode, einfach unaufmerksam 

quer zu lesen, führt mit ziemlicher Sicherheit zur Verwirrung und 

das geht dann garantiert am Sinn dieses Kapitels vorbei. 

Obwohl konzentriertes Lesen bereits sehr viel bringt, möchte ich zusätzlich 

noch allen Lesern ans Herz legen, mit dem Programm ein wenig zu spielen

10.2 Das DDD 263 

und eigene Änderungen und Erweiterungen zu versuchen. Auf diese Art lernt 

man unter Garantie am meisten, auch wenn man sich vielleicht den einen oder 

anderen Absturz einhandelt :-). 

10.2.3 Vector 

Beginnen wir unser detailed Design mit der Klasse, die durch ihre Natur als 

Utility an vielen Stellen gebraucht wird, selbst aber wenig Direktes mit dem 

Rest des Programms zu tun hat: mit unserer Klasse Vector. Der Header für 

diesen hat hier bezeichnenderweise den Namen simple_vector.h bekommen, 

weil er zu Demonstrationszwecken so einfach wie möglich gehalten ist. 

Eine wichtige Überlegung spielt in das Design dieses Vektors hinein: Auf 

welche Art soll man Elemente im Vektor speichern? Im Sinne der Allgemeinheit 

soll es keine Rolle spielen, ob man nun Elemente eines primitiven Datentyps 

oder benutzerdefinierte Objekte speichert. Im Augenblick fehlt uns 

noch das Wissen um Templates, deshalb ist der allgemeinst mögliche Ansatz, 

der uns zur Verfügung steht, das Speichern der Elemente über void *. 

Dadurch, dass nicht die Elemente selbst, sondern nur Pointer auf die Elemente 

im Vektor gehalten werden, stellt sich gleich eine ganz wichtige Frage: 

Was soll man mit diesen im Destruktor tun? Soll man delete auf die Elemente 

aufrufen oder nicht? Leider ist keine der beiden Methoden im Sinne 

der Allgemeinheit befriedigend. Ruft man im Destruktor kein delete für die 

einzelnen Elemente auf, dann hat man die Verantwortung für die Freigabe 

delegiert. Das jedoch kann, je nach Verwendung, zu sinnlosen Mehrfachspeicherungen 

und wüsten Seiteneffekten führen. Ruft man jedoch im Destruktor 

immer ein delete für die Elemente auf, dann hat man dadurch erfolgreich 

verhindert, dass im Vektor auch Elemente gespeichert werden können, die 

nicht dynamisch allokiert wurden. 

Der sauberste Ausweg aus diesem Dilemma ist, den Benutzern des Vektors 

die Entscheidung zu überlassen und sie wählen zu lassen, welche der beiden 

Methoden sie nun bevorzugen. Diese Entscheidung führt dann zu folgendem 

Design des Vektors: 

1 // s i m p l e v e c t o r . h − a simple vector c l a s s 

2 

3 #ifndef s i m p l e v e c t o r h 

4 #define s i m p l e v e c t o r h 

5 


7 #include ” o b j e c t d e l e t o r . h” 

8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ A very simple vector c l a s s that i s able to s t o r e a number o f 

11 ∗ elements as given in the constructor . The number o f elements 

12 ∗ cannot be changed during runtime . 

13 ∗ When constructing a vector i t has to be chosen , whether 

14 ∗ the elements stored in i t are deleted on d e s t r u c t i o n . 

15 ∗/ 

16


17 class Vector 

18 { 

19 private : 

20 

21 /∗ Copy−construction i s not allowed 

22 ∗/ 

23 Vector ( const Vector & s r c ) ; 

24 


26 

27 /∗ The array of p o i n t e r s that hold the elements . I f the 

28 ∗ number of elements f o r t h i s vector i s 0 the pointer 

29 ∗ i s a l s o 0 . 

30 ∗/ 

31 void ∗∗ elements ; 

32 

33 /∗ The number of elements that can be held . The array o f 

34 ∗ p o i n t e r s holding the elements i s a l l o c a t e d to t h i s s i z e . 

35 ∗/ 

36 uint32 num elements ; 

37 

38 /∗ The d e l e t o r f o r elements . I t i s s e t as a parameter 

39 ∗ in the constructor i f d e l e t i o n o f o b j e c t s i s d e s i r e d when 

40 ∗ e i t h e r the vector i s destructed or the element i s overwritten . 

41 ∗ I f i t i s not s e t , no d e l e t i o n o f elements w i l l be done . This 

42 ∗ o bject i t s e l f w i l l not be deleted by the d e s t r u c t o r . 

43 ∗/ 

44 ObjectDeletor & d e l e t o r ; 

45 

46 public : 

47 

48 /∗ Standard constructor 

49 ∗ A l l o c a t e s elements , s e t s num elements and 

50 ∗ d e l e l e m e n t s i f n e c e s s a r y accordingly . 

51 ∗ @param num elements The number o f elements that the vector 

52 ∗ can hold . 

53 ∗ @param d e l e t o r The d e l e t o r i s c a l l e d whenever an element i s 

54 ∗ e i t h e r overwritten or the d e s t r u c t o r i s c a l l e d . I f 

55 ∗ d e l e t i o n of elements i s not d e s i r e d there i s a l s o 

56 ∗ a s p e c i a l DontDelete d e l e t o r ( sounds strange , eh ? :−)) 

57 ∗ that does nothing 

58 ∗/ 

59 Vector ( uint32 num elements , ObjectDeletor & d e l e t o r ) ; 

60 

61 /∗ Destructor 

62 ∗ d e l e t e s elements and i f d e l e l e m e n t s i f n e c e s s a r y i s s e t 

63 ∗ i t a l s o d e l e t e s every s i n g l e element stored in the vector 

64 ∗/ 

65 virtual ˜ Vector ( ) ; 

66 

67 /∗ Sets the given element at the given index p o s i t i o n . I s a l s o 

68 ∗ r e s p o n s i b l e to perform a check to determine i f index i s 

69 ∗ i n s i d e the allowed range . I f the index i s out o f range the 

70 ∗ c a l l i s ignored ( only because exceptions are not known yet ) 

71 ∗ I f there i s an element at the given index and i f the 

72 ∗ d e l e l e m e n t s i f n e c e s s a r y f l a g i s s e t t h i s element i s 

73 ∗ deleted before i t s pointer i s overwritten by the new one . 

74 ∗ @param index The index f o r the element ( s t a r t i n g at 0 ) . 

75 ∗ @param element A pointer to the element that has to be s e t . 

76 ∗/ 

77 virtual void setElementAt ( uint32 index , void ∗ element ) ; 

78 

79 /∗ Returns the element at the given index p o s i t i o n . I s a l s o 

80 ∗ r e s p o n s i g l e to perform a range−check o f index . I f the index 

81 ∗ i s outside the allowed range i t returns 0 ( only because 

82 ∗ exceptions are not known yet ) .

10.2 Das DDD 265 

83 ∗ @param index The index of the d e s i r e d element ( s t a r t i n g at 0 ) . 

84 ∗ @return The stored pointer to the element or 0 

85 ∗ i f outside range . 

86 ∗/ 

87 virtual void ∗ getElementAt ( uint32 index ) const ; 

88 

89 /∗ Returns the element at the given index p o s i t i o n and removes 

90 ∗ i t from the vector without c a l l i n g the d e l e t o r . I s a l s o 

91 ∗ r e s p o n s i g l e to perform a range−check o f index . I f the index 

92 ∗ i s outside the allowed range i t returns 0 ( only because 

93 ∗ exceptions are not known yet ) . 

94 ∗ @param index The index of the d e s i r e d element ( s t a r t i n g at 0 ) . 

95 ∗ @return The stored pointer to the element or 0 

96 ∗ i f outside range . 

97 ∗/ 

98 virtual void ∗ getAndRemoveElementAt ( uint32 index ) const ; 

99 

100 /∗ Returns the number of elements that the vector can hold as 

101 ∗ stored in num elements . 

102 ∗ @return The number of elements that the vector can hold . 

103 ∗/ 

104 virtual uint32 getMaxNumElements ( ) const 

105 { 

106 return ( num elements ) ; 

107 } 

108 } ; 

109 

110 

111 #endif // s i m p l e v e c t o r h 

In Zeile 44 sieht man, welche Konsequenz die Entscheidung hat, das Freigeben 

von Elementen den Benutzern des Vektors zu überlassen: Der Vektor 

kann nicht einfach selbst ein delete für ein Element aufrufen, denn die Elemente 

sind ja als void * gespeichert und delete ist nicht auf einem void * 

aufrufbar. Man kann sich auch sehr schnell überlegen, warum das so ist: 

Es ist delete ja dafür verantwortlich, eventuell existente Destruktoren aufzurufen. 

Das geht aber nicht, wenn man ihm nicht mitteilt, um welchen 

Typ es sich handelt. Aus diesem Grund wurde eine spezielle ObjectDeletor 

Klasse eingeführt, von der die konkreten Implementationen für die verschiedenen 

Elementtypen abgeleitet werden. Diese Klasse wurde aus Gründen der 

Übersichtlichkeit nicht in das Klassendiagramm aufgenommen. 

Mittels Templates, die in Kapitel 13 besprochen werden, kann man dieses 

Problem bei weitem sauberer, durchsichtiger, einfacher und effizienter in 

den Griff bekommen. Deshalb möchte ich es hier dabei belassen und keine 

besonderen Abhandlungen zum Thema Deletor schreiben. Leser, die, von C 

kommend, in Funktionspointer verliebt sind, können sich natürlich auch eine 

solche Lösung durch den Kopf gehen lassen. Zu den Funktionspointern werde 

ich noch in Abschnitt 15.3 ein paar Worte verlieren. 

Vorsicht Falle: Eine weitere Konsequenz hat die Entscheidung, den Vektor 

mit Hilfe des Deletors Objekte löschen zu lassen: Wird ein Element im 

Vektor überschrieben, so wird das zuvor an dieser Stelle befindliche Objekt 

gelöscht. Ist auch klar, sonst würde ja ein Speicherloch entstehen, wenn man 

den Pointer durch Überschreiben verliert. Was passiert allerdings, wenn man


z.B. zwei Elemente im Vektor vertauschen will? Man ruft getElementAt 

für das erste Element auf und merkt sich den retournierten Pointer. Dann 

ruft man getElementAt für das zweite Element auf, um es gleich wieder mit 

setElementAt an die Stelle des ersten Elements zu schreiben. Dann schreibt 

man das zwischengespeicherte erste Element an die Stelle, an der vorher das 

zweite Element stand. Und dann sucht man beim nächsten Zugriff auf eines 

der beiden Elemente ziemlich lange nach einer völlig unerklärbaren Segmentation 

Violation... 

In diesem Beispiel wird nämlich bei den beiden setElementAt Operationen 

von der Vektor Klasse das jeweils vorher dort gespeicherte Element 

durch einen entsprechenden Deletor Aufruf über den Jordan geschickt! Woher 

sollte der Vektor denn auch ahnen, dass wir die Elemente auch wirklich 

nicht “verlieren”? Um dieses Problem in den Griff zu bekommen, wurde die 

Methode getAndRemoveElementAt eingeführt, die das gelieferte Objekt aus 

dem Vektor entfernt, indem an diese Stelle ein 0 Pointer gesetzt wird. 

10.2.4 ObjectDeletor 

Das allgemeine Interface für einen ObjectDeletor ist denkbar einfach, wie 

man in der Folge sieht: 

1 // o b j e c t d e l e t o r . h − the i n t e r f a c e f o r an o b j e c t d e l e t o r 

2 // as i t i s used by the simple vector c l a s s 

3 

4 #ifndef o b j e c t d e l e t o r h 

5 #define o b j e c t d e l e t o r h 

6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 /∗ The i n t e r f a c e f o r an o bject d e l e t o r 

9 ∗/ 

10 

11 class ObjectDeletor 

12 { 

13 public : 


15 ∗ Just to make sure that a v i r t u a l d e s t r u c t o r e x i s t s 

16 ∗/ 

17 virtual ˜ ObjectDeletor ( ) { } 

18 

19 /∗ I s c a l l e d with a pointer to the o b j e c t and has to d e l e t e 

20 ∗ i t . Please note that i t can a l s o happen that a 0 pointer 

21 ∗ i s given as a parameter 

22 ∗ @param obj The pointer to the o b j e c t that has to be deleted 

23 ∗/ 

24 virtual void deleteObject ( void ∗ obj ) = 0 ; 

25 } ; 

26 

27 #endif // o b j e c t d e l e t o r h

10.2.5 Konkrete Deletors 

10.2 Das DDD 267 

Für die verschiedenen Elementtypen, die in Vektoren gespeichert werden, 

müssen natürlich die entsprechenden konkreten Deletors implementiert werden. 

Diese wurden gleich kurzerhand alle gemeinsam in ein File verpackt. 

Der einzig interessante Aspekt bei diesen konkreten Implementationen ist, 

dass es sich hier um eine leichte Abwandlung des Singleton Design Patterns 

handelt: Es gibt von jedem dieser konkreten Deletors im gesamten System 

nur jeweils eine einzige Instanz. Dies ist deshalb sinnvoll, weil diese Deletors 

keine Statusinformation speichern. Und man will ja nicht für jeden einzelnen 

Vektor immer wieder unnötig einen neuen Deletor anlegen, den man eigentlich 

sowieso schon hat. Um nun nicht mit irgendwelchen Merkervariablen 

Abhängigkeiten und Seiteneffekte zu erzeugen, gibt es bei unseren konkreten 

Deletors immer eine static Methode getInstance, über die man eine 

Referenz auf die einzige existente Instanz des Deletors erhält. 

Der erste Deletor in den Zeilen 17–54 ist auch gleich ein nettes Paradoxon: 

Wie der Name DontDelete schon sagt, ist er ein Deletor, der gar nicht daran 

denkt, etwas zu löschen :-). Der Grund für dessen Existenz ist einfach: Aus 

Sicherheitsgründen wollte ich nicht mit Pointers auf Deletors arbeiten, denn 

dabei kann man groben Unfug treiben (z.B. die einzige Instanz löschen, etc.). 

Daher wird im Programm immer nur mit Referenzen auf Deletors gearbeitet, 

so auch im Vektor selbst. Mit Referenzen hat man allerdings im Vektor die 

Möglichkeit nicht, einfach einen 0 Pointer als Signal für “nichts löschen” zu 

verwenden. Deshalb ruft der Vektor immer den ihm übergebenen Deletor auf 

und im Fall, dass man nichts löschen will, übergibt man eben die Instanz des 

DontDelete Deletors. Durch diese Maßnahme wird das Programm auch bei 

späteren Änderungen robuster gegen schwer zu findende Pointerfehler. Es 

ist nichts leichter, als im Vektor bei einer Änderung eine 0-Abfrage auf den 

Deletor Pointer zu vergessen... 

1 // c o n c r e t e o b j e c t d e l e t o r s . h − a c o l l e c t i o n o f the concrete 

2 // o bject d e l e t o r s that are used f o r the v e c t o r s in the 

3 // memory game 

4 

5 #ifndef c o n c r e t e o b j e c t d e l e t o r s h 

6 #define c o n c r e t e o b j e c t d e l e t o r s h 

7 

8 #include ” o b j e c t d e l e t o r . h” 


10 #include ” s i m p l e v e c t o r . h” 

11 #include ” s i m p l e d i s p l a y a b l e . h” 

12 

13 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

14 /∗ A concrete d e l e t o r that does not d e l e t e anything :−) 

15 ∗/ 

16 

17 class DontDelete : public ObjectDeletor 

18 { 

19 private : 

20 /∗ Copy construction i s not allowed 

21 ∗/ 

22 DontDelete ( const DontDelete& s r c ) {}



24 

25 /∗ This v a r i a b l e holds the s i n g l e i n stance o f t h i s d e l e t o r . 

26 ∗ To obtain t h i s instance , getInstance has to be c a l l e d 

27 ∗/ 

28 static DontDelete d e l e t o r ; 

29 

30 /∗ This c l a s s i s implemented as a s i n g l e t o n , so the constructor 

31 ∗ must not be public . 

32 ∗/ 

33 DontDelete ( ) { } 

34 

35 /∗ This c l a s s i s implemented as a s i n g l e t o n , so the d e s t r u c t o r 


37 ∗/ 

38 virtual ˜ DontDelete ( ) { } 

39 public : 

40 

41 /∗ This method i s used to obtain an i n s t a n c e o f the d e l e t o r 

42 ∗/ 

43 static DontDelete & getInstance ( ) 

44 { 

45 return ( d e l e t o r ) ; 

46 } 

47 

48 /∗ This i s the dummy c a l l b a c k implementation that does not 

49 ∗ d e l e t e anything . . . 

50 ∗ @param obj The pointer to the o b j e c t to be deleted 

51 ∗/ 

52 virtual void deleteObject ( void ∗ obj ) {} 

53 

54 } ; 

55 

56 

57 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

58 /∗ A concrete d e l e t o r f o r char ∗ elements 

59 ∗/ 

60 

61 class CharDeletor : public ObjectDeletor 

62 { 

63 private : 


65 ∗/ 

66 CharDeletor ( const CharDeletor& s r c ) {} 


68 

69 /∗ This v a r i a b l e holds the s i n g l e i n s t a n c e o f t h i s d e l e t o r . 


71 ∗/ 

72 static CharDeletor d e l e t o r ; 

73 



76 ∗/ 

77 CharDeletor ( ) { } 

78 



81 ∗/ 

82 virtual ˜ CharDeletor ( ) { } 

83 public : 

84 

85 /∗ This method i s used to obtain an i n stance o f the d e l e t o r 

86 ∗/ 

87 static CharDeletor & getInstance ( ) 

88 {


90 } 

91 

92 /∗ This i s the c a l l b a c k implementation 


94 ∗/ 

95 virtual void deleteObject ( void ∗ obj ) 

96 { 

97 delete static cast(obj ) ; 

98 } 

99 } ; 

100 

10.2 Das DDD 269 

101 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

102 /∗ A concrete d e l e t o r f o r uint32 ∗ elements 

103 ∗/ 

104 

105 class Uint32Deletor : public ObjectDeletor 

106 { 

107 private : 


109 ∗/ 

110 Uint32Deletor ( const Uint32Deletor& s r c ) {} 


112 



115 ∗/ 

116 static Uint32Deletor d e l e t o r ; 

117 



120 ∗/ 

121 Uint32Deletor ( ) { } 

122 



125 ∗/ 

126 virtual ˜ Uint32Deletor ( ) { } 

127 public : 

128 


130 ∗/ 

131 static Uint32Deletor & getInstance ( ) 

132 { 


134 } 

135 



138 ∗/ 


140 { 


142 } 

143 } ; 

144 

145 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

146 /∗ A concrete d e l e t o r f o r Vector ∗ elements 

147 ∗/ 

148 

149 class VectorDeletor : public ObjectDeletor 

150 { 

151 private : 


153 ∗/ 

154 VectorDeletor ( const VectorDeletor& s r c ) {}



156 



159 ∗/ 

160 static VectorDeletor d e l e t o r ; 

161 



164 ∗/ 

165 VectorDeletor ( ) { } 

166 



169 ∗/ 

170 virtual ˜ VectorDeletor ( ) { } 

171 public : 

172 


174 ∗/ 

175 static VectorDeletor & getInstance ( ) 

176 { 


178 } 

179 



182 ∗/ 


184 { 


186 } 

187 } ; 

188 

189 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

190 /∗ A concrete d e l e t o r f o r Displayable ∗ elements 

191 ∗/ 

192 

193 class DisplayableDeletor : public ObjectDeletor 

194 { 

195 private : 


197 ∗/ 

198 DisplayableDeletor ( const DisplayableDeletor & s r c ) {} 


200 



203 ∗/ 

204 static DisplayableDeletor d e l e t o r ; 

205 



208 ∗/ 

209 DisplayableDeletor ( ) { } 

210 



213 ∗/ 

214 virtual ˜ DisplayableDeletor ( ) { } 

215 public : 

216 


218 ∗/ 

219 static DisplayableDeletor & getInstance ( ) 

220 {


222 } 

223 



226 ∗/ 


228 { 


230 } 

231 } ; 

232 

233 

234 #endif // c o n c r e t e o b j e c t d e l e t o r s h 

10.2.6 ArgumentHandler 

10.2 Das DDD 271 

Neben dem Vector ist auch die Basisklasse ArgumentHandler und alles, was 

sich rund um diese Klasse herum abspielt, ein relativ abgeschlossenes Thema 

für sich. Also wenden wir uns ihr gleich einmal zu. Der ArgumentHandler ist 

ganz einfach nur eine abstrakte Basis, über die das CommandlineHandling die 

einzelnen Parameter zur Auswertung weitergeben kann. Dementsprechend 

einfach ist auch dieses Interface: 

1 // simple argument handler . h − i n t e r f a c e f o r an argument handler 

2 

3 #ifndef simple argument handler h 

4 #define simple argument handler h 

5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 /∗ An abstract base c l a s s of a very simple argument handler . 

8 ∗ A concrete implementation of a handler has to be derived from 

9 ∗ t h i s base and obtains n o t i f i c a t i o n s f o r every s i n g l e argument . 

10 ∗/ 

11 

12 class ArgumentHandler 

13 { 

14 public : 

15 


17 ∗ The d e s t r u c t o r i s j u s t implemented to make sure that a v i r t u a l 

18 ∗ d e s t r u c t o r e x i s t s 

19 ∗/ 

20 virtual ˜ ArgumentHandler ( ) { } 

21 

22 /∗ This method i s a c a l l b a c k used to n o t i f y the handler o f an 

23 ∗ argument that was obtained . 

24 ∗ @param index The index of the argument . All arguments are 

25 ∗ numbered in a consecutive order s t a r t i n g at 0 . 

26 ∗ @param arg A pointer to the argument that was obtained . This 

27 ∗ parameter i s declared as a void ∗ , because argument 

28 ∗ n o t i f i c a t i o n s are performed in a typed manner . 

29 ∗ Depending on the expected argument type the t r i g g e r 

30 ∗ c l a s s of a n o t i f i c a t i o n has to perform the according 

31 ∗ conversion . I f e . g . an i n t argument i s expected 

32 ∗ the n o t i f i c a t i o n i s done with an i n t ∗ . 

33 ∗/ 

34 virtual void argumentNotification ( uint32 index , const void ∗ arg ) = 0 ; 

35 } ;


36 

37 

38 #e n d i f // simple argument handler h 

10.2.7 MemoryCommandlineArgumentHandler 

Da wir gerade das entsprechende Interface kennen gelernt haben, sehen wir 

uns auch gleich die entsprechende Implementation an, die in unserem Spiel 

Anwendung finden wird. 

1 // memory commandline arg handler . h − s p e c i a l argument handler 

2 // f o r the memory game 

3 

4 #ifndef memory commandline arg handler h 

5 #define memory commandline arg handler h 

6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 /∗ The commandline argument handler f o r the memory game 

9 ∗ I t i s implemented as a simple container that s t o r e s the number 

10 ∗ o f rows and columns that are s e t via c a l l b a c k s from the 

11 ∗ CommandlineHandling or a compatible c l a s s . 

12 ∗/ 

13 

14 class MemoryCommandlineArgumentHandler : public ArgumentHandler 

15 { 


17 

18 /∗ The i n d i c e s of the number of rows and columns according to 

19 ∗ the commandline s p e c i f i c a t i o n o f the game ( argv [ 0 ] = progname , 

20 ∗ argv [ 1 ] = rows , argv [ 2 ] = c o l s ) . 

21 ∗/ 

22 static const uint32 ROW DEF INDEX = 1; 

23 static const uint32 COL DEF INDEX = 2; 

24 

25 /∗ The number of rows of the gameboard 

26 ∗/ 

27 uint32 num rows ; 

28 

29 /∗ The number of columns of the gameboard 

30 ∗/ 

31 uint32 num cols ; 

32 

33 public : 

34 

35 /∗ Default constructor 

36 ∗ I n i t i a l i z e s a l l v a r i a b l e s to 0 

37 ∗/ 

38 MemoryCommandlineArgumentHandler ( ) : 

39 num rows ( 0 ) , num cols ( 0) { } 

40 


42 ∗ Just to make sure that there i s a v i r t u a l d e s t r u c t o r 

43 ∗/ 

44 virtual ˜ MemoryCommandlineArgumentHandler ( ) { } 

45 

46 /∗ Callback f o r a n o t i f i c a t i o n according to the base i n t e r f a c e 

47 ∗ I f everything i s ok t h i s c a l l b a c k w i l l be c a l l e d f o r two 

48 ∗ arguments : The number of rows and the number o f columns . 

49 ∗ According to the convention both arguments w i l l be passed 

50 ∗ as p o i n t e r s to uint32 . See a l s o c l a s s CommandlineHandling 

51 ∗ @param index The index of the argument in the commandline .

10.2 Das DDD 273 

52 ∗ As i s the s p e c i f i c a t i o n the program name has index 0 

53 ∗ and the arguments s t a r t with index 1 . 

54 ∗ @param arg The argument s t r i n g as given in the commandline 

55 ∗/ 

56 virtual void argumentNotification ( uint32 index , const void ∗ arg ) 

57 { 

58 switch ( index ) 

59 { 

60 case ROW DEF INDEX: 

61 num rows = ∗( static cast(arg ) ) ; 

62 break ; 

63 case COL DEF INDEX: 

64 num cols = ∗( static cast(arg ) ) ; 

65 break ; 

66 default : 

67 break ; 

68 } 

69 } 

70 

71 /∗ Returns the number of rows as s e t from the commandline 

72 ∗ @return The value of the rows−parameter 

73 ∗/ 

74 virtual uint32 getRows ( ) 

75 { 

76 return ( num rows ) ; 

77 } 

78 

79 /∗ Returns the number of columns as s e t from the commandline 

80 ∗ @return The value of the c o l s−parameter 

81 ∗/ 

82 virtual uint32 getCols ( ) 

83 { 

84 return ( num cols ) ; 

85 } 

86 } ; 

87 

88 

89 #endif // memory commandline arg handler h 

10.2.8 CommandlineHandling 

Um das Kapitel des Argument Handlings abzurunden, werfen wir einen Blick 

auf die Klasse CommandlineHandling. Diese Klasse ist dafür verantwortlich, 

die Argumente aus der Commandline entgegenzunehmen und an die entsprechende 

Instanz eines Argument Handlers weiterzuleiten. Um das Handling 

der Commandline möglichst offen und wiederverwendbar zu gestalten, implementiert 

die hier definierte Klasse CommandlineHandling folgendes Schema: 

• Jedes einzelne Argument, das ein Programm erwartet, wird explizit deklariert. 

• Eine solche Deklaration enthält den Index des erwarteten Arguments, den 

Typ, der erwartet wird und den Handler, der für das Argument schlussendlich 

verantwortlich ist. 

• Nachdem alle erwarteten Argumente deklariert wurden, wird die Commandline 

an das Handling übergeben und entsprechend ausgewertet. Für 

alle zuvor deklarierten Argumente, die auf der Commandline spezifiziert 

wurden, wird der entsprechend registrierte Handler aufgerufen.


Ich möchte hier gleich betonen, dass diese Art des Handlings einer Commandline 

wirklich nur für sehr einfache Programme sinnvoll ist. Jedoch geht 

die Implementation eines wirklich in der Praxis einsetzbaren Commandline 

Handlings hier bei weitem am Sinn des kleinen Beispiels vorbei. Sehen wir 

uns also an, wie diese Klasse unter den gegebenen Voraussetzungen aussieht: 

1 // simple commandline handling . h − a simple c l a s s f o r handling 

2 // commandline arguments 

3 

4 #ifndef simple commandline handling h 

5 #define simple commandline handling h 

6 



9 #include ” simple argument handler . h” 

10 #include ” c o n c r e t e o b j e c t d e l e t o r s . h” 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

13 /∗ Every s i n g l e argument that has to be handled has to be 

14 ∗ declared with a type and an according handler here . I t i s 

15 ∗ not mandatory that a l l arguments are declared , there may 

16 ∗ a l s o be undeclared ones that are simply skipped . 

17 ∗/ 

18 

19 class CommandlineHandling 

20 { 


22 

23 /∗ The types of a l l declared arguments . I f an argument i s 

24 ∗ declared f o r a c e r t a i n index , the type i s r e g i s t e r e d here . 

25 ∗ I f there i s no argument declared f o r a c e r t a i n index then 

26 ∗ t h i s element i s a 0 pointer . This i s i n t e r p r e t e d as ” ignore 

27 ∗ the argument ” and the c l a s s has to r e a c t accordingly . An 

28 ∗ undeclared argument i s d e f i n i t e l y a s p e c i f i e d s i t u a t i o n . 

29 ∗/ 

30 Vector types ; 

31 

32 /∗ The handlers f o r a l l declared arguments . The same r u l e s 

33 ∗ f o r ” missing ” p o s i t i o n s are v a l i d as f o r the types f i e l d . 

34 ∗ The only d i f f e r e n c e i s that handlers f o r the ” missing ” 

35 ∗ p o s i t i o n s are 0 p o i n t e r s . The s i n g l e handlers w i l l not 

36 ∗ be deleted on d e s t r u c t i o n . 

37 ∗/ 

38 Vector handlers ; 

39 

40 /∗ The maximum number of d e c l a r a b l e arguments . I f more arguments 

41 ∗ are passed on from the commandline they are simply ignored . 

42 ∗/ 

43 int32 max num args ; 

44 

45 public : 

46 

47 /∗ The constants f o r a l l the argument types . Add a d d i t i o n a l 

48 ∗ known types here . 

49 ∗/ 

50 static const uint32 UINT32 ARG = 0 x01 ; 

51 


53 

54 /∗ This constant holds the index f o r the highest declared 

55 ∗ argument type constant . I f constants f o r new types are 

56 ∗ added i t has to be adopted accordingly . All argument 

57 ∗ types with values higher than t h i s one are considered 

58 ∗ e r r o r s and ignored accordingly ( j u s t because exceptions

59 ∗ are not known yet ) 

60 ∗/ 

61 static const uint32 HIGHEST ARG TYPE = UINT32 ARG; 

62 

63 private : 

64 


66 ∗/ 

67 CommandlineHandling ( const CommandlineHandling & s r c ) : 

68 types ( 0 , DontDelete : : getInstance ( ) ) , 

69 handlers ( 0 , DontDelete : : getInstance ( ) ) { } 

70 

71 public : 

72 

10.2 Das DDD 275 

73 /∗ Standard Constructor 

74 ∗ @param max num args S p e c i f i e s the maximum number o f arguments 

75 ∗ that may be declared f o r t h i s i n s t a n c e o f the handler 

76 ∗/ 

77 explicit CommandlineHandling ( int32 max num args ) : 

78 types ( max num args , Uint32Deletor : : getInstance ( ) ) , 

79 handlers ( max num args , DontDelete : : getInstance ( ) ) , 

80 max num args ( max num args ) {} 

81 



84 ∗/ 

85 virtual ˜ CommandlineHandling ( ) { } 

86 

87 /∗ This method i s used to d e c l a r e an argument that has to be 

88 ∗ handled . 

89 ∗ @param index The index of the argument to be handled . I f 

90 ∗ the index i s out of range i t i s ignored ( j u s t because 


92 ∗ @param type The type of the argument . Valid types are the 

93 ∗ ones that e x i s t as constants above . 

94 ∗ @param handler The handler that has to be c a l l e d f o r the 

95 ∗ declared argument . I f t h i s handler i s a 0 pointer 

96 ∗ then the operation i s ignored ( j u s t because 


98 ∗/ 

99 virtual void declareArgument ( uint32 index , uint32 type , 

100 ArgumentHandler ∗ handler ) ; 

101 

102 /∗ This method i s c a l l e d a f t e r the i n i t i a l i z a t i o n phase to 

103 ∗ t r i g g e r handling of the commandline . I t takes the arguments 

104 ∗ one by one , converts them to the types declared f o r them 

105 ∗ and c a l l s the appropriate handlers . 

106 ∗ @param num args The number of arguments passed on 

107 ∗ @param args The arguments as obtained from the commandline 

108 ∗/ 

109 virtual void handleCommandline ( int32 num args , 

110 char ∗ args [ ] ) ; 

111 } ; 

112 

113 

114 #endif // simple commandline handling h 

10.2.9 SimpleOutputHandling 

Bevor wir die Klasse SimpleOutputHandling näher betrachten, möchte ich 

noch anmerken, dass diese deshalb in der hier angeführten Form geschrieben 

wurde, da der Umgang mit allgemeinen Output Streams derzeit noch nicht


bekannt ist. Ansonsten würden diese sich im Design dieser Klasse und der 

von ihr verwalteten Displayable Klassen niederschlagen. 

Die Idee hinter der Klasse SimpleOutputHandling ist nun, dass alle Teile 

des Spiels, die etwas zur Ausgabe beizutragen haben, von Displayable 

abgeleitet sind und beim Handler explizit angemeldet werden. Wenn ein 

Output generiert werden soll, so werden die angemeldeten darstellbaren Objekte 

genau in der Reihenfolge ihrer Anmeldung zum Schreiben desselben 

aufgefordert. 

Im Gegensatz zu den Beispielen, die in Kapitel 9 besprochen wurden, haben 

wir es hier mit einer kleinen Abwandlung der Idee mit den darstellbaren 

Objekten zu tun: Es wird nicht mehr eine Display Repräsentation verlangt, 

die dann vom Handler auf den Output geschrieben wird. Dies ist vor allem in 

Bezug auf Container, die selbst darstellbare Objekte halten, nicht besonders 

effizient und verleitet auch in diesen Fällen zur Implementation von Seiteneffekten. 

Hier wird ein anderer Weg gegangen: Das Callback, das aufgerufen 

wird, enthält eine Referenz auf einen OutputContext. Dieser enthält die 

notwendigen Methoden, die es einem darstellbaren Objekt erlauben, seinen 

Output zu schreiben. Wohin dieser Output nun geschrieben wird, ist durch 

die spezielle Ausprägung des Contexts bestimmt. In unserem Fall ist dies ein 

simpler textueller Context, der die Ausgabe auf cout weiterreicht. 

Noch eine wichtige Entscheidung wurde getroffen, die sich im Displayable 

niederschlägt: Wenn ein Displayable beim Output Handling angemeldet 

wird, so wird es durch Aufruf eines Callbacks von dieser Anmeldung unterrichtet. 

Dadurch können eventuelle Initialisierungen zum richtigen Zeitpunkt 

stattfinden. 

Diese Ideen sehen nun in eine Klasse gegossen so aus: 

1 // simple output handling . h − simple v e r s i o n o f output handling 

2 

3 #ifndef s i m p l e o u t p u t h a n d l i n g h 

4 #define s i m p l e o u t p u t h a n d l i n g h 

5 




9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ 

12 ∗ A simple output handling c l a s s f o r text based output . Elements 

13 ∗ o f c l a s s Displayable are added one by one and when an output 

14 ∗ operation i s t r i g g e r e d they are asked in exactly the same order 

15 ∗ as they have been r e g i s t e r e d to d e l i v e r t h e i r d i s p l a y 

16 ∗ r e p r e s e n t a t i o n . This r e p r e s e n t a t i o n i s then written to cout . 

17 ∗/ 

18 

19 class SimpleOutputHandling 

20 { 


22 

23 /∗ This vector has space f o r the maximum number o f d i s p l a y a b l e s 

24 ∗ as given in the constructor . The order in which d i s p l a y a b l e s 

25 ∗ are stored in t h i s vector i s the order in which they w i l l 

26 ∗ be c a l l e d when output i s written .

27 ∗/ 

28 Vector d i s p l a y a b l e s ; 

29 

10.2 Das DDD 277 

30 /∗ The number of d i s p l a y a b l e s c u r r e n t l y stored in the vector 

31 ∗/ 

32 uint32 num displayables ; 

33 

34 /∗ The output context which d i s p l a y a b l e s obtain through the 

35 ∗ c a l l b a c k to write t h e i r output . This context i s s e t by 

36 ∗ an appropriate parameter in the constructor . 

37 ∗/ 

38 OutputContext & output context ; 

39 

40 private : 

41 


43 ∗/ 

44 SimpleOutputHandling ( const SimpleOutputHandling & s r c ) : 

45 d i s p l a y a b l e s ( 0 , DontDelete : : getInstance ( ) ) , 

46 output context ( s r c . output context ) {} 

47 

48 public : 

49 


51 ∗ @param max num displayables The maximum number o f d i s p l a y a b l e s 

52 ∗ that s h a l l be handled by an i n stance o f t h i s c l a s s 

53 ∗ @param output context The output context that the d i s p l a y a b l e s 

54 ∗ have to use . 

55 ∗/ 

56 SimpleOutputHandling ( uint32 max num displayables , 

57 OutputContext &output context ) : 

58 d i s p l a y a b l e s ( max num displayables , DontDelete : : getInstance ( ) ) , 

59 num displayables ( 0 ) , 

60 output context ( output context ) {} 

61 



64 ∗/ 

65 virtual ˜ SimpleOutputHandling ( ) { } 

66 

67 /∗ Adds a d i s p l a y a b l e f o r handling . I f the maximum number o f 

68 ∗ d i s p l a y a b l e s i s reached the d i s p l a y a b l e i s simply ignored 

69 ∗ ( j u s t because exceptions are not known yet ) . The r e g i s t e r e d 

70 ∗ d i s p l a y a b l e i s a l s o n o t i f i e d through a c a l l to the method 

71 ∗ d i s p l a y a b l e R e g i s t e r e d of the c l a s s Displayable . 

72 ∗ @param d i s p l a y a b l e A r e f e r e n c e to the d i s p l a y a b l e which i s 

73 ∗ added f o r handling . Although i t should be c l e a r 

74 ∗ because of the r e f e r e n c e : d i s p l a y a b l e s which are 

75 ∗ r e g i s t e r e d are NOT deleted when the handler i s 

76 ∗ destructed ! 

77 ∗/ 

78 virtual void addDisplayable ( Displayable & d i s p l a y a b l e ) ; 

79 

80 /∗ This method i s c a l l e d to t r i g g e r writing o f the output . I t 

81 ∗ c a l l s the c a l l b a c k methods of the r e g i s t e r e d d i s p l a y a b l e s 

82 ∗ one by one in exactly the same order in which they were 

83 ∗ r e g i s t e r e d . This order i s r e f l e c t e d by the order o f the 

84 ∗ d i s p l a y a b l e s in the vector . 

85 ∗/ 

86 virtual void writeOutput ( ) ; 

87 

88 /∗ Returns a clone of the current output context . Please note 

89 ∗ that the c a l l e r i s r e s p o n s i b l e to d e l e t e i t i f no longer 

90 ∗ needed . 

91 ∗ @return A pointer to a dynamically a l l o c a t e d clone o f t h i s 

92 ∗ instance


93 ∗/ 

94 virtual OutputContext ∗ getOutputContextClone ( ) 

95 { 

96 return ( output context . getClone ( ) ) ; 

97 } 

98 } ; 

99 

100 

101 #endif // s i m p l e o u t p u t h a n d l i n g h 

10.2.10 Displayable 

Die Klasse SimpleOutputHandling arbeitet ausschließlich mit Elementen der 

Klasse Displayable. Diese ist eine abstrakte Basisklasse, von der man darstellbare 

Klassen entsprechend ableiten muss. Das Interface, das solche Klassen 

dann implementieren müssen, ist sehr einfach: 

1 // s i m p l e d i s p l a y a b l e . h − a simple a b s t r a c t base f o r a 

2 // d i s p l a y a b l e o b j e c t 

3 

4 #ifndef s i m p l e d i s p l a y a b l e h 

5 #define s i m p l e d i s p l a y a b l e h 

6 

7 #include ” simple output context . h” 

8 class SimpleOutputHandling ; 

9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ The abstract base c l a s s f o r t e x t u a l l y d i s p l a y a b l e o b j e c t s , 

12 ∗ as i t i s used by SimpleOutputHandling 

13 ∗/ 

14 


16 { 

17 public : 

18 



21 ∗/ 

22 virtual ˜ Displayable ( ) { } 

23 

24 /∗ This c a l l b a c k i s used to n o t i f y a d i s p l a y a b l e that i t 

25 ∗ has j u s t been r e g i s t e r e d with an output handler . I t can 

26 ∗ perform a l l necessary operations in t h i s method to 

27 ∗ be prepared to generate output . 

28 ∗ @param handler The handler that t h i s d i s p l a y a b l e was 

29 ∗ r e g i s t e r e d with . 

30 ∗/ 

31 virtual void d i s p l a y a b l e R e g i s t e r e d ( 

32 SimpleOutputHandling &handler ) = 0 ; 

33 

34 /∗ The c a l l b a c k that i s c a l l e d by SimpleOutputHandling when 

35 ∗ outputting the d i s p l a y a b l e s i s t r i g g e r e d . 

36 ∗ @param context The output context to write to . 

37 ∗/ 

38 virtual void writeDisplayRep ( OutputContext &context ) = 0 ; 

39 

40 } ; 

41 

42 #endif // s i m p l e d i s p l a y a b l e h

10.2.11 OutputContext 

10.2 Das DDD 279 

Abhängig davon, ob es sich nun um einen Text-, Graphik- oder anderen 

Kontext handelt, stehen verschiedene Methoden in diesem Kontext zur 

Verfügung. Diese können nicht wirklich in einer Basisklasse deklariert werden, 

denn sie sind einfach zu unterschiedlich und nicht vorhersehbar. Aus 

diesem Grund ist die abstrakte Basisklasse OutputContext auch dementsprechend 

primitiv gestaltet: 

1 

2 #ifndef s i m p l e o u t p u t c o n t e x t h 

3 #define s i m p l e o u t p u t c o n t e x t h 

4 

5 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

6 /∗ The base c l a s s f o r a l l d i f f e r e n t output contexts . I t i s 

7 ∗ used in context with the Displayable i n t e r f a c e . 

8 ∗/ 

9 

10 class OutputContext 

11 { 

12 public : 

13 



16 ∗/ 

17 virtual ˜ OutputContext ( ) { } 

18 

19 /∗ Returns a clone of the output context . Has to be overridden 

20 ∗ by a l l derived c l a s s e s to d e l i v e r a clone o f the c o r r e c t 

21 ∗ type . This clone has to be dynamically a l l o c a t e d via new 

22 ∗ and the c a l l e r i s r e s p o n s i b l e to d e l e t e i t i f no longer 

23 ∗ needed . 

24 ∗ @return A pointer to the dynamically generated clone o f t h i s 

25 ∗ OutputContext . This clone has to have exactly the 

26 ∗ type of the derived c l a s s . 

27 ∗/ 

28 virtual OutputContext ∗ getClone ( ) = 0 ; 

29 } ; 

30 

31 

32 #endif // s i m p l e o u t p u t c o n t e x t h 

10.2.12 TextOutputContext 

Die Ausprägung des Output Contexts, die im Spiel Verwendung findet, ist ein 

ganz primitiver TextOutputContext, der gerade eben einmal ein paar Methoden 

besitzt, über die man Daten ausgeben kann. Diese werden einfach auf 

cout geschrieben. Mit dem Wissen um Streams, die noch in Abschnitt 16.6 

kurz umrissen werden, könnte man diesen Kontext natürlich sauberer gestalten. 

1 // s i m p l e t e x t o u t p u t c o n t e x t . h − a simple text output context 

2 

3 #ifndef s i m p l e t e x t o u t p u t c o n t e x t h 

4 #define s i m p l e t e x t o u t p u t c o n t e x t h


5 


7 

8 #include ” simple output context . h” 

9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ A very simple text output context 

12 ∗/ 

13 

14 class TextOutputContext : public OutputContext 

15 { 

16 public : 

17 


19 ∗ Nothing has to be done in i t 

20 ∗/ 

21 TextOutputContext ( ) { } 

22 

23 /∗ Copy constructor 

24 ∗ Just because i t has to be made e x p l i c i t 

25 ∗/ 

26 TextOutputContext ( const TextOutputContext & s r c ) {} 

27 


29 ∗ Just because of the convention . . . 

30 ∗/ 

31 virtual ˜ TextOutputContext ( ) { } 

32 

33 /∗ This method i s used to write text to the output . 

34 ∗/ 

35 virtual void write ( const char ∗ text ) 

36 { 

37 std : : cout

10.2.13 GameCard 

10.2 Das DDD 281 

Die Basisklasse für unsere Spielkarte ist eine weitere kleine Variation der im 

letzten Kapitel besprochenen Karten, die folgendermaßen aussieht: 

1 // game card v3 . h − d e c l a r a t i o n o f a general card f o r games 

2 

3 #ifndef game card v3 h 

4 #define game card v3 h 

5 


7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ A general c l a s s of a card f o r games . I t has two s i d e s and can 

10 ∗ be turned around . One way of turning i t i s to d e l i b e r a t e l y put 

11 ∗ the f r o n t or the back s i d e up . The other way i s to f l i p the 

12 ∗ card . This c l a s s does not handle any other information than 

13 ∗ the v i s i b l e s i d e . I t has nothing to do with d i s p l a y 

14 ∗ r e p r e s e n t a t i o n s and other s t u f f . 

15 ∗/ 

16 


18 { 


20 

21 /∗ Stores the s i d e of the card that i s v i s i b l e at the moment . 

22 ∗/ 

23 uint8 v i s i b l e s i d e ; 

24 

25 public : 

26 

27 /∗ The f o l l o w i n g two constants d e f i n e the p o s s i b l e values f o r 

28 ∗ the v i s i b l e s i d e of the card . 

29 ∗/ 

30 static const uint8 FRONT SIDE = 0 x01 ; 

31 static const uint8 BACK SIDE = 0x02 ; 

32 


34 ∗ @param v i s i b l e s i d e Has to be e i t h e r o f the two constants 

35 ∗ defined above . The parameter i s checked f o r 

36 ∗ v a l i d i t y and i f i t i s i n v a l i d the i n i t i a l l y 

37 ∗ v i s i b l e s i d e i s the f r o n t s i d e . 

38 ∗/ 

39 explicit GameCard( uint8 v i s i b l e s i d e ) : 

40 v i s i b l e s i d e ( ( ( v i s i b l e s i d e == FRONT SIDE ) | | 

41 ( v i s i b l e s i d e == BACK SIDE) ) ? 

42 v i s i b l e s i d e : FRONT SIDE) {} 

43 

44 /∗ Copy Constructor 

45 ∗ Implemented e x p l i c i t l y to make sure that i t cannot be 

46 ∗ f o r g o t t e n in f uture changes . 

47 ∗/ 

48 GameCard( const GameCard & s r c ) 

49 { 

50 v i s i b l e s i d e = s r c . v i s i b l e s i d e ; 

51 } 

52 



55 ∗/ 

56 virtual ˜GameCard( ) { } 

57 

58 /∗ Turns the card to the other s i d e . No checks f o r the 

59 ∗ v a l i d i t y of the stored s i d e are necessary because i t s 

60 ∗ v a l i d i t y i s f u l l y guaranteed by the constructor and


61 ∗ the other methods . 

62 ∗/ 

63 virtual void turnCard ( ) 

64 { 

65 v i s i b l e s i d e = ( v i s i b l e s i d e == FRONT SIDE) ? 

66 BACK SIDE : FRONT SIDE; 

67 } 

68 

69 /∗ Puts the f r o n t s i d e of the card up ( i . e . makes i t v i s i b l e ) , 

70 ∗ r e g a r d l e s s of which s i d e i s v i s i b l e at the moment . 

71 ∗/ 

72 virtual void putFrontSideUp ( ) 

73 { 

74 v i s i b l e s i d e = FRONT SIDE; 

75 } 

76 

77 /∗ Puts the back s i d e of the card up ( i . e . makes i t v i s i b l e ) , 

78 ∗ r e g a r d l e s s of which s i d e i s v i s i b l e at the moment . 

79 ∗/ 

80 virtual void putBackSideUp ( ) 

81 { 

82 v i s i b l e s i d e = BACK SIDE; 

83 } 

84 

85 /∗ Returns the v i s i b l e s i d e of the card . 

86 ∗ @return The v i s i b l e s i d e of the card in the form o f one o f 

87 ∗ the two constants FRONT SIDE or BACK SIDE. 

88 ∗/ 

89 virtual uint8 g e t V i s i b l e S i d e ( ) 

90 { 

91 return ( v i s i b l e s i d e ) ; 

92 } 

93 } ; 

94 

95 

96 #endif // game card v3 h 

10.2.14 MemoryGameCard 

Die Klasse MemoryGameCard ist ebenfalls eine weitere kleine Variation der im 

letzten Kapitel besprochenen Memory Spielkarten. Sie ist eine einfache, darstellbare 

Spielkarte. Als solche ist sie von Displayable und von GameCard 

abgeleitet und speichert ein Symbol für die Vorderseite und ein Symbol für 

die Rückseite. Nachdem die Karte keine Kristallkugel befragen kann, welches 

Symbol sie für die Vorder- und welches für die Rückseite speichern soll, 

müssen diese beiden von außen gesetzt werden. Dies muss natürlich im Konstruktor 

geschehen, denn es muss ja verhindert werden, dass jemand schummelt, 

indem einfach das Symbol umgesetzt wird :-). Dieses Meisterwerk hat 

dann die folgende Form: 

1 // memory game card v5 . h − memory game card as used in the example 

2 



5 


7 #include ” s i m p l e d i s p l a y a b l e . h”

8 #include ” s i m p l e t e x t o u t p u t c o n t e x t . h” 

9 

10.2 Das DDD 283 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ A game card f o r the memory game . I t i s able to s t o r e symbols 

12 ∗ f o r both s i d e s . Both are stored as a r b i t r a r y char p o i n t e r s . 

13 ∗ The card i s compatible to the mechanism defined by the 

14 ∗ SimpleOutputHandling c l a s s because i t i s derived from 

15 ∗ Displayable . I t i s a l s o a standard GameCard . 

16 ∗/ 

17 class MemoryGameCard : public GameCard , 

18 public Displayable 

19 { 


21 

22 /∗ The s t r i n g s t o r i n g the f r o n t s i d e symbol . I t i s a copy o f 

23 ∗ the f r o n t s i d e symbol that i s passed on as a parameter o f 

24 ∗ the constructor and has to be deleted in the d e s t r u c t o r . 

25 ∗/ 


27 

28 /∗ The s t r i n g s t o r i n g the back s i d e symbol . I t i s a copy o f 

29 ∗ the back s i d e symbol that i s passed on as a parameter o f 

30 ∗ the constructorand has to be deleted in the d e s t r u c t o r . 

31 ∗/ 


33 

34 private : 

35 

36 /∗ Copy construction i s forbidden 

37 ∗/ 

38 MemoryGameCard( const MemoryGameCard & s r c ) : 

39 GameCard(BACK SIDE) {} 

40 

41 public : 

42 


44 ∗ I t has to c a l l the constructor f o r the base c l a s s e s . The 

45 ∗ constructor f o r GameCard i s c a l l e d so that the back s i d e i s 

46 ∗ i n i t i a l l y the v i s i b l e s i d e . 

47 ∗ The s t r i n g s passed on f o r the symbols have to be copied to the 

48 ∗ appropriate members . I f 0 p o i n t e r s are passed then an empty 

49 ∗ s t r i n g i s generated f o r the i n t e r n a l r e p r e s e n t a t i o n ( j u s t 

50 ∗ because exceptions are not known yet ) . 

51 ∗/ 


53 const char ∗ back symbol ) ; 

54 


56 ∗ Has to d e l e t e the copied s t r i n g s f o r the f r o n t and the 

57 ∗ back symbols 

58 ∗/ 

59 virtual ˜MemoryGameCard ( ) ; 

60 

61 /∗ Nothing s p e c i a l to be done when a card i s r e g i s t e r e d 



64 ∗/ 


66 SimpleOutputHandling &handler ) {} 

67 

68 /∗ Writes e i t h e r the f r o n t or the back symbol according to the 

69 ∗ s i d e that i s v i s i b l e at the moment . 

70 ∗/ 

71 virtual void writeDisplayRep ( OutputContext &context ) 

72 { 

73 dynamic cast(context ) .


74 write ( ( v i s i b l e s i d e == FRONT SIDE) ? 

75 front symbol : back symbol ) ; 

76 } 

77 

78 /∗ Returns the f r o n t symbol of the card 

79 ∗ @return The f r o n t symbol 

80 ∗/ 

81 virtual const char ∗ getFrontSymbol ( ) 

82 { 

83 return ( front symbol ) ; 

84 } 

85 

86 /∗ Returns the back symbol of the card 

87 ∗ @return The back symbol 

88 ∗/ 

89 virtual const char ∗ getBackSymbol ( ) 

90 { 

91 return ( front symbol ) ; 

92 } 

93 } ; 

94 


10.2.15 MemoryGameboard 

Die Klasse MemoryGameboard ist für alles verantwortlich, was mit der Anzeige 

des Spielbretts und der darauf liegenden Karten zu tun hat. Aus diesem 

Grund ist sie auch die Drehscheibe für alles, was mit dem Auflegen und 

Umdrehen von Karten zu tun hat. Um der Spielsteuerung zu ermöglichen, 

herauszufinden, wie viele Karten bereits umgedreht wurden, hat diese Klasse 

auch die entsprechenden Abfragemethoden zu implementieren. Diese Methoden 

dürfen vor allem nicht naiv implementiert werden, denn je nach Größe des 

Spielfelds kann ein oftmaliges Abfragen jeder einzelnen Karte zu erheblichen 

Performanceproblemen führen. 

Das Memory Spielbrett ist nicht dafür verantwortlich, die Karten, die 

auf ihm liegen, zu generieren. Es ist nur dafür verantwortlich, Karten, die 

aufgelegt werden, auch entsprechend zu speichern. 

Auch bei der Darstellung des Spielfelds ist noch eine Kleinigkeit zu beachten: 

Es ist nicht genug, einfach nur die auf dem Feld liegenden Karten bei 

der verantwortlichen Instanz von SimpleOutputHandling anzumelden. Um 

sinnvoll spielen zu können, müssen auch die Reihen und Spalten des Spielfelds 

mit entsprechenden Köpfen versehen werden, die die Koordinaten anzeigen. 

Um nun keine Seiteneffekte und künstliche Abhängigkeiten in das Programm 

einzubauen, ist der einzig sinnvolle Weg, auch diese Köpfe über entsprechende 

darstellbare Objekte zu realisieren, die von Displayable abgeleitet sind. 

Diese sind im überblicksartigen Klassendiagramm noch nicht enthalten, 

werden aber nun als notwendige Hilfsklassen eingeführt (siehe Abschnitt 

10.2.16 und Abschnitt 10.2.17). 

Ein kleiner Exkurs: Manche Leser werden es schon bemerkt haben, dass 

ich hier eine Kleinigkeit demonstrieren möchte. Der Schritt, einfach so eine

10.2 Das DDD 285 

kleine Hilfsklasse einzuführen, die im Klassendiagramm noch nicht enthalten 

ist, ist schlimm genug. In der Praxis muss nun unbedingt ein Schritt zurück 

gemacht werden und das Klassendiagramm ergänzt werden. 

Das ist jedoch noch nicht alles: Im Normalfall wäre jetzt sogar der 

Zeitpunkt gekommen, zu dem man allgemeingültig über simple darstellbare 

Objekte und über Container von darstellbaren Objekten nachdenken muss. 

Das Spielbrett ist nämlich von seiner Logik her genau ein solcher Container. 

Das würde dann eine weitere Änderung im Klassendiagramm bedeuten: 

Ein darstellbarer Container ist abgeleitet von Displayable und das 

MemoryGameboard ist dann von diesem abgeleitet. Um hier nicht zur absoluten 

Verwirrung beizutragen, führe ich diesen allgemeinen Container nicht 

ein. Stattdessen wird das MemoryGameboard dergestalt entworfen, dass es die 

Containerfunktionalität besitzt. 

Alle Leser mögen sich aber nun unbedingt ein paar Gedanken machen, 

was diese Vorgangsweise, die leider auch in der Praxis sehr oft praktiziert 

wird, bedeutet! Hier bahnt sich bereits ein böser Hack an, denn es ist zu 

erwarten, dass im Lauf der Zeit das Spiel mehrere Änderungen erfährt und 

dass wahrscheinlich auch dann an mehreren Stellen ein allgemeiner Container 

gebraucht würde. In jedem Fall muss dann eine erhebliche Menge an 

Code umgeschrieben werden, wenn man ihn erst verspätet einführt. Oder, 

noch schlimmer, alle Klassen, die ihn brauchen, implementieren die Funktionalität 

selbst. Dass das dann auf Kosten der Übersichtlichkeit, Wartbarkeit, 

Änderbarkeit und Intuitivität geht, lässt sich leicht nachvollziehen. 

Nach diesem Exkurs, der etwas zum Nachdenken anregen sollte, sieht das mit 

Vorsicht zu genießende Resultat für unser Spielbrett folgendermaßen aus: 

1 // memory gameboard . h − a simple gameboard f o r memory 

2 

3 #ifndef memory gameboard h 

4 #define memory gameboard h 

5 


7 #include ” simple output handling . h” 




11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

13 /∗ The c l a s s f o r the gameboard . This c l a s s i s r e s p o n s i b l e f o r 

14 ∗ the management of the cards and has to take care f o r 

15 ∗ r e g i s t e r i n g them at the output handler . I t a l s o has to keep 

16 ∗ track of the number of cards on the board and o f the number 

17 ∗ o f cards with f r o n t and back s i d e s up . Turning cards i s 

18 ∗ performed via a c a l l to t h i s c l a s s . 

19 ∗/ 

20 

21 class MemoryGameboard : public Displayable 

22 { 


24 

25 /∗ Stores the number of rows of the board according to the 

26 ∗ parameter passed to the constructor . In p r i n c i p l e t h i s


27 ∗ i s a reduncancy , because the vector o f v e c t o r s used to 

28 ∗ s t o r e the cards a l s o keeps track o f i t , but i t ’ s much 

29 ∗ more readable t h i s way . 

30 ∗/ 

31 uint32 num rows ; 

32 

33 /∗ Stores the number of columns o f the board according to the 

34 ∗ parameter passed to the constructor . This i s the same 

35 ∗ reduncancy as s t o r i n g the number o f rows , but i t ’ s a l s o 

36 ∗ done f o r r e a d a b i l i t y reasons . 

37 ∗/ 

38 uint32 num cols ; 

39 

40 /∗ The number of cards on the board that are l y i n g f r o n t 

41 ∗ s i d e up . This member i s updated on every s i n g l e operation 

42 ∗ that i s performed on a card on the board . 

43 ∗/ 

44 uint32 num cards front side up ; 

45 

46 /∗ The row vector that s t o r e s a l l the column v e c t o r s used 

47 ∗ to hold the cards . This vector i s i n i t i a l i z e d to d e l e t e 

48 ∗ the cards in the d e s t r u c t o r . 

49 ∗/ 

50 Vector ∗ row vector ; 

51 

52 /∗ The vector s t o r i n g a l l the d i s p l a y a b l e s that are r e s p o n s i b l e 

53 ∗ f o r the row headings . I t i s i n i t i a l i z e d to d e l e t e the 

54 ∗ d i s p l a y a b l e s in the d e s t r u c t o r . 

55 ∗/ 

56 Vector ∗ r o w h e a d i n g d i s p l a y a b l e s ; 

57 


59 ∗ f o r the column headings . I t i s i n i t i a l i z e d to d e l e t e the 

60 ∗ d i s p l a y a b l e s in the d e s t r u c t o r . 

61 ∗/ 

62 Vector ∗ c o l h e a d i n g d i s p l a y a b l e s ; 

63 


65 ∗ f o r the end of l i n e a f t e r each column i n c l u d i n g the column 

66 ∗ heading l i n e . I t i s i n i t i a l i z e d to d e l e t e the d i s p l a y a b l e s 

67 ∗ in the d e s t r u c t o r . 

68 ∗/ 

69 Vector ∗ e o l d i s p l a y a b l e s ; 

70 

71 /∗ This instance of the output handler i s needed to implement 

72 ∗ the container ’ s d i s p l a y f u n c t i o n a l i t y . Here a l l the cards , 

73 ∗ row and column headings are r e g i s t e r e d . On a c a l l to 

74 ∗/ 

75 SimpleOutputHandling ∗ container output handling ; 

76 

77 /∗ This holds the clone of the output context to be able to 

78 ∗ d e l e t e i t in the d e s t r u c t o r . 

79 ∗/ 

80 OutputContext ∗ c o n t a i n e r o u t p u t c o n t e x t ; 

81 

82 private : 

83 


85 ∗/ 

86 MemoryGameboard( const MemoryGameboard& s r c ) {} 

87 

88 public : 

89 


91 ∗ I n i t i a l i z e s the v e c t o r s f o r the cards , the row and column 

92 ∗ headings and s e t s the output handler to 0 . The output

10.2 Das DDD 287 

93 ∗ handler i s then s e t when the gameboard i t s e l f i s r e g i s t e r e d 

94 ∗ with the ” master ” output handler . 

95 ∗ The number of rows and the number o f columns are checked in 

96 ∗ a way that they both have to be non−zero and that the number 

97 ∗ o f f i e l d s o v e r a l l i s even ( there i s always an even number o f 

98 ∗ cards ! ) . I f something i s wrong the values have to be c o r r e c t e d 

99 ∗ accordingly ( j u s t because exceptions are not known yet ) . 

100 ∗ @param num rows The number of rows f o r the f i e l d 

101 ∗ @param num cols The number of columns f o r the f i e l d 

102 ∗/ 

103 MemoryGameboard( uint32 num rows , uint32 num cols ) ; 

104 


106 ∗ Has to d e l e t e a l l v e c t o r s and the output handler f o r the 

107 ∗ container . 

108 ∗/ 

109 virtual ˜MemoryGameboard ( ) ; 

110 

111 /∗ Because the gameboard does not produce any s p e c i a l i z e d 

112 ∗ output i t s e l f ( a l l text f i e l d s are r e g i s t e r e d as text 

113 ∗ d i s p l a y a b l e s ) i t only t r i g g e r s output o f the contained 

114 ∗ d i s p l a y a b l e elements . 

115 ∗ @param context The output context to write to 

116 ∗/ 


118 { 

119 i f ( container output handling ) 

120 container output handling −>writeOutput ( ) ; 

121 } 

122 

123 /∗ When t h i s method i s c a l l e d a l l necessary text d i s p l a y a b l e s 

124 ∗ have to be generated and stored in the row and column heading 

125 ∗ v e c t o r s . Additionally the container output handler has to 

126 ∗ be i n s t a n t i a t e d and these generated d i s p l a y a b l e s have to 

127 ∗ be r e g i s t e r e d there together with a l l the cards . 

128 ∗ ATTENTION: This behaviour means that a l l cards already 

129 ∗ have to be on the gameboard before r e g i s t e r i n g i t with the 

130 ∗ d i s p l a y handler ! ! ! ! Otherwise t h i s method ’ s tasks are not 

131 ∗ f u l f i l l a b l e c o r r e c t l y ! ! ! 

132 ∗ ATTENTION: I f t h i s board i s r e g i s t e r e d with more than one 

133 ∗ d i s p l a y handler the i n i t i a l i z i n g s t e p s must not be done 

134 ∗ again , because everything i s already setup c o r r e c t l y . 

135 ∗ Therefore t h i s method has to check t h i s b e f o r e . 

136 ∗ @param handler The handler f o r which t h i s d i s p l a y a b l e was 

137 ∗ r e g i s t e r e d . 

138 ∗/ 


140 SimpleOutputHandling &handler ) ; 

141 

142 /∗ Turns a l l the cards so that they show the f r o n t s i d e . This 

143 ∗ method does not t r i g g e r any output , so f o r the r e s u l t o f 

144 ∗ the operation to be shown the output has to be t r i g g e r e d 

145 ∗ e x p l i c i t l y by an according c a l l to the d i s p l a y handler . 

146 ∗ This method a l s o updates the i n t e r n a l cache f o r the number 

147 ∗ o f cards that show t h e i r f r o n t s i d e at the moment ( t h i s 

148 ∗ i s the v a r i a b l e num cards front side up ) . 

149 ∗/ 

150 virtual void putAllCardsFrontSideUp ( ) ; 

151 

152 /∗ Turns a l l the cards so that they show the back s i d e . This 

153 ∗ method does not t r i g g e r any output , so f o r the r e s u l t o f 

154 ∗ the operation to be shown the output has to be t r i g g e r e d 

155 ∗ e x p l i c i t l y by an according c a l l to the d i s p l a y handler . 

156 ∗ This method a l s o updates the i n t e r n a l cache f o r the number 

157 ∗ o f cards that show t h e i r f r o n t s i d e at the moment ( t h i s 

158 ∗ i s the v a r i a b l e num cards front side up ) .


159 ∗/ 

160 virtual void putAllCardsBackSideUp ( ) ; 

161 

162 /∗ Turns the card given by the coordinates , so that i t shows 

163 ∗ the f r o n t s i d e . I f necessary ( i . e . the card showed i t s 

164 ∗ back s i d e before ) the v a r i a b l e num cards front side up 

165 ∗ has to be updated . 

166 ∗ @param row The row of the card to be turned s t a r t i n g 

167 ∗ with 0 f o r the f i r s t row . 

168 ∗ @param c o l The column of the card to be turned s t a r t i n g 

169 ∗ with 0 f o r the f i r s t column . 

170 ∗/ 

171 virtual void putCardFrontSideUp ( uint32 row , uint32 c o l ) ; 

172 

173 /∗ Turns the card given by the coordinates , so that i t shows 

174 ∗ the back s i d e . I f necessary ( i . e . the card showed i t s 

175 ∗ f r o n t s i d e before ) the v a r i a b l e num cards front side up 

176 ∗ has to be updated . 

177 ∗ @param row The row of the card to be turned s t a r t i n g 

178 ∗ with 0 f o r the f i r s t row . 

179 ∗ @param c o l The column of the card to be turned s t a r t i n g 


181 ∗/ 

182 virtual void putCardBackSideUp ( uint32 row , uint32 c o l ) ; 

183 

184 /∗ Returns a pointer to the card at the given p o s i t i o n . 

185 ∗ I f there i s no card at t h i s p o s i t i o n a 0 pointer i s 

186 ∗ returned ( t h i s happens i m p l i c i t l y because o f the kind o f 

187 ∗ storage of the cards in the vector ) . 

188 ∗ @param row The row of the d e s i r e d card s t a r t i n g with 0 

189 ∗ f o r the f i r s t row . 

190 ∗ @param c o l The column of the d e s i r e d card s t a r t i n g 


192 ∗/ 

193 virtual MemoryGameCard ∗ getCard ( uint32 row , uint32 c o l ) const ; 

194 

195 /∗ Returns the number of rows . This may be a number that i s 

196 ∗ d i f f e r e n t to the one given in the constructor , because i t 

197 ∗ could have happened that i t was c o r r e c t e d i n t e r n a l l y ( see 

198 ∗ a l s o : d e s c r i p t i o n of the constructor ) 

199 ∗ @return The actual number of rows 

200 ∗/ 

201 virtual uint32 getNumRows ( ) const 

202 { 

203 return ( num rows ) ; 

204 } 

205 

206 /∗ Returns the number of columns . This may be a number that i s 

207 ∗ d i f f e r e n t to the one given in the constructor , because i t 

208 ∗ could have happened that i t was c o r r e c t e d i n t e r n a l l y ( see 

209 ∗ a l s o : d e s c r i p t i o n of the constructor ) 

210 ∗ @return The actual number of columns 

211 ∗/ 

212 virtual uint32 getNumCols ( ) const 

213 { 

214 return ( num cols ) ; 

215 } 

216 

217 /∗ Returns the number of cards that c u r r e n t l y are l y i n g on the 

218 ∗ board with t h e i r f r o n t s i d e s up . 

219 ∗ @return The actual number of cards that show t h e i r f r o n t s i d e s 

220 ∗/ 

221 virtual uint32 getNumCardsFrontSideUp ( ) const 

222 { 

223 return ( num cards front side up ) ; 

224 }

225 

10.2 Das DDD 289 

226 /∗ Returns the number of cards that c u r r e n t l y are l y i n g on the 

227 ∗ board with t h e i r back s i d e s up . 

228 ∗ @return The actual number of cards that show t h e i r back s i d e s 

229 ∗/ 

230 virtual uint32 getNumCardsBackSideUp ( ) const 

231 { 

232 return ( ( num rows ∗ num cols ) − num cards front side up ) ; 

233 } 

234 

235 /∗ This method i s c a l l e d to put a card on the board . I f a card 

236 ∗ already occupies the d e s i r e d place t h i s c a l l i s ignored . 

237 ∗ Please note that the card has to be deleted then , because 

238 ∗ the c a l l e r s r e l y on t h i s f a c t ! ( j u s t because exceptions are 

239 ∗ not known yet ) 

240 ∗ A range−check has to be performed on the coordinates . I f they 

241 ∗ are out of range the c a l l i s ignored and the card i s deleted , 

242 ∗ because c a l l e r s r e l y on t h i s f a c t ! ( j u s t because exceptions 

243 ∗ are not known yet ) 

244 ∗ @param card A pointer to the card that has to be put on the 

245 ∗ board . The card w i l l be deleted in the d e s t r u c t o r ! 

246 ∗ @param row The row , where the card has to be put . 

247 ∗ @param c o l The column , where the card has to be put . 

248 ∗/ 

249 virtual void putCardOnBoard (MemoryGameCard ∗ card , 

250 uint32 row , uint32 c o l ) ; 


252 /∗ An i n t e r n a l convenience method used to obtain a card . I t 

253 ∗ does not perform any checks because i t assumes that they 

254 ∗ have already been performed before . 

255 ∗ @param row The row of the d e s i r e d card . 

256 ∗ @param c o l The column of the d e s i r e d card . 

257 ∗/ 

258 MemoryGameCard ∗ internalGetCard ( uint32 row , uint32 c o l ) const 

259 { 

260 return ( static cast( 

261 static cast( 

262 row vector −>getElementAt ( row))−>getElementAt ( c o l ) ) ) ; 

263 } 

264 } ; 

265 

266 

267 #endif // memory gameboard h 

Dass es einen Vektor für die einzelnen Displayables der Reihenköpfe (Zeile 

56) und Spaltenköpfe (Zeile 62) gibt, ist ja zu erwarten. Was aber soll im 

Vektor in Zeile 69 bloß gehalten werden? Ganz einfach: Die Displayables, die 

nach jeder Spielfeldzeile den Zeilenumbruch bewirken! Ansonsten wäre das 

Spielfeld ja ziemlich lang und flach :-). 

10.2.16 IntDisplayable 

Die Klasse IntDisplayable, die hier vorgestellt wird, braucht eigentlich keine 

besondere Erklärung: 

1 // s i m p l e i n t d i s p l a y a b l e . h − a d i s p l a y a b l e f o r i n t e g r a l numbers 

2 

3 #ifndef s i m p l e i n t d i s p l a y a b l e h 

4 #define s i m p l e i n t d i s p l a y a b l e h


5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ A simple d i s p l a y a b l e f o r signed i n t e g e r s o f 6 4 Bits maximum length . 

11 ∗ I t implements the Displayable i n t e r f a c e and i s constructed with an 

12 ∗ appropriate number . When the c a l l b a c k to generate output i s c a l l e d , 

13 ∗ the i n t e g e r i s written . 

14 ∗/ 

15 class IntDisplayable : public Displayable 

16 { 


18 

19 /∗ The i n t e g e r that s h a l l be displayed as passed on in the constructor . 

20 ∗/ 

21 int64 num ; 

22 

23 private : 

24 


26 ∗/ 

27 IntDisplayable ( const IntDisplayable & s r c ) {} 

28 

29 public : 

30 


32 ∗ I t has to c a l l the constructor f o r the base c l a s s and s t o r e the 

33 ∗ given i n t e g e r 

34 ∗/ 

35 explicit IntDisplayable ( int64 num ) : 

36 Displayable ( ) , num (num) {} 

37 


39 ∗ Just to meet the convention 

40 ∗/ 

41 virtual ˜ IntDisplayable ( ) { } 

42 

43 /∗ Nothing s p e c i a l has to be done upon r e g i s t r a t i o n 



46 ∗/ 


48 SimpleOutputHandling &handler ) {} 

49 

50 /∗ Writes the number to the context . This method can only work 

51 ∗ with a text context . 


53 ∗/ 


55 { 

56 dynamic cast(context ) . write (num ) ; 

57 } 

58 

59 } ; 

60 

61 #endif // s i m p l e i n t d i s p l a y a b l e h 

10.2.17 TextDisplayable 

Analog zur Darstellung von Ganzzahlen mittels eines besonderen Displayables 

gibt es auch eine entsprechende Klasse TextDisplayable, die sich für 

Strings verantwortlich fühlt:

1 // s i m p l e t e x t d i s p l a y a b l e . h − a d i s p l a y a b l e f o r text 

2 

3 #ifndef s i m p l e t e x t d i s p l a y a b l e h 

4 #define s i m p l e t e x t d i s p l a y a b l e h 

5 




9 

10.2 Das DDD 291 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ A simple d i s p l a y a b l e f o r text 

12 ∗ I t implements the Displayable i n t e r f a c e and i s constructed with an 

13 ∗ appropriate s t r i n g . When the c a l l b a c k to 

14 ∗ obtain the d i s p l a y r e p r e s e n t a t i o n i s c a l l e d t h i s s t r i n g i s written . 

15 ∗ The s t r i n g may be any s t a t i c a l l y or dynamically a l l o c a t e d char ∗ , 

16 ∗ because i t i s copied . 

17 ∗/ 

18 class TextDisplayable : public Displayable 

19 { 


21 

22 /∗ The s t r i n g s t o r i n g the text to be displayed . I t i s a copy o f the 

23 ∗ s t r i n g that i s passed on as a parameter o f the constructor . 

24 ∗ Therefore i t has to be deleted in the d e s t r u c t o r . 

25 ∗/ 

26 char ∗ t e x t ; 

27 

28 private : 

29 


31 ∗/ 

32 TextDisplayable ( const TextDisplayable & s r c ) {} 

33 

34 public : 

35 


37 ∗ I t has to c a l l the constructor f o r the base c l a s s . 

38 ∗ The text passed on i s copied to the t e x t member . I f a 0 pointer 

39 ∗ i s given as a parameter t e x t i s i n i t i a l i z e d to an empty 

40 ∗ s t r i n g ( j u s t because exceptions are not known yet ) . 

41 ∗/ 

42 explicit TextDisplayable ( const char ∗ text ) : 

43 Displayable ( ) , t e x t (0) 

44 { 

45 i f ( text ) 

46 { 

47 t e x t = new char [ s t r l e n ( text ) + 1 ] ; 

48 strcpy ( t e x t , text ) ; 

49 } 

50 } 

51 


53 ∗ Just to meet the convention 

54 ∗/ 

55 virtual ˜ TextDisplayable ( ) 

56 { 

57 delete t e x t ; 

58 } 

59 

60 /∗ Nothing s p e c i a l has to be done upon r e g i s t r a t i o n 



63 ∗/ 


65 SimpleOutputHandling &handler ) {}


66 

67 /∗ Writes the number to the context . This method can only work 

68 ∗ with a text context . 


70 ∗/ 


72 { 

73 dynamic cast(context ) . write ( t e x t ) ; 

74 } 

75 

76 } ; 

77 

78 #endif // s i m p l e t e x t d i s p l a y a b l e h 

10.2.18 Event 

Da die Entscheidung beim Reagieren auf den User-Input zugunsten eines 

sauberen Event Modells gefallen ist, brauchen wir einmal eine Basisklasse 

Event. Diese benötigt eigentlich keine besondere, tiefergehende Erklärung: 

1 // simple event . h − simple c l a s s f o r events 

2 

3 #ifndef s i m p l e e v e n t h 

4 #define s i m p l e e v e n t h 

5 


7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ A very simple base c l a s s f o r events . All events have to be 

10 ∗ derived from i t and f o r each event type a corresponding 

11 ∗ constant has to be placed here . This base does nothing but 

12 ∗ s t o r e the type of the event so that i t can be asked f o r i t . 

13 ∗ All f u n c t i o n a l i t y f o r s p e c i a l events has to be implemented 

14 ∗ in the appropriate derived c l a s s e s . 

15 ∗/ 

16 

17 class Event 

18 { 


20 

21 /∗ The type of the event . Must be one o f the constants below 

22 ∗/ 

23 int32 event type ; 

24 

25 public : 

26 

27 /∗ Constants f o r p o s s i b l e event types . I f a new type i s 

28 ∗ introduced an according constant has to be placed here . 

29 ∗/ 

30 static const int32 WORDEVENT = 0x1 ; 

31 


33 ∗ Has to s t o r e the type i n t e r n a l l y . No checks f o r v a l i d types 

34 ∗ are performed because events are u s u a l l y generated extremely 

35 ∗ often and t h e r e f o r e performance i s an i s s u e . 

36 ∗ @param event type The type of the event . Has to be one o f 

37 ∗ the constants above 

38 ∗/ 

39 explicit Event ( int event type ) 

40 { 

41 event type = event type ;

42 } 

43 


45 ∗/ 

46 Event ( const Event & s r c ) 

47 { 

48 event type = s r c . event type ; 

49 } 

50 



53 ∗/ 

54 virtual ˜ Event ( ) { } 

55 

10.2 Das DDD 293 

56 /∗ Returns the type of the event 

57 ∗ @return The type of the event as given in the constructor 

58 ∗/ 

59 int32 getType ( ) const 

60 { 

61 return ( event type ) ; 

62 } 

63 } ; 

64 

65 

66 #endif // s i m p l e e v e n t h 

10.2.19 WordEvent 

Der hier vorgestellte WordEvent stellt eine Spezialisierung des allgemeinen 

Events von zuvor dar. Er wird dazu verwendet, den erhaltenen User Input 

Wort für Wort an die Applikation weiterzureichen: 

1 // simple word event . h − a word event c l a s s 

2 

3 #ifndef simple word event h 

4 #define simple word event h 

5 


7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ A c l a s s f o r a s p e c i f i c word event . I s used f o r words that 

10 ∗ are input by u sers and have to be passed on . 

11 ∗/ 

12 

13 class WordEvent : public Event 

14 { 


16 

17 /∗ The word that a r r i v e d as a user input and has to be 

18 ∗ passed on . This i s a copy and has to be deleted in 

19 ∗ the d e s t r u c t o r . Also a 0 pointer i s p o s s i b l e . 

20 ∗/ 

21 char ∗ word ; 

22 

23 public : 

24 


26 ∗ c o p i e s the word that i s passed on to i t 

27 ∗/ 

28 explicit WordEvent( const char ∗ word ) : 

29 Event (WORDEVENT) ,


30 word (0) 

31 { 

32 i f ( ! word ) 

33 return ; 

34 word = new char [ s t r l e n ( word ) + 1 ] ; 

35 strcpy ( word , word ) ; 

36 } 

37 


39 ∗ c o p i e s the word from the o r i g i n a l 

40 ∗/ 

41 WordEvent( const WordEvent & s r c ) : 

42 Event (WORDEVENT) , 

43 word (0) 

44 { 

45 i f ( ! s r c . word ) 

46 return ; 

47 word = new char [ s t r l e n ( s r c . word ) + 1 ] ; 

48 strcpy ( word , s r c . word ) ; 

49 } 

50 


52 ∗ d e l e t e s the copy of the word 

53 ∗/ 

54 virtual ˜WordEvent ( ) 

55 { 

56 delete [ ] word ; 

57 } 

58 

59 /∗ Returns the word that i s stored in the event 

60 ∗ @return The word stored in the event 

61 ∗/ 

62 virtual const char ∗ getWord ( ) const 

63 { 

64 return ( word ) ; 

65 } 

66 } ; 

67 

68 

69 #endif // simple word event h 

10.2.20 SimpleInputHandling 

Im Prinzip implementiert die Klasse SimpleInputHandling einen einfachen 

Dispatcher Loop, der auch nur einen einzigen Event Handler kennt. Diesen 

muss man explizit registrieren und danach kann man den Loop über die entsprechende 

Methode starten. Es wurde hier keinerlei Multithreading implementiert, 

deshalb kehrt die Methode runDispatcher auch nicht zurück, bis 

man den Loop gestoppt hat. Es ist allerdings garantiert, dass der Loop ohne 

einen zuvor gesetzten Handler sich nicht erhängt oder endlos läuft. Falls kein 

Handler gesetzt wurde, kehrt diese Methode sofort zurück. Diese grandiose 

Klasse hat dann die folgende Form: 

1 // simple input handling . h − a simple input handling c l a s s 

2 

3 #ifndef s i m p l e i n p u t h a n d l i n g h 

4 #define s i m p l e i n p u t h a n d l i n g h 

5

6 #include ” simple event handler . h” 

7 

10.2 Das DDD 295 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ This c l a s s reads the user input from s t d i n and passes i t on 

10 ∗ to the r e g i s t e r e d handler word by word in the form o f 

11 ∗ WordEvent i n s t a n c e s . 

12 ∗/ 

13 

14 class SimpleInputHandling 

15 { 


17 

18 /∗ The maximum length of accepted input words . I f an input word 

19 ∗ i s longer i t w i l l be s p l i t up i n t o two input words . 

20 ∗/ 

21 static const uint32 MAXWORDLENGTH = 256; 

22 

23 private : 

24 

25 /∗ This i s a pure s t a t i c method c o l l e c t i o n . Therefore f o r b i d 

26 ∗ c o nstructing an instance . 

27 ∗/ 

28 SimpleInputHandling ( ) { } ; 

29 

30 /∗ I f construction i s not p o s s i b l e , a l s o d e s t r u c t i o n does 

31 ∗ not make any sense at a l l . 

32 ∗/ 

33 virtual ˜ SimpleInputHandling ( ) { } ; 

34 


36 

37 /∗ This v a r i a b l e i s used i n t e r n a l l y to stop the dispatcher 

38 ∗ loop . I f i t i s s e t the loop w i l l stop a f t e r the next 

39 ∗ word that has been obtained from the user input . 

40 ∗/ 

41 static bool s t o p d i s p a t c h e r l o o p ; 

42 

43 /∗ This i s the event handler that obtains the n o t i f i c a t i o n s 

44 ∗ about the user input words . 

45 ∗/ 

46 static EventHandler ∗ event handler ; 

47 

48 public : 

49 

50 /∗ This method i s used to s e t the r e s p o n s i b l e event handler . 

51 ∗ I f there i s already a handler s e t , the new one w i l l r e p l a c e 

52 ∗ the old one . Please note that the old event handler w i l l 

53 ∗ NOT be deleted ! 

54 ∗ @param handler The event handler that i s r e s p o n s i b l e f o r 

55 ∗ events from now on . 

56 ∗/ 

57 static void setEventHandler ( EventHandler ∗ handler ) 

58 { 

59 event handler = handler ; 

60 } 

61 

62 /∗ This method i s c a l l e d to s t a r t the dispatcher loop . I t w i l l 

63 ∗ NOT return u n t i l the loop i s stopped because multithreading 

64 ∗ i s not implemented here . To stop the loop the method 

65 ∗ stopDispatcher has to be c a l l e d . Then t h i s method w i l l return 

66 ∗ a f t e r the next word that has been dispatched . 

67 ∗ I f no handler i s s e t t h i s method w i l l return immediately ( j u s t 

68 ∗ because exceptions are not known yet ) . 

69 ∗/ 

70 static void runDispatcher ( ) ; 

71


72 /∗ Call t h i s method to stop the dispatcher loop . I f i t i s c a l l e d 

73 ∗ from within the event handler while i t i s j u s t handling an 

74 ∗ event , the loop w i l l be stopped as soon as the handler 

75 ∗ n o t i f i c a t i o n method returns . I f i t i s c a l l e d from any other 

76 ∗ point in the program , the dispatcher loop w i l l be stopped 

77 ∗ a f t e r the next word event has been processed . 

78 ∗/ 

79 static void stopDispatcher ( ) 

80 { 

81 s t o p d i s p a t c h e r l o o p = true ; 

82 } 

83 } ; 

84 

85 

86 #endif // s i m p l e i n p u t h a n d l i n g h 

10.2.21 SimpleEventHandling 

Wo Events durch die Gegend geschickt werden, braucht es auch einen Handler 

dazu. Die Basisklasse dafür, von der alle Möchtegern-Event-Handler abgeleitet 

sein müssen, sieht so aus: 

1 // simple event handler . h − a simple a b stract event handler 

2 

3 #ifndef s i m p l e e v e n t h a n d l e r h 

4 #define s i m p l e e v e n t h a n d l e r h 

5 

6 #include ” simple event . h” 

7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗ A simple base c l a s s . All event handlers that s h a l l be used 

10 ∗ with SimpleInputHandling have to be derived from i t 

11 ∗/ 

12 

13 class EventHandler 

14 { 

15 public : 

16 



19 ∗/ 

20 virtual ˜ EventHandler ( ) { } 

21 

22 /∗ This method i s the c a l l b a c k that i s c a l l e d f o r every s i n g l e 

23 ∗ event that i s dispatched . 

24 ∗ @param event The event that i s dispatched . I t can be an 

25 ∗ a r b i t r a r y s u b c l a s s of Event . 

26 ∗/ 

27 virtual void handleEvent ( const Event &event ) = 0 ; 

28 } ; 

29 

30 

31 #endif // s i m p l e e v e n t h a n d l e r h 

10.2.22 MemoryGameControl 

Die Klasse MemoryGameControl ist die Drehscheibe, die alles steuert, was den 

Spielablauf betrifft. Sie ist einerseits dafür verantwortlich, das Spielfeld mit

10.2 Das DDD 297 

entsprechenden Karten zu füllen, andererseits ist sie Handler für die Events, 

die aufgrund des User Inputs generiert werden. 

Als Handler hat diese Klasse dafür zu sorgen, dass die Karten gemäß 

den Wünschen der Spieler umgedreht werden und, falls sie ein passendes 

Paar waren, umgedreht bleiben. Falls sie kein passendes Paar dargestellt haben, 

werden sie wieder verdeckt. Damit das Spiel ein Ende haben kann, ist 

MemoryGameControl natürlich auch dafür verantwortlich, immer den Überblick 

darüber zu behalten, ob es überhaupt noch Karten gibt, die umgedreht 

werden könnten. 

Die Verteilung der Karten soll folgendermaßen vor sich gehen: 

1. Es wird eine entsprechende Anzahl von Paaren generiert. Dazu wird ein 

entsprechender Symbolgenerator verwendet, der die Symbole gleich in 

einer zufälligen Reihenfolge liefert. 

2. Vom Symbolgenerator werden die generierten und bereits zufällig verteilten 

Symbole abgeholt und wiederum nach dem Zufallsprinzip je zwei 

Karten mit dem entsprechenden Symbol am Spielfeld platziert. 

Beim Behandeln des User Inputs passiert Folgendes: 

1. Es werden pro Karte, die umgedreht werden soll, immer zwei Wort Events 

erwartet. Jeder dieser Events enthält eine Koordinate. Die erste Koordinate 

entspricht jeweils der Reihe, die zweite der Spalte der Karte, die 

umgedreht werden soll. 

2. Sobald beide Koordinaten für die erste Karte eingelangt sind, wird diese 

umgedreht. 

3. Sobald dann noch beide Koordinaten für die zweite Karte eingelangt sind, 

wird auch diese umgedreht. 

4. Jetzt wird entschieden, ob die beiden Karten zueinander passen. Wenn 

ja, bleiben sie umgedreht. Wenn nein, werden sie wieder verdeckt. 

5. Eine letzte Überprüfung muss noch stattfinden, falls ein passendes Paar 

erwischt wurde, nämlich, ob es überhaupt noch weitere verdeckte Karten 

gibt. Wenn nein, wird das Spiel beendet. 

Bei jeder einzelnen Aktion, in der Karten ihre sichtbare Seite wechseln, muss 

die Spielsteuerung den Output Handler veranlassen, eine Anzeige zu triggern. 

Ansonsten würden die Spieler nicht wirklich viel von ihrem Erfolg zu sehen 

bekommen. Bei mir wäre das zwar egal, weil ich bestenfalls durch Zufall ein 

richtiges Paar erwische, aber es soll ja auch andere Spieler geben :-). 

Außer der Steuerung des “normalen” Spielablaufs hat die Spielsteuerung 

noch eine andere Aufgabe: Sie muss es ermöglichen, dass zu Beginn des Spiels 

alle Karten einmal mit der Symbolseite nach oben zu liegen kommen, damit 

sich die Spieler das Feld einprägen können. Die einfachste Variante hierfür, 

die auch implementiert werden soll, ist folgende: 

1. Durch Eingabe von s (=show) werden alle Karten umgedreht, sodass 

ihre Symbole sichtbar sind.


2. Durch Eingabe von h (=hide) werden sie wieder verdeckt. 

Um nun nicht mit zu vielen Spezialfällen kämpfen zu müssen, nehmen wir 

einfach einmal an, dass alle Spieler sich an die Regeln halten und zu Beginn 

einmal s drücken, sich die Karten kurz einprägen, dann h drücken und danach 

regulär spielen. Es werden daher keine Sonderabfragen eingebaut, ob ein Spiel 

bereits in Gange ist und deshalb s nicht mehr zulässig ist, etc... 

Eine kleine Anregung meinerseits: Interessierte Leser könnten das Programm 

z.B. um diese Funktionalität ergänzen. Dem Spieltrieb sind natürlich 

keine Grenzen gesetzt und man könnte auch noch eine Hilfe implementieren, 

die durch Eingabe von h angezeigt wird. Im Rahmen des Buchs bleiben wir 

jedoch am Boden und bei der Grundfunktionalität, die sich in der folgenden 

Klasse niederschlägt: 

1 // memory game control . h − the main c o n t r o l o f the memory game 

2 

3 #ifndef memory game control h 

4 #define memory game control h 

5 


7 #include ”memory game control . h” 


9 #include ”memory gameboard . h” 


11 #include ”memory cardpair . h” 



14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

16 /∗ 

17 ∗ MemoryGameControl 

18 ∗ 

19 ∗ the main c o n t r o l of the memory game 

20 ∗ 

21 ∗/ 

22 

23 class MemoryGameControl : public EventHandler 

24 { 


26 

27 /∗ The p o s s i b l e event handling s t a t e s f o r every s i n g l e card . 

28 ∗ Because the event handler d e l i v e r s input word by word , the 

29 ∗ coordinates come one a f t e r the other . Therefore i t i s 

30 ∗ necessary to keep track of what i s expected next . 

31 ∗/ 

32 static const uint8 WAITING FOR ROW AND COL = 0x0 ; 

33 static const uint8 WAITING FOR COL = 0x1 ; 

34 

35 /∗ This i s the back s i d e symbol o f the cards 

36 ∗/ 

37 static const char CARD BACK SYMBOL[ ] = ” . ” ; 

38 

39 /∗ The gameboard that t h i s instance o f the game c o n t r o l i s 

40 ∗ r e s p o n s i b l e f o r . 

41 ∗/ 

42 MemoryGameboard &gameboard ; 

43 

44 /∗ The output handler f o r the game . I f cards are turned the 

45 ∗ request to redraw the board has to go to t h i s handler . 

46 ∗/

47 SimpleOutputHandling & output handler ; 

48 

10.2 Das DDD 299 

49 /∗ Whenever a card i s s e l e c t e d f o r turning i t i s r e g i s t e r e d 

50 ∗ in the current cardpair . This v a r i a b l e can be asked i f i t 

51 ∗ already holds both cards or only one and then the game 

52 ∗ c o n t r o l can r e a c t accordingly . 

53 ∗/ 

54 MemoryCardpair c u r r e n t c a r d p a i r ; 

55 

56 /∗ This i s the i n t e r n a l event handling s t a t e and the v a r i a b l e 

57 ∗ can take one of the two values o f the constants above . I t 

58 ∗ i s always stored here , what the c o n t r o l i s waiting f o r in 

59 ∗ r e s p e c t to the coords . Either i t waits f o r both coords 

60 ∗ o f a card or the row already a r r i v e d and i t waits only f o r 

61 ∗ the column of a s e l e c t e d card . 

62 ∗/ 

63 uint8 c o o r d w a i t s t a t u s ; 

64 

65 /∗ I f the row was already passed as an event i t i s in the 

66 ∗ meantime stored in t h i s v a r i a b l e u n t i l the column a r r i v e s . 

67 ∗/ 

68 uint32 stored row num ; 

69 

70 public : 

71 


73 ∗ The gameboard that t h i s c o n t r o l i n stance i s r e s p o n s i b l e f o r 

74 ∗ and the output handler f o r d i s p l a y i n g o f the gameboard 

75 ∗ are passed to i t and stored in the appropriate i n t e r n a l 

76 ∗ v a r i a b l e s . All other v a r i a b l e s have to be i n i t i a l i z e d to 

77 ∗ t h e i r according 0 values 

78 ∗ @param gameboard The gameboard to be c o n t r o l l e d . I t comes 

79 ∗ without any cards on i t . A c a l l to the method 

80 ∗ putCardsOnGameboard then f i l l s i t with appropriate 

81 ∗ c a r d p a i r s . 

82 ∗ @param output handler The output handler that i s r e s p o n s i b l e 

83 ∗ f o r d i s p l a y i n g the gameboard . 

84 ∗/ 

85 MemoryGameControl(MemoryGameboard &gameboard , 

86 SimpleOutputHandling &output handler ) : 

87 gameboard ( gameboard ) , 

88 output handler ( output handler ) , 

89 c o o r d w a i t s t a t u s (WAITING FOR ROW AND COL) , 

90 stored row num ( 0) { } 

91 

92 



95 ∗/ 

96 virtual ˜ MemoryGameControl ( ) { } 

97 

98 /∗ This method i s c a l l e d to t r i g g e r f i l l i n g o f the gameboard . I t 

99 ∗ u t i l i z e s an instance of MemoryCardSymbolGenerator and then 

100 ∗ d i s t r i b u t e s a pair of cards f o r each symbol randomly on the 

101 ∗ board . 

102 ∗/ 

103 virtual void putCardsOnGameboard ( ) ; 

104 

105 /∗ This i s the c a l l b a c k f o r word events that are a r e s u l t o f the 

106 ∗ u sers ’ input . Here a l l the a c t i o n s are t r i g g e r e d according to 

107 ∗ the game ’ s l o g i c . 

108 ∗ @param event An event coming from the input handler . Only 

109 ∗ events of c l a s s WordEvent a r r i v e here . 

110 ∗ @param dispatcher The Input handler that c a l l e d t h i s 

111 ∗ method to dispatch the event . 

112 ∗/


113 virtual void handleEvent ( const Event &event ) ; 

114 


116 

117 /∗ I n t e r n a l method that i s c a l l e d from within handleEvent i f a 

118 ∗ coordinate was passed . This method has to keep track o f 

119 ∗ the c o n t r o l flow that two coordinates make one card . I t does 

120 ∗ not keep track of p a i r s , t h i s i s done by the i n t e r n a l method 

121 ∗ actOnCard below , which has to be c a l l e d f o r each p a i r o f 

122 ∗ coordinates . 

123 ∗ Please note that i t i s not guaranteed that the word r e a l l y 

124 ∗ contains a v a l i d numeric word , t h e r e f o r e t h i s has to be checked . 

125 ∗ Please a l s o note the the user input contains coordinates with 

126 ∗ a range of 1 . . . n , whereas i n t e r n a l l y the range i s 0 . . . ( n−1). 

127 ∗ Therefore the transformation o f coordinates has to take place 

128 ∗ here when c a l l i n g actOnCard . 

129 ∗ @param word The s t r i n g r e p r e s e n t a t i o n o f the ( maybe ) coord 

130 ∗/ 

131 virtual void coordWasPassed ( const char ∗ word ) ; 

132 

133 /∗ I n t e r n a l method that i s c a l l e d f o r each p a i r o f row/ c o l 

134 ∗ to perform an appropriate action on a card . This method has 

135 ∗ to keep track of p a i r s of cards as w e l l and act accordingly . 

136 ∗ Also the end of the game has to be detected here . 

137 ∗ @param row The row of the card on the board s t a r t i n g at 0 

138 ∗ @param c o l The column of the card on the board s t a r t i n g at 0 

139 ∗/ 

140 virtual void actOnCard ( uint32 row , uint32 c o l ) ; 

141 

142 /∗ I n t e r n a l helper method that i s c a l l e d to put one card on 

143 ∗ the board randomly . This method i s c a l l e d f o r each card 

144 ∗ during the card d i s t r i b u t i o n process . 

145 ∗ @param card The card to be put onto the board 

146 ∗ @param num rows The number of rows o f the board 

147 ∗ @param num cols The number of columns o f the board 

148 ∗/ 

149 void putCardOnBoardRandomly(MemoryGameCard ∗ card , 

150 uint32 num rows , 

151 uint32 num cols ) ; 

152 } ; 

153 

154 

155 #endif // memory game control h 

10.2.23 MemoryCardSymbolGenerator 

Beim Symbolgenerator bleiben wir hier bei der einfachsten Variante: Wir 

brauchen für unser einfaches Spiel nur einen Generator, der Symbole im Bereich 

A–Z, a–z und 0–9 erzeugt. Man sagt dem Generator einfach, wie viele 

Symbole man haben will, er generiert diese und danach liefert er auf Anfrage 

Symbol für Symbol in zufälliger Reihenfolge. Es wird garantiert, dass jedes 

Symbol, das der Generator liefert, nur ein einziges Mal vorkommen kann. 

Hier könnte man sich natürlich im Sinne der Wahrscheinlichkeitstheorie 

ziemlich austoben, aber das werden wir in diesem Beispiel zugunsten der 

Übersichtlichkeit bleiben lassen. Die folgende, einfache Variante dieser Klasse 

genügt ja wirklich für unsere Zwecke:

1 // memory card symbol generator . h − simple symbol generator 

2 

3 #ifndef memory card symbol generator h 

4 #define memory card symbol generator h 

5 



8 

10.2 Das DDD 301 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ A simple symbol generator that generates up to 6 2 d i f f e r e n t 

11 ∗ 1− character symbols [A−Za−z0 −9] in a random manner . The 

12 ∗ symbols can be obtained one by one by subsequent c a l l s to 

13 ∗ a method . 

14 ∗/ 

15 

16 class MemoryCardSymbolGenerator 

17 { 

18 public : 

19 

20 /∗ The maximum number of symbols that can be generated by 

21 ∗ t h i s c l a s s 

22 ∗/ 

23 static const uint32 MAX NUM SYMBOLS = 6 2 ; // [A−Za−z0−9] 

24 

25 /∗ I n t e r n a l constant f o r random d i s t r i b u t i o n . The number 

26 ∗ o f swap operations i s c a l c u l a t e d by multiplying the 

27 ∗ number of symbols generated by t h i s f a c t o r . 

28 ∗/ 

29 static const uint32 SYMBOL SWAP FACTOR = 3; 

30 


32 

33 /∗ The number of symbols that have not been fetched yet 

34 ∗/ 

35 uint32 num symbols remaining ; 

36 

37 /∗ The i n t e r n a l vector s t o r i n g the symbols that have been 

38 ∗ generated . The s i n g l e symbols are deleted in the 

39 ∗ d e s t r u c t o r . 

40 ∗/ 

41 Vector symbols ; 

42 

43 /∗ I n t e r n a l method that f i l l s the vector with symbols . 

44 ∗ After f i l l i n g the vector , the symbols are in a 

45 ∗ consecutive order and they have to be randomly 

46 ∗ d i s t r i b u t e d by a c a l l to 

47 ∗ distributeSymbolsRandomlyInVector ( see below ) 

48 ∗/ 

49 void fillVectorWithSymbols ( ) ; 

50 

51 /∗ I n t e r n a l method that d i s t r i b u t e s the symbols in 

52 ∗ the vector randomly using swap operations . The 

53 ∗ number of swap operations performed i s c a l c u l a t e d 

54 ∗ by multiplying the number of symbols with the 

55 ∗ SYMBOL SWAP FACTOR constant . 

56 ∗/ 

57 void distributeSymbolsRandomlyInVector ( ) ; 

58 

59 private : 

60 


62 ∗/ 

63 MemoryCardSymbolGenerator ( 

64 const MemoryCardSymbolGenerator & s r c ) : 

65 symbols ( 0 , DontDelete : : getInstance ()){}


66 

67 public : 

68 


70 ∗ The constructor has to c a l l the appropriate methods to 

71 ∗ f i l l the vector and d i s t r i b u t e the symbols randomly in 

72 ∗ i t . D i r e c t l y a f t e r construction the symbols can be 

73 ∗ obtained by subsequent c a l l s to getNextSymbol . 

74 ∗ I f the number of symbols to be generated i s g r e a t e r than 

75 ∗ MAX NUM SYMBOLS i t i s c o r r e c t e d accordingly ( j u s t because 


77 ∗ @param num symbols The number o f symbols that have to 

78 ∗ be generated in a range from 1 . . .MAX NUM SYMBOLS 

79 ∗ @return 

80 ∗/ 

81 explicit MemoryCardSymbolGenerator ( uint32 num symbols ) ; 

82 


84 ∗ Just to make sure a v i r t u a l constructor e x i s t s 

85 ∗/ 

86 virtual ˜ MemoryCardSymbolGenerator ( ) { } 

87 

88 /∗ D e l i v e r s the symbols one a f t e r the other . I f no more 

89 ∗ symbols e x i s t in the vector i t returns 0 ( j u s t because 


91 ∗/ 

92 virtual char getNextSymbol ( ) ; 

93 } ; 

94 

95 

96 #endif // memory card symbol generator h 

10.2.24 MemoryCardpair 

Die Hilfsklasse MemoryCardpair dient zur Vereinfachung der Logik in der 

Spielsteuerung. Sie ist dafür verantwortlich, sich die Karten eines Paars zu 

merken und zusätzlich noch zu speichern, was mit ihnen passiert ist, also ob 

sie umgedreht wurden oder nicht. Dadurch, dass hier die entsprechende Undo 

Information vorhanden ist, unterstützt diese Klasse sinnigerweise Methoden 

wie Originalzustand wiederherstellen und man kann sie auch fragen, ob die 

Symbole zueinander passen. Dies liest sich dann als Source Code so: 

1 // memory cardpair . h − d e c l a r a t i o n o f a p a i r o f cards f o r memory 

2 

3 #ifndef memory cardpair h 

4 #define memory cardpair h 

5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ U t i l i t y c l a s s f o r managing c a r d p a i r s in the memory game . 

11 ∗/ 

12 

13 class MemoryCardpair 

14 { 

15 public : 

16 

17 /∗ Status f l a g s to be able to f i n d out whether no card , one

18 ∗ card or both cards have already been s e t . 

19 ∗/ 

20 const static uint8 CARD ONE SET = 0x01 ; 

21 const static uint8 CARD TWO SET = 0x02 ; 

22 


24 

25 /∗ I n t e r n a l s t a t u s f l a g s to f i n d out whether e i t h e r o f the 

26 ∗ cards has been turned . 

27 ∗/ 

28 const static uint8 CARD ONE TURNED = 0 x40 ; 

29 const static uint8 CARD TWO TURNED = 0 x80 ; 

30 

31 /∗ Bitmasks f o r the card−s e t and the card−turned b i t s . Both 

32 ∗ s t a t u s f l a g s are s e t in the same v a r i a b l e ( see below ) 

33 ∗/ 

34 const static uint8 CARD SET BITS = 0x03 ; 

35 const static uint8 CARD TURN BITS = 0xc0 ; 

36 

37 /∗ I n t e r n a l v a r i a b l e to s t o r e the s t a t u s f l a g s . Only the 

38 ∗ constants above may be s e t . 

39 ∗/ 

40 uint8 c a r d s e t s t a t u s ; 

41 

42 /∗ Status v a r i a b l e s f o r rows and columns o f the two cards 

43 ∗/ 

44 uint32 card1 row ; 

45 uint32 c a r d 1 c o l ; 

46 uint32 card2 row ; 

47 uint32 c a r d 2 c o l ; 

48 public : 

49 


51 ∗ Sets a l l s t a t u s v a r i a b l e s to t h e i r 0 s t a t e 

52 ∗/ 

53 MemoryCardpair ( ) : 

54 c a r d s e t s t a t u s ( 0 ) , 

55 card1 row ( 0 ) , c a r d 1 c o l ( 0 ) , 

56 card2 row ( 0 ) , c a r d 2 c o l ( 0) { } 

57 



60 ∗/ 

61 virtual ˜ MemoryCardpair ( ) { } 

62 

10.2 Das DDD 303 

63 /∗ Called a f t e r the f i r s t card was chosen . This method s t o r e s 

64 ∗ the coordinates of the card and turns i t f r o n t s i d e up , i f 

65 ∗ i t i s not already v i s i b l e . I t f u r t h e r s t o r e s , whether the 

66 ∗ card was i n i t i a l l y f r o n t or back s i d e up to be able to 

67 ∗ to perform an undo i f the pair does not match . 

68 ∗ @param row The row of the card to turn . 

69 ∗ @param c o l The column of the card to turn . 

70 ∗ @param gameboard The gameboard to work on . 

71 ∗/ 

72 virtual void turnCardOneFrontSideUp ( 

73 uint32 row , uint32 c o l , MemoryGameboard &gameboard ) ; 

74 

75 /∗ Analogous to the method above , j u s t f o r the second card 

76 ∗ o f the pair . 

77 ∗/ 

78 virtual void turnCardTwoFrontSideUp ( 

79 uint32 row , uint32 c o l , MemoryGameboard &gameboard ) ; 

80 

81 /∗ Returns the s t a t u s f l a g s that correspond to the b i t s that 

82 ∗ determine which cards were s e t . 

83 ∗ @return A b i t−combination of the two bitmask constants that


84 ∗ are used to s t o r e which cards are s e t 

85 ∗/ 

86 virtual uint8 whichCardsAreSet ( ) 

87 { 

88 return ( c a r d s e t s t a t u s & CARD SET BITS ) ; 

89 } 

90 

91 /∗ Returns , whether both cards were i n i t i a l l y l y i n g on the f i e l d 

92 ∗ with t h e i r back s i d e s up 

93 ∗ @return true i f both cards were i n i t i a l l y hidden , f a l s e 

94 ∗ otherwise 

95 ∗/ 

96 virtual bool wereBothCardsBackSideUp ( ) 

97 { 

98 return ( ( c a r d s e t s t a t u s & CARD TURN BITS) == 

99 CARD TURN BITS) ; 

100 } 

101 

102 /∗ Returns , whether the symbols o f the two cards are matching . 

103 ∗ I f not both cards were already s e l e c t e d , the method returns 

104 ∗ f a l s e ( j u s t because exceptions are not known yet ) . 

105 ∗ @param gameboard The gameboard to work on 

106 ∗ @return true i f the symbols are matching , f a l s e otherwise 

107 ∗/ 

108 virtual bool cardSymbolsMatching ( 

109 MemoryGameboard &gameboard ) ; 

110 

111 /∗ Undo . . . r e s t o r e s the o r i g i n a l v i s i b l e s t a t e o f each o f the 

112 ∗ two cards 

113 ∗ @param gameboard The gameboard to work on . 

114 ∗/ 

115 virtual void turnCardsBackToTheirOriginalState ( 

116 MemoryGameboard &gameboard ) ; 

117 

118 /∗ Clears a l l the s t a t u s f i e l d s o f t h i s i n s t a n c e 

119 ∗/ 

120 virtual void c l e a r ( ) ; 

121 } ; 

122 

123 

124 #endif // memory cardpair h 

10.3 Auszüge aus der Implementation 

Um das Verständnis für die Zusammenhänge und die Abläufe im Spiel etwas 

zu vertiefen, möchte ich an dieser Stelle noch eine paar Auszüge aus den 

Implementationen der Klassen ganz kurz besprechen. Der vollständige Code 

ist in Anhang B zu finden. 

Am schnellsten kommt man durch einen kurzen Blick auf das Hauptprogramm 

zum tieferen Verständnis: 

1 //memory main . cpp − main program that s t a r t s memory 

2 


4 

5 #include ” simple commandline handling . h” 

6 #include ”memory commandline arg handler . h” 

7 #include ”memory gameboard . h”




11 #include ” simple input handling . h” 

12 

13 using std : : c e r r ; 


15 

10.3 Auszüge aus der Implementation 305 


17 { 

18 // i n s t a n t i a t e the commandline handler , d e c l a r e the 

19 // required arguments ( row / column ) and l e t i t parse 

20 // the commandline . 

21 CommandlineHandling commandline handler ( 3 ) ; 

22 MemoryCommandlineArgumentHandler arg handler ; 

23 commandline handler . declareArgument ( 

24 1 , CommandlineHandling : : UINT32 ARG,& arg handler ) ; 



27 commandline handler . handleCommandline ( argc , argv ) ; 

28 

29 // analyse the number of rows and columns 

30 uint32 rows = arg handler . getRows ( ) ; 

31 uint32 c o l s = arg handler . getCols ( ) ; 

32 i f ( ( rows < = 0 ) | | ( c o l s 9 ) | | ( c o l s > 9)) 

34 { 

35 c e r r


74 output handler . writeOutput ( ) ; 

75 SimpleInputHandling : : setEventHandler(&game control ) ; 

76 SimpleInputHandling : : runDispatcher ( ) ; 

77 return ( 0 ) ; 

78 } 

Gemäß unserer Designentscheidungen läuft hier Folgendes ab: 

1. Zuerst wird die Commandline ausgewertet. Dazu wird in Zeile 21 eine 

Instanz des entsprechenden Handlers erzeugt. Dass diese für drei Argumente 

initialisiert wird, versteht sich auch von selbst, denn wir erwarten 

ja den Programmnamen, die Anzahl der Reihen und die Anzahl der Spalten 

als Parameter. Die Anzahl der Reihen und Spalten werden auch als 

Argumente in den Zeilen 23–26 deklariert und für beide ist unser besonderer 

Argument Handler aus Zeile 22 verantwortlich. Die tatsächliche 

Auswertung findet dann durch den Aufruf in Zeile 27 statt. Danach hat 

der Handler die erhaltenen Werte gespeichert und sie stehen zur Abfrage 

in den Zeilen 30–31 bereit. In den Zeilen 32–65 findet nur eine Plausibilitätskontrolle 

und eventuelle Korrektur der Anzahl der Reihen und 

Spalten statt. 

2. Richtig interessant wird es wieder in Zeile 68: Dort wird der Output 

Kontext erzeugt, den das Programm zum Schreiben verwendet. 

3. In Zeile 69 wird der Output Handler mit dem entsprechenden Kontext 

generiert. Dieser wird nur für ein Displayable initialisiert, denn mehr 

als das Spielbrett selbst bekommt dieser Handler nicht zu sehen. 

4. Das Spielbrett wird in Zeile 70 angelegt. 

5. In Zeile 71 wird die Spielsteuerung erzeugt und mit dem Spielbrett und 

dem Output Handler initialisiert. Damit wäre eigentlich bereits das ganze 

Spiel von der Systematik her am Laufen. 

6. Da es sich ohne Karten schlecht spielt, werden diese durch den Aufruf in 

Zeile 72 am Brett verteilt. 

7. In Zeile 73 wird das Spielbrett endgültig beim Output Handler angemeldet. 

Dies darf aus internen Gründen nicht vor dem Verteilen der Karten 

passieren, da sonst dessen Containerfunktionalität gestört wäre. Ja, ja, 

ich weiß, das sollte man besser machen, genau deshalb möchte ich es 

gerne interessierten Lesern als Aufgabe zum Spielen überlassen :-). 

8. Der Aufruf in Zeile 74 sorgt dafür, dass das Brett in seinem Initialzustand 

einmal am Bildschirm angezeigt wird. 

9. In den Zeilen 75–76 wird nur noch der Event Handler initialisiert und der 

Dispatcher gestartet. Dieser Dispatcher läuft so lange, bis das Spiel vorbei 

ist, dann wird er aus der Spielsteuerung heraus gestoppt. Damit wird 

dann auch gleich automatisch das Programm beendet, denn in Zeile 77 

steht ja das entsprechende return, das die main Funktion verlässt. 

Leser, die dieses Spiel nun selbst ausprobieren wollen, können das ganz einfach 

tun:


1. make -f MemoryMakefile aufrufen (oder in ihrer eigenen Umgebung 

entsprechend das Programm compilieren). 

2. memory 6 6 oder ähnlich starten. Die Anzahl der Reihen und der Spalten 

kann jeweils zwischen 1–9 sein. 

3. Wenn das Feld mit den verdeckten Karten (dargestellt als .) erscheint, 

s eingeben, gefolgt von Return. Dadurch werden alle Karten angezeigt. 

4. Nach dem Einprägen der Karten h eingeben, gefolgt von Return. Dadurch 

werden die Karten wieder umgedreht. 

5. Koordinatenpaare durch Leerzeichen bzw. Return getrennt eintippen, 

die jeweils eine Karte aufdecken sollen. Z.B. deckt die Eingabe von 2 3 

Return die Karte in Reihe 2 und Spalte 3 auf. 

6. Wenn man das Spiel gewinnt, so beendet es sich automatisch. Sollte 

man mitten unter dem Spiel die Lust verlieren, so hilft die Eingabe von 

q Return. Ganz ungeduldige Spieler können auch mittels Control-c dem 

Gemetzel ein Ende bereiten :-). 

Von der Logik her interessant und deshalb einen Blick wert ist auch die Implementation 

der Klasse MemoryGameboard: Wie bereits bei den Deklarationen 

besprochen wurde, werden alle darstellbaren Objekte in Vektoren gespeichert, 

damit sie im Destruktor auch sicher wieder freigegeben werden. Die Vektoren 

bekommen dazu den entsprechenden DisplayableDeletor spendiert. Wirft 

man jedoch einen Blick auf den Konstruktor der Klasse, der in der Folge 

abgedruckt ist, so ist leicht zu erkennen, dass hierbei noch überhaupt keine 

Displayables angelegt werden: 

10 MemoryGameboard : : MemoryGameboard( uint32 num rows , 

11 uint32 num cols ) : 

12 num rows ( num rows ) , 

13 num cols ( num cols ) , 

14 num cards front side up ( 0 ) , 

15 row vector ( 0 ) , 

16 r o w h e a d i n g d i s p l a y a b l e s ( 0 ) , 

17 c o l h e a d i n g d i s p l a y a b l e s ( 0 ) , 

18 e o l d i s p l a y a b l e s ( 0 ) , 

19 container output handling ( 0 ) , 

20 c o n t a i n e r o u t p u t c o n t e x t (0) 

21 { 

22 i f ( ( num rows ∗ num cols ) % 2) // not an even number 

23 num rows ++; 

24 

25 row vector = new Vector ( num rows , 

26 VectorDeletor : : getInstance ( ) ) ; 

27 for ( uint32 current row = 0 ; current row < num rows ; 

28 current row ++) 

29 row vector −>setElementAt ( 

30 current row ,new Vector ( num cols , 

31 DisplayableDeletor : : getInstance ( ) ) ) ; 

32 } 

Des Rätsels Lösung, wann die darstellbaren Objekte erzeugt werden, ergibt 

sich aus einem Blick auf die Methode displayableRegistered:


59 void MemoryGameboard : : d i s p l a y a b l e R e g i s t e r e d ( 

60 SimpleOutputHandling &handler ) 

61 { 

62 // already r e g i s t e r e d with some handler , no f u r t h e r 

63 // setup necessary 

64 i f ( r o w h e a d i n g d i s p l a y a b l e s ) 

65 return ; 

66 

67 uint32 num displayables = ( num rows ∗ num cols ) + // cards 

68 num rows + 1 + // EOL elements 

69 num rows + 1 + // c o l headings 

70 num cols ; // row headings 

71 r o w h e a d i n g d i s p l a y a b l e s = new Vector ( 

72 num cols , DisplayableDeletor : : getInstance ( ) ) ; 

73 c o l h e a d i n g d i s p l a y a b l e s = new Vector ( 

74 num rows + 1, DisplayableDeletor : : getInstance ( ) ) ; 

75 e o l d i s p l a y a b l e s = new Vector ( 


77 c o n t a i n e r o u t p u t c o n t e x t = handler . getOutputContextClone ( ) ; 

78 container output handling = new SimpleOutputHandling ( 

79 num displayables , ∗ c o n t a i n e r o u t p u t c o n t e x t ) ; 

80 

81 // j u s t because some compilers have a wrong treatment f o r 

82 // v a r i a b l e s in c o n t r o l statements . . . 

83 uint32 row count = 0; 

84 uint32 col count = 0; 

85 

86 // generate the top l i n e with the column headings and 

87 // r e g i s t e r i t 

88 IntDisplayable ∗ heading = 0; 

89 TextDisplayable ∗ text = 0; 

90 // a space needs to be the f i r s t element o f the headings 

91 text = new TextDisplayable ( ” ” ) ; 

92 c o l h e a d i n g d i s p l a y a b l e s −>setElementAt ( 0 , text ) ; 

93 container output handling −>addDisplayable (∗ text ) ; 

94 // the r e s t of the heading l i n e contains the consecutive 

95 // numbers of the columns 

96 for ( col count = 1 ; col count setElementAt ( c o l count , heading ) ; 

100 container output handling −>addDisplayable (∗ heading ) ; 

101 } 

102 // an e o l i s placed at the end o f the l i n e 

103 text = new TextDisplayable ( ”\n” ) ; 

104 e o l d i s p l a y a b l e s −>setElementAt ( 0 , text ) ; 


106 // now f o r each row : 

107 // ( 1 ) generate the row heading and r e g i s t e r i t 

108 // ( 2 ) r e g i s t e r a l l cards in the row . 

109 // ( 3 ) generate an EOL d i s p l a y a b l e and r e g i s t e r i t 

110 for ( row count = 0 ; row count < num rows ; row count++) 

111 { 

112 heading = new IntDisplayable ( row count + 1 ) ; 

113 r o w h e a d i n g d i s p l a y a b l e s −>setElementAt ( row count , heading ) ; 


115 for ( col count = 0 ; col count < num cols ; c o l c o unt++) 

116 { 

117 // not very e f f i c i e n t but e a s i e r to read 

118 container output handling −>addDisplayable ( 

119 ∗dynamic cast( 

120 internalGetCard ( row count , c o l count ) ) ) ; 

121 } 


123 e o l d i s p l a y a b l e s −>setElementAt ( row count + 1, text ) ;



125 } 

126 } 

Hier wird in Zeile 64 zuerst kontrolliert, ob überhaupt noch etwas getan 

werden muss, oder ob bereits alles fertig angelegt ist. Das ist notwendig, 

denn es könnte ja diese Klasse auch bei zwei Handlers angemeldet werden. 

Dann würde ohne diese Abfrage ein Speicherloch entstehen. 

In den Zeilen 67–70 wird ausgerechnet, mit wie vielen darstellbaren Objekten 

wir es hier überhaupt zu tun haben. Danach werden die entsprechenden 

Vektoren in den Zeilen 71–76 angelegt. In Zeile 77 wird ein Clone des 

Output Contexts besorgt, der dem neu angelegten Output Handler für diesen 

Container in den Zeilen 78–79 spendiert wird. In den Zeilen 88–125 werden 

dann die entsprechenden Reihen- und Spaltenköpfe, sowie die Zeilenumbrüche 

angelegt und gemeinsam mit den Spielkarten beim Output Handler genau in 

der Reihenfolge registriert, in der sie dargestellt werden sollen. In der Deklaration 

dieser Klasse war schon zu sehen, dass dieser Handler jedes Mal in 

der inline Methode writeDisplayRep aufgefordert wird, seinen Output zu 

schreiben. 

Interessierte Leser können jetzt gleich zur Programmänderung schreiten 

und einen entsprechenden DisplayableContainer implementieren, der als 

Basis für alle Displayables mit Containerfunktionalität dient. Von diesem 

wäre dann das MemoryGameboard abzuleiten, um zu einer sauberen Lösung 

zu kommen. Noch ein kleiner Tipp: Die Idee, selbst den Output Handler zu 

vergewaltigen und ihn mit einem Clone des Output Contexts ans Werk zu 

schicken ist auch nicht ganz sauber und entsprechend verbesserungswürdig. 

Mit diesem hier kurz zusammengefassten Wissen über die Systematik 

im Programm sollte der restliche Source Code leicht verständlich sein. Die 

gesamte Implementation, wie sie in Anhang B abgedruckt ist, ist straightforward. 

Aus diesem Grund möchte ich hier auch keinen weiteren Platz dafür 

verschwenden.

11. Exceptions 

In den bisherigen Beispielen war es öfters der Fall, dass z.B. eine Methode mit 

unzulässigen Parametern aufgerufen wird. Ein typisches Beispiel findet sich 

in der Implementation der allgemeinen Vector Klasse aus unserem Memory- 

Spiel. Dort gibt es z.B. eine Methode getElementAt, die das Element liefert, 

das an einer bestimmten Stelle im entsprechenden Vector Objekt steht. 

Wenn allerdings der geforderte Index außerhalb des erlaubten Bereichs liegt, 

dann wird in dieser Implementation kurzerhand 0 geliefert. Ähnliches passiert 

dort in der Methode setElementAt: Liegt der Index außerhalb des 

erlaubten Bereichs, dann wird diese Operation einfach kommentarlos nicht 

durchgeführt. Dass dieses Verhalten nicht wirklich zur Stabilität von Software 

beiträgt, versteht sich von selbst, denn wie soll man denn einen Fehler 

finden, wenn dieser nicht einmal gemeldet wird? Und genau damit, wie man 

einen solchen Fehler ordnungsgemäß und sauber mitteilt, um ihn auch einer 

sauberen Behandlung zuzuführen, beschäftigt sich dieses Kapitel: Das Mittel 

der Wahl für diese Fälle sind die sogenannten Exceptions, durch die, wie der 

Name schon sagt, Ausnahmezustände in einem Programm signalisiert und 

damit auch sauber behandelt werden können. 

Vor der Besprechung der technischen Details von Exceptions in C ++ 

möchte ich noch unbedingt ein paar Worte zu deren sinnvoller und sauberer 

Anwendung verlieren. Oft wird nämlich von Entwicklern die von den Erfindern 

beabsichtigte Semantik von Exceptions missverstanden, wodurch sich 

einige Ungereimtheiten ergeben können. 

Prinzipiell ist die Verwendung von Exceptions für den Fall gedacht, dass 

Entwickler zu einem bestimmten Zeitpunkt zur Laufzeit feststellen können, 

dass ein Problem vorliegt, jedoch nicht wissen können, wie sie dieses Problem 

behandeln sollen. Im oben zitierten Beispiel mit der Vector Klasse 

kann man leicht einen unerlaubten Index feststellen. Weil aber nicht bekannt 

ist, wofür ein Vector Objekt zur Laufzeit gerade verwendet wird und 

wodurch also der unerlaubte Index zustande kommt, kann man keine Behandlung 

durchführen. Jedoch kann man davon ausgehen, dass der Teil des 

Programms, der den falschen Aufruf abgesetzt hat, auf das Problem reagieren 

kann. Folgende Logik versteckt sich nun hinter dem Exception Mechanismus, 

um die Problemerkennung von der Problembehandlung zu trennen:

312 11. Exceptions 

1. Der Teil der Software, der ein Problem erkennt, wirft eine Exception 

(daher kommt auch das Keyword throw, das wir noch kennen lernen 

werden). 

2. Der Teil der Software, der sich bereit erklärt, bestimmte Probleme behandeln 

zu können, signalisiert diese Bereitschaft durch eine Deklaration, 

eine Exception fangen zu können (daher kommt auch das Keyword 

catch, das wir noch kennen lernen werden). 

3. Wenn also eine Exception geworfen wird, dann wird in der Methodenund 

Funktionen-Aufrufhierarchie des Programms so lange zurück zum 

Aufrufenden gesprungen (dies nennt sich auch Stack Unwinding), bis 

ein fangender Teil gefunden wird. Diesem wird die Exception dann zur 

Behandlung zugeführt. 

Um nun eine gezielte Fehlerbehandlung zu gestatten, gibt es beliebige, durch 

die Entwickler definierbare Typen von Exceptions. Es ist auch leicht einzusehen, 

warum man solche Typen unterscheidet, denn wenn ein Programmteil 

z.B. weiß, wie ein Zugriffs-Indexfehler zu behandeln ist, dann muss derselbe 

Teil noch lange nicht wissen, wie man mit einem Out-of-Memory Fehler 

umgeht. Mit einem verbreiteten Missverständnis möchte ich an dieser Stelle 

auch noch aufräumen: Eine Exception zu werfen bedeutet nicht, dass unbedingt 

etwas völlig Katastrophales passiert wäre. Es ist auch keineswegs 

gesagt, dass Exceptions “so gut wie nie” auftreten bzw. auftreten dürfen. 

Exceptions werden immer dann gebraucht, wenn etwas passiert, was dem 

regulär geplanten Programmablauf zuwiderläuft. 

Es gibt noch einige Aspekte, die unbedingt Beachtung finden müssen, um 

Exceptions wirklich sinnvoll einzusetzen. Um diese besprechen zu können, 

möchte ich einmal an einem kleinen Beispiel die Realisierung des Exception- 

Mechanismus in C ++ zeigen. Hierzu ziehen wir am besten gleich unsere Klasse 

Vector heran und arbeiten sie entsprechend um. Das Resultat liest sich dann 

wie folgt (first_exception_demo.cpp): 

1 // f i r s t e x c e p t i o n d e m o . cpp − a small demo , how the exception 

2 // mechanism works in C++ 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ 

12 ∗ Exception 

13 ∗ 

14 ∗ base c l a s s f o r a l l exceptions 

15 ∗ 

16 ∗/ 

17 

18 class Exception 

19 { 


21 static uint32 c u r r e n t i d ;

22 uint32 my id ; 

23 public : 

24 Exception ( ) 

25 { 

26 my id = c u r r e n t i d ++; 

27 cout


88 

89 virtual void setElementAt ( uint32 index , void ∗ element ) 

90 throw( IndexOutOfBoundsException ) ; 

91 

92 virtual void ∗ getElementAt ( uint32 index ) const 

93 throw( IndexOutOfBoundsException ) ; 

94 

95 virtual uint32 getMaxNumElements ( ) const 

96 { 


98 } 

99 } ; 

100 

101 uint32 Exception : : c u r r e n t i d = 0; 

102 

103 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


105 ∗ 

106 ∗ @param num elements the number o f elements that the vector can hold 

107 ∗/ 

108 

109 Vector : : Vector ( uint32 num elements ) 

110 { 

111 num elements = num elements ; 

112 i f ( num elements ) 

113 { 

114 elements = new void ∗ [ num elements ] ; 

115 while ( num elements−−) 

116 elements [ num elements ] = 0 ; 

117 } 

118 else 

119 elements = 0; 

120 } 

121 

122 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

123 /∗ s e t s the element at the d e s i r e d index 

124 ∗ 

125 ∗ @param index the index of the element to s e t 

126 ∗ @param element the element to s e t 

127 ∗ @exception IndexOutOfBoundsException i f the index i s outside 

128 ∗ of the allowed range 

129 ∗/ 

130 

131 void Vector : : setElementAt ( uint32 index , void ∗ element ) 

132 throw( IndexOutOfBoundsException ) 

133 { 

134 i f ( index >= num elements ) 

135 throw IndexOutOfBoundsException ( ) ; 

136 elements [ index ] = element ; 

137 } 

138 

139 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

140 /∗ 

141 ∗ @param index the index of the element to be returned 

142 ∗ @return the d e s i r e d element 

143 ∗ @exception IndexOutOfBoundsException i f the index i s outside 

144 ∗ of the allowed range 

145 ∗/ 

146 

147 void ∗ Vector : : getElementAt ( uint32 index ) const 

148 throw( IndexOutOfBoundsException ) 

149 { 


151 throw IndexOutOfBoundsException ( ) ; 

152 return ( elements [ index ] ) ; 

153 }

154 

11. Exceptions 315 

155 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


157 { 

158 Vector t e s t v e c t o r ( 3 ) ; 

159 int32 just an element = 0; 

160 

161 try 

162 { 

163 cout


deklariert sie mittels Angabe von throw(...). Möchte man mehrere Exceptions 

deklarieren, dann werden diese innerhalb der Klammern durch 

Komma getrennt angegeben. Weil throw, gleich wie z.B. const, zum Teil 

der Signatur einer Methode wird, muss dieselbe Angabe auch in der Definition 

der Methode mit angeführt werden. Dies sieht man z.B. in den 

Zeilen 131–132. Dass diese Art der Deklaration natürlich nicht nur für 

Methoden, sondern auch für Funktionen gilt, versteht sich von selbst. 

Schreibt man zur Deklaration einer Methode keine throw Angabe, so bedeutet 

dies (leider) nicht, dass keine Exception geworfen werden kann, 

sondern genau das Gegenteil: Es können in diesem Fall beliebigste Exceptions 

geworfen werden! Diese Konvention wurde in C ++ aus Gründen der 

Kompatibilität zu altem Source-Code gewählt. Möchte man explizit deklarieren, 

dass keine Exception geworfen werden kann, so muss man dies 

durch ein explizites throw() ohne Angabe von Exceptions tun. 

Es gibt immer wieder Diskussionen, was die explizite throw Angabe betrifft. 

Ein Teil der Entwickler meint, man solle per Coding Standard auf 

eine explizite Angabe bestehen, ein anderer Teil meint, man solle auf diese 

verzichten. Die Hauptargumente der beiden Fraktionen sind folgende: 

Gegen explizite Angabe: 

– Bei Programmänderungen kann es in Ableitungshierarchien passieren, 

dass man neu hinzugekommene Exceptions in der gesamten Hierarchie 

ergänzen muss. 

– Je nach Compiler kann die explizite Angabe von Exceptions das Programm 

verlangsamen, da zur Zusicherung der Einhaltung der Angabe 

hinter den Kulissen versteckte try ... catch Blöcke erzeugt werden. 

– Wenn wirklich eine Exception geworfen wird, die nicht angegeben wurde, 

ist die Standardbehandlung, die vom Compiler eingesetzt wird 

ein abort(). Dies kann zu unerwünschten Effekten führen, da auto- 

Variablen in diesem Fall nicht mehr ordnungsgemäß destruiert werden. 

– Beim Erstellen von Templates (siehe Kapitel 13) kann es Probleme geben, 

weil man gewisse datentypabhängige Verhaltensweise beim besten 

Willen nicht voraussehen kann. 

Für explizite Angabe: 

– Der Code wird robuster, da keine unerwarteten Exceptions geworfen 

werden und man immer weiß, was man eventuell zu behandeln hat. 

Da ich auf dem Standpunkt stehe, dass saubere, robuste Software das 

oberste Ziel in einer Entwicklung sein muss, bin ich persönlich ein Mitglied 

der Fraktion, die für die explizite Angabe plädiert. Zu den beiden 

Hauptargumenten der anderen Fraktion möchte ich Folgendes anmerken: 

Wenn man in der Designphase vorausschauend genug arbeitet, dann passieren 

Änderungen, die sich durch die gesamte Hierarchie ziehen sehr selten 

bis gar nicht. Der Performanceverlust durch implizite try ... catch 

Blöcke ist so minimal, dass er in den allermeisten Fällen ohne besondere 

Messung überhaupt nicht bemerkbar ist. Einzig in absoluten Hoch-


geschwindigkeitsroutinen könnte (!!!) es sein, dass das allerletzte kleine 

Bisschen an Performance noch um jeden Preis herausgequetscht werden 

muss. Dort könnte (!!!) man in einem solchen Fall über einen begrenzten 

Bruch mit den expliziten Angaben nachdenken. Meine Erfahrung spricht 

allerdings dagegen. Das Problem beim Erstellen von Templates muss man 

zum Teil akzeptieren und hier ist im Spezialfall wirklich eine Ausnahme 

zu machen. Das Argument jedoch, dass abort() zu Problemen führt, ist 

zwar korrekt, aber ich kann diese Argumentation nicht akzeptieren. Dieser 

Fall darf bei sauberer Entwicklung nur in der Testphase auftreten, nicht in 

einem Produkt! 

Alle Leser mögen nun selbst entscheiden, welchen Standpunkt sie einsichtiger 

finden. Im Sinne eines guten Programmierstils und im Sinne der 

Lesbarkeit, Wartbarkeit und Robustheit von Software möchte ich jedoch 

raten, Exceptions auch wirklich explizit mittels throw anzuführen. Per 

Konvention sollte man dann auch konsequenterweise keine Exceptions aus 

Methoden oder Funktionen werfen, bei denen keine throw Angabe existiert. 

Nebenbei bemerkt: Eine allgemein übliche Bezeichnung für das unschöne 

Werfen von Exceptions, obwohl keine solchen deklariert wurden, ist der 

Begriff silent throw. 

• In Zeile 135 sieht man, wie eine Exception geworfen wird: Es wird hierzu 

ein temporäres Objekt erzeugt. Warum wir hier ausgerechnet mit einem 

temporären Objekt arbeiten und was bei Abarbeitung des throw genau 

hinter den Kulissen passiert, wird in der Folge noch besprochen werden. 

• In den Zeilen 161–173 sieht man schlussendlich, wie man sich bereit erklärt, 

Exceptions auch zu fangen, die auftreten könnten: Der Teil des Codes, 

für den man sich in puncto Exceptions zuständig fühlt, wird durch einen 

try Block umschlossen. Direkt im Anschluss an diesen stehen dann ein 

oder mehrere catch Blöcke in denen die entsprechenden Exceptions auch 

behandelt werden können. In unserem Beispiel ist dies genau ein einziges 

catch, das auf eine IndexOutOfBoundsException reagiert. 

Das try-catch Konstrukt ist folgendermaßen zu verstehen: In welcher Zeile 

auch immer innerhalb des try Blocks eine Exception geworfen wird, wird 

sie dem entsprechenden catch zugeführt. Sollte keine Exception auftreten, 

so wird auch keiner der catch Blöcke angesprungen und das Programm 

läuft erst unterhalb aller dieser Blöcke weiter. 

Die Exception, die in unserem Demoprogramm auftritt, wird verursacht 

durch den Aufruf von setElementAt in Zeile 167. Dort wird nämlich mit 

einem illegalen Index auf den Vektor zugegriffen. Dadurch, dass dort eine 

Exception geworfen wird, wird das Statement in Zeile 168 nicht mehr 

erreicht, denn das Auftreten der Exception bewirkt, dass das Programm 

mit der Behandlung der Exception im catch Block in den Zeilen 170–173 

fortfährt.


Vorsicht Falle: Leider wird bei der Behandlung von Exceptions sehr oft 

ein gravierender Fehler gemacht, der zum Teil auf Schlampigkeit, zum Teil 

aber auch auf Unwissenheit beruht: Jede Exception, die innerhalb eines try 

Blocks auftritt, bewirkt sofort das Anspringen des entsprechenden catch. 

Das bedeutet, dass alle Statements, die unterhalb der Zeile stehen, in der die 

Exception aufgetreten ist, nicht mehr ausgeführt werden. Sollte dort Code 

stehen, der unbedingt immer ausgeführt werden muss (z.B. irgendein delete 

von dynamisch allokiertem Speicher), dann hat man ein Problem, denn bis zu 

dieser Zeile kommt man im Falle einer Exception ja nicht! Aus diesem Grund 

muss man sich sehr gut überlegen, wie man try Blöcke setzt, damit man nicht 

ins offene Messer läuft und einerseits zwar eine “schöne” Fehlerbehandlung 

implementiert, die aber selbst gleich noch schlimmere Fehler macht und z.B. 

wachsende Programme oder sonstige schlimme Inkonsistenzen verursacht! 

Es stellt sich nun die Frage, wie wir die Exception, die in Zeile 135 geworfen 

wurde, durch catch an einer ganz anderen Stelle im Programm fangen 

können. Eigentlich müsste das Exception Objekt ja zu diesem Zeitpunkt 

schon lange tot sein, da die throw Expression, in deren Rahmen das temporäre 

Objekt generiert wurde, bereits fertig abgearbeitet ist. 

Die Antwort darauf klärt auch gleich das Phänomen der zwei erzeugten 

Objekte auf: Wird eine Exception geworfen, so wird immer (!) automatisch 

eine Kopie dieser Exception generiert. Genau diese Kopie ist es, die wir 

auch durch unser catch fangen und nicht, wie viele Entwickler annehmen, 

das Original! Die Kopie ist ebenfalls ein temporäres Objekt und die Lifetime 

dieses Objekts endet, sobald der catch Block verlassen wurde, denn dort ist 

für den Compiler dann diese Expression zu Ende. 

Jetzt, wo diese Eigenheit geklärt ist, können wir den Output zu Ende 

analysieren: 

1. In Zeile 167 wird ein Aufruf auf setElementAt mit Index 5 als Parameter 

durchgeführt. 

2. In Zeile 134, in der Implementation von setElementAt, wird eine Überprüfung 

vorgenommen, ob dieser Index auch wirklich zulässig ist. Weil 

wir aber die Instanz von Vector so angelegt haben, dass sie maximal 3 

Elemente halten kann, wird entschieden, dass es mit der Zulässigkeit gar 

nicht so weit her ist. 

3. Es wird also entsprechend in Zeile 135 eine IndexOutOfBoundsException 

als temporäres Objekt geworfen und dadurch wird die Methode an dieser 

Stelle auch verlassen. Der Konstruktoraufruf des temporären Objekts 

äußert sich im Output durch die Meldungen 

default - constructing Exception, id = 0 

default - constructing IndexOutOfBoundsException, id = 0 

4. Wie bereits erwähnt, wird von throw sofort eine Kopie dieses Objekts 

angelegt. Da wir einen Copy Constructor bereitgestellt haben, wird die-


ser auch verwendet. Dies sieht man im Output an den Meldungen 

copy - constructing Exception, id = 1 

copy - constructing IndexOutOfBoundsException, id = 1 

5. Nach Anlegen dieser Kopie ist die throw Expression abgearbeitet. Es 

wird also das ursprüngliche Exception Objekt damit zerstört. Dies äußert 

sich an den Meldungen 

destructing IndexOutOfBoundsException, id = 0 

destructing Exception, id = 0 

Dieses Zerstören ist auch der Grund, warum ich im Demoprogramm den 

einzelnen Objekten den Member my_id_ verpasst habe: Man sieht, welche 

Instanz zerstört wird. Bei uns hat das Original die Id 0 und die Kopie 

hat die Id 1. 

6. Nach dem Zerstören des Originals beginnt das Stack Unwinding, also 

das Zurückgehen in der Aufrufhierarchie am Stack, bis ein entsprechender 

try Block mit zugehörigem catch gefunden wird. Hierbei wird 

setElementAt verlassen und das erste passende catch findet sich direkt 

in der aufrufenden main Funktion in Zeile 170. Genau dort läuft das 

Programm dann weiter, wie sich am Output leicht erkennen lässt. 

7. Beim Verlassen des catch Blocks ist auch die Lifetime der Kopie des 

temporären Objekts zu Ende (diese war natürlich selbst ein temporäres 

Objekt, wie sich leicht überlegen lässt). Entsprechend finden wir auch 

im Output die entsprechenden Meldungen zu den Destruktoraufrufen 

destructing IndexOutOfBoundsException, id = 1 

destructing Exception, id = 1 

Das Grundprinzip des Exception Mechanismus ist im Prinzip also recht klar 

und einfach nachvollziehbar. Es wurde auch bereits erwähnt, dass es verschiedene 

catch Blöcke für verschiedene Exceptions geben kann. Nun stellt sich 

nur noch die Frage, wie diese verschiedenen Exceptions unterschieden werden. 

Die Antwort ist einfach: aufgrund ihres Typs. Ein bestimmter catch 

Block wird angesprungen, wenn die Exception, die geworfen wurde, eine der 

folgenden Bedingungen erfüllt: 

• Die geworfene Exception hat genau denselben Typ, wie im catch Statement 

als Parameter angegeben. 

• Die im catch als Parameter angegebene Exception ist eine public Basisklasse 

der geworfenen Exception. Dann sind diese beiden Typen ja bekannterweise 

voll kompatibel. 

• Wenn die geworfene Exception ein Pointer ist (ja, auch das geht!) und 

dieser Pointer zu einem Pointer-Parameter in einem catch Statement typkompatibel 

ist. 

• Wenn die geworfene Exception eine Referenz ist (wie zu erwarten, geht das 

auch) und diese Referenz zu einem Referenz-Parameter in einem catch 

Statement typkompatibel ist.


Außerdem gilt noch, dass immer der erste catch Block angesprungen wird, 

der eine dieser Bedingungen erfüllt. Sollten also aus Gründen der Typenkompatibilität 

mehrere catch Blöcke in Frage kommen, so wird der erste 

davon genommen. Das bedeutet also, dass auch die Reihenfolge, in der die 

catch Blöcke vorkommen, eine große Bedeutung spielt. Sehen wir uns das 

am besten an einem Beispiel an (second_exception_demo.cpp): 

1 // second exception demo . cpp − another demo , how the exception 

2 // mechanism works in C++ 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


12 { 

13 public : 

14 Exception ( ) { } 

15 virtual ˜ Exception ( ) { } 

16 } ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 class DerivedAException : public virtual Exception 

20 { 

21 public : 

22 DerivedAException ( ) { } 

23 virtual ˜ DerivedAException ( ) { } 

24 } ; 

25 

26 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

27 class DerivedBException : public virtual Exception 

28 { 

29 public : 

30 DerivedBException ( ) { } 

31 virtual ˜ DerivedBException ( ) { } 

32 } ; 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 class DerivedCException : public DerivedAException 

36 { 

37 public : 

38 DerivedCException ( ) { } 

39 virtual ˜ DerivedCException ( ) { } 

40 } ; 

41 

42 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

43 class DerivedDException : public DerivedAException , 

44 public DerivedBException 

45 { 

46 public : 

47 DerivedDException ( ) { } 

48 virtual ˜ DerivedDException ( ) { } 

49 } ; 

50 

51 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

52 void demoFuncException ( ) 

53 throw( Exception ) 

54 { 

55 throw Exception ( ) ; 

56 }

57 


58 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

59 void demoFuncDerivedAException ( ) 

60 throw( DerivedAException ) 

61 { 

62 throw DerivedAException ( ) ; 

63 } 

64 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

65 void demoFuncDerivedBException ( ) 

66 throw( DerivedBException ) 

67 { 

68 throw DerivedBException ( ) ; 

69 } 

70 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

71 void demoFuncDerivedCException ( ) 

72 throw( DerivedCException ) 

73 { 

74 throw DerivedCException ( ) ; 

75 } 

76 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

77 void demoFuncDerivedDException ( ) 

78 throw( DerivedDException ) 

79 { 

80 throw DerivedDException ( ) ; 

81 } 

82 

83 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


85 { 

86 try 

87 { 

88 uint32 num runs = 5; 

89 while ( num runs−−) 

90 { 

91 try 

92 { 

93 switch ( num runs ) 

94 { 

95 case 4 : 

96 demoFuncDerivedDException ( ) ; 

97 break ; 

98 case 3 : 

99 demoFuncDerivedCException ( ) ; 

100 break ; 

101 case 2 : 

102 demoFuncDerivedBException ( ) ; 

103 break ; 

104 case 1 : 

105 demoFuncDerivedAException ( ) ; 

106 break ; 

107 case 0 : 

108 demoFuncException ( ) ; 

109 break ; 

110 } 

111 } 

112 catch ( DerivedCException &exc ) 

113 { 

114 cout


123 } 

124 catch ( DerivedDException &exc ) 

125 { 

126 // ATTENTION ! ! ! This one w i l l never become a c t i v e ! 

127 cout


Vorsicht Falle: Wie bereits demonstriert wurde, kann es durch Unachtsamkeiten 

bei der Anordnung der catch Blöcke dazu kommen, dass manche davon 

nicht erreichbar sind. Dieses Problem kann man leicht vermeiden, indem 

man Klassen, die tiefer in der Ableitungshierarchie stehen, weiter oben fängt 

und solche, die höher stehen, entsprechend weiter unten, um “den Rest” der 

Exceptions, die nicht explizit mit ihrer genauen Klasse angegeben wurden, 

auch noch sinnvoll zu fangen. 

Das Verhalten von Exceptions, dass sie entsprechend ihrer Typenhierarchie 

behandelbar sind, hilft enorm beim Design großer Libararies. Es hat 

sich sinnvollerweise eingebürgert, dass es für eine Library einen bestimmten 

Basis Exceptiontyp gibt, von dem alle anderen abgeleitet sind. Zum Beispiel 

könnte man in einer Library mit mathematischen Klassen eine Basis 

Exception MathException definieren. Davon abgeleitet wäre dann z.B. eine 

DivisionByZeroException, eine VectorException, eine MatrixException, 

etc. Sollte man bestimmte Exceptions gesondert behandeln wollen, fängt 

man diese speziell, wenn nicht, reicht ein catch auf eine MathException und 

dadurch fängt man automatisch alle möglicherweise auftretenden Exceptions 

aus dieser Library. 

Jetzt bleibt noch eine Frage offen: Was passiert, wenn eine Exception geworfen 

wird, aber kein passendes catch dazu auffindbar ist? Irgendwann ist 

ja das Stack Unwinding einmal am Ende des Stacks angelangt. In diesem 

Fall wird eine Standard Behandlung durchgeführt, die üblicherweise zum 

Programmabbruch mittels abort() führt. Wie dieser Mechanismus genau 

funktioniert und wie man sich z.B. zu Debugging Zwecken noch in diesen 

einklinken kann, wird in Abschnitt 15.7 besprochen. Im Augenblick genügt 

es, zu wissen, wie man Exceptions sinnvoll fängt und ich möchte allen Lesern 

unbedingt anraten, die Behandlung von Exceptions auch gewissenhaft 

durchzuführen, damit es gar nicht erst zu sogenannten uncaught Exceptions 

kommen kann. 

Eine Anmerkung hätte ich noch zur Deklaration von möglichen Exceptions, 

die aus einer Methode oder Funktion geworfen werden, mittels 

throw(...): Ebenso wie beim Fangen von Exceptions, bei der nicht der 

genaue Typ, sondern die Typenkompatibilität zählt, verhält es sich bei 

der Angabe von Exceptions, die geworfen werden können. In der Angabe 

mit throw(...) muss nur ein kompatibler Typ, also entweder die genaue 

Exception oder eine ihrer Basisklassen angegeben sein. Man könnte 

also zum Beispiel in unserem Demoprogramm in Zeile 78 auch einfach 

throw(Exception) schreiben und würde damit kein Problem heraufbeschwören, 

denn DerivedDException ist ja von Exception abgeleitet. Im 

Falle, dass man ein Overriding einer Methode macht, bei der bereits ein throw 

deklariert wurde, kann diese Deklaration in der abgeleiteten Klasse entweder 

gleich sein, oder die Originaldeklaration einschränken. Das ist auch völlig logisch, 

denn damit erreicht man, dass immer maximal die Exceptions geworfen


werden können, die ursprünglich deklariert waren. Dadurch ist sichergestellt, 

dass keine neuen Exceptions geworfen werden können, auf die Code, der mit 

der Basisklasse zu tun hatte, eventuell gar nicht reagieren kann. 

Es wurde bereits erwähnt, dass man Exceptions auch “weiterwerfen” 

kann. Ich möchte gleich vorausschicken, dass dieses Konstrukt in nicht allzu 

vielen Fällen als schön bezeichnet werden kann, denn entweder kann man eine 

Exception behandeln, dann soll man sie fangen, oder nicht, dann soll man sie 

in Ruhe lassen. Eine der ganz wenigen Ausnahmen zu dieser Regel ist der 

Fall, dass man für eine Exception zwar keine Behandlung durchführen kann, 

aber noch ein paar Dinge aufräumen muss, bevor diese Exception dann ihrer 

tatsächlichen Behandlung zugeführt wird. Um z.B. für diesen Fall zu wissen, 

wie man dies in C ++ bewerkstelligt, sehen wir uns am besten ein kleines 

Beispiel an (rethrow_exc_demo.cpp): 

1 // rethrow exc demo . cpp − a demo , how re−throwing an exception 

2 // works in C++ 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


12 { 

13 public : 

14 Exception ( ) 

15 { 

16 cout

46 } 

47 catch ( Exception &exc ) 

48 { 

49 cout


29 

30 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

31 Dummy: :Dummy( ) 


33 { 

34 cout


Objekte in ihrem “halbtoten” Zustand belassen, denn das resultiert in ganz 

tollen und langen Debugging-Sessions, in denen man teuflische Gespenster 

jagen darf. 

In unserem Fall ist dieses Problem leicht in den Griff zu bekommen, man 

braucht nur ein entsprechendes delete durchzuführen, bevor man die Exception 

im Konstruktor wirft. Damit hat man sinnvoller- und robusterweise 

kein “halbtotes” Objekt konstruiert, sondern die “halbe” Konstruktion wieder 

rückgängig gemacht. 

Noch ein Punkt kommt hier ins Spiel: Es wurde bereits gesagt, dass alle 

Objekte, die fertig konstruiert wurden, auch wieder destruiert werden. Dies 

gilt natürlich auch für alle Member Variablen eines Objekts, selbst wenn im 

Konstruktor des Objekts selbst eine Exception geworfen wurde. Sobald diese 

fertig konstruiert waren, stellen sie keine Gefahr mehr dar. Selbiges gilt 

auch in Ableitungshierarchien: Sobald der Konstruktor einer Basisklasse korrekt 

abgearbeitet war, wird auch deren Destruktor aufgerufen, selbst wenn 

im Konstruktor einer abgeleiteten Klasse eine Exception in Bodenhöhe geflogen 

kommt. Den Beweis für diese Aussagen tritt das folgende Beispiel an 

(another_exc_in_constructor_demo.cpp): 

1 // another exc in constructor demo . cpp − what happens when throwing an 

2 // exception in a constructor ? 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


12 { 

13 public : 

14 Exception ( ) { } 

15 Exception ( const Exception& exc ) {} 

16 virtual ˜ Exception ( ) { } 

17 } ; 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 class Whatever 

21 { 

22 public : 

23 Whatever ( ) { cout



39 Whatever a v a r i a b l e ; 

40 public : 

41 Dummy( ) 

42 throw( Exception ) ; 

43 virtual ˜Dummy( ) ; 

44 } ; 

45 

46 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

47 Dummy: :Dummy( ) 


49 { 

50 cout


Der Grund hierfür ist leicht einzusehen, wenn man sich kurz überlegt, was 

bei Exceptions passiert. Wir haben bereits diskutiert, dass bei einer Exception 

das sogenannte Stack Unwinding stattfindet. Dabei werden natürlich 

alle auto-Variablen aus dem Speicher entfernt (und natürlich destruiert), die 

ihre Lifetime hinter sich haben, wenn der Block, in dem sie definiert wurden, 

verlassen wird. Und jetzt stellen wir uns vor, dass eine Variable im Zuge des 

Stack Unwindings destruiert wird und selbst eine Exception wirft. Welche 

der beiden Exceptions soll jetzt behandelt werden? Die erste, die das Stack 

Unwinding in Gang gesetzt hat oder die zweite, die während des Unwindings 

passiert ist? Beide gleichzeitig behandeln geht nicht, eine davon einfach verwerfen 

geht auch nicht, ein tolles Dilemma! Es wird in diesem Fall einfach der 

brutale Weg gegangen und das Programm intern mittels abort abgewürgt. 

Das wollen wir natürlich alle nicht, dementsprechend ist die starke Empfehlung 

von oben unbedingt einzuhalten! 

Vorsicht Falle: Wenn man unvorsichtig ist, kann es passieren, dass in einem 

Destruktor eine Methode bzw. Funktion aufgerufen wird, die selbst eine Exception 

werfen kann. In solchen Fällen darf niemals übersehen werden, dass 

man im Destruktor selbst ein entsprechendes try-catch Konstrukt unterbringt, 

ansonsten würde ja unabsichtlich die Exception aus dem Destruktor 

hinaus geworfen werden! 

Vorsicht Falle: Leider gibt es immer wieder Entwickler, die der Meinung 

sind, dass man Exceptions am besten einfach ignoriert, um sie nach außen 

zu verstecken. Zu diesem Zweck bauen sie sogenannte silent Catches in ihren 

Code ein, also solche, die einfach einen leeren catch Block besitzen. Dies 

darf man niemals machen, denn damit gelingt es bravourös, dass man Fehler, 

die auftreten und sauber gemeldet würden, kommentarlos ignoriert. Damit 

können sich dann Programme unheimlich komisch verhalten, weil sie eigentlich 

intern in einem Fehlerzustand sind, aber trotzdem weiterlaufen, als wäre 

nichts geschehen. 

Die allerschlimmsten Exemplare von silent Catches, die man immer wieder 

findet, sind solche, bei denen im leeren catch Block ein Kommentar à la 

// this exception can never happen 

steht. Der richtige Standpunkt dazu ist allerdings: Wenn die Exception nicht 

auftreten kann, dann muss man zumindest einen Output einbauen, der den 

“unmöglichen” Fall meldet. Hatte man Recht und die Exception tritt nie 

auf, dann stört auch der Output nicht. Hatte man allerdings unrecht (sehr 

oft, v.a. nach Programmänderungen!!!), dann sieht man wenigstens, dass ein 

Fehler aufgetreten ist! 

Vor allem sollte man sich wirklich überlegen, ob man ein solches catch 

nicht gleich bleiben lässt und jemandem “weiter oben” die Behandlung 

überlässt, für den Fall, dass die Exception doch auftritt.


Vorsicht Falle: Manche Entwickler verwenden Exceptions bewusst zum 

Modellieren von bestimmten Control-Flows, z.B. zur Steuerung von Schleifen. 

Erstens stellt dies einen groben Widerspruch zur Semantik von Exceptions 

dar, zweitens kann man damit besonders hübsche Zeitbomben bauen, die 

viele Leute an den Rand der Verzweiflung treiben können. 

Nehmen wir zum Beispiel an, dass ein Entwickler in einer Schleife ein 

Vektor-Objekt Element für Element durchlaufen will und innerhalb der 

Schleife irgendwelche Methoden auf diesen einzelnen Objekten aufruft. Nehmen 

wir weiters an, dass der Vektor so implementiert ist, dass bei unerlaubter 

Indizierung eine IndexOutOfBoundsException geworfen wird. Der Entwickler 

kommt auf die glorreiche Idee, eine Endlosschleife zu implementieren und 

diese in ein try mit zugehörigem catch auf die IndexOutOfBoundsException 

einzubetten. Sobald die Exception geworfen wird, wird angenommen, dass 

alle Elemente im Vektor abgearbeitet wurden, denn man hat mit einem zu 

großen Index zugegriffen. 

Jetzt passiert allerdings Folgendes: In einer der Methoden, die auf ein Einzelobjekt 

aufgerufen werden, tritt aufgrund eines Softwarefehlers eine ganz 

anders begründete IndexOutOfBoundsException auf, als die, die erwartet 

wird. Diese bewirkt dann, dass die Schleife unabsichtlich verlassen wird, bevor 

noch alle Objekte abgearbeitet wurden! Die Implementation geht aber 

davon aus, dass die Exception dadurch entstand, dass der Vektor fertig abgearbeitet 

war. Somit hat man tollerweise nur einen Teil des Vektors abgearbeitet 

und sucht verzweifelt nach irgendwelchen verlorenen Objekten! 

Vorsicht Falle: Wie bereits erwähnt, können nicht nur Objekte, sondern 

auch Pointer auf Objekte als Exceptions verwendet werden. Aus Performancegründen 

kann dies auch sehr geistreich sein, denn z.B. eine Kopie eines 

Pointers anzulegen, ist im Regelfall deutlich schneller, als eine Kopie 

eines gesamten Objekts anzulegen. Nur leider übersehen manche Entwickler, 

dass eine dynamisch angelegte Exception auch sinnigerweise wieder irgendwo 

freigegeben werden muss, wie man an folgendem Beispiel beobachten kann 

(exception_memory_leak_problem.cpp): 

1 // exception memory leak problem . cpp − demo , how a memory leak 

2 // can be caused by bad exception throwing . 

3 

4 



7 



10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


13 { 

14 public : 

15 Exception ( ) { cout


16 virtual ˜ Exception ( ) { cout


noch eine zusätzliche Kopie der Exception angelegt wird, da ja call-by-value 

in C ++ der Standardmechanismus ist. 

Um nicht missverstanden zu werden: Die Fallen, in die man beim Exception 

Handling stolpern kann, sollen niemanden abschrecken, sondern nur 

warnen, worauf man aufpassen muss. Exceptions sind etwas sehr Brauchbares 

und sollen auch unbedingt verwendet werden! Die Behandlung von 

irgendwelchen “Ausnahmezuständen” ist seit den Urzeiten der Softwareentwicklung 

ein heißes Thema und Exceptions sind die sauberste und robusteste 

Möglichkeit, mit unerwarteten Ereignissen umzugehen. Code, der robust und 

fehlertolerant ist, ist eben bei weitem komplexer als Code, der nur so lange 

funktioniert, wie alles im “Normalzustand” bleibt. Wer kann zum Beispiel 

behaupten, dass im Falle von Netzwerken der andere Rechner immer erreichbar 

ist oder überhaupt existiert? Wer kann vorherbestimmen, ob ein File, 

das man öffnen will, garantiert vorhanden ist? Es ist also notwendig, eine 

Fehlererkennung und entsprechende Behandlung in den Code einzubauen. 

Es kursiert leider auch noch immer die große Angst vor Performanceproblemen 

bei der Verwendung von Exceptions, da ein try ... catch ein 

wenig ineffizienter ist, als z.B. eine Abfrage von return Werten. Diese Angst 

ist allerdings im Normalfall unbegründet. Man darf nämlich nicht außer Acht 

lassen, dass eine saubere und übersichtliche Programmstruktur in der Regel 

eine effizientere Implementation von Algorithmen begünstigt. 

Ein kurzer Vergleich des Exception Mechanismus mit alternativen Techniken 

zur Fehlerbehandlung zeigt seine Stärken: 

• Man kann einen Fehler ignorieren und einfach probieren, weiterzumachen. 

Dass das katastrophale Folgen haben kann, versteht sich von selbst und 

deswegen möchte ich diese Art der “Fehlerbehandlung” gar nicht näher 

kommentieren. 

• Man kann einfach bei einem Fehler das Programm beenden. Dieses Verhalten 

führt früher oder später sicher zu einem größeren Desaster. Erstens ist 

ein Programm, das sich bei jeder Gelegenheit beendet, eine Katastrophe 

für die Benutzer. Zweitens bedeutet dieses Verhalten, dass intern durch das 

willkürliche Unterbrechen von Abläufen schlimmste Inkonsistenzen entstehen 

können. Sobald dann einmal aufgrund eines solchen Verhaltens eine 

größere Datenbank inkonsistent ist, weil einfach beim Beenden nur die halben 

Daten geschrieben werden konnten, kann man sich das Lachen kaum 

noch verhalten. Dieses Verhalten ist also absolut unbrauchbar! 

• Man kann im Fehlerfall eine Meldung z.B. auf Standard-Error schreiben. 

Das Problem dabei ist, dass man ja trotzdem irgendwie mit dem Programm 

fortfahren muss. Es muss also sowieso eine der anderen, hier erwähnten, 

Strategien zusätzlich implementiert werden, denn sonst käme dieses Verhalten 

dem Ignorieren des Fehlers gleich. 

• Man kann aus allen Methoden und Funktionen im Fehlerfall bewusst 

“unmögliche” Ergebnisse zum Signalisieren eines Fehlers liefern. Dies war


lange Zeit gängige Praxis, vor allem in C-Programmen. Allerdings hat dieses 

Verhalten auch große Nachteile. Einerseits muss man bei jedem einzelnen 

Aufruf den return-Wert abfragen und entsprechenden Error-Handling 

Code schreiben, zweitens gibt es genug Fälle, in denen ein “unmöglicher” 

Wert gar nicht wirklich vorhanden ist! Auch das Speichern eines Fehlers 

in einer globalen Variable (z.B. errno) ist nicht so toll, denn z.B. 

im Falle von Multithreading Umgebungen ist dies nicht synchronisierbar. 

Außerdem hat man das Problem, dass das Melden von Fehlern und die 

Behandlung derselben nicht sauber getrennt vonstatten gehen kann, denn 

der Fehlerbehandlungscode kommt immer inmitten irgendwelcher Blöcke 

vor. Dieses Verhalten ist also auch nicht so toll. 

• Man kann mittels Callbacks (z.B. über Funktionspointer) Fehler melden. 

Das funktioniert zwar im Prinzip nicht so schlecht, leider hat es den entscheidenden 

Nachteil, dass im Fehlerfall der Ausstieg aus einer Methode 

bzw. Funktion und das Resume im Error-Handling Code nicht sauber passieren 

kann. Hier kommt es dann zu schlimmen Orgien mit Status- und 

Merkervariablen, die erstens ungewollte Abhängigkeiten und Seiteneffekte 

nach sich ziehen und zweitens den Code relativ undurchschaubar machen. 

• Man kann im Fehlerfall einen Dialog mit dem User beginnen, der entscheiden 

soll, wie jetzt fortgefahren wird. Dieses Verhalten ist absolut katastrophal, 

denn was soll den ein Benutzer mit der Frage anfangen, wie jetzt bei 

einem Illegalen Zugriff auf Adresse 0x17a5972b vorzugehen ist??? 

Sinnigerweise werden Exceptions also auch in der Standard-Library von C ++ 

verwendet. Aus diesem Grund möchte ich hier noch ein paar Kleinigkeiten 

ergänzen, die ich bisher schuldig geblieben bin: 

• Der Operator new wirft eine Exception vom Typ bad_alloc, wenn beim 

Anfordern von Speicher etwas schief geht. Um mit dieser Exception umgehen 

zu können, ist ein #include im Code notwendig. 

• Der dynamic_cast Operator wirft eine Exception vom Typ bad_cast, 

wenn der Cast fehlschlägt. Ein #include ist zum Umgang 

mit dieser notwendig. 

• Der typeid Operator wirft eine Exception vom Typ bad_typeid, wenn 

etwas fehlschlägt. Auch hier ist #include zum Umgang mit 

demselben notwendig. 

Viele andere Methoden, Operatoren und Funktionen aus der Standard Library 

werfen Exceptions im Fehlerfall. Welche, kann man den entsprechenden 

Manual Pages entnehmen. Leider folgen die Standard Exceptions keinem eindeutigen 

Namensschema, aber damit muss man wohl leben, denn eine Änderung 

dieser Exceptions würde weltweit eine Unmenge von C ++ Entwicklern 

zur Verzweiflung treiben.

12. Operator Overloading 

Bei den bisherigen Betrachtungen zu Klassen und Objekten haben wir bereits 

die verschiedenen Arten von Members, also Variablen und Methoden, kennen 

gelernt. Eines fehlt noch, um Klassen und Objekte zu einem Gesamtkonzept 

zu machen, nämlich Operatoren! Je nachdem, mit welchen Objekten man es 

zu tun hat, ist eine Verknüpfung derselben mittels Operatoren oft ein sehr 

logischer Zugang zu deren Konzept. Wenn man zwei Ganzzahlenwerte addieren 

kann, wieso sollte man das mit “höheren” Datentypen (z.B. Vektoren) 

nicht tun können? 

12.1 Grundprinzipien des Operator Overloadings 

Um nun nicht gleich zu abstrakt zu werden, nehmen wir einmal als Einstiegsdroge 

für das Operator Overloading eine einfache (!) mathematische 

Vektor-Klasse. Ich gebe schon zu, dass dies wirklich nicht das spannendste 

Beispiel ist und dass es bereits vielfach in der Literatur in verschiedensten 

Formen abgehandelt ist. Für den Einstieg ist es allerdings eines der demonstrativsten 

Beispiele. Sobald wir über die Grundprinzipien hinaus sind, 

wird es dann wieder spannender. Von unserer Minimalversion eines Vektors 

erwarten wir folgende Dinge: 

• Ein Vektor-Objekt speichert eine gewisse Anzahl von double Elementen. 

Beim Erzeugen eines solchen Objekts wird diese Anzahl (durch entsprechenden 

Konstruktoraufruf) festgelegt. 

• Der Zugriff auf die einzelnen Elemente eines Vektors soll mittels Angabe 

eines Index in eckigen Klammern hinter einer Vektor-Variable erfolgen, wie 

es auch bei “normalen” Arrays in C ++ üblich ist. 

• Zwei Vektoren sollen addierbar sein. Dies soll intuitiverweise einfach durch 

ein + zwischen zwei Vektoren geschehen. Die Addition von zwei Vektoren 

soll mathematisch korrekt durchgeführt werden, indem einfach die jeweiligen 

Einzelelemente an jeder Index-Position miteinander addiert werden. 

• Es soll eine Subtraktion eines Vektors von einem anderen möglich sein. 

Dazu will man einfach ein - zwischen diese beiden Vektoren schreiben. Die 

Subtraktion eines Vektors von einem anderen soll mathematisch korrekt 

geschehen, indem einfach die jeweiligen Einzelelemente subtrahiert werden.

336 12. Operator Overloading 

• Positives und negatives Vorzeichen sollen im Zusammenhang mit Vektoren 

verwendet werden können. 

• Ein Vektor soll mit einem Skalar (also bei uns mit einem double Wert) 

multiplizierbar sein. Dabei soll mathematisch korrekt jedes Einzelelement 

des Vektors mit dem Skalar multipliziert werden. 

• Die Zuweisung eines Vektors auf einen anderen mittels = Operator soll 

möglich sein. 

• Für Addition, Subtraktion und Multiplikation soll es auch die Zuweisungs- 

Kurzformen +=, -= und *= geben. 

• Der Vergleich zweier Vektoren auf Gleichheit sowie auf Ungleichheit soll 

intuitiverweise mittels == bzw. != möglich sein. 

Im Prinzip stellt sich also hier nur die Frage, wie man in C ++ dem Compiler 

erklärt, was ein Operator zu tun hat. Denkt man ein wenig näher über 

die Eigenschaften von Operatoren nach, so lässt sich leicht erkennen, dass 

sie eigentlich auch nichts anderes als Methoden bzw. Funktionen sein müssten. 

Und bis auf die spezielle Syntax, die Operatoren zugrunde liegt, ist das 

auch so. Nehmen wir z.B. einmal den folgenden Ausdruck her, bei dem wir 

annehmen, dass beide Variablen vom selben Typ MathVector sind: 

vector1 + vector2 

Das bedeutet für den Compiler salopp gesprochen: Ich habe einen binären 

Plus-Operator, der als seine Operanden jeweils etwas vom Typ MathVector 

oder etwas Kompatibles nimmt. 

Oder nehmen wir folgenden Ausdruck unter denselben Typ-Voraussetzungen: 

-vector1 

Das bedeutet für den Compiler salopp gesprochen: Ich habe einen unären 

Minus-Operator, der als Operanden etwas vom Typ MathVector oder etwas 

Kompatibles nimmt. 

Solche Betrachtungen des Compilers gelten natürlich für alle Operatoren, 

die in C ++ definiert sind, also auch Index- und Typumwandlungs-Operatoren 

und z.B. sogar für die Operatoren new und delete. 

Der Operator ist in allen Fällen für den Compiler irgendetwas Aufrufbares, 

das die Aufgabe schon erledigen wird, also ausführbarer Code, der die 

Implementation des Operators repräsentiert. 

Wenn wir nun noch weiter in Betracht ziehen, dass der Compiler Ausdrücke 

von links nach rechts auswertet, dann kann man auch einen sinnvollen 

Platz definieren, an dem der Compiler diese Definition sucht: 

• Bei binären Operatoren in der Deklaration der Klasse, der der linke Operand 

angehört. 

• Bei unären Operatoren in der Klasse, der der (einzige) Operand angehört. 

Bei einem unären Minus also ist dies der Operand rechts neben dem Minus, 

beim Index Operator ist es der Operand links davon. 

Allgemein gesprochen sucht der Compiler immer in der Klasse des Operanden 

nach der Operator-Definition, auf die sich der Operator bezieht. Im Falle,

12.1 Grundprinzipien des Operator Overloadings 337 

dass sich ein Operator auf zwei Operanden bezieht, also bei allen binären 

Operatoren, sucht der Compiler in der Klasse des linken Operanden. Ich 

schicke gleich voraus, dass dies nur ein Teil der Wahrheit ist, den Rest werden 

wir in Kürze noch besprechen. Für den Augenblick reicht diese Betrachtung 

einmal aus. 

Es ist also für unsere Beispiele nur notwendig, dass wir in der Klasse 

MathVector die geforderten Operatoren als Members deklarieren und definieren 

und schon funktioniert das Spielchen. Die Deklaration einer MathVector 

Klasse, die die oben angesprochenen Forderungen erfüllt und entsprechende 

Operatoren implementiert, sieht dann am Beispiel folgendermaßen aus 

(math_vector_v1.h): 

1 // math vector v1 . h − a simple mathematical vector c l a s s as a 

2 // demo f o r operator overloading 

3 

4 #ifndef math vector v1 h 

5 #define math vector v1 h 

6 




10 

11 using std : : invalid argument ; 

12 using std : : b a d a l l o c ; 

13 using std : : r a n g e e r r o r ; 

14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

16 /∗ 

17 ∗ MathVector 

18 ∗ 

19 ∗ A simple mathematical vector c l a s s 

20 ∗ 

21 ∗/ 

22 

23 class MathVector 

24 { 


26 static uint32 c u r r e n t i d ; 

27 

28 uint32 i n t e r n a l i d ; 


30 double ∗ elements ; 

31 

32 virtual void performAddOperation ( const MathVector &vec to add ) 

33 throw ( ) ; 

34 

35 virtual void performSubtractOperation ( 

36 const MathVector & v e c t o s u b t r a c t ) 

37 throw ( ) ; 

38 public : 

39 MathVector ( uint32 num elements ) 

40 throw( invalid argument , b a d a l l o c ) ; 

41 

42 MathVector ( const MathVector &vec ) 


44 

45 virtual ˜ MathVector ( ) 

46 throw ( ) ; 

47 

48 virtual double &operator [ ] ( uint32 index ) const


49 throw( r a n g e e r r o r ) ; 

50 

51 virtual MathVector operator + ( const MathVector &vec to add ) const 


53 

54 virtual MathVector &operator + ( ) const 

55 throw ( ) ; 

56 

57 virtual MathVector &operator += (const MathVector &vec to add ) 

58 throw( invalid argument ) ; 

59 

60 virtual MathVector operator − ( const MathVector & v e c t o s u b t r a c t ) const 


62 

63 virtual MathVector operator − ( ) const 

64 throw ( ) ; 

65 

66 virtual MathVector &operator −= (const MathVector & v e c t o s u b t r a c t ) 


68 

69 virtual MathVector operator ∗ ( double num to multiply by ) const 

70 throw( b a d a l l o c ) ; 

71 

72 virtual MathVector &operator ∗= (double num to multiply by ) 

73 throw ( ) ; 

74 

75 virtual MathVector &operator = ( const MathVector & v e c t o a s s i g n ) 


77 

78 virtual bool operator == (const MathVector &vec to compare with ) const 

79 throw ( ) ; 

80 

81 virtual bool operator ! = ( const MathVector &vec to compare with ) const 

82 throw ( ) ; 

83 } ; 

84 

85 

86 #endif // math vector v1 h 

In den Zeilen 48–82 sind die einzelnen Operatoren deklariert, die von dieser 

Version des Vektors unterstützt werden. Wie sich leicht erkennen lässt, funktioniert 

die Deklaration von Operatoren genau gleich wie die Deklaration von 

Methoden, nur dass statt des Methodennamens das Keyword operator, gefolgt 

vom gewünschten Operator geschrieben wird. Natürlich gelten auch für 

Operatoren genau dieselben Regeln für Overloading, Overriding, static und 

dynamic Binding, wie wir sie bereits bei Methoden kennen gelernt haben. 

Gehen wir die Operatoren also einmal der Reihe nach durch um zu sehen, 

wann und wie sie vom Compiler eingesetzt werden: 

• In den Zeilen 48–49 ist der Index-Operator deklariert. Dieser nimmt einen 

uint32 als Parameter und liefert eine Reference auf einen double. Im Fall, 

dass der Index ungültig ist, wird ein range_error geworfen. Ich habe mich 

hier bewusst für die Verwendung der vordefinierten Exceptions aus der 

Standard-Library entschieden, da diese Exceptions allen C ++ Entwicklern 

geläufig sind (obwohl ich z.B. den Namen range_error nicht so toll finde). 

Wenn der Compiler also irgendwo im Code z.B. das Statement 

vector1[5]


findet, dann wird er, unter der Voraussetzung, dass vector1 vom Typ 

MathVector ist (was ab jetzt vorausgesetzt wird), die Implementation dieses 

Operators mit 5 als Parameter aufrufen. Die Implementation hat dann 

die Aufgabe, eine Referenz auf das Element mit Index 5 zu liefern oder eine 

Exception zu werfen, falls der vector1 z.B. nur für 3 Elemente angelegt 

wurde. 

Für alle Leser, die sich nun fragen, warum hier eine Referenz geliefert wird 

und nicht einfach nur ein double, soll folgendes Beispiel Klarheit schaffen: 

Mit dem Statement 

vector1[5] = 17.5; 

will man diesem Element ja einen Wert zuweisen. Und das geht nur, wenn 

man mit Referenzen arbeitet. Wie sollte man sonst auch auf die richtige 

Speicherstelle zugreifen? 

Vorsicht Falle: Das in Abschnitt 9.4.6 besprochene Overloading für 

const und non-const Methoden gilt natürlich in derselben Form für Operatoren. 

Viele C ++ Neulinge glauben allerdings, dass sie hiermit zwei verschiedene 

Index-Operatoren so definieren könnten, dass die const Variante 

nur zum Lesen dient und die non-const Variante auch zum Schreiben. Der 

Compiler kann aber gar nicht wissen, was man mit dem Ergebnis des Operators 

machen will, woher denn auch? Die einzige Basis, auf der er seine 

Entscheidung trifft, ist die Konstantheit des Objekts selbst, auf das der 

Operator angewandt wird. Ist dieses konstant, so wird die const Variante 

des Operators aufgerufen, sonst nicht (alles natürlich genau den Regeln 

aus Abschnitt 9.4.6 entsprechend). 

• In den Zeilen 51–52 ist der Additions-Operator deklariert, der zwei Vektoren 

addieren kann. Das Ergebnis dieser Operation ist ein neuer Vektor, 

denn man will die beiden Operanden natürlich nicht verändern. Aus diesem 

Grund wird auch ein Objekt vom Typ MathVector als return Wert 

geliefert und keine Referenz auf einen Vektor. Das Statement 

vector1 + vector2 

wird also folgendermaßen vom Compiler aufgelöst: Es wird der Additions- 

Operator von vector1 mit vector2 als Parameter aufgerufen. Dieser muss 

ein Objekt liefern, das durch die Durchführung der Addition entsteht. 

Noch etwas läßt sich hier leicht erkennen: Das Resultat der Operation ist 

ein neues Objekt. Dieses wird allerdings nur temporär gebraucht und darf 

nicht “für ewig” im Speicher liegen bleiben. Wir haben es also hier wieder 

mit einem temporären Objekt zu tun, das nach Abschluss der Expression 

verworfen wird. Bei der Implementation dieses Operators werden wir uns 

dieser Eigenschaft dann noch näher zuwenden. 

• In den Zeilen 54-55 ist der unäre Plus-Operator definiert. Dieser ist daran 

zu erkennen, dass er keinen Parameter nimmt, weil er ja unär ist :-). 

Der Grund, warum hier eine Referenz als return Wert geliefert wird, ist 

in Performancebetrachtungen zu finden: Wozu soll man ein neues Objekt


erzeugen, das ja nur temporär ist und danach sowieso wieder weggeworfen 

wird? Das unäre Plus bewirkt ja überhaupt keine Änderung am Inhalt des 

Vektors. Also kann die Implementation gleich eine Referenz auf sich selbst 

liefern um unnötiges Erzeugen und wieder Wegwerfen zu verhindern. Das 

Statement 

+vector1 

wird also vom Compiler der Behandlung durch diesen Operator zugeführt. 

• In den Zeilen 57–58 findet sich der Additions-Kurzzuweisungs-Operator. 

Eine Anwendung dieses Operators bewirkt natürlich eine Veränderung des 

Inhalts des Objekts. Deshalb kann auch gleich eine Referenz auf das 

geänderte Objekt als return-Wert geliefert werden. Findet der Compiler 

also irgendwo im Code das Statement 

vector1 += vector2; 

dann wird dieser Operator auf vector1 mit vector2 als Parameter aufgerufen. 

Lesern, die sich nun fragen, warum dieser Operator überhaupt 

einen return-Wert liefert, möchte ich folgendes Beispiel zeigen, das absolut 

regulär ist: 

vector3 = vector1 += vector2; 

Hier wird zuerst eine Additions-Kurzzuweisung von vector2 auf vector1 

gemacht und das Ergebnis dieser Operation wird dann vector3 zugewiesen 

(siehe auch Zuweisungs-Operator weiter unten). Wäre der Operator als 

void Operator definiert (was theoretisch möglich ist), dann wäre ein solches 

Statement hierdurch mit Erfolg verhindert worden und der Compiler würde 

sich beschweren. 

• In den Zeilen 60–67 finden sich die verschiedenen Minus-Operatoren. Diese 

funktionieren analog zu den soeben besprochenen Plus-Operatoren, allerdings 

mit einer Ausnahme: Das unäre Minus liefert als return-Wert keine 

Referenz, sondern ein Objekt. Muss es auch, denn hier wird ja der entsprechende 

negative Vektor erwartet, allerdings ohne das Original zu ändern. 

• In den Zeilen 69–73 sind die entsprechenden Multiplikations-Operatoren 

deklariert. Ich denke, zu diesen kann ich mir die Erklärung jetzt auch 

ersparen, denn sie funktionieren praktisch analog zu den Additions- und 

Subtraktionsoperatoren. Nur nehmen sie als zweites Argument eben keinen 

MathVector, sondern einen double Wert. Wer Lust hat, kann ja auch die 

Multiplikation von zwei Vektoren (also das sog. Kreuzprodukt) implementieren. 

Dies geschieht durch ein einfaches Overloading des entsprechenden 

Multiplikations-Operators durch einen, der als Parameter ein Element vom 

Typ MathVector nimmt. 

• In den Zeilen 75–76 ist der Zuweisungs-Operator definiert. Wie dieser 

funktioniert, lässt sich leicht vorstellen. Dass auch dieser Operator einen 

return-Wert liefert ist ebenso logisch, denn Statements wie 

vector1 = vector2 = vector3; 

sollen natürlich auch unterstützt werden.


• In den Zeilen 78–82 sind die logischen Vergleichsoperatoren deklariert. 

Auch hier denke ich mir, dass eine genaue Erklärung überflüssig ist. 

Da die Implementation relativ lang ist, führen wir uns diese häppchenweise 

zu Gemüte. Gleich vorausschicken möchte ich, dass aus Gründen der Lesbarkeit 

bei der Implementation nicht das letzte Bisschen möglicher Performance 

herausgequetscht wird. Vielmehr soll der hier abgedruckte Code übersichtlich 

sein. Beginnen wir die Betrachtungen am besten bei den beiden Konstruktoren 

und dem Destruktor (math_vector_v1.cpp): 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

12 /∗ standard constructor 

13 ∗/ 

14 MathVector : : MathVector ( uint32 num elements ) 

15 throw( invalid argument , b a d a l l o c ) 

16 { 

17 i n t e r n a l i d = c u r r e n t i d ++; 

18 cout


In den Zeilen 17–19 sowie in den Zeilen 35–38, sieht man, dass jede Instanz 

eines Vektors eine eigene interne Identifikation bekommt und ein Output erzeugt 

wird, der es erlaubt, am Bildschirm zu sehen, was gerade passiert. Dies 

wurde deshalb eingebaut, um sehen zu können, wann temporäre Objekte erzeugt 

und wieder verworfen werden. Dadurch lässt sich am Output leicht 

erkennen, welcher Schritt einer Auflösung von Ausdrücken gerade abgearbeitet 

wird. 

In den Zeilen 21–23 und 40–42 ist zu erkennen, dass der Versuch der 

Erzeugung eines Vektors mit 0 Elementen nicht erlaubt ist und mit einer 

entsprechenden Exception quittiert wird. Die Abfrage auf die Anzahl der 

Elemente ist natürlich auch im Copy-Constructor notwendig, denn wer hindert 

jemanden daran, zu versuchen, von einem “halbtoten” Objekt (siehe 

Kapitel 11) eine Kopie anzulegen? Dass beim Werfen von Exceptions aus 

dem Konstruktor natürlich im Hinterkopf behalten werden muss, dass dadurch 

ja niemals wieder der Destruktor dieses Objekts aufgerufen wird (siehe 

Kapitel 11), versteht sich von selbst. Eine Frage stellt sich allerdings noch: 

Es wird eine bad_alloc Exception deklariert, aber nirgends im Code wird 

tatsächlich eine geworfen. Was soll das nun wieder? Ganz einfach: Man 

deklariert nicht nur Exceptions, die man selbst wirft, sondern natürlich auch 

solche, die geworfen werden können und die man nicht selbst behandelt. Diese 

fallen dadurch praktisch weiter nach oben durch. Genau das passiert bei 

new: Wenn nicht mehr genügend Speicher vorhanden ist, um den Request zu 

erfüllen, dann wird eine bad_alloc Exception geworfen. Unser Vektor kann 

weder dagegen etwas tun, noch weiß er, wie mit einem solchen Fehler umgegangen 

werden könnte, also überlassen wir das dem aufrufenden Codeteil. 

Der Destruktor in den Zeilen 54–60 bietet erwartungsgemäß keine besonderen 

Überraschungen. Natürlich wird auch hier entsprechender Output erzeugt, 

um die Lifetime aller Objekte am Bildschirm nachverfolgen zu können. 

Sehen wir uns noch schnell die Implementation des Index-Operators an, 

bevor wir zum ersten Demoprogramm schreiten, das unser Meisterwerk verwendet: 

65 double &MathVector : : operator [ ] ( uint32 index ) const 

66 throw( r a n g e e r r o r ) 

67 { 

68 cout


1 // math vector v1 test1 . cpp − f i r s t t e s t program f o r math v e c t o r s 

2 


4 

5 #include ” math vector v1 . h” 

6 




10 


12 { 

13 try 

14 { 

15 MathVector vector1 ( 3 ) ; 



18 

19 uint32 index = 3; 

20 while ( index−−) 

21 vector1 [ index ] = vector2 [ index ] = vector3 [ index ] = index ; 

22 

23 cout


5 MathVector , id = 1 : operator [ ] 








13 Vectors i n i t i a l i z e d to : 

14 vector1 : MathVector , id = 0 : operator [ ] 

15 0 MathVector , id = 0 : operator [ ] 


17 2 




21 2 




25 2 

26 MathVector , id = 2 : d e s t r u c t o r 



Im Testprogramm in den Zeilen 15–17 werden drei Vektoren erzeugt, jeder 

von ihnen kann drei Elemente halten. Am Output erkennen wir dies in den 

Zeilen 1–3 und sehen, dass vector1 die Id 0, vector2 die Id 1 und vector3 

die Id 2 bekommen hat. 

In den Zeilen 20–21 des Testprogramms werden den einzelnen Elementen 

der einzelnen Vektoren Werte zugewiesen. Hierbei kommt erwartungsgemäß 

unser selbstdefinierter Index-Operator zum Tragen, wie sich am Output in 

den Zeilen 4–12 zeigt. 

Die Zeilen 23–35 demonstrieren nur noch, dass der Index-Operator auch 

wirklich funktioniert hat, indem die einzelnen Elemente der einzelnen Vektoren 

ausgegeben werden. Im Output vermischt sich dadurch die Anzeige 

des Operator-Aufrufs und des Ergebnisses. Die Zeilen 14–17 des Outputs 

zeigen für vector1, dass immer zuerst unser Index-Operator aufgerufen 

wird, der den entsprechenden double Wert liefert, der wiederum ausgegeben 

wird. Selbiges gilt für die Zeilen 18–21 (=vector2) und für die Zeilen 22–25 

(=vector3). Da sich nach Zeile 35 die Lifetime unserer Vektoren ihrem Ende 

zuneigt, sieht man im Output in den Zeilen 26–28, wie sie ordnungsgemäß 

destruiert werden. 

In den Zeilen 40, 45 und 50 sieht man, wie man bei den Standard- 

Exceptions zum Text kommt, der ihnen beim Konstruieren übergeben wurde: 

Man ruft einfach die Methode what auf. 

Lesern, die sich mit diesem Testprogramm spielen wollen, möchte ich 

natürlich nicht vorenthalten, dass das Makefile dazu unter dem Namen 

MathVectorV1Test1Makefile auf der beiliegenden CD-ROM zu finden ist. 

Nach diesem Einstieg in die Welt der Operatoren über den Index-Operator 

wird es Zeit, dass wir zu den interessanteren Vertretern der Operatoren- 

Spezies kommen. Nehmen wir also die verschiedenen Minus-Operatoren einmal 

ein wenig genauer unter die Lupe:


119 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

120 /∗ 

121 ∗/ 

122 MathVector MathVector : : operator − ( 

123 const MathVector & v e c t o s u b t r a c t ) const 


125 { 

126 cout


In den Zeilen 122–135 ist der “normale” Subtraktions-Operator definiert. 

Dass vor der Subtraktion eine Überprüfung stattfindet, ob die beiden Vektoren 

dieselbe Größe haben, ist nicht weiter neu. Genauso wenig Neuigkeiten 

bietet die Exception, die geworfen wird, falls ebendiese Größe nicht übereinstimmt. 

Auch die Deklaration der bad_alloc Exception ist klar, denn 

in Zeile 132 kann es ja passieren, dass beim Anlegen des Resultat Vektors 

die Speicheranforderung schief geht. Weil es keine sinnvolle Möglichkeit gibt, 

dieses Problem innerhalb unseres Operators zu beheben, lassen wir die Exception 

nach oben durchfallen. 

In Zeile 132 kommt allerdings jetzt etwas vor, das bisher noch unbekannt 

ist: this. Das Keyword this steht für den Pointer auf sich selbst, 

auch self Pointer oder this Pointer genannt. Dadurch haben alle Objekte 

die Möglichkeit innerhalb ihrer Methoden auf die Adresse ihrer eigenen Instanz 

zuzugreifen. Natürlich gilt das nur für Methoden, die nicht static 

sind, denn diese gehören ja zur Klasse und nicht zu einer Instanz. Zeile 132 

legt also eine Kopie der aktuellen Instanz an, auf der der Operator aufgerufen 

wurde. Von dieser Kopie wird dann in Zeile 133 durch den Aufruf von 

performSubtractOperation der andere Vektor abgezogen. Das daraus entstehende 

Resultat wird als return-Wert geliefert. Genau in Zeile 134 sieht 

man, wann der Block, der einen Funktionsrumpf umschließt, als geschlossen 

betrachtet wird und damit die Lifetime von Variablen in diesem zu Ende 

ist: Erst, wenn return abgeschlossen und das Resultat “verarbeitet” wurde. 

Ansonsten müsste ja direkt beim Rücksprung bereits result destruiert werden, 

bloß dann würde man ein totes Objekt retournieren. Das wäre natürlich 

nicht im Sinne des Erfinders. 

Die Methode performSubtractOperation wurde bewusst aus dem Operator 

herausgezogen, da sie auch beim Kurzzuweisungs-Subtraktionsoperator 

gebraucht wird. Oft wird dies anders modelliert und ein Operator verwendet 

einfach einen anderen Operator, z.B. - legt ein result Objekt an und wendet 

auf dieses dann den -= Operator an, bevor es retourniert wird. Davor 

möchte ich allerdings abraten, denn damit kommt es fast garantiert entweder 

zu doppelten Überprüfungen ein- und derselben Einschränkungen, oder es 

wird unnötigerweise ein Objekt angelegt, das im Fall einer Exception wieder 

verworfen wird oder andere unnötige Dinge passieren. Als Grundregel möchte 

ich für solche Fälle sagen, dass es immer besser ist, eine public Methode bzw. 

einen public Operator so zu schreiben, dass alle Überprüfungen darin vorgenommen 

werden und danach wird eine interne Methode aufgerufen, die nur 

noch die Operation ohne weitere Überprüfungen ausführt. 

Die Implementation des Subtraktions-Kurzzuweisungs-Operators in den 

Zeilen 156–168 ist im Prinzip dieselbe, wie die des “normalen” Subtraktions- 

Operators. Der einzige Unterschied besteht darin, dass kein result Objekt 

angelegt wird, sondern das Objekt selbst, auf dem der Operator aufgerufen 

wurde, verändert wird.


Die Implementation des unären Minus-Operators in den Zeilen 140–151 ist 

straightforward: Es wird ein result Objekt angelegt, in dem jedes einzelne 

Element durch sein negatives Pendant ersetzt wird. Dies geschieht in der 

Schleife in den Zeilen 148–149. 

Die Additions-Operatoren sind analog zu den Subtraktions-Operatoren 

implementiert. Aus diesem Grund erspare ich den Lesern hier das Abdrucken 

derselben. Wenden wir uns nun also lieber unseren Multiplikations- 

Operatoren zu: 

173 MathVector MathVector : : operator ∗ ( double num to multiply by ) const 

174 throw( b a d a l l o c ) 

175 { 

176 cout


216 double ∗ dst = elements ; 

217 while ( count−−) 

218 ∗ dst++ = ∗s r c++; 

219 return (∗ this ) ; 

220 } 

Nur um ein kleines bisschen interessanter sind die beiden Vergleichsoperatoren, 

denn dort scheint sich ein Widerspruch zur oben erwähnten Grundregel 

mit internen Methoden und public Operatoren und deren Verwendung bzw. 

Durchmischung eingeschlichen zu haben: 

222 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

223 /∗ 

224 ∗/ 

225 bool MathVector : : operator == ( 

226 const MathVector &vec to compare with ) const 

227 throw( ) 

228 { 

229 i f ( vec to compare with . num elements ! = num elements ) 

230 return ( false ) ; 

231 uint32 count = num elements ; 

232 double ∗ s r c = vec to compare with . elements ; 

233 double ∗ dst = elements ; 


235 { 

236 i f ( ∗ dst ++ != ∗ s r c++) 

237 return ( false ) ; 

238 } 

239 return ( true ) ; 

240 } 

241 

242 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

243 /∗ 

244 ∗/ 

245 bool MathVector : : operator ! = ( 

246 const MathVector &vec to compare with ) const 

247 throw( ) 

248 { 

249 return ( ! ( ∗ this == vec to compare with ) ) ; 

250 } 

In Zeile 249 wird jetzt plötzlich der == Operator auch intern verwendet, obwohl 

ich gemeint habe, dass dies verpönt sei. Der Grund dafür ist einfach: In 

der Implementation des != Operators wird wirklich absolut nichts gemacht, 

als das Ergebnis des == Operators zu negieren. Es finden keine Überprüfungen 

statt und es gibt auch sonst keinen Code in dieser Methode. Aus diesem 

Grund ist der Regelbruch hier zulässig. Im Normalfall würde man diesen 

Operator außerdem aufgrund seiner Kürze als inline implementieren. 

Um uns nun noch ein kurzes Bild von der Verwendung der Operatoren 

und den internen Vorgängen machen zu können, werfen wir einen Blick auf 

das folgende Testprogramm (math_vector_v1_test2.cpp):


1 // math vector v1 test2 . cpp − another t e s t program f o r math v e c t o r s 

2 


4 


6 




10 


12 { 

13 try 

14 { 




18 

19 uint32 index = 3; 

20 while ( index−−) 

21 vector2 [ index ] = vector3 [ index ] = index ; 

22 

23 // here the copy constructor i s c a l l e d ! 

24 MathVector vector4 = vector3 ; 

25 

26 vector1 = ( vector2 ∗ 2 ) + ( vector3 ∗ 2 ) ; 

27 vector4 −= vector3 ; 

28 } 

29 catch ( invalid argument &exc ) 

30 { 

31 c e r r


15 MathVector , id = 4 : operator + , other id = 5 

16 MathVector , id = 6 : copy constructor , other id = 4 

17 MathVector , id = 0 : operator = , other id = 6 




21 MathVector , id = 3 : operator −= , other id = 2 





Die Zeilen 15–17 des Testprogramms erzeugen wie gehabt die Zeilen 1–3 im 

Output. Die Zuweisungs-Orgie in den Zeilen 20–21 findet sich im Output 

in den Zeilen 4–9 wieder. In Zeile 24 des Programms zeigt sich erneut, was 

bereits in Abschnitt 9.2.3 erwähnt wurde: Die Initialisierung einer Variable 

ist definitiv nicht dasselbe, wie eine Zuweisung eines Wertes an eine Variable. 

Sobald eine Instanz einer Klasse erzeugt wird und in der Initialisierung eine 

“Zuweisung” eines Wertes stattfindet, wird vom Compiler nachgesehen, ob 

es einen passenden Konstruktor gibt. Wenn ja, wird dieser verwendet, wie 

es bei uns mit dem Copy-Constructor passiert. Gibt es keinen, der genau 

passt, dann wird nach den üblichen Regeln derjenige ausgesucht, der “am 

besten” passt. Was nicht passiert, ist, dass zuerst der default Konstruktor 

verwendet wird und danach ein Aufruf des Zuweisungs-Operators erfolgt! 

Findet der Compiler keinen passenden Konstruktor, quittiert er dies mit einer 

Fehlermeldung! 

Das bedeutet, dass die beiden folgenden Codestücke 

MyClass var1 = 17; 

und 

MyClass var1; 

var1 = 17; 

absolut nicht dasselbe bewirken, obwohl dies oft fälschlich angenommen wird! 

Im ersten Fall wird ein Konstruktor gesucht, der als Parameter einen int 

nehmen kann. Im zweiten Fall wird zuerst das Objekt über den default 

Konstruktor konstruiert und danach wird über den Zuweisungsoperator 17 

zugewiesen (falls ein solcher Operator existiert). 

Genau dieser Unterschied ist es auch, warum man immer die Konstruktion 

und die damit einhergehende Initialisierung von Members im Initialisierungsteil 

des Konstruktors (also nach dem : und vor dem Rumpf) vornehmen 

sollte, anstatt erst im Rumpf des Konstruktors eine Zuweisung zu machen. 

Natürlich funktioniert das nur, wenn ein entsprechender Konstruktor zur 

Verfügung steht :-). 

Jetzt aber wieder zurück zu unserem Programm: Sehen wir uns an, was 

alles passiert, wenn Zeile 26 ausgewertet wird: Im Output schlägt sich diese 

Zeile nämlich gleich mit vielen Meldungen zu Buche, die von Zeile 11–20 

reichen: 

• Zu Beginn wird der Operator * aufgerufen, der vector2 mit 2 multipliziert, 

wie in Zeile 11 des Outputs zu sehen ist.


• Die Meldung über den Aufruf des Copy-Constructors in Zeile 12 des Outputs 

stammt von der Implementation dieses Operators, der ja ein result 

Objekt anlegt. 

• Die Zeilen 13–14 geben darüber Auskunft, dass gerade die zweite Multiplikation, 

also vector3 mit 2, stattfindet. 

• Zeile 15 meldet den Aufruf des + Operators auf dem Resultat der ersten 

Multiplikation (also dem temporären Objekt). Diese Addition wird erwartungsgemäß 

mit dem zweiten temporären Objekt, also dem Resultat aus 

der zweiten Multiplikation, durchgeführt. 

• In Zeile 16 des Outputs sieht man, dass bei dieser Addition der beiden 

temporären Objekte natürlich gemäß der Implementation des + Operators 

ein weiteres temporäres Objekt erzeugt wird. 

• Dieses weitere temporäre Objekt wird dann endlich unserem vector1 zugewiesen, 

wie Zeile 17 zeigt. 

• In den Zeilen 18–20 sieht man, dass nach Ende der Operation auch alles 

wieder brav aufgeräumt wird. 

Vergleicht man diese temporäre Objektorgie mit dem Aufruf des Operators 

-=, dessen Output in Zeile 21 erscheint, dann erkennt man einen “geringfügigen” 

Unterschied: Hierbei wird nämlich kein einziges temporäres Objekt angelegt 

und wieder verworfen! Die Zeilen 22–25 zeigen nur noch das Destruieren 

unserer vier Vektoren am Ende ihrer Lifetime. 

Vorsicht Falle: Die zuvor demonstrierte Operation, in der massig temporäre 

Objekte angelegt und wieder zerstört werden, zeigt, dass man wirklich immer 

bedenken sollte, wie man gewisse Codezeilen schreibt! Es ist ja nicht nur bei 

unserem kleinen Demo-Vektor so, dass je nach Operation temporäre Objekte 

gebraucht werden. Leider wird von allzu vielen Entwicklern immer noch 

die Existenz der Zuweisungs-Kurzformen missachtet und das kann in enorm 

ineffizientem Code enden, obwohl sich die Entwickler keiner Schuld bewusst 

sind. Allerdings ist es nun einmal so, dass die folgenden zwei Zeilen 

var1 = var1 + var2; 

var1 += var2; 

keinesfalls dasselbe bedeuten und intern auch zu völlig verschiedenem Verhalten 

führen, auch wenn das Ergebnis in beiden Fällen gleich aussieht! In 

der ersten Zeile wird ein temporäres Objekt erzeugt, zugewiesen und wieder 

verworfen. In der zweiten Zeile wird einfach die Addition durchgeführt und 

das war’s. 

Was sieht man hier? Auch bei scheinbar belanglosen Dingen ist ein tieferes 

Grundverständnis für den Computer, die verwendete Sprache und allgemeine 

Restriktionen absolut unabdingbar um saubere Software zu schreiben! 

Ich habe es bereits mehrfach erwähnt, aber aus gutem Grund tue ich es 

hier noch einmal: Ich möchte mit den Hinweisen auf solche Fallen keinesfalls 

jemanden verschrecken, ganz im Gegenteil! Ich möchte nur alle Leser darauf 

aufmerksam machen, dass ausprobieren, spielen und verstehen gefragt sind!


Je mehr man probiert und analysiert, desto besser wird man gewisse Phänomene 

kennen lernen und mit ihnen umgehen lernen. Das ist ja gerade der 

Grund, warum Erfahrung in der Softwareentwicklung so viel wert ist! 

Ein kleiner Exkurs: Sieht man sich z.B. die Implementation des Subtraktionsoperators 

an, so wird hierbei ein Objekt result geliefert. In unserem 

Fall zieht dieses der Compiler direkt für die Weiterverarbeitung heran. Je 

nach Compiler könnte es in diesem Fall auch passieren, dass er naiverweise 

eine temporäres Objekt als Kopie von result für die Weiterverarbeitung 

anlegt. Darunter würde die Performance dieses Operators im Vergleich zum 

entsprechenden Kurzzuweisungs Operator natürlich noch zusätzlich leiden. 

Ich würde allen Lesern anraten, entsprechende Tests mit ihrer verwendeten 

Entwicklungsumgebung durchzuführen. 

Vorsicht Falle: Ich habe es hier beim Vektor nicht implementiert, um nicht 

völlige Verwirrung zu stiften, aber eine große Falle tut sich, je nach Implementation, 

beim Zuweisungs- und beim Vergleichsoperator auf: Was passiert 

bei einer Selbstzuweisung bzw. bei einem Vergleich mit sich selbst? In unserem 

Beispiel gibt es hierbei ein Problem. Deshalb sollte man in diesen Fällen 

immer gleich als erste Zeile in den entsprechenden Operatoren durch einen 

Vergleich des Parameters mit this feststellen, ob man nicht gerade mit sich 

selbst in einer Operation konfrontiert ist. Ist man hierbei unvorsichtig, dann 

können sich daraus sehr interessante Debugging Sessions ergeben :-). 

Alle Leser, die spätestens jetzt bedingt durch Angst (hoffentlich nicht) 

oder bedingt durch Neugierde (hoffentlich schon) der Spieltrieb gepackt hat, 

finden das Makefile zu diesem Programm unter dem Namen 

MathVectorV1Test2Makefile auf der beiliegenden CD-ROM. 

Ein kleineres Problemchen gilt es noch bei unserer Klasse MathVector zu 

lösen: Das folgende Statement 

2.0 * DEC1 

kann vom Compiler in der jetzigen Version der Klasse nicht verarbeitet werden. 

Nach unseren Regeln, die wir oben definiert haben, müsste er jetzt 

nämlich im double nach einem Operator suchen, der diesen mit einem 

MathVector multipliziert. Den gibt es natürlich nicht. Genau hier kommt 

ins Spiel, warum ich über die Suche nach den Operatoren gesagt habe, dass 

das noch nicht die ganze Wahrheit wäre. Es gibt nämlich sehr wohl eine 

Möglichkeit einen Operator zu definieren, der diesen Fall abdeckt. Jedoch ist 

dies keine Methode unserer Klasse MathVector mehr, sondern eine Funktion, 

die zwei Parameter nimmt: einen linken und einen rechten Operanden. 

Ergänzen wir also unseren Header um die Deklaration dieser Funktion und 

fügen die Implementation derselben zu unserer Implementation des restlichen 

Vektors hinzu, dann funktioniert auch das. Das Ergebnis dieses Umbaus sind


die Files math_vector_v2.h und math_vector_v2.cpp, von denen ich hier 

nur die ergänzten Ausschnitte inkludiere: 

84 MathVector operator ∗ ( double num to multiply by , 

85 const MathVector& vec ) 


283 MathVector operator ∗ ( double num to multiply by , 

284 const MathVector& vec ) 


286 { 

287 return ( vec ∗ num to multiply by ) ; 

288 } 

Um kontrollieren zu können, ob alles erwartungsgemäß funktioniert, gibt es 

das folgende Testprogramm (math_vector_v2_test.cpp): 

1 // math vector v2 test . cpp − t e s t program f o r extended math v e c t o r s 

2 


4 


6 




10 


12 { 

13 try 

14 { 


16 MathVector vector2 = 3 ∗ vector1 ; 

17 } 

18 catch ( invalid argument &exc ) 

19 { 

20 c e r r


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

12.2 Typumwandlungen 355 

einer entsprechen Exception quittiert. Der springende Punkt hierbei liegt in 

der Forderung der vollen Kompatibilität zu einem int. Es sollen also nicht 

nur alle Operationen gleich funktionieren wie bei einem int, sondern ein solches 

Objekt soll auch in Operationen beliebig mit int-Variablen gemischt 

werden können. 

Eine brute-force Variante diese Klasse zu implementieren würde darin 

bestehen, alle Operatoren, die für int definiert sind, auch tatsächlich für 

diese Klasse als entsprechende Operatoren zu definieren. Diese Variante ist 

aber sehr unschön, da in jedem einzelnen Operator sowieso wieder nur der 

entsprechende systeminterne Operator für int aufgerufen würde. 

Besser wäre da schon die Möglichkeit, unser Objekt zu einem “echten” 

int wandeln zu können. Dann nämlich würden alle für int definierten Operatoren 

automatisch funktionieren und bräuchten nicht extra implementiert 

werden. Die Überprüfung des vorgegebenen Wertebereichs müsste nur in 

den entsprechenden Zuweisungsoperatoren erfolgen und alle unsere Wünsche 

wären erfüllt. Genau diese Möglichkeit gibt es, wenn man ein Overloading 

der entsprechenden Operatoren zur Typumwandlung vornimmt, wie im folgenden 

Beispiel gezeigt wird (range_controlled_int.cpp): 

1 

2 // r a n g e c o n t r o l l e d i n t . cpp : demo f o r type conversionoperators 

3 




7 


9 

10 using std : : invalid argument ; 



13 




17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 /∗ 

20 ∗ RangeControlledInt 

21 ∗ 

22 ∗ implements i n t e g e r s with a c o n t r o l l e d range 

23 ∗ 

24 ∗/ 

25 

26 class RangeControlledInt 

27 { 


29 int32 min ; 

30 int32 max ; 

31 int32 value ; 

32 public : 

33 RangeControlledInt ( int32 min , int32 max , int32 value = 0) 

34 throw( invalid argument , r a n g e e r r o r ) ; 

35 

36 RangeControlledInt ( const RangeControlledInt & s r c ) ; 

37 

38 virtual ˜ RangeControlledInt ( ) { }


39 

40 virtual RangeControlledInt &operator = ( 

41 const RangeControlledInt & s r c ) 


43 

44 virtual RangeControlledInt &operator = ( int32 value ) 


46 

47 virtual operator int32 ( ) const ; 

48 } ; 

49 

50 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

51 /∗ 

52 ∗/ 

53 RangeControlledInt : : RangeControlledInt ( int32 min , 

54 int32 max, 

55 int32 value ) 

56 throw( invalid argument , r a n g e e r r o r ) 

57 { 

58 cout

105 ( value > max ) ) 

106 throw r a n g e e r r o r ( ” value out o f range ” ) ; 

107 value = value ; 


109 } 

110 


111 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

112 /∗ 

113 ∗/ 

114 RangeControlledInt : : operator int32 ( ) const 

115 { 

116 cout


12 6 

13 ∗∗∗∗ RangeControlledInt : conversion to int32 

14 RangeControlledInt : = with int32 

15 Oops − caught r a n g e e r r o r : value out o f range 

Aufmerksame Leser haben sicherlich bereits erkannt, dass die Deklaration des 

Typumwandlungs-Operators in Zeile 46 zu finden ist. Allerdings liest sich dieser 

Operator doch etwas komisch, wenn man ihn mit den anderen Operatoren 

vergleicht. Der Name des Operators ist int32 und das Fehlen von Parametern 

zwischen den Klammern sagt uns, dass er ein unärer Operator ist. Allerdings 

ist im Gegensatz zu anderen Operatoren kein expliziter return-Value 

angegeben! Wenn man kurz nachdenkt, wird auch klar warum: Was soll eine 

Umwandlung auf einen int32 denn auch anderes liefern als einen int32? Definiert 

man also einen Typumwandlungs-Operator, so schreibt man einfach 

das Keyword operator, gefolgt vom Datentyp, in den man umwandeln will, 

gefolgt von öffnender und schließender runder Klammer, das war’s. Dass sich 

hinter der Syntax mit dem fehlenden return-Value eine Erleichterung für die 

Compilerbauer versteckt, ist eine andere Geschichte :-). 

Die Implementation des Typumwandlungs-Operators in den Zeilen 113– 

117 braucht sicherlich keine nähere Erklärung. Um genau verfolgen zu 

können, was hinter den Kulissen passiert, wurde in gewohnter Weise in alle 

Methoden ein entsprechender Output eingebaut. Werfen wir also nun einen 

Blick auf denselben: 

Die Zeilen 1–2 des Outputs werden beim Anlegen der entsprechenden 

Variablen in den Zeilen 126–127 des Programms erzeugt. Dass die Zeilen 

3–4 des Outputs ihren Ursprung in den Zuweisungen aus den Zeilen 129– 

130 des Programms haben, ist auch nicht weiter verwunderlich. Zeile 131 

des Programms wird in dieser Beziehung schon interessanter, denn von ihr 

rühren die Zeilen 5–6 des Outputs her, die zeigen, dass hier zum ersten 

Mal unser Typumwandlungs-Operator ins Spiel kommt: Hier wird zuerst 

controlled_var2 in einen int32 verwandelt, danach wird die Subtraktion 

durchgeführt und das Ergebnis wird dann entsprechend zugewiesen. Man 

sieht also, dass der Compiler aus dem Subtraktionsoperator und dem links 

von ihm stehenden int32 den Schluss gezogen hat, dass rechts wohl auch 

ein int32 stehen sollte, damit die Operation ordnungsgemäß ausgeführt 

werden kann. In unserer Klassendeklaration hat er den entsprechenden 

Typumwandlungs-Operator gefunden und automatisch eingesetzt. 

Dass dies nicht nur funktioniert, wenn links des Operators ein int32 

steht, sondern auch umgekehrt und sogar in beliebiger Kombination, beweisen 

die Zeilen 132–133 des Programms, die im Output die Zeilen 7–10 

erzeugen. Salopp gesagt arbeitet der Compiler also so, dass er zuerst einen 

Ausdruck daraufhin analysiert, was denn sinnvolle Kombinationen von Datentypen 

wären, um die gewünschten Operationen auszuführen. Findet er 

dann entsprechende Typumwandlungen, so werden diese eingesetzt und alles 

geht seinen erwarteten Weg.


Dass dieses Verhalten nicht nur auf mathematische Operationen beschränkt 

ist, zeigt sich sehr schön in Zeile 134 des Programms: Wir können 

einfach controlled_var1 mittels


der Folge zu sehen ist. Die Deklaration findet sich in math_vector_v3.h und 

sieht folgendermaßen aus: 

48 virtual operator double ∗ ( ) const 

49 throw( bad cast ) ; 

Implementiert wird der Operator in math_vector_v3.cpp: 

65 MathVector : : operator double ∗ ( ) const 

66 throw( bad cast ) 

67 { 

68 cout

35 exc . what()


vergessen, so haben wir ein wunderbar wachsendes Programm erzeugt, wobei 

die Ursache für das entstandene Speicherloch ausgesprochen schwer zu finden 

ist und den Entwicklern sicherlich einige lange Nächte beschert. 

Vorsicht Falle: Wie wir gesehen haben, sind selbstdefinierte Typumwandlungs-Operatoren 

auf Pointer-Typen eine ziemlich heikle Angelegenheit, bei 

der sehr viel schief gehen kann. In unserem Fall wird durch die Definition 

einer expliziten Umwandlungsmethode, wie weiter oben vorgeschlagen wurde, 

auch nur ein Teil des Problems gelöst, die Zeitbombe “Array” bleibt allerdings 

in einer oder der anderen Form bestehen. Ich kann also allen Lesern hier nur 

Folgendes raten: 

Das Mischen von Objekten mit dazu (teil-)kompatiblen Array-Datentypen 

ist prinzipiell zu vermeiden! 

Sollte man aus irgendwelchen Gründen auf eine solche Funktionalität 

nicht verzichten können, so sollte man dafür eine eigene Zugriffsmethode 

implementieren (und ihre Gefahren gut dokumentieren :-)). 

Vorsicht Falle: Manchmal wird in gewissen Designs dem Compiler zu viel 

zugetraut, haben doch implizite Typumwandlungen durch den Compiler auch 

ihre Grenzen. Der Compiler weigert sich (zum Glück), mehrere verschiedene 

Umwandlungen hintereinander auszuführen. Was das bedeutet, kann man 

leicht am folgenden Beispiel erkennen: 

Nehmen wir an, wir hätten eine Klasse IntStore, die eine Typumwandlung 

auf int32 besitzt: 

1 class IntStore 

2 { 

3 // Constructor , Destructor , etc . . . 

4 

5 virtual operator int32 ( ) const ; 

6 } ; 

Weiters hätten wir eine Klasse CommonStore, die eine Typumwandlung auf 

IntStore unterstützt: 

1 class CommonStore 

2 { 

3 // Constructor , Destructor , etc . . . 

4 

5 virtual operator IntStore ( ) const ; 

6 } ; 

Und nun schreiben wir Folgendes: 

CommonStore my_store; 

int32 my_var = 10 + my_store; 

Manche Leser mögen nun glauben, dass die Berechnung funktionieren sollte, 

denn der Compiler kann ja zuerst die Umwandlung von my_store auf ein 

Objekt vom Typ IntStore einsetzen. Da dieses dann eine Umwandlung auf 

int32 unterstützt, wäre der Fall erledigt. 

Der Compiler jedoch sieht das anders, denn er betrachtet nur die Umwandlungen, 

die von CommonStore selbst zur Verfügung gestellt werden. Da

12.3 Speicherverwaltung 363 

er dort keine passende Umwandlung findet, endet der Versuch der Übersetzung 

des obigen Statements in einem Fehler. Es gibt auch zwei sehr gute 

Gründe für dieses Verhalten: 

1. Würde der Compiler Umwandlungsketten suchen (und finden), so kann 

es leicht zu bösen Überraschungen bezüglich Ambiguitäten oder auch 

bezüglich Verträglichkeit von Datentypen kommen, die sich eigentlich 

beabsichtigterweise nicht vertragen sollten. 

2. Müsste der Compiler auf die Suche nach Umwandlungsketten gehen, 

dann würde ihn dies nicht wirklich performanter machen, denn dafür 

wäre die Implementation von einigen sehr komplexen graphentheoretischen 

Algorithmen notwendig. Und die durch Umwandlungen aufgespannten 

Graphen können groß werden... 

12.3 Speicherverwaltung 

Waren schon selbstdefinierte Typumwandlungs-Operatoren mit Vorsicht anzuwenden, 

so kommen wir jetzt zu einem Thema, das wirklich als for Experts 

only ausgewiesen werden muss: Overloading der new und delete 

Operatoren, um gewisse Teile der Speicherverwaltung selbst in die Hand zu 

nehmen. Im Prinzip kann man damit sehr sinnvolle Konstrukte implementieren, 

aber die Möglichkeiten, ungeahnte Zeitbomben in die eigene Software 

einzubauen, sind auch nicht zu verachten! Man muss wirklich ganz genau wissen, 

was man tut, wenn man ein Overloading von new und delete sinnvoll 

und robust einsetzen will! 

Genug gewarnt – wenden wir uns also nun wirklich den Grundprinzipien 

einer selbstgebastelten Speicherverwaltung zu. 

12.3.1 Einfaches new und delete 

Bisher haben wir damit gelebt, dass bei einem Aufruf von new einfach hinter 

den Kulissen genügend Speicher reserviert wurde und wir keinen Einfluss darauf 

hatten, wo dieser Speicherblock hergenommen wird und wo er endgültig 

zu liegen kommt. In den allermeisten Fällen ist das auch vollkommen ausreichend. 

Stellen wir uns aber nun z.B. vor, dass wir es mit einem System zu tun 

hätten, in dem gewisse Objekte in einem besonderen Speicherbereich liegen 

müssen, um eine saubere Funktionalität zu gewährleisten. In embedded Systems 

kann es schon einmal vorkommen, dass man es mit zwei verschiedenen 

Arten von Speichern zu tun hat. Die eine Art von Speicher gestattet einen 

schnellen Zugriff, ist aber flüchtig. Die andere Art von Speicher ist langsam, 

dafür aber nicht flüchtig und gestattet daher das Speichern von Objekten, die 

auch nach dem “Ausschalten” des Systems erhalten bleiben. Es ginge jetzt


zu weit, solche Systeme einer genaueren Analyse zu unterziehen, eines ist allerdings 

offensichtlich: Objekte, auf die man oft zugreift, müssen im schnellen 

Speicher zu liegen kommen. Objekte, deren Zustand erhalten bleiben muss, 

müssen wohl oder übel im nicht flüchtigen, dafür aber langsamen Speicher zu 

liegen kommen. Daneben gibt es noch die typischen Hybridobjekte, auf die 

einerseits oft zugegriffen wird, die andererseits aber trotzdem nicht flüchtig 

sein dürfen. Diese lassen wir im Augenblick außer Acht, werden aber später 

noch einmal darauf zurückkommen. 

Was wollen wir also erreichen? Der Aufruf von new soll den Speicherblock 

für das entsprechende Objekt automatisch entweder im schnellen oder 

im langsamen Teil des Speichers ablegen, je nachdem wie es die Natur des 

Objekts verlangt. Damit eine Klasse kundtun kann, in welchem Teil des Speichers 

sie zu liegen kommen will, schreiben wir zwei Basisklassen, von denen 

entsprechend abgeleitet werden muss: Eine Klasse FastAccessibleObject 

und eine Klasse NonVolatileObject. Je nachdem, von welcher Klasse abgeleitet 

wird, kommt ein Objekt bei seiner dynamischen Erzeugung im einen 

oder anderen Teil des Speichers zu liegen. Bevor das Ganze nun zu theoretisch 

wird, sehen wir uns das am besten gleich an einem ersten kleinen 

Beispiel an (first_new_delete_overloading_demo.cpp). 

In diesem Beispiel ist zur Demonstration eine Klasse MemoryProvider 

implementiert, die nur als Platzhalter für eine “richtige” Speicherverwaltung 

dient, die in solchen Systemen gebraucht wird. Diese Klasse sieht folgendermaßen 

aus: 

23 class MemoryProvider 

24 { 

25 private : 

26 MemoryProvider ( ) ; // f o r b i d i n s t a n t i a t i o n 

27 public : 

28 static const uint32 FAST = 0x01 ; 

29 static const uint32 NON VOLATILE = 0 x02 ; 

30 

31 static void ∗ allocMemBlock ( uint32 mem type , s i z e t s i z e ) 


33 static void freeMemBlock ( void ∗ base ptr ) 

34 throw ( ) ; 

35 } ; 

Wie sich leicht erkennen lässt, kann man über diese Klasse die entsprechenden 

(uninitialisierten!) Speicherblöcke anfordern und nicht mehr benötigte 

Speicherblöcke wieder freigeben lassen. Beim Anfordern gibt man den Typ 

des benötigten Blocks sowie seine Größe in Bytes an und bekommt einen 

entsprechenden Base-Pointer geliefert. Beim Freigeben übergibt man einfach 

den Base-Pointer. Die Implementation der Methoden liest sich so: 

182 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

183 /∗ This i s j u s t a dummy implementation f o r demo purposes . . . 

184 ∗/ 

185 void ∗ MemoryProvider : : allocMemBlock ( uint32 mem type , s i z e t s i z e ) 

186 throw( b a d a l l o c )

187 { 

188 switch (mem type) 

189 { 

190 case FAST: 

191 case NON VOLATILE: 

192 return ( malloc ( s i z e ) ) ; 

193 } 

194 return ( 0 ) ; 

195 } 

196 


197 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

198 /∗ This i s j u s t a dummy implementation f o r demo purposes . . . 

199 ∗/ 

200 void MemoryProvider : : freeMemBlock ( void ∗ base ptr ) 

201 throw( ) 

202 { 

203 i f ( base ptr ) 

204 f r e e ( base ptr ) ; 

205 } 

So einige Leser werden sich jetzt fragen, ob ich vielleicht zu lange in der Sonne 

war, weil ich hier doch tatsächlich die Funktionen malloc und free verwende. 

In Abschnitt 6.2.2 habe ich noch ausdrücklich erklärt, dass man von diesen 

Funktionen tunlichst die Finger lassen soll und stattdessen new und delete 

verwenden soll. Der Grund für diesen vermeintlichen Regelverstoß ist einfach 

zu erklären: Wenn man schon new und delete implementiert, dann bewegt 

man sich ja bereits eine Ebene tiefer unten und muss einfach irgendwo her 

einen nicht initialisierten Speicherblock bekommen. Deshalb ist es in diesem 

Kontext (und ausschließlich in diesem!) erlaubt und zumeist notwendig, mit 

malloc und free zu arbeiten. 

Folgende von C übernommene Funktionen werden angeboten, wenn man 

inkludiert: 

void *malloc(size_t size): Allokiert Speicher der Größe size und liefert 

den Base-Pointer darauf. Der Speicher, der allokiert wird, ist nicht 

initialisiert. 

void *calloc(size_t num,size_t size): Allokiert Speicher der Größe 

num * size, initialisiert diesen mit 0 und liefert den Base-Pointer darauf. 

void free(void *base_ptr): Gibt Speicher, der entweder über Aufruf von 

malloc oder calloc allokiert wurde, wieder frei. 

void *realloc(void *base_ptr,size_t size): Ändert die Größe des 

durch base_ptr referenzierten Speicherblocks auf size. Da nicht garantiert 

werden kann, dass der Block nicht z.B. im Zuge eines Vergrößerns 

verschoben werden muss, wird der neue Base-Pointer des Blocks zurückgeliefert. 

Der neu hinzugekommene Speicher ist nicht initialisiert. 

Vorsicht Falle: Man sieht, es gibt also auch tatsächlich ein realloc, obwohl 

ich es bisher konsequent unter den Tisch gekehrt habe. Allerdings wird auch 

auf dieser unteren Ebene dringendst von dessen Verwendung abgeraten! 

Das Problem bei realloc ist, dass der Block im Speicher verschoben


werden kann. Hat man nun z.B. einen Pointer, der auf ein Objekt zeigt, das 

in einem solchen Speicherblock liegt, dann zeigt nach einer Verschiebung des 

Blocks dieser Pointer ins Nirvana. Welche lustigen Folgen das haben kann, 

lässt sich leicht vorstellen. 

Vorsicht Falle: Es wurde bereits implizit erwähnt, aber weil es derartig 

gefährlich ist, möchte ich es hier noch einmal explizit anführen: 

• Die Funktion malloc allokiert nur Speicher. Sie weiß nichts von Objekten 

oder sonstigen C ++ Features. Es wird also bei Verwendung von malloc 

niemals ein Konstruktor aufgerufen. 

• Die Funktion free gibt nur Speicher frei. Auch sie weiß nichts von Objekten. 

Es wird also bei Verwendung von free niemals ein Destruktor 

aufgerufen. 

Das Schlimmste, was man machen kann (und ich habe so etwas bereits in 

mehr als einem C ++ Programm gesehen!), ist also Folgendes: Man legt ein 

Objekt ordnungsgemäß mit new an. Anstatt allerdings das Objekt dann mit 

delete wieder freizugeben, ruft man free mit dem Base-Pointer des Objekts 

auf. Dadurch wird kein Destruktor aufgerufen und was das bedeutet, kann 

man sich ausmalen! 

Vorsicht Falle: Um den Blick nicht vom Wesentlichen abzulenken, habe 

ich im Beispiel den return-Value von malloc nicht überprüft. Die Funktion 

malloc ist allerdings gleich definiert wie in C: Wenn der Speicher ausgeht, 

dann retourniert sie einen 0-Pointer! Diese Funktion weiß nichts von Exceptions 

und wirft dementsprechend selbsttätig keine bad_alloc Exception, wenn 

nicht mehr genug Speicher da ist. 

Aus diesem Grund muss bei einer ernsthaften Implementation von new 

immer der return-Value von malloc abgefragt und entsprechend reagiert werden. 

Allerdings ist dies allein bei einer ernsthaften Implementation auch nicht 

genug! Per Konvention darf man nicht blindlings eine bad_alloc Exception 

werfen, denn es gibt da noch eine weitere Konvention in C ++, die man 

zu beachten hat. Wie man nun korrekt nach Standard die Behandlung von 

Speicherknappheit übernimmt, wird ausführlich in Abschnitt Verhalten bei 

“Ausgehen” des Speichers diskutiert. 

Der Vollständigkeit halber möchte ich an dieser Stelle auch noch erwähnen, 

dass bei Inkludieren von auch noch die aus C bekannten Funktionen 

memcpy, memmove, memchr, memcmp und memset zur Verfügung stehen. 

Und natürlich muss ich auch hier gleich vor deren unsachgemäßen Verwendung 

dringendst warnen. 

Nach diesem kurzen aber notwendigen Ausflug in die Welt der Low-Level 

Speicherverwaltung wird es Zeit zum eigentlichen Thema dieses Kapitels


zurückzukehren: Overloading von new und delete. Sehen wir uns dazu die 

Deklaration der Klasse FastAccessibleObject an: 

46 class FastAccessibleObject 

47 { 

48 public : 

49 void ∗ operator new( s i z e t s i z e ) 


51 void operator delete ( void ∗ base ptr ) 

52 throw ( ) ; 

53 

54 FastAccessibleObject ( ) { } 

55 

56 virtual ˜ FastAccessibleObject ( ) { } 

57 } ; 

In den Zeilen 49–50 sehen wir, wie ein new Operator definiert ist: Es wird ein 

Parameter übergeben, der die Größe des benötigten Speicherblocks in Bytes 

angibt. Der erwartete return-Value ist dann der Base-Pointer des allokierten 

Speicherblocks. Im Falle, dass etwas schief geht, muss eine bad_alloc 

Exception geworfen werden. In den Zeilen 51–52 sehen wir, wie ein delete 

Operator definiert ist: Es wird einfach der Base-Pointer des freizugebenden 

Speicherblocks übergeben. Die Implementation dieser beiden Operatoren 

liest sich dann folgendermaßen: 

138 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

139 /∗ 

140 ∗/ 

141 void ∗ FastAccessibleObject : : operator new( s i z e t s i z e ) 


143 { 

144 cout


Eine Klasse, die ein FastAccessibleObject repräsentiert, wird entsprechend 

von dieser Basis abgeleitet und kommt damit automatisch im 

schnellen Teil des Speichers zu liegen. Als Beispiel hierfür dient die Klasse 

MyFastObject: 

89 class MyFastObject : public FastAccessibleObject 

90 { 


92 int32 some data ; 

93 uint32 some other data ; 

94 public : 

95 MyFastObject ( ) 

96 { 

97 cout

8 d e s t r u c t o r of MyNonVolatileObject 

9 d e l e t e o f NonVolatileObject c a l l e d 

10 c r e a t i n g with e x p l i c i t constructor c a l l s . . . 

11 constructor of MyFastObject 

12 constructor of MyNonVolatileObject 

13 s t a t i c a l l y a l l o c a t e d o b j e c t s . . . 



16 l e a v i n g main 


18 d e s t r u c t o r of MyFastObject 




Die Zeilen 1–9 repräsentieren den Output, der durch die Zeilen 212–216 unseres 

Programms erzeugt wird. Im Falle des dynamischen Erzeugens eines 

neuen Objekts, wie es z.B. in Zeile 213 unseres Programms gemacht wird, 

passiert Folgendes: 

1. Es wird intern ausgerechnet, wie viel Speicherplatz das Objekt benötigt. 

Darauf haben wir in unserem Programm überhaupt keinen Einfluss, denn 

dies wird einzig und allein vom Compiler erledigt. 

2. Danach wird unser selbstdefinierter new Operator aufgerufen und ihm 

die benötigte Größe mitgeteilt (siehe Zeile 2 des Outputs). Im Operator 

selbst muss der Speicherblock bereitgestellt werden und ein Base-Pointer 

darauf zurückgeliefert werden. 

3. Nachdem der Speicher zur Verfügung steht, wird intern der entsprechende 

Konstruktor aufgerufen (siehe Zeile 3 des Outputs). Auch darauf haben 

wir als Entwickler natürlich keinen Einfluss. 

Wird ein Objekt mittels delete in die ewigen Jagdgründe geschickt, dann 

passiert dies folgendermaßen: 

1. Zuerst wird intern der entsprechende Destruktor aufgerufen. Darauf haben 

wir natürlich keinen Einfluss. 

2. Danach wird der nun nicht mehr benötigte Speicherblock zur Freigabe 

an unseren selbstdefinierten delete Operator übergeben, der für das 

Aufräumen zu sorgen hat. 

Man sieht also ganz deutlich, dass man durch das Overloading von new und 

delete einzig und allein Einfluss auf die Beschaffung und Freigabe von Speicher 

nehmen kann. Es ist natürlich in keinster Weise festgelegt, woher man 

den Speicher beim Anfordern bekommt bzw. wie man ihn wieder freigibt. 

Das einzig Wichtige ist, dass man beim Anfordern einen entsprechenden 

Block liefern kann und den Hinweis zur Freigabe korrekt behandelt. Es ist 

auch nicht festgelegt, dass der von new gelieferte Block genau die angeforderte 

Größe haben muss, wichtig ist nur, dass er mindestens die geforderte 

Speicherkapazität besitzt. Genau diese Definition wird von erfahrenen 

Entwicklern so ausgenützt, dass sie nicht jeden Block einzeln mit malloc 

anfordern und dann mit free wieder dem System überantworten. Stattdessen 

wird für Objekte, die sehr oft erzeugt und wieder zerstört werden, ein


Pool von vorallokierten Blöcken verwaltet (bzw. auch nur ein einziger großer 

Block, in den viele kleinere hineinpassen). Einzelne Blöcke aus diesem Pool 

werden dann nur als benutzt oder unbenutzt markiert. Sinnvoll und richtig 

angewandt bringt diese Art der Verwaltung in gewissen Fällen enorme 

Performancesteigerungen der Software mit sich. 

Noch eine Eigenschaft der beiden Operatoren wird hier deutlich: beide 

sind implizit static, obwohl sie explizit nicht so deklariert wurden. Das 

ist auch absolut lebensnotwendig, denn new beschafft erst den Speicher für 

eine Instanz, kann also niemals selbst zu dieser Instanz gehören. Zum Zeitpunkt 

des Aufrufs existiert diese ja noch gar nicht. Ebenso verhält es sich 

mit delete, denn dieses wird ja erst nach dem Abarbeiten des Destruktors 

aufgerufen, die Instanz ist also nicht mehr wirklich lebendig. 

Welchen Einfluss haben unsere selbstdefinierten new und delete Operatoren 

nun auf das Verhalten eines nicht dynamisch angelegten Objekts? Die 

Zeilen 10–20 des Outputs, die von den Zeilen 218–227 des Programms her 

rühren, zeigen es ganz deutlich: überhaupt keinen! 

Dies ist auch vollkommen verständlich, wenn man sich einmal vor Augen 

führt, welche verschiedenen Speicherbereiche innerhalb eines laufenden 

Programms existieren und wie sie verwaltet werden: 

Static Memory: Dies ist der Bereich in dem Variablen mit globaler Lifetime 

abgelegt werden. Für diesen Bereich ist der Linker zuständig. 

Automatic Memory: Dies ist der Bereich in dem die sogenannten auto- 

Variablen, also lokale Variablen, abgelegt werden. Jeder Eintritt in eine 

Methode, Funktion oder einfach in einen Block bekommt einen eigenen 

Bereich im automatic Memory. Für diesen Bereich ist der Compiler 

zuständig und der Bereich wird als Stack verwaltet und deshalb auch oft 

einfach als Stack bezeichnet. 

Anm.: Es gibt in C ++ sogar das (redundante!) Keyword auto, wenn 

jemand Lust hat, es explizit zu schreiben. Das Keyword hat allerdings 

überhaupt keinen Einfluss auf die Verwaltung, sondern ist nur als Eye- 

Catcher für die Entwickler gedacht. 

Free Memory: Dies ist der (ausschließlich) von Entwicklern selbst verwaltete 

Speicherbereich eines Programms, der auch oft als Heap bezeichnet wird. 

Dieser Teil des Memories wird für die mittels new und delete explizit 

dynamisch verwalteten Daten herangezogen. 

Nachdem wir weder dem Linker noch dem Compiler ins Handwerk pfuschen 

dürfen, denn dies hätte fatale Folgen, haben wir also sowohl auf das static 

als auch auf das automatic Memory keinen Einfluss. Unsere new und delete 

Operatoren kommen ausschließlich dann zum Tragen, wenn wir Objekte am 

Heap ablegen, also dynamische Speicherverwaltung verwenden. 

Dass dies aber z.B. für unser Beispiel keine Einschränkung bedeutet, lässt 

sich auch schnell erkennen: Will man, dass ein Objekt im nicht flüchtigen 

Teil des Speichers zu liegen kommt, dann will man es ja offensichtlich über


längere Zeit speichern. Das ist bei lokalen Variablen sowieso nicht der Fall, 

also betrifft uns dies nicht. Sehr wohl würde es uns betreffen, wenn wir 

einfach eine Variable mit globaler Lifetime anlegen wollten und diese im nicht 

flüchtigen Speicher zu liegen kommen sollte. In diesem Fall ist es dann so, 

dass entweder die Compiler/Linker Kombination für unser System sowieso 

das static Memory im nicht flüchtigen Teil verewigt oder wir eben einfach per 

Konvention nur mittels dynamischer Memory-Verwaltung arbeiten dürfen. 

12.3.2 Array new und delete 

Es ist bereits bekannt, dass es verschiedene new und delete Operatoren gibt, 

je nachdem, ob man ein einzelnes Objekt oder ein Array von Objekten anlegen 

will. Genau diese Unterscheidung trifft uns auch beim Overloading 

dieser Operatoren, denn für Arrays gibt es tatsächlich explizit die alternativen 

Operatoren new[] und delete[]. Man sieht also, dass der Aufruf 

von delete[] statt delete für Arrays nicht nur reine Kosmetik ist, sondern 

dass sich dahinter sehr wohl ein eigener, separater Operator mit besonderen 

Eigenschaften verbirgt. Ergänzen wir also unser Beispielprogramm um 

die entsprechenden Array-Operatoren um zu sehen, wie sich diese verhalten 

(second_new_delete_overloading_demo.cpp). Die geänderte Klasse 

FastAccessibleObject sieht dann folgendermaßen aus: 

48 class FastAccessibleObject 

49 { 

50 public : 



53 

54 void ∗ operator new [ ] ( s i z e t s i z e ) 


56 


58 throw ( ) ; 

59 

60 void operator delete [ ] ( void ∗ base ptr ) 

61 throw ( ) ; 

62 

63 FastAccessibleObject ( ) { } 

64 

65 virtual ˜ FastAccessibleObject ( ) { } 

66 } ; 

Die Implementation der beiden dazugekommenen Operatoren birgt nichts 

wirklich Berauschendes, wie sich leicht erkennen lässt: 

169 void ∗ FastAccessibleObject : : operator new [ ] ( s i z e t s i z e ) 


171 { 

172 cout


191 void FastAccessibleObject : : operator delete [ ] ( void ∗ base ptr ) 

192 throw( ) 

193 { 

194 cout


4 new o f NonVolatileObject c a l l e d with s i z e 16 



7 d e l e t e o f FastAccessibleObject c a l l e d 



10 c r e a t i n g arrays of o b j e c t s . . . 

11 new [ ] of FastAccessibleObject c a l l e d with s i z e 40 




15 new [ ] of NonVolatileObject c a l l e d with s i z e 52 







22 d e l e t e [ ] of FastAccessibleObject c a l l e d 




26 d e l e t e [ ] of NonVolatileObject c a l l e d 

27 ∗∗∗∗∗ and now the catastrophe ! ! ! ! ! ! ∗ ∗ ∗ ∗ ∗ 

28 new [ ] of FastAccessibleObject c a l l e d with s i z e 40 




32 new [ ] of NonVolatileObject c a l l e d with s i z e 52 





37 d e l e t e o f FastAccessibleObject c a l l e d 




Die einzige wirkliche Besonderheit beim Anlegen von Arrays, die im Output 

augenfällig wird, ist die angeforderte Größe des Speicherblocks: In unserem 

Fall ist der angeforderte Speicherblock für ein Array nämlich in beiden Fällen 

um 4 Bytes größer als erwartet! Man sieht z.B., dass für ein MyFastObject 

12 Bytes angefordert werden, für 3 Objekte dieses Typs allerdings mitnichten 

36 Bytes, sondern 40! Ganz gleich verhält es sich bei MyNonVolatileObject. 

Das ist darauf zurückzuführen, dass im angeforderten Block auch administrative 

Daten abgelegt werden, die allerdings für die verschiedenen Systeme 

weder in ihrer Größe noch in ihrem Inhalt standardisiert und daher den Entwicklern 

nicht explizit zugänglich sind. 

Bewusst wurde in das Programm in den Zeilen 286–293 zu Demonstrationszwecken 

auch eine absolute Katastrophe eingebaut, die furchtbare Folgen 

hat. Es werden dort nämlich Arrays mittels new[] angelegt. Diese werden 

allerdings schlimmerweise nicht korrekt mit delete[], sondern nur mit 

delete wieder freigegeben. Das wahre Ausmaß dieses Harakiri-Konstrukts 

wird deutlich, wenn man sich die Zeilen 27–39 des Outputs ansieht: Es werden 

die beiden Arrays ordnungsgemäß angelegt, allerdings passiert beim Freigeben 

Grauenvolles: Erstens werden nicht alle Objekte ordnungsgemäß destruiert, 

sondern immer nur eines von dreien! Zweitens wird der falsche Operator


aufgerufen, der sich z.B. auf einen anderen Speicherbereich beziehen könnte – 

mit entsprechend fatalen Folgen. Wie lang man suchen kann, bis man einen 

solchen Fehler in einem verrückt gewordenen Programm findet, kann man 

sich leicht ausmalen. 

12.3.3 Placement Operator new 

Neben den beiden new Operatoren für individuelle Objekte und für Arrays 

gibt es noch einen dritten, den sogenannten Placement Operator new(). Bei 

diesem übergibt man noch zusätzlich als zweiten Parameter einen Pointer, 

der einen Hinweis darauf gibt, wo der Speicher allokiert werden soll. 

Nehmen wir am besten eine kleine Änderung an unserem Beispiel vor, 

um zu sehen, was dieser Operator bietet und wie man mit ihm umgeht 

(third_new_delete_overloading_demo.cpp). Die erste Änderung betrifft 

den MemoryProvider: Anstatt nur statische Methoden zur Verfügung zu stellen, 

muss man nun eine Instanz erzeugen. Die Verwendung ist so gedacht, 

dass man für jeden spezifischen Teil des Memories eine eigene Instanz hat. 

Bei uns also eine für den schnellen und eine für den nicht flüchtigen Teil des 

Memories. Die umgeschriebene Klasse liest sich dann so: 

24 class MemoryProvider 

25 { 

26 public : 

27 // u s u a l l y the constructor has a parameter f o r the s t a r t 

28 // address of the managed pool , the s i z e , etc . . . but f o r 

29 // demo purposes I don ’ t want to write a ” r e a l ” memory 

30 // management c l a s s . So i t ’ s j u s t a dummy . . . 

31 MemoryProvider ( ) { } ; 

32 

33 void ∗ allocMemBlock ( s i z e t s i z e ) 


35 

36 void freeMemBlock ( void ∗ base ptr ) 

37 throw ( ) ; 

38 } ; 

Die Implementationen der beiden Methoden zum Allokieren und Freigeben 

sind in unserem Demoprogramm wieder reine Dummies, die mit malloc und 

free geschrieben sind. Deshalb erspare ich mir das Abdrucken derselben an 

dieser Stelle. 

Anstatt zwei verschiedene Klassen, eine für das schnelle und eine für das 

langsame Memory zu haben, brauchen wir hier nur noch eine einzige Klasse, 

denn beim Aufruf von new wird jetzt ein Pointer auf die gewünschte Instanz 

des Memory Managers mitgegeben. Also haben wir es hier mit der Klasse 

SpecialMemoryManagedObject zu tun: 

49 class SpecialMemoryManagedObject 

50 { 

51 private : 

52 // f o r b i d standard i n s t a n t i a t i o n


54 throw( b a d a l l o c ) { return ( ( void ∗ ) 0 ) ; } 

55 


56 // f o r b i d array i n s t a n t i a t i o n 



59 public : 

60 void ∗ operator new( s i z e t s i z e , MemoryProvider ∗ mem provider ) 


62 

63 static void destroy ( SpecialMemoryManagedObject ∗ obj , 

64 MemoryProvider ∗ mem provider ) 

65 throw ( ) ; 

66 

67 SpecialMemoryManagedObject ( ) { } 

68 

69 virtual ˜ SpecialMemoryManagedObject ( ) { } 

70 } ; 

In dieser Klasse wurden bewusst die Standard-Operatoren new und new[] 

als private deklariert, um ihre Verwendung zu verhindern. Dafür gibt es 

jetzt den speziellen Placement Operator new(), dessen Deklaration man in 

den Zeilen 60–61 sieht. Wenn man schon mit Placement arbeitet, so sollte 

man (je nach Anwendung) auch das Standard delete nicht mehr verwenden. 

Deshalb wurde eine static Methode destroy eingeführt, die diese Aufgabe 

übernimmt. Diese sieht man in den Zeilen 63–65. 

Die Implementation des Placement Operators birgt auch keine Überraschungen. 

Es wird einfach der Speicher vom mitübergebenen Provider angefordert, 

wie man in der Folge sieht: 

105 void ∗ SpecialMemoryManagedObject : : operator new( 

106 s i z e t s i z e , MemoryProvider ∗ mem provider ) 


108 { 

109 cout


120 throw( ) 

121 { 

122 cout

93 

94 virtual ˜MyMemManagedObject( ) 

95 { 

96 cout


Was sind nun die Vor- und Nachteile dieser Art der Speicherverwaltung mittels 

Placement Operator? 

• Der große Vorteil liegt darin, dass man nicht zur Compiletime durch 

entsprechende Ableitung festlegen muss, wo ein Objekt genau zu liegen 

kommt. Stattdessen kann man dies zur Laufzeit bestimmen. Vor allem 

für die Implementation von bestimmten Container-Objekten ist dies ein 

essentielles Feature. 

• Der erste Nachteil ist das Fehlen eines speziellen Placement Operators für 

Arrays. Im Prinzip kann man diesen Nachteil bis zu einem gewissen Grad 

umgehen, denn man kann ja einfach “genügend” Platz für ein Array anfordern 

und den Rest irgendwie intern verwalten. Allerdings ist das dann 

wirklich nicht mehr sehr sauber und v.a. für Entwickler sehr ungewohnt, 

denn sie können nun nicht mehr einfach ein Array anlegen, sondern müssen 

explizit zur Selbsthilfe greifen. Deshalb würde ich wirklich empfehlen, die 

Placement-Konstruktion niemals zu verwenden, wenn man Arrays brauchen 

könnte, um keine Zeitbomben zu basteln. 

• Der zweite Nachteil ist das Fehlen eines speziellen Placement delete() 

Operators als Gegenstück zum Placement new() Operator. Dadurch ist 

man nämlich gezwungen, sich selbst zu merken, wo ein Objekt angelegt 

wurde, um dies auch durch einen entsprechenden destroy Aufruf wieder 

ordnungsgemäß freizugeben. Was passieren kann, wenn man dem falschen 

aus einer Menge von Pools sagt, dass er ein Objekt freigeben soll, kann 

man sich ja denken. 

• Der dritte Nachteil ist, dass man das in diesem Fall zumeist verbotene 

delete nicht wirklich als private deklarieren kann und damit gesichert 

dessen Aufruf verhindern kann. Ein solcher Versuch wird nämlich im Normalfall 

mit einer Warning des Compilers quittiert. 

Obwohl ich ein sehr entschiedener Gegner von schmutzigen Tricks bin, möchte 

ich trotzdem hier eine abgewandelte Implementation unseres Beispiels vorstellen, 

die zumindest die leidigen delete Probleme ausschließt. Allerdings 

möchte ich gleich vorausschicken, dass das delete Problem durch einen wirklich 

sehr schmutzigen Trick eliminiert wurde, der selbst wieder eine Zeitbombe 

darstellen kann. Warum ich die Lösung trotzdem vorstelle hat einen einfachen 

Grund: Die hier eingebaute Zeitbombe existiert genau an einer Stelle im 

Programm und sie ist auf jeder Plattform für sich testbar. Funktioniert alles 

wie geplant, ist es o.k., wenn nicht, weiß man genau, wo man zu suchen hat. 

Die Zeitbombe, die entsteht, wenn man destroy falsch anwendet, verteilt 

sich wunderhübsch im gesamten Programm, ist also bei weitem gefährlicher. 

Die erste Änderung im Programm betrifft unsere Basisklasse für die selbst 

verwalteten Objekte. Diese wurde um eine Variable mem_provider_ und um 

den Operator delete ergänzt. Auch wurde konsequenterweise der delete[] 

Operator verboten. Außerdem wurde plangemäß die Methode destroy eliminiert:

49 class SpecialMemoryManagedObject 

50 { 

51 private : 

52 // f o r b i d standard i n s t a n t i a t i o n 



55 

56 // f o r b i d array i n s t a n t i a t i o n 



59 

60 // as a consequence a l s o f o r b i d array d e l e t i o n 


62 throw( ) { } 

63 


65 MemoryProvider ∗ mem provider ; 

66 


67 public : 

68 void ∗ operator new( s i z e t s i z e , MemoryProvider ∗ mem provider ) 


70 


72 throw ( ) ; 

73 

74 SpecialMemoryManagedObject ( ) { } 

75 

76 virtual ˜ SpecialMemoryManagedObject ( ) { } 

77 } ; 

Die Variable mem_provider_ dient dazu, sich intern zu merken, von welchem 

Provider der Speicherblock angefordert wurde. Damit braucht sich die verwendende 

Applikation nicht mehr selbst bei der Freigabe darum zu kümmern. 

Die Implementation von new() wurde entsprechend abgeändert. Sie sorgt 

jetzt dafür, dass der übergebene Placement Parameter auch im erzeugten 

Objekt gespeichert wird: 

112 void ∗ SpecialMemoryManagedObject : : operator new( 

113 s i z e t s i z e , MemoryProvider ∗ mem provider ) 


115 { 

116 cout


Sollte also nun jemand auf die fatale Idee kommen, im Konstruktor dieses 

Objekts die Variable mem_provider_ initialisieren zu wollen, dann geht Gewaltiges 

schief. Allerdings muss man sagen, dass alle Entwickler, die sich 

an einer existenten Klasse zur Speicherverwaltung vergreifen wollen, wirklich 

genau wissen müssen, was sie tun. Ansonsten sollten sie sowieso gefälligst 

die Finger davon lassen. Insofern ist die Gefahr (hoffentlich) nur noch halb 

so groß :-). 

Der zweite Teil des schmutzigen Tricks findet sich im delete Operator 

wieder: 

128 void SpecialMemoryManagedObject : : operator delete ( void ∗ base ptr ) 

129 throw( ) 

130 { 

131 cout 

135 mem provider ; 

136 cout

180 delete n o n v o l a t i l e o b j ; 

181 

182 return ( 0 ) ; 

183 } 


Der Beweis, dass dieses Meisterwerk trotz aller schmutzigen Tricks auch wirklich 

funktioniert, findet sich im folgenden Output. Man sieht deutlich, dass 

für die beiden Objekte, die von verschiedenen Providern erzeugt wurden, 

auch dieselben Provider zum Freigeben wieder angesprochen werden. Um 

bösen Zungen zuvorzukommen: Ich verspreche, dass dieser Output kein Fake 

ist :-). 

c r e a t i n g object in f a s t memory . . . 

new o f SpecialMemoryManagedObject c a l l e d , s i z e : 1 6 

provider : 0 x804a6d0 

constructor of MyMemManagedObject 

c r e a t i n g object in non v o l a t i l e memory . . . 

new o f SpecialMemoryManagedObject c a l l e d , s i z e : 1 6 

provider : 0 x804a6e0 

constructor of MyMemManagedObject 

d e l e t i n g o bject from f a s t memory . . . 

d e s t r u c t o r of MyMemManagedObject 

d e l e t e o f SpecialMemoryManagedObject c a l l e d , provider : 0 x804a6d0 

d e l e t i n g o bject from non v o l a t i l e memory . . . 

d e s t r u c t o r of MyMemManagedObject 

d e l e t e o f SpecialMemoryManagedObject c a l l e d , provider : 0 x804a6e0 

12.3.4 delete mit zwei Parametern 

Bisher haben wir delete so kennen gelernt, dass einfach der Base-Pointer 

des freizugebenden Blocks als Parameter übergeben wurde. Für unsere 

Fälle war das auch kein Problem, denn wir haben immer nur eine Dummy- 

Speicherverwaltung verwendet, anstatt uns wirklich um den Speicher selbst 

zu kümmern. Schreibt man aber tatsächlich selbst eine Speicherverwaltung, 

so hat man zwei Möglichkeiten: 

1. Man merkt sich zu jedem angeforderten Block intern selbst die Größe, 

die angefordert wurde. Damit braucht man beim Freigeben keine weitere 

Information als den Base-Pointer, um den Rest erledigen zu können, denn 

man weiß ja über den Block genau Bescheid. 

2. Man verlässt sich auf das System und fordert, dass man beim Freigeben 

gefälligst mitgeteilt bekommt, wie groß denn der Block ist, den man 

freigeben soll. 

Vorausschicken möchte ich, dass die erste Methode immer die Methode der 

Wahl sein sollte, denn diese ist die sichere Variante (es wird weiter unten 

noch besprochen, warum). Im Normalfall werden auch alle Memory 

Verwaltungen nach dieser ersten Methode implementiert. In den seltenen 

Ausnahmefällen, in denen man dies, aus welchen Gründen auch immer, 

nicht tun will und das Merken der Blockgröße dem System überlässt,


hilft ein spezieller delete Operator, der zwei Parameter übergeben bekommt, 

nämlich den Base-Pointer und die Größe. Im folgenden Beispiel 

(fifth_new_delete_overloading_demo.cpp) wurde eine Abwandlung unsere 

selbstverwalteten Objekte implementiert. Wiederum gibt es eine Basisklasse, 

die entsprechende new, new[], delete und delete[] Operatoren 

implementiert. Die Deklaration sieht folgendermaßen aus: 

23 class MemoryManagedObject 

24 { 

25 public : 



28 



31 

32 void operator delete ( void ∗ base ptr , s i z e t s i z e ) 

33 throw ( ) ; 

34 

35 void operator delete [ ] ( void ∗ base ptr , s i z e t s i z e ) 

36 throw ( ) ; 

37 

38 virtual ˜ MemoryManagedObject ( ) { } 

39 } ; 

Bei den beiden delete Operatoren ist nun jeweils ein zweiter Parameter 

dabei, der Auskunft über die Größe des freizugebenden Blocks gibt. Die Implementation 

der Operatoren in unserem Beispiel birgt nichts wirklich Neues 

und liest sich so: 

70 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

71 /∗ 

72 ∗/ 

73 void ∗ MemoryManagedObject : : operator new( s i z e t s i z e ) 


75 { 

76 cout


99 cout


130 

131 cout


Blocks übergeben wird. Niemand hindert uns daran, aus internen Gründen 

ein wenig mehr Speicher für einen Block zu allokieren. Davon weiß allerdings 

der Compiler nichts, wie sollte er auch? Das bedeutet aber, dass der bei 

delete bzw. delete[] übergebene Größenparameter wieder nur dem geforderten 

Mindestwert entspricht, anstatt unsere tatsächlich allokierte Größe zu 

reflektieren! Wie man sich leicht vorstellen kann, erzeugt man durch dieses 

Verhalten wunderbar tief fliegende Programme, die einem viele angenehme 

Nächte der Fehlersuche bescheren :-). 

12.3.5 Globale new und delete Operatoren 

Bisher haben wir uns nur damit beschäftigt, wie man auf Klassenbasis die 

Speicherverwaltung beeinflussen kann. Was aber, wenn man wirklich die 

komplette Speicherverwaltung in einem Programm auf einen Schlag austauschen 

will? Auch daran wurde in C ++ gedacht und aus diesem Grund gibt es 

die Operatoren auch in globaler Variante, also quasi als Funktionen anstatt 

als Members. 

Wie man im folgenden Beispiel sieht, funktionieren die globalen Operatoren 

im Prinzip ganz gleich wie die Members, die nur für einzelne Klassen 

gelten (global_new_delete_overloading.cpp). Die globalen Operatoren 

lesen sich erwartungsgemäß so: 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗/ 



19 { 

20 cout


46 /∗ 

47 ∗/ 


49 throw( ) 

50 { 

51 cout

101 throw ( ) ; 

102 


104 throw ( ) ; 

105 


106 MemoryManagedObject ( ) 

107 { 

108 cout


208 cout


bedeutet, dass wir durch Overloading der globalen Operatoren ausschließlich 

die Verwaltung des Speichers für Objekte übernehmen können, deren Klassen 

selbst noch keine besondere Speicherverwaltung implementieren. 

Vorsicht Falle: Da die globalen Operatoren nur dann herangezogen werden, 

wenn eine Klasse nicht bereits selbst die entsprechenden new und delete 

Operatoren implementiert, hat das Austauschen der Speicherverwaltung für 

ein gesamtes Programm nach dieser Methode mit äußerster Umsicht zu geschehen. 

Sonst kann es leicht zu sehr unangenehmen Interferenzen kommen, 

sollten die Prinzipien der beiden Speicherverwaltungsalgorithmen nicht kompatibel 

zueinander sein! 

Besonders bösartig wird dieser Fehler, wenn z.B. eine Klasse, aus welchen 

Gründen auch immer, nur die new Operatoren implementiert, aber delete 

dem System überlässt. Dann passiert nämlich der Fall, dass das klasseninterne 

new und als Gegenstück dazu das globale delete aufgerufen wird. 

Plötzlich bekommt also das globale delete einen Block zur Freigabe, den 

es selbst gar nicht bereitgestellt hat! Je nachdem, welcher Algorithmus für 

die globale Speicherverwaltung implementiert wurde, kann dies dazu führen, 

dass sich die Entwickler des Programms mit erheblichen Tiefflugversuchen 

desselben konfrontiert sehen, die sie sich beim besten Willen nicht erklären 

können. 

Daher möchte ich hier ganz eindringlich einen Ratschlag anbringen: 

Wenn man eine individuelle Speicherverwaltung für eine Klasse 

schreibt, dann müssen unbedingt immer die Operatoren paarweise 

implementiert werden. Niemals darf ein new ohne zugehöriges 

delete implementiert werden oder umgekehrt! 

Je nachdem, was man mit individueller Speicherverwaltung in Klassen 

bezweckt, kann man vorausschauend genug arbeiten, um dieses Problem zumindest 

in einigen Fällen gar nicht erst aufkommen zu lassen. Nehmen wir 

an, die new und delete Operatoren wurden deshalb in einer Klasse individuell 

implementiert, weil zusätzlich zum Beschaffen und Freigeben von Speicher 

noch etwas anderes stattfinden soll (z.B. inkrementieren bzw. dekrementieren 

eines Reference Counters). Wo der Speicher herkommt, ist allerdings den 

Operatoren egal, sie würden sowieso einfach nur malloc und free verwenden. 

Für diesen Fall kann man den zuvor erwähnten Stolperstein umgehen, 

indem man nicht malloc und free aufruft, sondern stattdessen, mittels 

Scope-Operator, die globalen Operatoren new und delete bzw. new[] und 

delete[]. Solange diese nicht von uns besonders implementiert sind, werden 

automatisch die systeminternen Operatoren herangezogen, sonst unsere 

besonderen Varianten. Schreiben wir also unsere Implementation der Operatoren 

für das MemoryManagedObject den neuen Erkenntnissen entsprechend 

um (global_new_delete_overloading_version2.cpp):


146 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

147 /∗ 

148 ∗/ 

149 void ∗ MemoryManagedObject : : operator new( s i z e t s i z e ) 


151 { 

152 cout


d e s t r u c t o r of SimpleObject 

d e s t r u c t o r of SimpleObject 

g l o b a l d e l e t e [ ] c a l l e d with base : 0 x804b2f0 

c r e a t i n g MyMemoryManagedObject 

new o f MemoryManagedObject c a l l e d with s i z e 12 

g l o b a l new c a l l e d with s i z e 12 

constructor of MemoryManagedObject 

constructor of MyMemoryManagedObject 

d e l e t i n g MyMemoryManagedObject . . . 

d e s t r u c t o r of MyMemoryManagedObject 

d e s t r u c t o r of MemoryManagedObject 

d e l e t e o f MemoryManagedObject c a l l e d with base : 0 x804b2f0 

g l o b a l d e l e t e c a l l e d with base : 0 x804b2f0 

c r e a t i n g MyMemoryManagedObject array . . . 

new [ ] of MemoryManagedObject c a l l e d with s i z e 40 

g l o b a l new [ ] c a l l e d with s i z e 40 







d e l e t i n g MyMemoryManagedObject array . . . 







d e l e t e [ ] of MemoryManagedObject c a l l e d with base : 0 x804b2f0 

g l o b a l d e l e t e [ ] c a l l e d with base : 0 x804b2f0 

12.3.6 Weitere Aspekte der eigenen Speicherverwaltung 

Um die Abhandlung über die handgestrickte Speicherverwaltung abzurunden, 

möchte ich hier noch kurz auf ein paar kleine Aspekte eingehen, die in der 

Praxis Relevanz besitzen. 

Vererbung von new und delete. Es ist natürlich nicht nur möglich, die 

new und delete Operatoren einfach einmal mittels Overloading für individuelle 

Klassen zu implementieren und diese Implementation zu vererben. Auch 

hier gelten die üblichen Regeln für das Overriding. Sollte man also von einer 

Basisklasse ableiten, die individuelle Speicherverwaltung macht, und sollte 

man weiters mit diesem Verhalten nicht zufrieden sein, so kann man in der 

Ableitung selbst ein Overriding vornehmen und damit die Operatoren aus 

der Basisklasse außer Kraft setzen. Im folgenden Beispiel ist dies kurz demonstriert 

(new_delete_overriding.cpp): 

1 // n e w d e l e t e o v e r r i d i n g . cpp − a demo f o r o v e r r i d i n g 

2 // i n d i v i d u a l new and d e l e t e operators in s u b c l a s s e s 

3 




7 #include < c s t d l i b> 


9





13 

14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

16 /∗ 

17 ∗ MemoryManagedObject 

18 ∗ 

19 ∗ j u s t an o bject with i t s own memory management 

20 ∗ 

21 ∗/ 

22 


24 { 

25 public : 



28 { 

29 cout

76 ∗/ 

77 


78 class MyMemoryManagedObject : public MemoryManagedObject 

79 { 


81 int32 some data ; 

82 uint32 some other data ; 

83 public : 



86 { 

87 cout


Das MemoryManagedObject hat sich bis auf den Umbau zu inline Methoden 

in Bezug auf den bereits bekannten Vorgänger nicht verändert. Sehr 

wohl aber ist MyMemoryManagedObject ein wenig mutiert: Es sind jetzt in 

dieser Klasse die Operatoren new und delete für individuelle Objekte overridden. 

Die entsprechenden Array-Operatoren wurden beim Alten belassen. 

Der Output des Programms zeigt auch gleich, dass dieser Umbau den erwarteten 

Effekt hat: 

c r e a t i n g MyMemoryManagedObject 

overridden new ! ! ! ! ! s i z e = 12 



d e l e t i n g MyMemoryManagedObject . . . 



overridden d e l e t e ! ! ! ! ! base = 0 x804ab68 

c r e a t i n g MyMemoryManagedObject array . . . 

new [ ] of MemoryManagedObject c a l l e d with s i z e 40 







d e l e t i n g MyMemoryManagedObject array . . . 







d e l e t e [ ] of MemoryManagedObject c a l l e d with base : 0 x804ab68 

Dass natürlich beim Overriding auch wieder äußerste Vorsicht geboten ist, um 

nicht die Speicherverwaltung des Originals völlig durcheinander zu bringen, 

versteht sich von selbst. 

Manchmal gibt es auch Fälle, in denen es absolut nicht erwünscht ist, 

dass eine abgeleitete Klasse die Operatoren new und delete erbt, da sie 

aus irgendwelchen Gründen sehr speziell implementiert sind und nur für die 

Basisklasse korrekt funktionieren würden. In solchen Fällen wird oft folgende 

Implementation gewählt (new_and_delete_only_for_base.cpp): 

1 // n e w a n d d e l e t e o n l y f o r b a s e . cpp − a demo , how to implement 

2 // new and d e l e t e in a way that they do not i n f l u e n c e memory 

3 // management of derived c l a s s e s 

4 






10 




14 

15 

16 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

17 /∗


18 ∗ MemoryManagedObject 

19 ∗ 

20 ∗ an o bject with i t s own memory management which checks f o r 

21 ∗ i n h e r i t a n c e s i t u a t i o n s 

22 ∗ 

23 ∗/ 

24 


26 { 

27 public : 



30 { 

31 cout


84 } ; 

85 

86 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

87 /∗ 

88 ∗/ 


90 { 

91 cout


Wenn in der Ableitung Member-Variablen definiert werden, dann ist es 

beinahe sicher, dass sich die Größe der Ableitung im Vergleich zur Basis 

ändert. Jedoch kann man es aus verschiedenen compilerinternen Gründen 

heraus auch nicht wirklich garantieren. 

Im Sinne einer robusten Entwicklung kann ich daher nur sagen, dass Probleme 

wie dieses per Konvention und nicht über einen Trick gelöst werden 

sollten. Nur dann bewegt man sich immer auf der sicheren Seite. 

Verhalten bei “Ausgehen” des Speichers. In Abschnitt 12.3.1 wurde 

bereits darauf hingewiesen, dass erstens malloc keine Exception wirft, falls 

nicht mehr genügend Speicher vorhanden ist, sondern einen 0-Pointer liefert. 

Zweitens dürfen selbstdefinierte new Operatoren auch nicht einfach blindlings 

eine bad_alloc Exception werfen, sondern müssen per Konvention dem 

Entwickler zuvor noch eine besondere Chance geben. Diese Chance ist der 

besondere new_handler. 

Sehen wir uns das ganze Spielchen einmal aus Sicht der Applikationsentwickler 

an, die mit speziellen Implementationen von new und delete nichts 

am Hut haben. Eine Applikation hat per Konvention in C ++ die Möglichkeit, 

eine Funktion set_new_handler aufzurufen, die als Parameter einen Funktionspointer 

nimmt, der auf eine Funktion zeigt, die keine Parameter nimmt 

und keinen return-Value liefert. Dieser spezielle Handler kann z.B. dafür sorgen, 

dass auf irgendeinem Weg Speicher freigemacht wird oder er kann auch 

einfach eine bad_alloc Exception werfen, wenn er keine Chance mehr sieht. 

Im Prinzip muss er sogar eine bad_alloc Exception werfen, wenn es keine 

weitere Chance mehr gibt, denn sonst kommt es zu einer Endlosschleife, 

doch dazu später. Sehen wir uns dazu kurz ein Beispielprogrämmchen an 

(first_new_handler_demo.cpp): 

1 // first new handler demo . cpp − a demo f o r s e t t i n g a new handler 

2 // from within an a p p l i c a t i o n 

3 






9 





14 using std : : set new handler ; 

15 

16 int32 ∗ dummy memory consumer ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 /∗ 

20 ∗/ 

21 void memoryExhaustedHook ( ) 


23 { 

24 c e r r


25 i f ( dummy memory consumer ) // there i s something to get r i d o f 

26 { 

27 delete [ ] dummy memory consumer ; 

28 dummy memory consumer = 0; 

29 c e r r try again ” b a d a l l o c 

Per Definition liefert die Funktion set_new_handler den zuletzt aktiven 

Handler. Je nach Applikation sollte man sich diesen merken und wieder einsetzen, 

wenn man seinen eigenen Handler nicht mehr im Programm haben 

will. 

Nachdem wir jetzt das erwartete Verhalten bei Speicherknappheit kennen, 

wissen wir endlich auch, wie sich ein eigener new Operator korrekt zu verhalten 

hat, um dieser Konvention zu entsprechen. Zur Demonstration habe 

ich das obige Beispiel um eine korrekt funktionierende Definition eines globalen 

new[] Operators erweitert (correct_new_operator_demo.cpp). Bis 

auf den neu hinzugekommenen new[] Operator hat sich das Programm nicht 

verändert, also möchte ich auch nur diesen hier abdrucken: 



25 { 

26 cout


32 // i s the standard place , where i t i s stored . However , 

33 // t h i s i s C++−Compiler Implementation dependent and may 

34 // not work . Therefore there i s a more portable 

35 // t r i c k to obtain the new handler : 

36 new handler i n s t a l l e d h a n d l e r = set new handler ( 0 ) ; 

37 set new handler ( i n s t a l l e d h a n d l e r ) ; 

38 

39 i f ( ! i n s t a l l e d h a n d l e r ) 

40 throw b a d a l l o c ( ) ; // no handler i n s t a l l e d , sorry . . . 

41 i n s t a l l e d h a n d l e r ( ) ; // handler e x i s t s − there i s hope :−) 

42 } 

43 } 

Man sieht hier ganz deutlich, warum ich zuvor gemeint habe, dass ein eigener 

Handler unbedingt eine bad_alloc Exception werfen muss, wenn er 

beschließt, dass gar nichts mehr geht: solange er dies nämlich nicht tut, signalisiert 

er, dass es möglich wäre, dass er vielleicht doch noch irgendwo ein 

wenig Speicher auftreiben kann. Es ist also durchaus legitim, dass ein solcher 

Handler nicht auf einen Schlag einen riesigen Brocken Memory frei macht. 

Stattdessen kann er bei jedem Aufruf ein wenig mehr Speicher frei machen, 

bis new endlich zufrieden ist. Deshalb läuft die Speicherbeschaffung auch in 

einer Endlosschleife, wie man in den Zeilen 27–42 sehen kann. Diese wird nur 

dadurch beendet, dass entweder genug Speicher da ist oder eine Exception 

das Gemetzel beendet. 

In den Zeilen 36–37 wird ganz bewusst ein kleiner Trick implementiert, 

um zum entsprechenden Handler zu kommen: Im Normalfall ist der Handler 

in der globalen Variable _new_handler gespeichert. Allerdings sind Variablen, 

die mit einem Underline beginnen, per Konvention besondere Systemvariablen, 

die von Applikationsentwicklern gefälligst nicht verwendet werden 

sollen. Nebenbei haben solche Variablen auch die nicht gerade verwunderliche 

Eigenschaft, ohne vorherige Ankündigung ihren Namen oder Platz zu 

ändern. Alles das führt zu einer nicht besonders portablen Implementation. 

Wir wissen aber, dass die Funktion set_new_handler als return-Value den 

zuvor installierten Handler liefert. Genau diese Eigenschaft nützen wir hier 

aus, indem wir einen neuen Handler installieren (einfach einen 0-Handler). 

Dadurch bekommen wir den tatsächlich installierten, den wir gleich in Zeile 

37 wieder einsetzen, damit alles beim Alten bleibt. Und schon haben wir 

durch diesen kleinen Trick unser Programm viel portabler gemacht, als es 

sonst der Fall wäre :-). 

Der Output des Programms zeigt, dass diese Implementation genau das 

tut, was wir von ihr erwarten. Je nach Rechner fällt die Anzahl der Zeilen, 

die vor dem ersten Fehlschlag von malloc ausgegeben wird ziemlich lang aus. 

Aufgrund der Wertlosigkeit und der gleichzeitigen hohen Anzahl dieser Zeilen 

wurde der Output entsprechend gekürzt :-). 



[ . . . l o t s o f equal l i n e s deleted . . . ] 

g l o b a l new [ ] c a l l e d with s i z e 400000


memoryExhaustedHook c a l l e d 

could f r e e some memory −> try again 



memoryExhaustedHook c a l l e d 

no more memory a v a i l a b l e −> b a d a l l o c 

12.4 Abschließendes zu overloadable Operators 

Nachdem nun Operator Overloading im Allgemeinen und Spezialitäten sowie 

Tücken der Typumwandlungs-Operatoren und der Speicherverwaltung mittels 

new und delete im Speziellen besprochen wurden, möchte ich an dieser 

Stelle noch schnell ein paar abschließende Worte zu diesem Thema verlieren. 

Vor allem gehört erwähnt, dass nicht wirklich alle Operatoren, die in C ++ 

zur Verfügung stehen (siehe Tafel 3.1), auch wirklich selbst definiert werden 

können. 

Die wenigen Ausnahmen hierbei bilden der Scope-Operator (::), der 

Member-Zugriffsoperator (.) und der Member-Zugriff über das Dereferenzieren 

eines Pointers auf einen Member (.*). 

Um Missverständnisse zu vermeiden: Den Pfeil-Operator (->) kann man 

sehr wohl selbst definieren. Diese Möglichkeit kann man sehr gut zum 

Einführen einer automatischen Indirektion auf ein anderes Objekt gebrauchen, 

wie es für verschiedene Konzepte der Delegation notwendig ist. Eine 

allzu genaue Abhandlung zu solchen Themen gehört allerdings in die weiterführende 

Literatur und würde den Rahmen dieses Buchs sprengen. Da 

jedoch ein Overloading des -> Operators ein Verhalten zeigt, das für Neulinge 

nicht auf den ersten Blick einsichtig ist, möchte ich hierzu noch ein kurzes 

Beispiel besprechen (member_access_overloading_demo.cpp): 

1 // member access overloading demo . cpp − short demo f o r 

2 // overloading of the −> operator 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ 

12 ∗ MyObject 

13 ∗ 

14 ∗ Just a dummy c l a s s 

15 ∗ 

16 ∗/ 

17 

18 class MyObject 

19 { 


21 uint32 value ; 

22 public : 

23 MyObject ( uint32 value )

24 throw ( ) { value = value ; } 

25 

26 virtual ˜ MyObject ( ) 

27 throw( ) { } 

28 

29 virtual uint32 getValue ( ) 

30 { 

31 cout


Interessant ist jetzt nur, was hier intern passiert. Es ist nämlich -> ein unärer 

Operator, wie in Zeile 58 zu erkennen ist. Dieser Operator liefert allerdings 

wirklich einen Pointer auf das gewünschte Objekt. So weit, so gut, bloß damit 

ist doch eigentlich -> bereits abgearbeitet, also quasi “aufgebraucht”. Wieso 

kommt es dann tatsächlich zu einem Aufruf von getValue? Das liegt daran, 

dass C ++ diesen Operator zweistufig behandelt: 

1. Zuerst wird unser definierter Operator aufgerufen. 

2. Auf dem return-Value wird dann der “echte” Memberzugriff gemäß -> 

durchgeführt. 

Der Ausdruck obj_ptr->getValue() wird also vom Compiler so behandelt, 

als ob hier 

(obj_ptr.operator->())->getValue() 

stünde. Dieses Verhalten ist auch das einzig sinnvolle, denn ansonsten würde 

ein Overloading keinen Wert haben. Ein Objekt kann nur durch diese Behandlung 

des Operators nach außen hin so tun, als ob es ein Pointer auf ein 

anderes Objekt wäre. 

Vorsicht Falle: Drei Operatoren gibt es, bei denen ich allen Lesern den 

guten Tipp geben möchte, die Finger von einem Overloading zu lassen, außer 

es geht gar nicht anders. Dies ist einerseits der , (=Komma) Operator, 

andererseits && und ||. Das Problem dabei ist, dass hier nicht mehr gesagt 

ist, ob standardmäßig eine short Evaluation des Ausdrucks stattfindet. Der 

Compiler kann sehr wohl entscheiden, dass hier auf jeden Fall den selbstgebastelten 

Operator aufruft, weil er diesem ja nicht ins Handwerk pfuschen 

will. Das kann alle möglichen Probleme, vom einfachen Performancemord 

bis hin zur Segmentation Violation in gewissen Situationen nach sich ziehen. 

Sollte man also wirklich diese Operatoren selbst definieren wollen, so muss 

man auf allen verwendeten Plattformen testen, welche Art der Evaluierung 

vom Compiler herangezogen wird und entsprechend darauf reagieren. 

Vorsicht Falle: Neben den bereits erwähnten Fallen gibt es noch eine ganz 

besondere, in die vor allem Neulinge tappen, wenn sie beginnen, sich beim 

Operator Overloading wohl zu fühlen: Die übertriebene und damit oft nicht 

mehr intuitive Anwendung des Operator Overloadings! 

Operatoren sind nur dann eine Hilfe für Entwickler, wenn sie intuitiv sind. 

Zum Beispiel ist ein + Operator vollkommen intuitiv, wenn er zur Addition 

von z.B. Vektoren oder Matrizen definiert ist. Auch zum aneinander Reihen 

von Strings (=concatenation) ist dessen Einsatz noch sinnvoll. Gar nicht 

mehr intuitiv ist dieser Operator, wenn er z.B. für ein Objekt Auto als Gas 

geben definiert wird und vielleicht auch dann noch der Operator - als bremsen 

dazukommt. Klar wird man nach Lektüre der Dokumentation wissen, dass 

diese Operatoren so verwendet werden, aber trotzdem ist in diesem Fall die 

Implementation über Methoden bei weitem intuitiver und leichter lesbar.

12.4 Abschließendes zu overloadable Operators 403 

Mir ist schon bewusst, dass die Grenze zwischen sinnvoller und schlechter 

Anwendung fließend ist. Es ist aber garantiert besser, im Fall des geringsten 

Zweifels an der Intuitivität eines Operators, diesen nicht zu definieren, 

sondern stattdessen eine entsprechende Methode zu implementieren.

13. Templates 

Bevor wir überhaupt in das Thema der Templates eintauchen möchte ich hier 

aus gutem Grund etwas vorausschicken: Templates sind eines der mächtigsten 

Konzepte von C ++. Gleichzeitig sind sie auch eines der am schwierigsten zu 

begreifenden Konzepte, vor allem für Leute, die sich noch nicht so gut in 

C ++ oder in der Softwareentwicklung im Allgemeinen auskennen. Folgende 

Steigerung der Schwierigkeitsgrade ist in der Diskussion der Templates in der 

Folge zu finden 

• Abschnitt 13.1 ist sehr leicht zu verdauen. 

• Abschnitt 13.2 und Abschnitt 13.3 sind auch noch keine allzu schwere Kost 

und deshalb für Neulinge genießbar. 

• Bei Abschnitt 13.4 wird es schon etwas haariger und Abschnitt 13.5 würde 

ich als for Experts only bezeichnen. Meine Empfehlung ist daher, dass 

sich Einsteiger als Versuch noch an Abschnitt 13.4 versuchen sollten. Sollte 

es hierbei schon zu Verständnisproblemen kommen, kann man guten 

Gewissens dieses Kapitel auslassen und dessen Lektüre auf einen späteren 

Zeitpunkt verlegen, zu dem man dann schon mehr Erfahrung im Umgang 

mit C ++ hat. Keinesfalls würde ich Neulingen anraten, Abschnitt 13.5 zu 

lesen, denn ohne größere Erfahrung mit Templates in der Praxis ist er wirklich 

praktisch unverdaulich. Mit Erfahrung zu einem späteren Zeitpunkt 

ist dieser Abschnitt allerdings Goldes wert und dann ist der Augenblick 

gekommen, wo man dieses Buch noch einmal aufschlagen sollte. 

So, jetzt aber wirklich – die Templates wollen behandelt werden. 

Als sauberes und klares Abstraktionskonzept haben wir bisher das Konzept 

von Klassen kennen gelernt, das es erlaubt Daten, Operatoren und Methoden 

zu einem vollwertigen Typ zu vereinen. Nun gibt es aber Fälle, in denen selbst 

dies nicht genug ist und in denen wir am liebsten keine konkreten, sondern 

generische Datentypen zur Verfügung hätten. Was bedeutet das nun schon 

wieder? 

Wenden wir uns kurz einem Beispiel aus der Welt der immer wieder gebrauchten 

Utilities zu und betrachten wir einen Buffer: In einen solchen 

wollen wir nach dem FIFO (=First In First Out) Konzept im einfachsten 

Fall mittels einer Methode put Daten hineinstellen und mittels get diese in 

derselben Reihenfolge wieder herausholen. Welchen Typ diese Daten haben,

406 13. Templates 

ist für das generelle Konzept eines Buffers nicht wichtig, denn sein Verhalten 

ändert sich ja nicht, egal ob wir nun int Werte oder char Werte hineinstellen 

und wieder herausholen wollen. 

Nicht nur bei vollständigen Klassen findet man diese Fälle, in denen der 

Datentyp eigentlich für die Funktionalität nicht so wichtig ist, denselben Fall 

gibt es auch bei simplen Funktionen. Nehmen wir einfach nur an, dass es eine 

Funktion geben soll, die ein Array von Daten sortiert. Egal, welchen tollen 

Sortieralgorithmus diese Funktion nun implementiert, eines ist sicher: Solange 

der Datentyp, der in diesem Array gespeicherten Elemente die Operatoren 

>, und < (evtl. auch ==, je nach Algorithmus) und den Zuweisungsoperator 

= unterstützt, ist dieses sortierbar. 

Genau hier sind wir also beim Prinzip der generischen Programmierung 

gelandet: Wir schreiben eine Klasse oder auch einen Algorithmus, ohne in 

der Implementierung auf konkrete Datentypen einzugehen. Stattdessen parametrisieren 

wir unsere Implementierung bei deren Verwendung mit diesen 

Datentypen um vom generischen Fall zur konkreten Implementation zu kommen. 

Im Fall unseres Buffers von zuvor bedeutet das im Prinzip Folgendes: 

1. Wir schreiben eine generische Klasse Buffer, die so allgemein formuliert 

ist, dass ihr der Datentyp egal ist. 

2. Bei Verwendung dieser Klasse wird über einen konkreten Typ-Parameter 

(z.B. char) ihr Einsatzgebiet festgelegt. In diesem Fall hätten wir also 

einen Buffer, der nur mit Characters umgehen kann. 

Dasselbe passiert im Fall unserer Funktion zum Sortieren eines Arrays. Auch 

hier wird der Algorithmus implementiert, ohne auf den echten Typ der zu 

sortierenden Elemente Rücksicht zu nehmen. Im speziellen Fall kann diese 

Funktion dann entweder ein int32-Array, ein char-Array oder auch ein beliebiges 

Objekt-Array sortieren, wenn nur der Datentyp die entsprechenden 

Operatoren implementiert. 

In C ++ sind die sogenannten Templates der Mechanismus, der es erlaubt, 

generische Datentypen zu schreiben und diese dann durch Typ- 

Parametrisierung in konkreten Varianten zum Einsatz zu bringen. 

Vorsicht Falle: Um einigen Lesern komische Überraschungen zu ersparen 

möchte ich gleich eine wichtige Warnung vorwegnehmen: Nicht alle Compiler 

können mit allen in der Folge vorgestellten Template-Aspekten umgehen. Es 

kann also passieren, dass das eine oder andere Testprogrämmchen, das in der 

Folge vorgestellt wird, nicht compiliert. 

Üblicherweise ist es so, dass im Prinzip kein heutzutage verwendeter Compiler 

ein Problem mit Function Templates (siehe Abschnitt 13.1) und mit 

Class Templates (siehe Abschnitt 13.3) hat. So einige Compiler können allerdings 

gewisse Aspekte der Spezialisierung von Templates nicht (siehe Abschnitt 

13.5).

13.1 Function Templates 

13.1 Function Templates 407 

Um Lesern, die bisher noch keine Erfahrung mit generischer Programmierung 

sammeln konnten, einen sanften Einstieg zu bieten, wenden wir uns zuerst 

dem leichter genießbaren Thema der generischen Funktionen zu, die in C ++ 

auch als Function Templates bezeichnet werden. Ziehen wir zu Erklärungszwecken 

ein ganz einfaches Beispiel heran: Wir wollen eine Funktion implementieren, 

die als Parameter ein beliebiges Array nimmt und als return-Value 

den Index des wertmäßig größten Elements in diesem Array liefert. Sollte der 

Maximalwert nicht eindeutig bestimmbar sein, weil mehrere Elemente gleich 

groß sind, so wird der Index des ersten der möglichen Elemente geliefert. 

Das Template zu dieser Funktion, das der generischen Implementation 

entspricht, findet sich in find_max_template_function.h und sieht so aus: 

1 // find max template function . h − implementation o f a template 

2 // function that f i n d s the g r e a t e s t element in an a r b i t r a r y array 

3 

4 #ifndef f i n d m a x t e m p l a t e f u n c t i o n h 

5 #define f i n d m a x t e m p l a t e f u n c t i o n h 

6 


8 

9 template uint32 findMax ( 

10 const ElementType ∗ elements , uint32 num elements ) 

11 { 

12 uint32 current max = 0; 

13 

14 for ( uint32 index = 0 ; index < num elements ; index++) 

15 { 

16 i f ( elements [ index ] > elements [ current max ] ) 

17 current max = index ; 

18 } 

19 return ( current max ) ; 

20 } 

21 

22 #endif // f i n d m a x t e m p l a t e f u n c t i o n h 

Um zu verstehen, was hier passiert, werfen wir einmal einen Blick auf Zeile 9, 

denn dort ist der Kern dessen versteckt, was Templates in C ++ ausmacht: Die 

Deklaration des generischen Typs. Die Deklaration 

template 

bedeutet in diesem Kontext Folgendes: ElementType ist in diesem Kontext 

ein generischer Typ, der bei Verwendung durch einen konkreten Typ ersetzt 

werden muss. Wo auch immer also im Rahmen der Deklaration und Definition 

der Funktion ElementType als Typ verwendet wird, steht dieser also als 

Platzhalter für den konkreten Typ. Das Keyword template und die spitzen 

Klammern, die den bzw. die generischen Typen einfassen, sind in der C ++ 

Syntax so definiert. 

Betrachten wir den Rest der Deklaration der Funktion in den Zeilen 9– 

10, dann sehen wir, dass ElementType gleich einmal als generischer Typ in 

der Parameterliste der Funktion verwendet wird. Dadurch ist die genaue


Bedeutung der Deklaration einmal folgendermaßen zu lesen: Es wird hier 

eine Funktion findMax deklariert, die als return-Value einen uint32 liefert 

und die als Parameter ein Array beliebiger Elemente sowie die Anzahl der 

in diesem Array enthaltenen Elemente nimmt. Dazu sei noch anzumerken, 

dass hier der generische Parameter class ElementType nicht zwangsweise 

für “echte” Klassen steht, es sind auch primitive Datentypen, wie z.B. int, 

zulässig. 

In der Implementation der Funktion in den Zeilen 11–20 sieht man, dass 

der Parameter elements ganz genau so verwendet wird, als würde es sich 

hier um einen konkreten Datentyp handeln. In Zeile 16 erkennt man, dass 

vom konkreten Datentyp nur eines verlangt wird: Instanzen dieses Datentyps 

müssen mittels des > Operators miteinander vergleichbar sein. 

Jetzt stellt sich nur noch die Frage, wie man mit einem solchen Template 

arbeitet. Irgendwann muss ja wohl aus unserer generischen Deklaration 

und Definition auch einmal eine konkret aufrufbare Funktion werden. Wie 

man in der Folge erkennen kann, müssen wir uns nicht im Besonderen darum 

kümmern, sondern können das einfach dem Compiler überlassen. Wir 

tun einfach so, als wäre diese Funktion für einen bestimmten Datentyp existent. 

Werfen wir also kurz einen Blick auf unser Testprogramm, das dieses 

Verhalten demonstriert (find_max_test.cpp): 

1 // find max test . cpp − demo , how the template works 

2 

3 #include ” find max template function . h” 


5 



8 


10 { 

11 int32 t e s t a r r a y 1 [ ] = { 4 , 1 , 2 , 5 , 3 } ; 

12 double t e s t a r r a y 2 [ ] = { 1 7 . 0 , 1 2 . 0 , 1 3 . 4 , − 7 . 5 , 1 1 . 3 } ; 

13 

14 cout

findMax f o r int32 array . . . max value i s at index 3 

findMax f o r double array . . . max value i s at index 0 


Was tut der Compiler also hinter den Kulissen, dass wir eine generische Funktion 

einfach so aufrufen können und in Wirklichkeit den Aufruf einer konkreten 

Funktion damit erreichen? Prinzipiell geht er nach folgendem Schema 

vor: 

1. Beim Aufruf einer Template Funktion wirft er einen Blick auf deren Deklaration, 

um herauszufinden, was denn die generischen Teile des Templates 

sind (davon kann es natürlich mehrere geben...). In unserem Fall gibt 

es den Datentyp ElementType, der eine konkrete Entsprechung braucht. 

2. Die Aufrufparameter werden mit den generischen Teilen des Templates 

verglichen. Dadurch erfährt der Compiler, welche Entsprechung er konkret 

nehmen soll. In Zeile 15 unseres Testprogramms findet der Compiler 

heraus, dass ElementType wohl int32 sein muss, denn die Funktion 

wird mit einem int32 * aufgerufen und im Template steht als Parameter 

ElementType *. Wenn ElementType also für int32 steht, passt alles 

wunderbar zusammen. 

3. Jetzt, wo der Compiler herausgefunden hat, was ElementType ist, geht er 

daran, im gesamten Funktionsrumpf alle Vorkommen dieses generischen 

Typs durch den konkreten Typ int32 zu ersetzen. Er bastelt also eine 

konkrete Funktion für diesen Typ. 

4. Die resultierende konkrete Funktion wird danach vom Compiler übersetzt, 

als ob wir selbst eine Funktion geschrieben hätten, die mit einem 

int32 Array arbeiten würde. 

5. Der Aufruf der konkreten Funktion wird nun endgültig an der Stelle 

eingesetzt, an der wir mit findMax in dieser Ausprägung arbeiten. 

Ganz genau dasselbe passiert in Zeile 18, nur dass hier die Analyse der generischen 

Parameter ergibt, dass der konkrete Datentyp ein double ist. Der 

Compiler erzeugt also eine neue konkrete Ausprägung der Funktion, die mit 

einem double Array arbeiten kann und setzt diesen Aufruf ein. Natürlich 

wird nicht jedes Mal, wenn der Compiler z.B. auf einen double stößt, wieder 

eine neue Ausprägung der Funktion erzeugt, denn die besondere Ausprägung 

mit double existiert ja nach dem ersten Vorkommen schon. Es wird ab dem 

zweiten Vorkommen einfach diese existente Ausprägung herangezogen. Genaueres 

dazu wird noch in Abschnitt 13.7 behandelt. 

Geht man dieses Schema, wie der Compiler mit Templates arbeitet, noch 

einmal im Kopf durch, dann erkennt man schnell, warum ich hier die gesamte 

Definition der Funktion einmal kurzerhand quasi als inline Code in das 

Header File geschrieben habe: Der Compiler muss die Definition der Funktion 

kennen, um aus dieser generischen Definition auch eine konkrete Ausprägung 

durch Ersetzen des Typs bauen und danach übersetzen zu können. Ich möchte 

allerdings hier gleich vorausschicken, dass dies im Prinzip notgedrungen so 

sein muss, dass es aber zum Glück trotzdem Möglichkeiten gibt, wie man die


Deklaration und die Definition von Templates voneinander trennen kann und 

damit wieder unsere saubere Aufteilung in cpp und h Files erreichen kann. 

Wie man dabei vorgeht, wird in Abschnitt 13.7 noch genauer behandelt. Um 

den Blick auf das Wesentliche nicht zu verlieren, begnügen wir uns derzeit 

einfach einmal mit dieser etwas unschönen Organisation des Source Codes 

und lassen Templates vollständig inklusive Definitionen im Header stehen. 

Nur so als kleines Gedankenexperiment möchte ich hier noch folgende 

Frage in den Raum stellen: Was muss man tun, wenn man bereits im generischen 

Typ selbst verankern will, dass es sich um einen Pointer handelt? Als 

Parameter will man also nicht mehr 

const ElementType *element 

stehen haben, sondern z.B. 

const ElementTypePtr element 

Nun, im Prinzip ist das ganz einfach, wie die folgende Modifikation beweist 

(find_max_template_function_v2.h): 

1 // find max template function v2 . h − a s l i g h t change o f the f i r s t 

2 // implementation that i n c l u d e s the pointer in the g e n e r i c type 

3 



6 


8 


10 const ElementTypePtr elements , uint32 num elements ) 

11 { 


13 


15 { 



18 } 


20 } 

21 


Es wurde ganz einfach der Name des generischen Parameters geändert, um 

Entwicklern, die Zeile 9 lesen, zu signalisieren, dass hier ein Pointer erwartet 

wird. Weiters wurde beim ersten Parameter in Zeile 10 der * weggelassen, 

denn wir wollen ja, dass der Pointer bereits Teil des generischen Parameters 

ist. Beim Auflösen kommt der Compiler ja schon automatisch darauf, dass 

mit ElementTypePtr z.B. in unserem Testprogramm entweder ein int32 * 

oder eben ein double * gemeint ist, denn nur so kann er ein korrektes Matching 

vornehmen. 

Das Testprogramm dazu hat sich bis auf das Inkludieren des modifizierten 

Headers gar nicht verändert. Deshalb möchte ich es auch hier nicht abdrucken. 

Es ist unter dem Namen find_max_test_v2.cpp auf der beiliegenden


CD-ROM verewigt. Auch den Output erspare ich hier den Lesern, denn auch 

dieser hat sich in keinster Weise verändert. 

Leider hat es sich sowohl im Alltag als auch in der Literatur eingebürgert, 

die Typ-Parameter von Templates unseligerweise mit möglichst kurzen und 

nichts sagenden Bezeichnern, wie z.B T, zu versehen. Von dieser Praxis kann 

ich nur energisch abraten, denn dies führt zu sehr schwer lesbaren Programmen. 

Deshalb habe ich auch ganz bewusst den generischen Typnamen im 

abgeänderten Beispiel mitgeändert. Damit wird einfach klar signalisiert, dass 

man hier mit einem Pointer auf irgendetwas zu tun hat. Würde hier einfach 

T oder Type oder Ähnliches stehen, so müsste man erst die Implementation 

lesen um überhaupt eine Idee zu bekommen, dass hier ein Array erwartet 

wird. 

Gehen wir in unseren Gedankenexperimenten zu generischen Typen noch 

einen Schritt weiter indem wir behaupten, dass der Parameter, der die Anzahl 

der Elemente angibt, eigentlich auch von seinem Typ her gar nicht so 

wirklich festgelegt ist. Es könnte sich hier, je nach Anwendung, um einen 

uint32, einen int32, einen long oder sonst einen ganzzahligen Datentyp 

handeln. Es könnte sich sogar um ein besonderes Objekt handeln, das nach 

außen eine Zahl repräsentieren kann, das aber selbst keineswegs ein primitiver 

Datentyp ist. So ein Beispiel haben wir ja bereits in Abschnitt 12.2 in 

Form unserer Range-Controlled Ganzzahl kennen gelernt. Was also, wenn wir 

auch diesen zweiten Parameter generisch definieren wollen? Nun, ganz einfach: 

Es ist natürlich in C ++ erlaubt, beliebig viele generische Typen für ein 

Template festzulegen. Also schreiten wir zur Tat und ändern unser Template 

entsprechend ab (find_max_template_function_v3.h): 

1 // find max template function v3 . h − a s l i g h t change that a l s o 

2 // makes the num elements parameter g e n e r i c 

3 



6 


8 

9 template IntType findMax ( 

10 const ElementType ∗ elements , IntType num elements ) 

11 { 

12 IntType current max = 0; 

13 

14 for ( IntType index = 0 ; index < num elements ; index++) 

15 { 



18 } 


20 } 

21 


In den Zeilen 9–10 erkennt man, dass man innerhalb der spitzen Klammern 

auch mehrere generische Typbezeichner angeben kann. In unserem Fall ha-


ben wir es hier also mit dem bereits bekannten ElementType sowie auch mit 

einem IntType zu tun. Wenn wir schon für die Anzahl der Elemente einen 

generischen Typ verwenden, dann ist es natürlich auch nur recht und billig, 

für den return-Value der Funktion denselben generischen Typ zu verwenden. 

Also haben wir hier auch die Deklaration des return-Values über unseren 

generischen Typ vorgenommen. Das bringt uns genau zur Eigenschaft von 

generischen Typen in Templates, die wir bisher implizit vorausgesetzt haben: 

Innerhalb einer Template Deklaration und Definition wird ein generischer 

Typ ganz genau gleich verwendet, wie wir sonst einen konkreten Typ verwenden 

würden. Das Ersetzen durch einen konkreten Typ nimmt dann der 

Compiler für uns vor. Der Gültigkeitsbereich der generischen Typbezeichner 

ist selbstverständlich auf die Deklaration und Definition des Templates selbst 

limitiert, ansonsten würde es ja zu sehr bösen Überraschungen kommen. 

Außer im return-Value und im zweiten Parameter findet sich der generische 

Typ IntType natürlich auch in der Definition der Funktion wieder, 

denn current_max muss natürlich auch diesen Typ haben, ebenso unsere 

Laufvariable index. 

Ändern wir nun wiederum unser Testprogramm so ab, dass es unsere modifizierte 

Version des Templates inkludiert, so zeigt sich, dass diese Version 

genau dasselbe Resultat liefert, wie die beiden Versionen zuvor. Der Compiler 

betrachtet hier einfach nur IntType als zusätzlichen generischen Parameter, 

zu dem er eine konkrete Entsprechung finden muss. Im Fall unseres Testprogramms 

wird als Entsprechung int gefunden, denn eine Ganzzahlkonstante 

wird vom Compiler natürlich implizit als int betrachtet. 

Das geänderte Testprogramm findet sich auf der beiliegenden CD-ROM 

unter dem Namen find_max_test_v3.cpp und der Output, den dieses Programm 

liefert, ist erwartungsgemäß wieder derselbe, den auch die Vorgängervarianten 

produziert haben. 

Auf den ersten Blick scheint diese Version des Templates also die Erfüllung 

aller Träume zu sein: Wir implementieren einmal den Algorithmus und er 

funktioniert unabhängig vom Typ der Elemente und auch unabhängig vom 

Typ der Längenangabe wunderbar. Hätten wir keine Function Templates zur 

Verfügung, so müssten wir für jeden bestimmten Elementtyp eine eigene overloaded 

Function schreiben. Außerdem müssten wir auch den num_elements 

Parameter immer an den Typ anpassen oder gleich den größtmöglichen Ganzzahldatentyp 

verwenden, um auf der sicheren Seite zu bleiben. Da wir im 

Vorhinein nicht einmal wissen, mit welchen Parametertypen und Kombinationen 

derselben wir es zu tun bekommen, schreiben wir gleich eine unendlich 

lange Latte von verschiedenen Overloadings und hoffen, dass eines davon 

schon auf die spätere Verwendung passen wird. 

Die hier angesprochene Erfüllung aller Träume birgt allerdings auch ein 

paar Albträume, die man erst nach der anfänglichen Euphorie bemerkt. Um 

auch über diese Bescheid zu wissen, betrachten wir einmal ein paar Möglich-


keiten etwaiger Fehlverwendungen unseres schönen Templates etwas näher 

(template_usage_dangers.cpp): 


112 { 

113 int32 t e s t a r r a y [ ] = { 4 , 1 , 2 , 5 , 3 } ; 

114 RangeControlledInt num with range ( 0 , 5 0 , 5 ) ; 

115 

116 // the f o l l o w i n g l i n e r e s u l t s in a compiler e r r o r , because 

117 // in the template the second parameter i s used f o r 

118 // array indexing 

119 findMax ( t e s t a r r a y , 5 . 5 ) ; 

120 

121 // the f o l l o w i n g l i n e r e s u l t s in a compiler e r r o r , because 

122 // of two reasons : 

123 // ( 1 ) no constructor with an i n t parameter i s defined 

124 // ( 2 ) the ++ operator i s not implemented 

125 findMax ( t e s t a r r a y , num with range ) ; 

126 return ( 0 ) ; 

127 } 

Im obigen Beispiel wurde bewusst nur main abgedruckt. Das Template entspricht 

der zuletzt betrachteten Variante, die beide Parameter generisch definiert. 

Die Klasse RangeControlledInt wurde direkt aus dem entsprechenden 

Beispiel in Abschnitt 12.2 übernommen. Wenn wir versuchen, das obige 

Beispiel zu compilieren, dann kommen wir leider zu keinem lauffähigen Programm, 

denn der Compiler hat hier ein paar Dinge zu bemängeln. 

Erstens passt ihm der Aufruf von findMax aus Zeile 119 ganz und gar 

nicht. Es wird nämlich hier die Funktion mit einem double als Längenparameter 

aufgerufen. Dies veranlasst den Compiler, eine entsprechende konkrete 

Implementation mit einem double zu erzeugen. Dieser wird allerdings 

in unserem Template als Index für das Array verwendet, was natürlich nicht 

gestattet ist. 

Zweitens passt dem Compiler auch der Aufruf von findMax aus Zeile 125 

nicht, denn hier wird ein RangeControlledInt als Längenparameter verwendet. 

Das bedeutet, dass dieser Typ auch für den return-Value und ebenso 

für die Laufvariable in unserem Template verwendet wird. Leider aber fehlt 

für diese Verwendung Entscheidendes: Es gibt keinen Konstruktor, der einfach 

nur einen einzigen Parameter, nämlich den Initialwert, nehmen würde. 

Außerdem ist der ++ Operator nicht definiert. Beides wird aber im Template 

beim Arbeiten mit der Laufvariable sowie mit dem return-Value gebraucht. 

Man kann nun sagen, dass der Aufruf mit dem double wirklich ein grober 

Unfug ist und dass man daher froh sein kann, dass der Compiler darauf hinweist. 

Weiters kann man behaupten, dass man beim RangeControlledInt 

selbst die Schuld trägt, weil man auf den entsprechenden Konstruktor und 

den ++ Operator hätte denken sollen. Also ergänzt man diese Klasse und 

kommt damit auch wirklich problemlos durch den Compiler. Damit hat man 

sich aber ein wunderbares verstecktes Problem eingehandelt, das verhängnisvoll 

sein kann: Beim Schreiben des Templates hat niemand damit gerechnet, 

dass beim Über- bzw. Unterschreiten eines vorgegebenen Wertes eine Excep-


tion geworfen wird (was ja die Eigenschaft unseres speziellen Typs ist)! Das 

kann, je nach Funktion, zu groben Inkonsistenzen führen. In unserem Fall 

passiert es “nur”, dass eine Exception geworfen wird, die durch das Funktionstemplate 

nicht explizit deklariert wurde – schlimm genug! In anderen 

Fällen kann es natürlich auch zu einer echten Katastrophe kommen. 

In unserem Fall der RangeControlledInt Klasse kann man sich auch 

noch auf eine andere Art schnell und sicher die Probleme vom Hals schaffen. 

Man braucht nur Zeile 125 umschreiben auf: 

findMax(test_array,static_cast(num_with_range)); 

Damit hat man die Verwendung unseres selbstdefinierten Cast-Operators erzwungen, 

wodurch das Template vom Compiler mit einem int32 als zweiten 

Parameter erzeugt wird. Gleich vorausschicken möchte ich, dass so eine 

Lösung nicht immer so leicht zu finden ist, wie man sich ja ausmalen kann. 

Leider gibt es in C ++ keine Möglichkeit, einen generischen Parameter auf 

einen genau definierten Satz von Möglichkeiten einzuschränken. Daher fehlt 

uns hier das programmiersprachliche Werkzeug, das notwendig wäre, um eine 

Fehlverwendung zu verhindern. Von der anderen Seite betrachtet ist es 

natürlich auch nicht immer möglich bzw. wünschenswert, alle möglichen 

Kombinationen von Typen auf einen erlaubten Satz einzuschränken, denn 

damit hat man bereits im Vorfeld Typen ausgeschlossen, die man zum Zeitpunkt 

der Entwicklung eines Templates noch nicht gekannt hat. Abhilfe dazu 

würde das Unterstützen von sogenannten Contracts in C ++ schaffen, aber eine 

Diskussion darüber geht an dieser Stelle zu weit. Deshalb möchte ich es 

hier bei folgender Warnung belassen: 

Vorsicht Falle: Bevor man in seiner Software ein Template verwendet, 

muss man sich sehr genau ansehen, welche Anwendung die Entwickler des 

Templates im Sinn hatten und auf welche Umstände sie Rücksicht genommen 

haben. Die Verwendung von Templates außerhalb dieser Grenzen kann 

ungeahnte Fehler zur Folge haben! 

Leider kann man sehr oft die Details, die helfen, diese Frage zu beantworten, 

nicht aus der Dokumentation entnehmen. In diesem Fall hilft wirklich 

nur eine Lektüre des Template Source Codes um absolute Sicherheit zu haben, 

dass man nicht in eine Falle tappt. 

13.2 Overloading Aspekte von Function Templates 

Im Prinzip kann man Function Templates auch so betrachten, dass sie durch 

ihren generischen Typmechanismus viele verschiedene Overloadings für eine 

Funktion automatisch bereitstellen. Was passiert nun, wenn man dazu noch 

ein “echtes” Overloading implementiert, das eine bestimmte Ausprägung eines 

solchen Function Templates explizit implementiert? Ich kann gleich vorwegnehmen, 

was die meisten Leser vermuten werden: es funktioniert. Al-

13.2 Overloading Aspekte von Function Templates 415 

lerdings erwartungsgemäß nicht ohne gewisse Fallen, die sich aufgrund von 

Ambiguitäten auftun, wie wir noch sehen werden. Werfen wir also am besten 

einen Blick auf ein Beispiel(templates_and_overloading.cpp): 

1 // templates and overloading . cpp − overloading function templates 

2 // with concrete f u n c t i o n s 

3 



6 



9 



12 { 

13 cout


In Zeile 48 wird findMax mit einem int32 Array und einem int Längenparameter 

aufgerufen, was natürlich den Compiler dazu bewegt, eine konkrete 

Ausprägung aus dem Template zu generieren. Anders verhält es sich da 

schon mit Zeile 49, in der findMax mit einem double Array und einem uint32 

Längenparameter aufgerufen wird. Da unsere konkrete Implementierung von 

findMax haarscharf diesen Parametersatz deklariert, sieht der Compiler überhaupt 

keine Veranlassung, aus dem Template eine konkrete Ausprägung zu 

basteln, denn es gibt ja bereits eine Implementation der Funktion, die alle 

Wünsche erfüllt. Der Beweis dieser Aussage findet sich im Output des 

Programms: 

template implementation o f findMax 

concrete implementation of findMax 

Das Angenehme an dieser Tatsache ist, dass wir also offensichtlich einen 

gewissen Einfluss auf bestimmte Ausprägungen eines Templates nehmen 

können. Wenn z.B. eine besondere Ausprägung eines Templates mit einem 

ganz bestimmten Datentyp, aus welchem Grund auch immer, eine besondere 

Implementation benötigt, dann können wir diese explizit schreiben. Hiermit 

kann man z.B. sehr gut die Behandlung von Sonderfällen innerhalb von 

Templates in Grenzen halten. 

Wo es eine angenehme Seite gibt, ist leider oft die unangenehme Seite 

auch nicht weit. Natürlich gibt es bei dieser Vorgehensweise auch nette Stolpersteine: 

Vorsicht Falle: Sollte der Parametersatz beim Aufruf nicht vollkommen 

exakt auf die konkrete Implementation der Funktion passen, dann kann man 

den Compiler in ein Ambiguitätsproblem stürzen, das er nicht mehr automatisch 

auflösen kann. Nehmen wir nur einmal an, dass in Zeile 49 der Aufruf 

folgendermaßen lauten würde: 

findMax(test_array2,5) 

dann bedeutet dies für den Compiler einen Aufruf mit einem double Array 

und mit einem int Parameter. Das passt nicht vollkommen exakt auf die 

konkrete Implementation, ist aber auch noch nicht so weit daneben, dass 

nicht mit einer impliziten Typumwandlung noch etwas zu machen wäre. 

Je nach Compiler passiert es hierbei, dass er entweder eine Warning von 

sich gibt, oder sich sogar vollständig weigern kann, die Entscheidung für eine 

der beiden Varianten selbsttätig zu treffen. Es kann dann nur noch mit einem 

expliziten Cast Abhilfe geschaffen werden. Wenn man allerdings mit einer 

fremden Library arbeitet, kann das schon einiges an Rätselraten zur Folge 

haben, bis man endlich durchschaut hat, warum sich der Compiler an einer 

bestimmten Stelle schlicht und ergreifend weigert, seine Arbeit zu erledigen. 

Bisher sind wir immer davon ausgegangen, dass der Compiler durch Analyse 

der Aufrufparameter implizit eine passende konkrete Ausprägung einer 

Funktion erzeugt. Manchmal sind wir allerdings interessiert daran, dies selbst 

in die Hand zu nehmen. Betrachten wir nur einfach den Fall, dass wir in ei-

13.2 Overloading Aspekte von Function Templates 417 

nem Programm immer das Maximum aus einem int32 Array finden wollen. 

Andererseits jedoch haben wir es in den verschiedenen Programmteilen einmal 

mit einem signed char, ein andermal mit einem int32 und wieder ein 

andermal mit einem long Parameter als Index zu tun. Der Compiler würde 

nun drei verschiedene konkrete Ausprägungen der Funktion erzeugen, was 

nicht immer wünschenswert ist. In diesem Fall wäre es genug, wenn einfach 

eine Version mit einem long als zweiten Parameter erzeugt würde, denn die 

anderen verwendeten Typen sind ja kompatibel dazu. Zu diesem Zweck gibt 

es die Möglichkeit der expliziten Angabe, mit welchen Typen man arbeiten 

will. Dies sieht dann folgendermaßen aus: 

1 // find max test v4 . cpp − adapted t e s t f o r V3 o f the template 

2 

3 #include ” find max template function v3 . h” 


5 



8 


10 { 


12 

13 cout


1 // find max template function v4 . h − a f u r t h e r modification 

2 // with two templates that overload each other 

3 



6 


8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


11 const ElementType ∗ elements , uint32 num elements ) 

12 { 


14 


16 { 



19 } 


21 } 

22 

23 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 



26 { 

27 IntType current max = 0; 

28 

29 for ( IntType index = 0 ; index < num elements ; index++) 

30 { 



33 } 


35 } 

36 


Hier haben wir es mit einem Overloading von zwei Function Templates zu 

tun, wobei das eine Template nur einen, das andere zwei Typ-Parameter 

entgegennimmt. Auf diese Art kann man quasi einen default Typ-Parameter 

realisieren. Über explizites Angeben der Ausprägung kann man dann jeweils 

die eine oder die andere Variante verwenden, wie das folgende Beispiel zeigt 

(find_max_test_v5.cpp): 

1 // find max test v5 . cpp − adapted t e s t f o r V4 the template 

2 

3 #include ” find max template function v4 . h” 


5 



8 


10 { 


12 

13 cout

16 cout


27 template class Buffer 

28 { 

29 public : 

30 static const uint32 MAX NUM ELEMENTS = 8; 

31 private : 

32 // f o r b i d assignment by making operator p r i v a t e 

33 const Buffer& operator = ( const Buffer&) 

34 { return (∗ this ) ; } 



37 uint32 num elements allocated ; 

38 uint32 read index ; 

39 uint32 w r i t e i n d e x ; 

40 ContentType ∗ elements ; 

41 public : 

42 Buffer ( ) 


44 

45 Buffer ( const Buffer &s r c ) 


47 

48 virtual ˜ Buffer ( ) 

49 throw ( ) ; 

50 

51 virtual void put ( ContentType const &element ) 


53 

54 virtual ContentType getNext ( ) 


56 } ; 

Wie bereits von den Function Templates her gewohnt, beginnt man mit dem 

Keyword template, gefolgt von der Liste der generischen Typenparameter 

in spitzen Klammern (siehe Zeile 27). In unserem Fall geht es hier um den 

Typ der einzelnen Elemente, die im Buffer zwischengespeichert werden sollen. 

Zeile 30 zeigt gleich sehr deutlich, dass dieses Template wirklich nur zu 

Demonstrationszwecken geschrieben wurde und dass es in dieser Form nicht 

sinnvoll in Programmen eingesetzt werden kann. Die Anzahl der Elemente, 

die im Buffer zwischengelagert werden können, ist nämlich auf großartige 

acht beschränkt. Die Zuweisung eines Buffers auf einen anderen wurde in 

den Zeilen 33–34 verhindert, indem der Zuweisungsoperator private gesetzt 

wurde. Das zugegebenermaßen schwachsinnige Statement in Zeile 34 existiert 

nur, um der Deklaration Genüge zu tun. Da der Operator sowieso nie 

aufgerufen wird, erwächst hierbei keine Gefahr. 

Eine Auffälligkeit erkennt man allerdings in den Zeilen 33–34: Sowohl der 

return-Type als auch der Parameter sind besondere Buffers, nämlich Buffers 

vom selben Typ, wie diese Instanz auch. Die Schreibweise 

Classname 

ist nämlich genau die Art, wie man eine konkrete Ausprägung eines Class 

Templates erzeugt. Dadurch, dass hier innerhalb der spitzen Klammern 

selbst wieder der generische Typ ContentType steht, erreicht man, dass 

“dieselbe” Ausprägung angenommen wird, wie sie auch der konkreten Aus-

13.3 Class Templates 421 

prägung entspricht, auf der eine Methode oder ein Operator aufgerufen wurde. 

Ganz genau dasselbe findet sich in Zeile 45 wieder: Der Copy Constructor 

ist natürlich nur für äquivalente konkrete Ausprägungen von Buffers definiert, 

es hätte wirklich keinen Sinn z.B. einen Copy Constructor zwischen verschiedenen 

Ausprägungen zuzulassen. 

Vorsicht Falle: Vor allem Entwicklern, die noch ungeübt im Erstellen 

von Templates sind, passiert es öfters, dass sie bei Parametern bzw. bei 

return-Values vergessen, die konkrete Ausprägung des Templates anzugeben. 

Fälschlicherweise könnte man für unseren Copy Constructor aus Zeile 45 Folgendes 

schreiben: 

Buffer(const Buffer &src) 

Diese Deklaration hat jedoch eine ganz andere Bedeutung: src ist nämlich 

irgendeine Ausprägung eines Buffers, allerdings bestimmt das erste Vorkommen 

im Source-Code, welche konkrete Ausprägung gemeint ist. Von dort weg 

wird angenommen, dass src genau diese Ausprägung hat. Zum Glück führt 

das dann zumeist aus anderen Gründen zu Compilerfehlern beim Übersetzen 

des Templates. Jedoch sind die entsprechenden Fehlermeldungen manchmal 

ziemlich kryptisch. 

Dazu muss auch noch gesagt werden, dass einige Compiler sich sowieso 

partout weigern, die obige Zeile zu übersetzen und stattdessen auf die Angabe 

der Ausprägung bestehen – meiner Meinung nach das sinnvollste Verhalten. 

Andere Compiler setzen wiederum implizit voraus, dass sicher dieselbe Ausprägung 

gemeint ist und übersetzen das Template dementsprechend. Dieses 

Verhalten führt zwar zu keinen Problemen, allerdings bin ich kein besonderer 

Freund davon, dass Compiler die Fehler von Entwicklern stillschweigend 

korrigieren anstatt sie zu melden. 

Die Methoden, die hier in der Klasse deklariert waren, müssen natürlich 

auch noch definiert werden. Aus bereits besprochenen Gründen beschränken 

wir uns auch hier im Augenblick darauf, dass die Definition ebenfalls im Header 

steht, um dem Compiler eine faire Chance zu geben, eine entsprechende 

konkrete Ausprägung der Klasse mit allen zugehörigen Methoden erzeugen zu 

können. Folgende Definitionen sind also in unserem Header noch enthalten: 

58 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

59 /∗ 

60 ∗/ 

61 template 

62 Buffer:: Buffer ( ) 


64 { 

65 num elements = 0; 

66 read index = 0; 

67 w r i t e i n d e x = 0; 

68 num elements allocated = 0 ; // j u s t in case new f a i l s . . . 

69 elements = new ContentType [MAX NUM ELEMENTS] ; 

70 num elements allocated = MAX NUM ELEMENTS;


71 } 

72 

73 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

74 /∗ 

75 ∗/ 

76 template 

77 Buffer:: Buffer ( const Buffer &s r c ) 


79 { 

80 cout


der die altbekannte template Deklaration und anstatt nur den 

Klassennamen als Scope für die Methode zu verwenden, verwendet man bei 

Templates eine besondere Ausprägung des Templates. In unserem Fall ist 

es Buffer. Dies bewirkt, dass für jede Ausprägung entsprechend 

auch eine neue Ausprägung der Methode erzeugt wird, was natürlich 

notwendig ist. 

Nur um einem oft gemachten Denkfehler vorzubeugen: Manche Leser 

könnten jetzt anmerken, dass es ja Fälle geben kann, in denen eine Methode 

von der Ausprägung des Templates unabhängig ist. Eine Methode, die bei 

unserem Buffer die Anzahl der gespeicherten Elemente liefert, wäre theoretisch 

ein solcher Fall, denn diese Anzahl ist immer einfach in num_elements_ 

gespeichert. Jedoch, wer garantiert uns, dass das innere Layout der Klasse in 

den verschiedenen Ausprägungen äquivalent ist? Die Offsets der verschiedenen 

Variablen können sich sehr wohl über verschiedene Ausprägungen hinweg 

verändern und damit ist es mit der Gleichheit von Methoden vorbei! 

Vorsicht Falle: In den Zeilen 89–90 sieht man im Copy Constructor unseres 

Buffers, dass in einer Schleife alle Elemente einzeln kopiert werden. 

Manche Leser mögen nun geneigt sein, zu sagen, dass dies doch nicht besonders 

performant ist und dass man durch Verwendung von memcpy hier 

eine deutliche Performancesteigerung erreichen kann. Dies jedoch würde in 

bestimmten Fällen zur Katastrophe führen, denn damit umgeht man den Copy 

Constructor der Elemente! In der “langsamen” Implementation, die hier 

geschrieben wurde, werden diese jedoch garantiert aufgerufen. 

Es wurde bereits vorweggenommen, wie man bestimmte Ausprägungen 

von Class Templates erzeugt: Man stellt einfach den Typ bzw. die Typen 

der gewünschten Ausprägung in spitzen Klammern dem Klassennamen nach. 

Genau dies wird auch im folgenden Testprogramm gemacht, um einerseits 

einen Buffer für char Daten und andererseits einen Buffer für float Daten 

zur Verfügung zu haben (buffer_class_test.cpp): 

1 

2 // b u f f e r c l a s s t e s t . cpp − demo how to work with c l a s s templates 

3 


5 

6 #include ” b u f f e r c l a s s t e m p l a t e . h” 

7 


9 { 

10 Buffer c h a r b u f f e r ; 

11 Buffer f l o a t b u f f e r ; 

12 

13 c h a r b u f f e r . put ( ’ a ’ ) ; 

14 c h a r b u f f e r . put ( ’ b ’ ) ; 

15 c h a r b u f f e r . put ( ’ c ’ ) ; 

16 c h a r b u f f e r . put ( ’ d ’ ) ; 

17 

18 f l o a t b u f f e r . put ( 1 . 0 f ) ; 


20 f l o a t b u f f e r . put ( 3 . 0 f ) ;



22 

23 cout


Ein Blick auf Zeile 26 verrät, dass zwischen den spitzen Klammern bei einer 

Template Deklaration nicht ausschließlich nur generische Typenbezeichnungen 

als Parameter stehen können. Es können auch ganz normale typisierte 

Parameter in dieser Liste enthalten sein, wie hier unser Parameter 

MAX_NUM_ELEMENTS, der vom Typ uint32 ist. In unserem Fall wird damit die 

maximale Anzahl von Elementen festgelegt, die ein Buffer halten kann und 

dieser Parameter ist in der Implementation äquivalent zu einer Konstante 

verwendbar. Stellvertretend für die Änderungen, die sich in der Definition 

der Methoden ergeben, möchte ich in der Folge den Copy-Constructor abdrucken: 

74 template 

75 Buffer:: Buffer ( 

76 const Buffer &s r c ) 


78 { 

79 cout


5 

6 #include ” b u f f e r c l a s s t e m p l a t e v 2 . h” 

7 


9 { 

10 Buffer c h a r b u f f e r ; 

11 Buffer f l o a t b u f f e r ; 

12 

13 c h a r b u f f e r . put ( ’ a ’ ) ; 

14 c h a r b u f f e r . put ( ’ b ’ ) ; 

15 c h a r b u f f e r . put ( ’ c ’ ) ; 

16 c h a r b u f f e r . put ( ’ d ’ ) ; 

17 





22 

23 cout


Wenn man sich überlegt, dass hier ein konkretes Fassungsvermögen zum 

Teil des Typs wird, so erkennt man sofort, dass natürlich dieses Fassungsvermögen 

unbedingt über eine Konstante angegeben werden muss. Es ist ja 

schließlich der Compiler, der die konkrete Ausprägung aus einem Template erzeugt 

und dieser hat natürlich vom Inhalt einer Variable keine Ahnung, denn 

dieser wird ja erst zur Laufzeit festgelegt. Diese logische Schlussfolgerung 

wird durch Zeile 44 untermauert, die bei Entfernen der Kommentarzeichen 

in einem Compilerfehler resultieren würde. Führt man den Gedanken zu Ende, 

was sonst noch alles zur Compilezeit bekannt ist, dann erkennt man, dass 

auch bestimmte Adressen in diese Kategorie fallen: Es sind dies die Adressen, 

die sich auf Daten mit sogenanntem external Linkage beziehen, also solche, 

die auch außerhalb ihres Files sichtbar sind, in dem sie definiert wurden. 

Im Klartext bedeutet das: Adressen von globalen Variablen und Funktionen 

können auch als Template Parameter Anwendung finden. Obwohl ich hier 

erwähnen möchte, dass diese Art von Parametrisierung nur sehr selten sinnvoll 

ist und nur noch von wirklichen Template Experten vorgenommen werden 

soll, möchte ich zumindest eine sinnvolle Anwendung anführen: Templates, 

die über einen Funktionspointer typisiert werden, der einen bestimmten Algorithmus 

ausführt. Zum Beispiel könnte man ein Template SortedList 

erstellen, das als Parameter den Funktionspointer auf eine bestimmte Sortierfunktion 

nimmt. Dadurch kann man beim Festlegen der Ausprägung die 

Reihenfolge der Sortierung und den gewünschten Algorithmus einfach durch 

Angabe der richtigen Sortierfunktion festlegen. Das hat den Vorteil, dass 

eine aufsteigend und eine absteigend sortierte Liste mit Elementen desselben 

Datentyps nicht typkompatibel sind und ein falscher Umgang mit solchen 

Listen hierbei schon vom Compiler bemerkt wird. 

Der Output des Testprogramms beweist, dass sich am Verhalten der Buffers 

in Bezug zur vorangegangenen Version nichts verändert hat und dass der 

Copy-Constructor auch wirklich aufgerufen wird: 

content of the char b u f f e r : a , b , c , d 

content of the f l o a t b u f f e r : 1 , 2 , 3 , 4 

copy constructor 

Dass man auch eine bestimmte Ausprägung eines Templates selbst wieder 

als Template Parameter verwenden kann, zeigt sich im folgenden Beispiel, in 

dem wir einen Buffer zum Zwischenspeichern von Elementen verwenden, die 

selbst konkrete Ausprägungen eines Templates sind. Das Class Template für 

den Buffer entspricht vollständig der obigen Version und wird deshalb hier 

nicht abgedruckt. Die Daten, die im Buffer gespeichert werden sollen, sind 

über das Template GenericStorage realisiert, das aus Einfachheitsgründen 

gleich im Testprogramm verewigt wurde (buffer_class_test_v3.cpp): 

1 // b u f f e r c l a s s t e s t v 3 . cpp − another demo f o r c l a s s templates 

2 

3 


5



7 

8 template class GenericStorage 

9 { 


11 DataType data ; 

12 public : 

13 GenericStorage ( ) { } 

14 

15 GenericStorage ( const DataType &data ) { data = data ; } 

16 

17 GenericStorage ( const GenericStorage &s r c ) 

18 { 

19 data = s r c . data ; 

20 } 

21 

22 virtual GenericStorage &operator = ( 

23 const GenericStorage &s r c ) 

24 { 



27 } 

28 

29 virtual operator DataType ( ) { return ( data ) ; } 

30 } ; 

31 


33 { 

34 Buffer a b u f f e r ; 

35 

36 a b u f f e r . put ( GenericStorage(1)); 




40 

41 cout

13.4 Ableiten von Class Templates 429 

ergibt. Genau so verwenden wir Templates auch, wenn wir von ihnen ableiten. 

Versuchen wir uns gleich einmal an unserem Buffer und implementieren 

wir eine Variante, die uns auch Auskunft über den inneren Zustand desselben 

geben kann, also wie viele Elemente im Augenblick zwischengespeichert werden 

und wie hoch die Gesamtkapazität ist (buffer_class_template_v3.h). 

In dieser Abwandlung wurde aus Gründen der Einfachheit auf die erste Variante 

des Buffers zurückgegriffen, die nur den Typ und nicht die Anzahl der 

Elemente als Parameter nimmt. 

66 template class QueryableBuffer : 

67 public Buffer 

68 { 

69 public : 

70 QueryableBuffer ( ) 

71 throw( b a d a l l o c ) : Buffer() {} 

72 

73 QueryableBuffer ( const QueryableBuffer &s r c ) 

74 throw( invalid argument , b a d a l l o c ) : 

75 Buffer(s r c ) {} 

76 

77 // a l s o support copying from a ” normal ” b u f f e r 

78 QueryableBuffer ( const Buffer &s r c ) 

79 throw( invalid argument , b a d a l l o c ) : 

80 Buffer(s r c ) {} 

81 

82 virtual ˜ QueryableBuffer ( ) 

83 throw( ) { } 

84 

85 virtual uint32 getNumBufferedElements ( ) 

86 { 


88 } 

89 

90 virtual uint32 getOverallCapacity ( ) 

91 { 

92 return ( num elements allocated ) ; 

93 } 

94 } ; 

In den Zeilen 66–67 sieht man, dass das Ableiten eines Class Templates von 

einem anderen keine Hexerei ist: Hier wird einfach von einem Buffer abgeleitet, 

der dieselbe konkrete Ausprägung hat, wie unser QueryableBuffer. 

In den Initialisierungen, z.B. in den Zeilen 70–71, wo der default Konstruktor 

der Basis explizit aufgerufen wird, wird ebenfalls diese Ausprägung des 

Buffers eingesetzt. Neben dem Copy-Constructor in den Zeilen 73–75 wurde 

zu Demonstrationszwecken auch noch ein anderer Konstruktor in den Zeilen 

78–80 eingeführt, der es zulässt, dass ein QueryableBuffer auch mit 

einem “normalen” Buffer als Parameter konstruiert werden kann. 

Um zu zeigen, dass das ganze Spielchen, das hier implementiert wurde, 

auch funktioniert, werfen wir noch einen kurzen Blick auf das dazugehörige 

Testprogrämmchen (buffer_class_test_v4.cpp):


1 

2 // b u f f e r c l a s s t e s t v 4 . cpp − demo f o r derived templates 

3 


5 


7 


9 { 

10 QueryableBuffer b u f f e r 1 ; 

11 QueryableBuffer b u f f e r 2 = b u f f e r 1 ; 

12 

13 // j u s t to show that the constructor with a 

14 // standard b u f f e r works . . . 

15 Buffer b u f f e r 3 ; 

16 QueryableBuffer b u f f e r 4 = b u f f e r 3 ; 

17 

18 b u f f e r 1 . put ( 1 ) ; 

19 b u f f e r 1 . put ( 2 ) ; 

20 b u f f e r 1 . put ( 3 ) ; 

21 b u f f e r 1 . put ( 4 ) ; 

22 

23 cout

1 class QueryableFloatBuffer : 

2 public Buffer 

3 { 

4 public : 

5 QueryableFloatBuffer ( ) 

6 throw( b a d a l l o c ) : Buffer(); 

7 

8 virtual ˜ QueryableFloatBuffer ( ) 

9 throw ( ) ; 

10 

11 virtual uint32 getNumBufferedElements ( ) ; 

12 

13 virtual uint32 getOverallCapacity ( ) ; 

14 } ; 

13.5 Explizite Spezialisierungen 431 

Man sieht in den Zeilen 1–2, dass man eine “ganz normale” Klasse auch 

von einer konkreten Ausprägung eines Templates ableiten kann, indem man 

einfach nur die gewünschte Ausprägung entsprechend einsetzt. In unserem 

Fall leiten wir von der konkreten Ausprägung eines Buffers ab, die float 

Elemente speichern kann. 

Natürlich funktioniert auch der umgekehrte Weg, nämlich ein Class Template 

zu schreiben, das selbst von einer “ganz normalen” Klasse abgeleitet ist. 

Ebenso kann man ein Class Template schreiben, dass von einer bestimmten 

Ausprägung eines anderen Class Templates abgeleitet ist. Ich denke, die Beispiele 

hierzu kann ich wirklich auslassen, denn der Mechanismus ist immer 

derselbe: 

• Bezieht man sich auf eine “normale” Klasse, dann wird als Typ der Klassenname 

verwendet. 

• Bezieht man sich auf eine Ausprägung eines Templates, dann ist noch die 

Angabe dieser Ausprägung in spitzen Klammern hinter dem Namen des 

Class Templates vonnöten. 

13.5 Explizite Spezialisierungen 

Ein sehr interessantes Thema bei Templates, von dem bisher nicht die Rede 

war, ist die Menge des erzeugten Codes. Um zu erkennen, wodurch man 

die Menge des vom Compiler für bestimmte Ausprägungen erzeugten Codes 

beeinflussen kann, führen wir einmal eine kurze Analyse durch. Nehmen 

wir der Einfachheit halber wieder unsere ein-Parameter Variante des Buffers 

und nehmen wir an, dass in unserem Code irgendwo die folgenden Zeilen 

vorkommen: 

Buffer char_ptr_buf; 

Buffer uint32_ptr_buf; 

Buffer double_ptr_buf; 

Hierdurch werden drei verschiedene konkrete Ausprägungen von Buffers erzeugt, 

eine die ein Array von char * hält, eine die ein Array von uint32 *


hält und schließlich noch eine für double *. Vom Standpunkt des Laufzeitverhaltens, 

der Typkompatibilität und der Typsicherheit ist ja alles in 

Ordnung. Bei genauerem Nachdenken erkennt man allerdings schnell, dass 

die ganze Angelegenheit doch einen gröberen Haken hat: In allen drei Fällen 

speichert man einfach nur Pointer. Worauf diese zeigen, ist unserem Buffer 

intern völlig egal, denn dieser interessiert sich nur für die interne Organisation 

des Speichers zum Ablegen derselben. Mit den Werten, auf die sie zeigen, 

hat ein Buffer nichts am Hut. Pointer sind einfach immer gleich groß, egal, 

worauf sie zeigen, denn Computer haben eben einmal eine fixe Adresslänge. 

Für den Compiler gibt es aber nicht einfach nur Adressen, sondern Pointer 

sind auch typisiert. Deshalb wird er für jede der obigen Ausprägungen 

eines Buffers eine vollständige konkrete Ausprägung des Templates erzeugen. 

Dass das dazu führen kann, dass Unmengen an quasi gleichem Code erzeugt 

werden, ist leicht einzusehen. 

Es wäre also schön, wenn wir eine einfache Möglichkeit hätten, alle Ausprägungen 

von Buffers, die irgendwelche Pointer halten, unter einer bestimmten 

Ausprägung des Templates zusammenzufassen. Alle anderen Ausprägungen 

sollen wie gewohnt einzeln und getrennt erzeugt werden. 

Damit sind wir endlich bei der Erklärung der Kapitelüberschrift: Für 

diese Art des Zusammenfassens mehrerer Template-Ausprägungen wird oft 

der Begriff der Spezialisierung verwendet. Bevor wir zur Lösung des gerade 

eben angerissenen Problems mit den Pointern kommen, möchte ich einmal 

kurz das Prinzip zeigen, durch das man Spezialisierungen erzeugt. Um genau 

zu sehen, was nun aus dem originalen Template kommt und was aus der 

Spezialisierung, wurde das ursprüngliche Template leicht verändert und um 

entsprechende Outputs ergänzt. Jede Methode (inklusive Konstruktoren, 

etc.) meldet sich nun mit dem String generic ... wenn sie aufgerufen 

wird. Ansonsten ist diese Version vollkommen identisch zur Urversion und 

dementsprechend ist es sinnlos, sie hier abzudrucken. 

Die Deklaration der besonderen Spezialisierung auf void * sieht folgendermaßen 

aus (buffer_class_void_ptr_specialization.h): 

7 

8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 /∗ 

11 ∗ s p e c i a l i z a t i o n of the Buffer template f o r void p o i n t e r s 

12 ∗ 

13 ∗/ 

14 

15 template class Buffer 

16 { 

17 public : 


19 private : 


21 const Buffer& operator = ( const Buffer&) 

22 { return (∗ this ) ; } 


24 uint32 num elements ;




28 void ∗∗ elements ; 

29 public : 

30 Buffer ( ) 


32 



35 


37 throw ( ) ; 

38 

39 virtual void put ( void ∗ const &element ) 


41 

42 virtual void ∗ getNext ( ) 


44 } ; 


In Zeile 15 sieht man, dass das Keyword template nur noch von einer öffnenden 

und einer schließenden spitzen Klammer gefolgt ist und dass kein generischer 

Typ mehr angegeben wird. Das kommt daher, dass man dem Compiler 

auf diese Art mitteilt, für welchen bzw. welche der Template Parameter die 

Spezialisierung stattfindet. Die Parameter, für die man spezialisiert, kommen 

in der Spezialisierung nicht mehr vor. Die anderen Parameter, die weiterhin 

vom Compiler behandelt werden sollen, bleiben erhalten. 

Würde man also z.B. eine Spezialisierung unserer Variation des Templates 

mit den zwei Parametern machen, jedoch nur den Typ, nicht aber die Anzahl 

der Elemente spezialisieren wollen, so müsste hier Folgendes stehen: 

template 

class Buffer 

In der Folge sieht man, dass in der gesamten Deklaration alle Vorkommen 

des generischen Parameters durch die spezielle Ausprägung void * ersetzt 

wurden. 

Was haben wir also bisher erreicht? 

• Wir haben dem Compiler mitgeteilt, dass es eine handgeschriebene Spezialisierung 

des Buffers für den Typ void * gibt und dass er diese besondere 

Ausprägung nicht mehr zu generieren braucht. 

• Wir haben die Deklaration dieser Spezialisierung auch wirklich von Hand 

vorgenommen und entsprechend angepasst. Je nach Spezialisierung wird 

die Anpassung verschieden ausfallen. Bei uns hat sich diese darauf beschränkt, 

dass wir einfach nur den entsprechenden Typ eingesetzt haben, 

wo ansonsten der generische Typ stehen würde. 

Wenn wir schon dem Compiler mitteilen, dass er mit dieser Ausprägung unseres 

Templates nichts mehr zu tun hat, dann sind wir auch wirklich vollständig 

dafür verantwortlich. Das bedeutet, dass wir natürlich auch die entsprechenden 

Ausprägungen der Methoden selbst schreiben müssen. Genau das passiert 

auch in der Folge. Stellvertretend für die ganzen Methoden, die für


die Spezialisierung implementiert wurden, möchte ich hier einfach nur den 

default Konstruktor abdrucken: 



54 { 

55 cout

14 

15 int32 i n t e g e r s [ ] = { 1 , 2 , 3 , 4 } ; 

16 

17 i n t 3 2 b u f f e r . put ( 1 ) ; 

18 i n t 3 2 b u f f e r . put ( 2 ) ; 

19 i n t 3 2 b u f f e r . put ( 3 ) ; 

20 i n t 3 2 b u f f e r . put ( 4 ) ; 

21 


22 v o i d p t r b u f f e r . put ( reinterpret cast( i n t e g e r s ) ) ; 

23 v o i d p t r b u f f e r . put ( reinterpret cast( i n t e g e r s + 1 ) ) ; 



26 

27 cout


Alles, was mit dem Buffer für int32 geschieht, kommt aus dem generischen 

Typ, für den der Compiler eine Ausprägung erzeugt hat. Alles jedoch, was 

mit dem Buffer für void * geschieht, bezieht sich auf unsere handgestrickte 

Spezialisierung. 

Was sieht man also daran? Es ist möglich, verschiedene Spezialisierungen 

per Hand zu implementieren. Die Gründe hierfür sind mannigfaltig. Ein 

Hauptgrund ist die Möglichkeit des Finetunings durch spezielle Implementationsmaßnahmen, 

die nur für bestimmte Datentypen Geltung haben, bei 

anderen Typen aber zu Problemen führen würden. 

Was sieht man an unserer speziellen Implementation für void *? Wir 

haben leider unser Traumziel, die verschiedenen Pointer-Typen hinter den 

Kulissen zu einer gemeinsamen Ausprägung zusammenzufassen, nicht wirklich 

so erreicht, wie wir das gerne hätten. In den Zeilen 22–41 sieht man sehr 

deutlich, dass wir einfach per Hand alle Pointer “gleichmachen”, indem wir 

sie auf void * und wieder zurück casten. Dazu hätten wir eigentlich im Prinzip 

nicht einmal eine Spezialisierung gebraucht, denn unsere Spezialisierung 

macht ja nichts Besondereres als die vollkommen generische Version. 

Aber, Kopf hoch, es gibt eine Lösung, die wirklich das macht, was wir 

gerne hätten. Es gibt nämlich eine Möglichkeit, eine einzige Spezialisierung 

zu schreiben, die alle Pointer-Typen gemeinsam erfasst. Wir müssen nur 

die Spezialisierung ein wenig anders deklarieren als im obigen Beispiel und 

einen kleinen weiteren Kunstgriff anwenden, um nicht alles komplett neu zu 

implementieren (buffer_class_ptr_specialization.h): 

17 template 

18 class Buffer : private Buffer 

19 { 

20 private : 


22 const Buffer& operator = 

23 ( const Buffer&) 

24 { return (∗ this ) ; } 

25 public : 

26 Buffer ( ) 


28 



31 


33 throw ( ) ; 

34 

35 virtual void put ( ContentType ∗ const &element ) 


37 

38 virtual ContentType ∗ getNext ( ) 


40 } ; 

In Zeile 18 ist des Pudels Kern Teil eins versteckt, wie wir eine Spezialisierung 

schreiben können, die für alle Pointer Typen gleichermaßen vom Compiler 

herangezogen wird: Es wird für die spezielle Ausprägung des Buffers der Typ


ContentType * gewählt. Das bedeutet, dass der Compiler bis zum * beim 

Aussuchen einer Ausprägung ein Matching vornehmen kann, wodurch alle 

Pointer Typen gemeinsam erfasst werden. Einem Blick auf Zeile 17 entnehmen 

wir allerdings, dass wir damit allein noch nicht wirklich eine Reduktion 

des erzeugten Source Codes erreicht haben. Die Parametrisierung auf einzelne 

Typen (in unserem Fall Pointer-Typen) existiert ja nach wie vor. Also 

wird der Compiler auch nach wie vor für jeden einzelnen Pointer-Typ eine 

konkrete Ausprägung erzeugen. Was soll dann das Ganze nun überhaupt? 

Genau hier kommt des Pudels Kern Teil zwei ins Spiel: In Zeile 18 sieht 

man, dass unsere Spezialisierung von einer konkreten Ausprägung des Buffers, 

nämlich von einem Buffer, abgeleitet ist. Egal also, mit welchem 

Typ von Pointer wir es zu tun haben, dieser Buffer ist schon 

konkret und damit gibt es zumindest von ihm keine neuen Ausprägungen. 

Wir brauchen also nur noch unsere Methoden so zu implementieren, dass sie 

diejenigen des Buffer aufrufen und schon haben wir, was wir wollen. 

Also schreiten wir zur Tat und tun das. Das Ergebnis sieht dann so aus: 

48 template 


50 throw( b a d a l l o c ) : Buffer() 

51 { 

52 cout


89 ∗/ 

90 template 

91 ContentType ∗ Buffer:: getNext ( ) 


93 { 

94 cout

35 i n t 3 2 p t r b u f f e r . put ( i n t e g e r s + 2 ) ; 

36 i n t 3 2 p t r b u f f e r . put ( i n t e g e r s + 3 ) ; 

37 

38 f l o a t p t r b u f f e r . put ( f l o a t s ) ; 

39 f l o a t p t r b u f f e r . put ( f l o a t s + 1 ) ; 



42 

43 c h a r p t r b u f f e r . put ( chars ) ; 

44 c h a r p t r b u f f e r . put ( chars + 1 ) ; 



47 

48 cout


g e n e r i c put method 

s p e c i a l i z e d put method 
























content of i n t 3 2 b u f f e r : g e n e r i c getNext method 

1 , g e n e r i c getNext method 



4 

content of f l o a t b u f f e r : g e n e r i c getNext method 




4 

content of i n t 3 2 p t r b u f f e r : s p e c i a l i z e d getNext method 

s p e c i a l i z e d getNext method 

1 , s p e c i a l i z e d getNext method 






4 

content of f l o a t p t r b u f f e r : s p e c i a l i z e d getNext method 








4 

content of c h a r p t r b u f f e r : s p e c i a l i z e d getNext method 


a , s p e c i a l i z e d getNext method 


b , s p e c i a l i z e d getNext method 


c , s p e c i a l i z e d getNext method 


d 

s p e c i a l i z e d d e s t r u c t o r 



s p e c i a l i z e d d e s t r u c t o r



g e n e r i c d e s t r u c t o r 



Es ist hier auch sehr schön am Output zu erkennen, dass durch das Inkludieren 

des Headers mit unserer ersten Spezialisierung des Buffers auf void * 

auch wirklich diese Spezialisierung bei der Ableitung herangezogen wird. 

Um zu zeigen, dass man unsere jetzige Spezialisierung nicht unbedingt 

zweistufig vornehmen muss, sondern diese auch direkt aus dem generischen 

Code erzeugen kann, ändern wir unser Testprogramm ein wenig ab, sodass es 

die void * Spezialisierung nicht mehr inkludiert. Das bedeutet, dass unsere 

allgemeine Pointer-Spezialisierung nun direkt von einer vom Compiler generierten 

Ausprägung des Buffers abgeleitet ist. Abgesehen von einem kleinen 

Stolperstein funktioniert dies natürlich auch... 

Vorsicht Falle: Leitet man eine Spezialisierung von einer bestimmten Ausprägung 

eines Templates ab, die vom Compiler generiert werden muss, so 

kann es je nach Compiler zu einem auf den ersten Blick unerklärlichen Effekt 

kommen: Der Compiler weigert sich die Spezialisierung zu übersetzen mit 

dem Hinweis darauf, dass z.B. in unserem Fall Buffer keine Basisklasse 

der Spezialisierung sei. 

Bei näherem Nachdenken wird dieser Effekt erklärbar: Wenn man von 

einer Klasse ableitet, dann geht der Compiler davon aus, dass die Basisklasse 

auch existiert. Viele Compiler ziehen gar nicht in Betracht, dass sie vielleicht 

selbst dafür verantwortlich sein könnten, diese Basisklasse zuerst einmal aus 

einem Template selbst zu generieren, bevor sie weitermachen. Soll heißen, 

rekursives Generieren von Template-Ausprägungen wird nicht wirklich immer 

unterstützt. 

Zum Glück können wir im Notfall selbst dafür sorgen, dass der Compiler 

eine existierende Instanz vorfindet: Wir brauchen ihn nur früh genug dazu 

zu zwingen, eine solche zu erzeugen und schon ist er zufrieden. Wie erzeugt 

man eine solche? Ganz einfach: Man legt eine entsprechende Variable an. 

Im Fall unseres Programms würde dies z.B. folgendermaßen aussehen: 


7 static Buffer dummy void ptr buffer ; 

8 #include ” b u f f e r c l a s s p t r s p e c i a l i z a t i o n . h” 

In Zeile 7 wird eine sinnlose Variable angelegt, der Compiler erzeugt dadurch 

den notwendigen Code und schon funktioniert die Ableitung klaglos. 

Vorsicht Falle: Ich gebe ja zu, dass es ziemlich dumm aussieht, wenn die 

Lösung zu einer Falle gleich selbst wieder eine andere Falle beinhaltet, aber 

leider ist es in diesem Fall so: 

Manche Leser mögen sich denken, dass es wirklich Verschwendung ist, 

gleich eine globale Variable mit einem Buffer anzulegen, der ja doch nie gebraucht 

wird. Viel weniger Speicher braucht da schon ein Pointer auf einen


solchen Buffer, also nimmt man einen solchen zur Hand und definiert ganz 

einfach so etwas wie: 

Buffer *dummy_ptr__; 

Leider bleibt der Compiler dadurch unbeeindruckt, denn ihm genügt das Wissen, 

dass es sich um einen Pointer handelt und dass er diesen irgendwann einmal 

zu gegebener Zeit typsicher behandeln muss. Zu diesem Zweck braucht 

er allerdings jetzt noch keine konkrete Ausprägung des Buffers zu erzeugen, 

denn die gegebene Zeit ist noch nicht gekommen. Niemand will derzeit 

nämlich mit dem Pointer wirklich arbeiten. Das bedeutet: Verschwendung 

oder nicht, wir brauchen eine “echte” Variable! 

Jetzt aber zurück zum Thema: Wir haben die Hürde des Erzwingens 

der Erzeugung einer Ausprägung durch unsere sinnlose Variable genommen 

und den Compiler überzeugt, dass er das Programm nun wirklich übersetzen 

soll. Damit bekommen wir beim Starten unseres Meisterwerks nun folgenden 

Output: 

g e n e r i c d e f a u l t constructor 




s p e c i a l i z e d d e f a u l t constructor 





































content of i n t 3 2 b u f f e r : g e n e r i c getNext method 

1 , g e n e r i c getNext method




4 

content of f l o a t b u f f e r : g e n e r i c getNext method 




4 

content of i n t 3 2 p t r b u f f e r : s p e c i a l i z e d getNext method 

g e n e r i c getNext method 







4 

content of f l o a t p t r b u f f e r : s p e c i a l i z e d getNext method 








4 

content of c h a r p t r b u f f e r : s p e c i a l i z e d getNext method 


a , s p e c i a l i z e d getNext method 


b , s p e c i a l i z e d getNext method 


c , s p e c i a l i z e d getNext method 


d 










Vorsicht Falle: Neben allen Aspekten der Spezialisierung, die hier angerissen 

wurden, können vor allem Neulinge auf dem Gebiet der Templates 

oft einer Versuchung nicht widerstehen: Sie wollen eine “normale” Klasse 

implementieren, die denselben Namen hat, wie ein Class Template. Dieses 

Unterfangen geht unweigerlich schief, denn Overloading ist nur für Funktionen 

und Methoden definiert, nicht aber für Klassen! Deshalb gilt folgende 

Grundregel: 

Reale Klassen und Class Templates dürfen niemals denselben 

Namen haben! 

Um das Thema der Spezialisierungen abzurunden möchte ich hier nur 

noch kurz anmerken, dass man solche Spezialisierungen in genau derselben 

Form auch mit Function-Templates durchführen kann und dass diese nicht 

auf Class Templates beschränkt sind. Eine explizite Besprechung von Bei-


spielen möchte ich allen Lesern an dieser Stelle ersparen, denn das Schema 

dahinter ist wirklich genau dasselbe, wie wir es eben bei den Class Templates 

besprochen haben. 

13.6 Verschiedenes zu Templates 

Nach dieser langen Abhandlung zum Thema Templates gibt es, neben den 

Aspekten zur Organisation des Source Codes, die in Abschnitt 13.7 noch genauer 

beleuchtet werden, noch zwei Kleinigkeiten, die erwähnt werden sollten: 

1. Ein generischer Typ-Parameter kann bereits innerhalb des Parametrisierungsteils 

eines Templates (also innerhalb der spitzen Klammern) als 

existenter Typ verwendet werden, nachdem er dort drinnen deklariert 

wurde. 

2. Es ist auch möglich, dass Methoden innerhalb eines Class-Templates 

selbst wieder Template-Methoden (=Function Templates) sind. 

Zur Verwendung von Typ-Parametern innerhalb des Parametrisierungsteils 

werfen wir am besten einen kurzen Blick auf das folgende Programm 

(generic_param_in_decl_use.cpp): 

1 // g e n e r i c p a r a m i n d e c l u s e . cpp − short demo that a g e n e r i c type 

2 // can be used i n s i d e the type d e c l a r a t i o n part o f a template 

3 



6 



9 

10 template 

11 class GenericStorage 

12 { 



15 public : 

16 GenericStorage ( ) 

17 { 

18 data = i n i t i a l v a l u e ; 

19 } 

20 

21 GenericStorage ( const DataType &data ) 

22 { 

23 data = data ; 

24 } 

25 


27 { 


29 } 

30 



33 { 

34 data = s r c . data ;


36 } 

37 

38 virtual operator DataType ( ) 

39 { 

40 return ( data ) ; 

41 } 

42 } ; 

43 

44 


46 { 

47 GenericStorage dummy; 

48 

49 cout


32 throw ( ) : r e a l p a r t ( s r c . r e a l p a r t ) , 

33 imaginary part ( s r c . imaginary part ) 

34 { 

35 cout

13.7 Source Code Organisation 447 

Dass ein Konstruieren von einer anderen Ausprägung von ComplexNumber 

nur möglich ist, wenn Real- und Imaginärteil zueinander kompatibel sind, 

ist durch die Initialisierung der Members in den Zeilen 40–41 sichergestellt. 

Sollten diese nicht kompatibel sein, dann beschwert sich natürlich sofort der 

Compiler. 

Auffällig an diesem Beispiel ist jedoch der extra implementierte Copy- 

Constructor in den Zeilen 31–36. Wozu brauchen wir diesen, wo doch bereits 

ein Template existiert, von dem eine konkrete Ausprägung der Copy- 

Constructor sein könnte? Die Antwort ist einfach: Der Copy-Constructor ist 

für den Compiler etwas ganz Besonderes und er denkt nicht im Traum daran, 

diesen aus dem Template zu erzeugen. Entweder er existiert explizit, so wie 

hier, oder er wird vom Compiler implizit nach seinen eigenen Regeln erzeugt. 

13.7 Source Code Organisation 

Bisher war immer davon die Rede, dass der Compiler nur dann den Code für 

eine konkrete Ausprägung eines Templates generieren kann, wenn er ihn auch 

vollständig sieht. Deshalb waren Deklaration und Definition aller Templates 

bisher immer vollständig in unseren Header Files enthalten. Schöner wäre 

es allerdings, wenn wir wieder zu unserer guten alten Methode greifen und 

die Deklarationen in einen Header, die Definitionen jedoch in ein cpp File 

schreiben könnten. 

Einen weiteren Aspekt gibt es noch, der bei Templates zu beachten ist: 

Der Scope des Compilers ist immer auf eine einzige sogenannte Compilation 

Unit beschränkt, also salopp gesprochen auf ein cpp File. Das bedeutet 

bei der Verwendung von Templates Folgendes: Wenn ein Header mit Template 

Deklarationen und Definitionen in mehreren Files inkludiert ist, dann 

erzeugt der Compiler bei jedem einzelnen File, das er getrennt übersetzt, alle 

benötigten konkreten Ausprägungen der Templates von Neuem. Nehmen 

wir als Beispiel an, dass wir in einem Programm vier verschiedene cpp Files 

haben. In jedem einzelnen dieser Files würde unser Buffer Template Header 

inkludiert werden und in jedem einzelnen File würde ein Buffer gebraucht 

werden. So, wie wir bisher mit Templates gearbeitet haben, würde 

der Compiler nun auch für jedes der einzelnen Files eine neue, identische 

konkrete Ausprägung ein- und desselben Buffers für int32 erzeugen. Zum 

Glück ist von Seiten des Compilers dafür gesorgt, dass diese identischen Ausprägungen 

nur innerhalb einer Compilation Unit sichtbar sind, sonst würde 

sich der Linker beschweren. Nichts desto Trotz haben wir es hier mit sinnlos 

erzeugtem Code zu tun, denn es würde ja reichen, dass eine Ausprägung 

einmal erzeugt wird und dann einfach in den anderen Compilation Units 

wiederverwendet wird, wenn sie schon existiert. 

Leider habe ich an dieser Stelle mehr schlechte als gute Nachrichten. Es 

ist nämlich im Prinzip nicht möglich, die Definition eines Templates einfach 

in ein getrenntes File zu schreiben, das für sich allein übersetzt und dann zum


Executable dazugelinkt wird. Das Problem hierbei ist, dass sich der Compiler 

für jede einzelne übersetzte Compilation Unit merken müsste, welche 

konkreten Ausprägungen eines Templates er jetzt braucht. Nachdem er auf 

diese Art alle Files übersetzt hat, müsste er die Liste der gebrauchten Ausprägungen 

nehmen. Mit Hilfe dieser Liste müsste er die Compilation Unit 

übersetzen, welche die entsprechenden Definitionen enthält, damit er auch 

wirklich den gesamten benötigten Code erzeugt. Leider tut das der Compiler 

nicht und es gibt auch keinen vorgegebenen Weg im Standard, wie er 

das tun sollte. Das bedeutet, dass wir die Geschichte mit dem Aufteilen in 

Deklarationen und Definitionen im Prinzip vergessen können. 

Es gibt jedoch zum Glück auch eine gute Nachricht: Im C ++ Standard ist 

ein Weg vorgegeben, wie der Compiler dafür sorgen kann und soll, dass nicht 

ein und dieselbe Ausprägung eines Templates für jede einzelne Compilation 

Unit immer wieder von Neuem gebaut wird und damit den Code unnötig 

aufbläst: Man kann Definitionen mit dem Keyword export versehen. Der 

Compiler reagiert laut Standard, wenn er auf eine gewünschte Ausprägung 

eines Templates stößt folgendermaßen: 

1. Er sieht nach, ob es schon eine zuvor erzeugte, exportierte Ausprägung 

in der Form gibt, wie sie gerade gebraucht wird. 

2. Wenn ja, wird sie einfach verwendet. 

3. Wenn nein, wird eine neue erzeugt und für eventuellen späteren Gebrauch 

exportiert. 

Leider hat auch das einen Haken: Nur ausgesprochen wenige Compiler beherrschen 

den Export und die Wiederverwendung von speziellen Ausprägungen 

außerhalb der Compilation Unit, in der sie erzeugt wurden :-(. 

Zumindest aber ist die Existenz eines Standard-Vorgehens ein gutes Zeichen, 

dass sich die Situation diesbezüglich bald zum Guten ändern könnte. 

Deshalb möchte ich für Templates die folgende Vorgehensweise anregen: 

• Man schreibt einen Header, in dem nur die Deklarationen enthalten sind. 

Das ist im Prinzip der einzige Teil, den Benutzer von Templates wirklich 

zu sehen bekommen sollen. 

• Man schreibt ein cpp File, in dem alle benötigten Definitionen enthalten 

sind. Hierbei ist jede Definition mit export zu versehen, in der Hoffnung, 

dass in Kürze die Compiler damit wirklich etwas anfangen können :-). 

• Man inkludiert dieses cpp File am Ende des Headers. Mir ist schon bewusst, 

dass sich nun bei vielen Lesern die Zehennägel aufrollen, denn ein 

cpp File sollte man beim besten Willen nicht inkludieren. Alle Leser, die 

dies wirklich außerordentlich stört, können auch gerne eine andere Extension, 

wie z.B. tcpp (für Template-cpp) oder die auch gebräuchliche Extension 

tcc verwenden. In persönlich bevorzuge die Methode, alles, was 

mit Templates zu tun hat, getrennt vom Rest der Headers und Sources, in 

einem eigenen Subdirectory zu halten und cpp zu verwenden.


Dadurch ist zwar weiterhin alles, also auch die Definition, inkludiert, jedoch 

bekommen die User der Templates nicht mehr alles auf einmal zu Gesicht, 

was sie im Prinzip gar nicht sehen sollen. Sie sollen sich ja nur für die 

Deklarationen interessieren, nicht für die Definitionen. 

• Der so in zwei Teile zerlegte Header wird wie gewohnt von den benutzenden 

Teilen des Templates eingebunden. 

Am Beispiel betrachtet sieht dies also folgendermaßen aus: Wir schreiben 

eine Template Deklaration (generic_storage.h). 

1 // g e n e r i c s t o r a g e . h − j u s t the d e c l a r a t i o n o f the g e n e r i c 

2 // storage template 

3 

4 #ifndef g e n e r i c s t o r a g e h 

5 #define g e n e r i c s t o r a g e h 

6 

7 template 

8 class GenericStorage 

9 { 



12 public : 

13 GenericStorage ( ) 

14 throw ( ) ; 

15 

16 GenericStorage ( const DataType &data ) 

17 throw ( ) ; 

18 


20 throw ( ) ; 

21 



24 throw ( ) ; 

25 

26 virtual operator DataType ( ) 

27 throw ( ) ; 

28 

29 } ; 

30 

31 // the f o l l o w i n g i n c l u s i o n i s unfortunately not avoidable 

32 #include ” g e n e r i c s t o r a g e . cpp” 

33 

34 #endif // g e n e r i c s t o r a g e h 

Zu dieser Deklaration schreiben wir die entsprechenden Definitionen in das 

File generic_storage.cpp: 

1 // g e n e r i c s t o r a g e . cpp − d e f i n i t i o n s o f the template methods 

2 

3 #include ” g e n e r i c s t o r a g e . h” 

4 

5 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

6 /∗ 

7 ∗/ 

8 export template 

9 GenericStorage:: GenericStorage ( ) 

10 throw( ) 

11 {


12 } 

13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗/ 


18 GenericStorage:: GenericStorage ( const DataType &data ) 

19 throw( ) 

20 { 

21 data = data ; 

22 } 

23 

24 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

25 /∗ 

26 ∗/ 


28 GenericStorage:: GenericStorage ( const GenericStorage &s r c ) 

29 throw( ) 

30 { 


32 } 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 /∗ 

36 ∗/ 


38 GenericStorage &GenericStorage:: operator = ( 


40 throw( ) 

41 { 



44 } 

45 

46 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

47 /∗ 

48 ∗/ 


50 GenericStorage:: operator DataType ( ) 

51 throw( ) 

52 { 


54 } 

Das Programm, das mit diesem Template arbeiten will, inkludiert wie gewohnt 

einfach unseren Header (generic_storage_test.cpp): 

1 // g e n e r i c s t o r a g e t e s t . cpp − t e s t program f o r the g e n e r i c storage 

2 // template that has been separated i n t o d e c l a r a t i o n and 

3 // d e f i n i t i o n f i l e s 

4 



7 


9 #include ” g e n e r i c s t o r a g e . h” 

10 



13 


15 { 

16 GenericStorage i n t 3 2 s t o r a g e ; 

17 i n t 3 2 s t o r a g e = 0;

18 GenericStorage double storage ( 1 2 . 0 ) ; 

19 


20 GenericStorage i n t 3 2 s t o r a g e 2 = i n t 3 2 s t o r a g e ; 

21 GenericStorage d o u b l e s t o r a g e 2 ; 

22 d o u b l e s t o r a g e 2 = double storage ; 

23 

24 cout

14. Namespaces 

Als letztes Feature im C ++ Sprachstandard kommen wir zu den sogenannten 

Namespaces, die man sehr sinnvoll zur Modularisierung von Software einsetzen 

kann. Mit Hilfe von Namespaces kann man logische Gruppierungen 

definieren und gegeneinander abgrenzen. Nehmen wir einfach an, wir hätten 

eine Sammlung von Klassen, Templates und Funktionen, die sich alle um das 

Thema Datenstrukturen drehen. Dann wäre es nur logisch, diese Sammlung 

nach außen hin als Gruppierung z.B. unter dem Namen Datastructures_ 

anzubieten. Grundsätzlich geht das sehr einfach, wie man am folgenden 

Beispiel sehen kann. Als Demonstration, wie man Funktionen in einen Namespace 

verpacken kann, schreiben wir einfach eine beliebige inline Funktion 

und stecken sie in einen Header (something.h): 

1 // something . h − j u s t a dummy function 

2 

3 #ifndef something h 

4 #define something h 

5 


7 



10 

11 namespace Datastructures 

12 { 

13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗/ 

17 inline void doSomething ( ) 

18 { 

19 cout

454 14. Namespaces 

gemeinsamen Namespace haben wollen, dann fällt auf, dass diese einfache 

Klammerung eigentlich noch nicht der Weisheit letzter Schluss sein kann. 

Denn damit müsste ja alles, was zu einem Namespace gehört auch gemeinsam 

in einem File stehen, was sicher nicht im Sinne des Erfinders ist. Zum Glück 

ist dem auch nicht so, denn Namespaces sind offen. Das bedeutet, dass an 

beliebig vielen verschiedenen Orten Teile eines Namespaces existieren können. 

Solange der Bezeichner des Namespaces derselbe ist, werden sie auch vom 

Compiler demselben Namespace zugerechnet. Mit jeder neuen Definition, 

die zu einem Namespace gehört, wird dieser also erweitert. Genau diese 

Eigenschaft nützen wir in einem kurzen Beispiel aus. Werfen wir einen Blick 

auf ein Template eines primitiven Stacks (simple_stack.h): 

1 // s i m ple stack . h − a simple stack template 

2 

3 #ifndef s i m p l e s t a c k h 

4 #define s i m p l e s t a c k h 

5 



8 


10 { 



13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗ Stack 

17 ∗ 

18 ∗ j u s t a simple stack template 

19 ∗ 

20 ∗/ 

21 

22 template 

23 class Stack 

24 { 

25 public : 


27 private : 

28 Stack ( const Stack&) {} 

29 const Stack& operator = ( 

30 const Stack&) { return (∗ this ) ; } 


32 ElementType ∗ elements ; 


34 public : 

35 Stack ( ) 

36 throw( b a d a l l o c ) : num elements (0) 

37 { 

38 elements = new ElementType [MAX NUM ELEMENTS] ; 

39 } 

40 

41 virtual ˜ Stack ( ) 

42 throw( ) 

43 { 

44 delete [ ] elements ; 

45 } 

46 

47 virtual void push ( ElementType const &element ) 

48 throw( r a n g e e r r o r )

49 { 

50 i f ( num elements >= MAX NUM ELEMENTS) 

51 throw r a n g e e r r o r ( ” stack overflow ” ) ; 

52 elements [ num elements ++] = element ; 

53 } 

54 

55 virtual ElementType pop ( ) 


57 { 

58 i f ( num elements





36 char ∗ elements ; 

37 public : 

38 CharBuffer ( ) 


40 

41 

42 virtual ˜ CharBuffer ( ) 

43 throw( ) 

44 { 


46 } 

47 

48 virtual void put ( char element ) 


50 

51 virtual char getNext ( ) 


53 } ; 

54 

55 } // end namespace Datastructures 

56 

57 #endif // c h a r b u f f e r h 

Die Definition der Methoden ist erwartungsgemäß in char_buffer.cpp zu 

finden, was sich dann so liest: 

1 #include ” c h a r b u f f e r . h” 

2 


4 { 

5 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

6 /∗ 

7 ∗/ 

8 CharBuffer : : CharBuffer ( ) 


10 { 

11 num elements = 0; 


13 w r i t e i n d e x = 0; 

14 num elements allocated = 0 ; // j u s t in case new f a i l s . . . 

15 elements = new char [MAX NUM ELEMENTS] ; 

16 num elements allocated = MAX NUM ELEMENTS; 

17 } 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 /∗ 

21 ∗/ 

22 void CharBuffer : : put ( char element ) 


24 { 

25 i f ( num elements >= num elements allocated ) 

26 throw r a n g e e r r o r ( ” b u f f e r overflow ” ) ; 

27 num elements ++; 

28 elements [ w r i t e i n d e x ++] = element ; 

29 i f ( w r i t e i n d e x >= num elements allocated ) 

30 w r i t e i n d e x = 0; 

31 } 

32 

33 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

34 /∗ 

35 ∗/

36 char CharBuffer : : getNext ( ) 


38 { 

39 i f ( num elements = num elements allocated ) 


45 return ( element ) ; 

46 } 

47 

48 } // end namespace Datastructures 

14. Namespaces 457 

Wie zu erwarten war, muss man auch die Definitionen in denselben Namespace 

verpacken, in dem schon die Deklarationen zu finden waren. Verabsäumt 

man das, so ist der Compiler recht unglücklich damit, weil er nicht 

erkennen kann, zu welcher Deklaration die Definition gehört. 

Wir haben also nun einen Namespace Datastructures_ definiert, in dem 

ein Buffer, ein Stack Template und eine (zugegeben recht sinnlose) Funktion 

enthalten sind. Wie man nun prinzipiell mit diesem Namespace umgeht, zeigt 

unser Demoprogramm (first_namespace_demo.cpp): 

1 // first namespace demo . cpp − demo how to use namespaces 

2 


4 

5 #include ” simple stack . h” 

6 #include ” c h a r b u f f e r . h” 

7 #include ”something . h” 


9 



12 


14 { 

15 Datastructures : : Stack a stack ; 

16 Datastructures : : CharBuffer a b u f f e r ; 

17 

18 Datastructures : : doSomething ( ) ; 

19 

20 a stack . push ( 1 ) ; 

21 a stack . push ( 2 ) ; 

22 a stack . push ( 3 ) ; 

23 a stack . push ( 4 ) ; 

24 

25 cout


39 Datastructures : : CharBuffer : :MAX NUM ELEMENTS


tion stehen, also in unserem Fall z.B. in Zeile 15, dann würde sich die Verwendung 

von cout ohne Scope Operator auf die main Funktion beschränken. 

Spinnt man diesen Gedanken mit der Sichtbarkeit weiter, so kann man 

sich leicht vorstellen, dass eine using Direktive, die innerhalb eines Namespaces 

steht, für den gesamten Namespace gilt. Dieses Feature wird gerne 

verwendet, wenn ein großes Modul mit mehreren kleinen Submodulen arbeitet. 

Alle Teile des Namespaces können hierbei auf die Submodule ohne 

besonderen Scope zugreifen, die Programmteile, die außerhalb des Namespaces 

stehen, aber nicht. Durch diesen Mechanismus kann man sehr gut 

gewisse Implementationsdetails vor den Benutzern einer Library verstecken. 

Neben der Verwendung von using für einzelne Teile eines Namespaces 

gibt es auch noch die Möglichkeit mit einer einzigen Anweisung gleich den 

gesamten Namespace sichtbar zu machen. Wollten wir unseren gesamten 

Namespace Datastructures_ sichtbar machen, würden wir Folgendes schreiben: 

using namespace Datastructures_; 

Damit wären alle Elemente aus unserem Namespace ohne expliziten Scope 

ansprechbar. Ich möchte jedoch darauf hinweisen, dass diese Vorgehensweise 

wirklich nur in besonderen Fällen sinnvoll ist. Im Normalfall ist es besser, einzelne 

Elemente aus einzelnen Namespaces einzubinden um Überraschungen 

zu verhindern. Es könnte ja sein, dass in einem Namespace gewisse Elemente 

enthalten sind, die eigentlich nur für den privaten Gebrauch innerhalb der 

Implementation dieses Namespaces gedacht sind. Mir ist schon klar, dass 

das eigentlich nur aufgrund von eher mangelhaftem Design von Namespaces 

passieren kann, aber man soll niemanden in Versuchung führen :-). 

Es gibt auch noch einen anderen Grund, warum man nicht gleich ganze 

Namespaces automatisch sichtbar machen soll: Was passiert, wenn in zwei 

Namespaces zufällig Elemente unter demselben Namen existieren? Dann 

kann sich der Compiler beim Aufruf ohne Scope nicht wirklich entscheiden, 

welches Element denn nun gemeint ist. In einem solchen Fall wird man also 

dann erst recht wieder gezwungen, mit einem expliziten Scope zu arbeiten, 

um den Compiler zu beruhigen. 

Einen Fall allerdings gibt es, in dem der Compiler einen Name-Clash selbst 

auflöst: Nehmen wir an, wir hätten in unserem Namespace Datastructures_ 

die Direktive 

using namespace SomeStacks_; 

und im Namespace SomeStacks_ hätten wir, so wie in Datastructures_, eine 

Funktion doSomething mit denselben Parametern. Ruft man in einem Codestück 

innerhalb des Namespaces Datastructures_ nun doSomething auf, 

so wird automatisch die Implementation aus dem eigenen Namespace genommen 

und nicht die sichtbar gemachte Implementation aus SomeStacks_. 

Aus gutem Grund möchte ich allen Lesern raten, die Bezeichner von 

Namespaces immer sprechend und nicht zu kurz zu machen. Namespaces 

mit Bezeichnern wie z.B. DS (für Datastructures_) sind um jeden Preis


zu vermeiden. Durch solche Bezeichner besteht die große Gefahr, dass man 

irrtümlich Namespaces, die miteinander nichts zu tun haben, zu einem gemeinsamen 

größeren Namespace vereint, bloß weil die Namen zufällig dieselben 

sind. Das ist sicher nicht im Sinne des Erfinders und vor allem sind 

dadurch Name-Clashes praktisch vorprogrammiert. Nun gibt es aber Fälle, 

in denen man kein explizites using für viele verschiedene Elemente aus einem 

Namespace schreiben will, weil man jedes einzelne für sich eigentlich nicht 

oft genug braucht, um das zu rechtfertigen. Andererseits aber braucht man 

trotzdem den Scope auf diesen Namespace ziemlich oft, weil man es eben 

mit vielen verschiedenen Namespaces zu tun hat. Für solche Fälle gibt es 

die Möglichkeit, einem Namespace ein Alias zu geben. Wollte man z.B. das 

Alias DS für Datastructures_ im Code verwenden, so kann man folgendes 

Statement schreiben: 

namespace DS = Datastructures_; 

Ich würde jedoch wirklich zur Vorsicht mahnen, denn man kann Code dadurch 

ziemlich verwirrend und damit unlesbar machen. 

Zu guter Letzt möchte ich noch auf eine Möglichkeit hinweisen, die man 

mit Namespaces hat und die eigentlich wie ein Paradoxon klingt: Es gibt 

auch sogenannte unnamed Namespaces. Man kann z.B. die folgenden Zeilen 

schreiben: 

1 namespace 

2 { 

3 void f ( ) 

4 { 

5 // whatever code 

6 } 

7 // some code 

8 f ( ) ; // c a l l s the function f defined above 

9 } 

Hierdurch hat man einen unnamed Namespace verwendet, der einzig und 

allein die Aufgabe hat, die Funktion mit dem glorreichen Namen f davor 

zu schützen, einer anderen Funktion f in die Quere zu kommen, die an einem 

anderen Ort definiert sein könnte. Der Aufruf von f() in Zeile 8 findet 

aufgrund der zuvor genannten Auflösungsstrategie sicher zuerst die im Namespace 

definierte Funktion f. 

Allerdings kann ich zu dieser Vorgehensweise wirklich nur noch sagen, 

dass es wohl keinen schlimmeren Hack gibt als solche sinnlosen Funktionsnamen. 

Sollte man jemals in die Situation kommen, einen unnamed Namespace 

zu brauchen, dann sollte man lieber einmal stark darüber nachdenken, ob 

nicht ein Umschreiben des Codes dringend vonnöten wäre. Bei sauber geschriebenem 

Code ist die Wahrscheinlichkeit praktisch Null, dass man jemals 

unnamed Namespaces brauchen würde. Natürlich kann man jetzt auch das 

Argument bringen, dass es ja z.B. alten Code gibt, den man wiederverwenden 

möchte und der eben leider einmal nicht so toll ist. Aber auch dann würde 

ich sehr dringend (!) zu einer Überarbeitung raten. Durch das Kaschieren 

von schlimmen Hacks hat man das Problem ja doch nur verschoben und nicht 

aus der Welt geschafft!


Ein gutes Haar muss ich allerdings trotzdem an den unnamed Namespaces 

lassen: In C ++ wird zwar die Verwendung des Keywords static bei globalen 

Variablen zum Einschränken der Sichtbarkeit auf die Compilation Unit 

weiterhin aus Kompatibilitätsgründen unterstützt. Jedoch wird angeraten, 

dieses Feature nicht mehr zu verwenden und stattdessen unnamed Namespaces 

zum Einsatz zu bringen. Wenn also kein schlimmer Hack vorliegt, wie 

im Beispiel zuvor, man sich aber trotzdem vor eventuellen Name-Clashes aus 

Vorsichtsgründen schützen will, dann sind unnamed Namespaces ein sauberes 

Mittel zum Zweck.

15. Verschiedenes 

In diesem Kapitel werden Aspekte von C ++ behandelt, die aus verschiedenen 

Gründen keinen guten Platz im bisherigen Text bekommen konnten. Sie 

hätten den Aufbau entweder durch starke Vorgriffe oder durch starke Nebenläufigkeit 

zu sehr verletzt. 

15.1 mutable Member Variablen 

Es wurde in Abschnitt 6.1 als auch in Abschnitt 9.4.1 bereits erwähnt, dass 

es eine saubere Alternative zum const_cast gibt. Es ist nämlich in C ++ 

möglich, bestimmte Member-Variablen als mutable zu deklarieren. Damit 

dürfen sie auch im Fall eines mit const vor Veränderung geschützten Objekts 

modifiziert werden, ohne dass sich der Compiler beschwert. Durch 

mutable steht also ein sauberer Mechanismus zur Verfügung, logische von 

physikalischer Konstanz zu trennen. Am Beispiel sieht das folgendermaßen 

aus (mutable_demo.cpp): 

1 // mutable demo . cpp − demo how mutable o b j e c t s help to avoid 

2 // the nasty c o n s t c a s t 

3 



6 



9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 /∗ 

12 ∗ ClassWithCache 

13 ∗ 

14 ∗ j u s t a dummy c l a s s with a cache 

15 ∗ 

16 ∗/ 

17 

18 class ClassWithCache 

19 { 


21 mutable uint32 c a c h e d r e s u l t ; 

22 mutable bool d i r t y ; 

23 uint32 o r i g i n a l ; 

24 public : 

25 ClassWithCache ( ) 

26 throw ( ) : c a c h e d r e s u l t ( 0 ) ,

464 15. Verschiedenes 

27 d i r t y ( true ) , 

28 o r i g i n a l ( 0 ) { } 

29 

30 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

31 virtual ˜ ClassWithCache ( ) 

32 throw( ) { } 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 virtual void s e t O r i g i n a l ( uint32 o r i g i n a l ) 

36 { 

37 o r i g i n a l = o r i g i n a l ; 

38 d i r t y = true ; 

39 } 

40 

41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 virtual uint32 g e t O r i g i n a l ( ) const 

43 { 

44 return ( o r i g i n a l ) ; 

45 } 

46 

47 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

48 virtual uint32 getResult ( ) const 

49 { 

50 i f ( d i r t y ) 

51 { 

52 cout

15.2 Unions im OO Kontext 465 

an object s t o r e s the o r i g i n a l 17 

a f t e r the c a l c u l a t i o n the r e s u l t i s : c a l c u l a t i n g r e s u l t . . . 

34 a l l f u r t h e r r e q u e s t s come from the cache : 

j u s t taking cached r e s u l t . . . 

34 

j u s t taking cached r e s u l t . . . 

34 

Diese Art des Cachings ist in vielen verschiedenen Situationen sehr brauchbar, 

vor allem auch, wenn es um Netzwerk- und Plattenzugriffe geht. Dort liegt 

dann auch einer der Haupteinsatzbereiche von mutable Member Variablen 

in der Praxis. 

Vorsicht Falle: Man kann gar nicht oft genug davor warnen: Sowohl ein 

const_cast als auch mutable Members sind ausschließlich dann einzusetzen, 

wenn auch wirklich die logische Konstanz eines Objekts gewahrt bleibt! Fehler, 

die dadurch entstehen, dass sich ein Objekt nicht mehr logisch konstant 

verhält, sind unglaublich schwer zu lokalisieren und ziehen zumeist lange 

Nächte mit hohem Kaffeeverbrauch im Zuge einer verzweifelten Debugging 

Session nach sich. 

15.2 Unions im OO Kontext 

In Abschnitt 2.4.3 wurden bereits die Grundeigenschaften von Unions und 

auch die Gefahren bei ihrer Nutzung erklärt. Da zu diesem Zeitpunkt aber die 

OO Konzepte von C ++ noch nicht bekannt waren, musste ich einige Aspekte 

schuldig bleiben, die ich in der Folge nachholen werde. Wenden wir uns zu 

diesem Zweck also am besten einem einfachen Beispiel zu (union_demo.cpp): 

1 // union demo . cpp − demo f o r unions in the OO context 

2 

3 



6 




10 using std : : bad cast ; 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

13 /∗ 

14 ∗ DummyUnion 

15 ∗ 

16 ∗ j u s t a dummy union f o r demo purposes 

17 ∗ 

18 ∗/ 

19 

20 union DummyUnion 

21 { 

22 private : 

23 DummyUnion( const DummyUnion&) {} 

24 const DummyUnion& operator = ( const DummyUnion&) { return (∗ this ) ; } 

25 public :


26 uint32 u i n t 3 2 v a l u e ; 

27 double double value ; 

28 

29 DummyUnion( ) 

30 throw( ) 

31 { 

32 cout

92 } 

93 


94 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

95 virtual operator uint32 ( ) 


97 { 

98 i f ( c u r r e n t t y p e ! = UINT32 TYPE) 

99 throw bad cast ( ) ; 

100 return ( the union . u i n t 3 2 v a l u e ) ; 

101 } 

102 

103 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

104 virtual operator double ( ) 


106 { 

107 i f ( c u r r e n t t y p e ! = DOUBLE TYPE) 

108 throw bad cast ( ) ; 

109 return ( the union . double value ) ; 

110 } 

111 

112 } ; 

113 

114 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

115 UnionEncapsulation : : UnionEncapsulation ( 

116 const UnionEncapsulation & s r c ) 

117 throw ( ) : c u r r e n t t y p e ( s r c . c u r r e n t t y p e ) 

118 { 

119 switch ( c u r r e n t t y p e ) 

120 { 

121 case UINT32 TYPE: 

122 the union . u i n t 3 2 v a l u e = s r c . the union . u i n t 3 2 v a l u e ; 

123 break ; 

124 case DOUBLE TYPE: 

125 the union . double value = s r c . the union . double value ; 

126 break ; 

127 default : 

128 c u r r e n t t y p e = NO TYPE; // a l s o an exception would be ok here 

129 case NO TYPE: 

130 break ; 

131 } 

132 } 

133 

134 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

135 UnionEncapsulation& UnionEncapsulation : : operator = ( 

136 const UnionEncapsulation & s r c ) 

137 throw( ) 

138 { 

139 c u r r e n t t y p e = s r c . c u r r e n t t y p e ; 

140 switch ( c u r r e n t t y p e ) 

141 { 

142 case UINT32 TYPE: 

143 the union . u i n t 3 2 v a l u e = s r c . the union . u i n t 3 2 v a l u e ; 

144 break ; 

145 case DOUBLE TYPE: 

146 the union . double value = s r c . the union . double value ; 

147 break ; 

148 default : 

149 c u r r e n t t y p e = NO TYPE; // a l s o an exception would be ok here 

150 case NO TYPE: 

151 break ; 

152 } 


154 } 

155 

156 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 



158 { 

159 UnionEncapsulation encap ; 

160 

161 encap . setValue ( ( uint32 ) 1 0 ) ; 

162 

163 try 

164 { 

165 cout


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.


15.3 Funktionspointer 

Wie bereits in Abschnitt 6.2.4 erwähnt, gibt es auch in C ++ die bereits 

von C her bekannten Funktionspointer. Man kann einfach eine entsprechende 

Pointervariable definieren und ihr als Adresse die Einsprungadresse 

einer Funktion zuweisen. In C ++ kann man Funktionspointer allerdings 

nicht nur auf Funktionen zeigen lassen, sondern unter anderem auch auf 

Member-Methoden. Sehen wir uns hierzu einfach ein kleines Beispiel an 

(function_pointer_demo1.cpp): 

1 // function pointer demo1 . cpp − f i r s t demo f o r function p o i n t e r s 

2 



5 



8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 uint32 aCalculationFunction ( uint32 val ) 

11 { 

12 return ( val ∗ 5 ) ; 

13 } 

14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

16 uint32 anotherCalculationFunction ( uint32 val ) 

17 { 

18 return ( val + 17); 

19 } 

20 

21 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

22 /∗ 

23 ∗ CalcMethodCollection 

24 ∗ 

25 ∗ j u s t a dummy c o l l e c t i o n of c a l c u l a t i o n methods 

26 ∗ 

27 ∗/ 

28 

29 class CalcMethodCollection 

30 { 

31 private : 

32 CalcMethodCollection ( ) ; 

33 CalcMethodCollection ( const CalcMethodCollection &) {} 

34 const CalcMethodCollection& operator = ( const CalcMethodCollection&) 

35 { return (∗ this ) ; } 

36 public : 

37 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

38 static uint32 aSpecialCalculationFunction ( uint32 val ) 

39 { 

40 return ( val ∗ 2 ) ; 

41 } 

42 

43 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

44 static uint32 anotherSpecialCalculationFunction ( uint32 val ) 

45 { 

46 return ( val + 12); 

47 } 

48 } ; 

49 

50 

51 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


53 { 

54 uint32 ( ∗ calcFunction ) ( uint32 ) = aCalculationFunction ; 

55 

15.3 Funktionspointer 471 

56 cout


so ganz genau sagen und ist vom Compiler abhängig. Entweder er lässt das 

Inlining der Methode überhaupt bleiben oder er generiert zwei verschiedene 

Ausprägungen derselben Methode, eine als inline Methode und eine andere, 

die über den Funktionspointer aufrufbar ist. Auch andere Alternativen sind 

möglich, aber eine Diskussion darüber überlasse ich am besten den Compilerbauern 

:-). 

Im obigen Beispiel habe ich bewusst nur static Members demonstriert. 

Wie verhält es sich aber nun mit Funktionspointern auf Members, die nicht 

static sind? Wenn man sich überlegt, dass bei solchen Methoden immer 

auch ein Scope auf die aktuelle Instanz mit im Spiel ist und dass entsprechend 

der this Pointer quasi als versteckter Parameter beim Aufruf mitgegeben 

wird, dann kann man sich leicht vorstellen, dass die Situation hierbei nicht 

mehr ganz so einfach ist. Wenn man einen Pointer auf eine Methode hat, muss 

man also beim Aufruf dafür sorgen, dass irgendwie der Kontext zu einer Instanz 

der Klasse, aus der die Methode kommt, erhalten bleibt. Wie das funktioniert, 

sieht man am folgenden Beispiel (function_pointer_demo2.cpp): 

1 // function pointer demo2 . cpp − demo o f ( something l i k e ) function 

2 // p o i n t e r s to non−s t a t i c methods 

3 



6 



9 

10 

11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

12 /∗ 

13 ∗ CalcMethodCollection 

14 ∗ 

15 ∗ j u s t a dummy c o l l e c t i o n of c a l c u l a t i o n methods 

16 ∗ 

17 ∗/ 

18 

19 class CalcMethodCollection 

20 { 

21 private : 

22 CalcMethodCollection ( const CalcMethodCollection &) {} 

23 const CalcMethodCollection& operator = ( const CalcMethodCollection&) 

24 { return (∗ this ) ; } 


26 uint32 m u l t i p l i c a t o r ; 

27 uint32 o f f s e t ; 

28 public : 

29 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

30 CalcMethodCollection ( uint32 m u l t i p l i c a t o r , uint32 o f f s e t ) 

31 throw ( ) : m u l t i p l i c a t o r ( m u l t i p l i c a t o r ) , 

32 o f f s e t ( o f f s e t ) {} 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 virtual ˜ CalcMethodCollection ( ) { } 

36 

37 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

38 uint32 aCalculatorMethod ( uint32 val ) 

39 { 

40 return ( val ∗ m u l t i p l i c a t o r ) ; 

41 }

42 

15.3 Funktionspointer 473 

43 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

44 virtual uint32 anotherCalculatorMethod ( uint32 val ) 

45 { 

46 return ( val + o f f s e t ) ; 

47 } 

48 } ; 

49 

50 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

51 /∗ 

52 ∗ AnotherCalcMethodCollection 

53 ∗ 

54 ∗ j u s t a demo f o r polymorphism 

55 ∗ 

56 ∗/ 

57 

58 class AnotherCalcMethodCollection : public CalcMethodCollection 

59 { 

60 public : 

61 AnotherCalcMethodCollection ( uint32 m u l t i p l i c a t o r , uint32 o f f s e t ) 

62 throw ( ) : CalcMethodCollection ( m u l t i p l i c a t o r , o f f s e t ) {} 

63 

64 virtual ˜ AnotherCalcMethodCollection ( ) 

65 throw( ) { } 

66 

67 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

68 virtual uint32 anotherCalculatorMethod ( uint32 val ) 

69 { 

70 return ( val + ( 2 ∗ o f f s e t ) ) ; 

71 } 

72 } ; 

73 

74 

75 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


77 { 

78 uint32 ( CalcMethodCollection : : ∗ calcFunction ) ( uint32 ) ; 

79 

80 CalcMethodCollection method collection1 ( 2 , 7 ) ; 

81 AnotherCalcMethodCollection method collection2 ( 2 , 7 ) ; 

82 

83 calcFunction = &CalcMethodCollection : : aCalculatorMethod ; 

84 cout


Prinzip gleich, wie wir es schon gewohnt sind, nur dass auch der Scope auf 

die Klasse mit angegeben werden muss, in der die Methode zu finden ist. 

Zeile 78 ist also folgendermaßen zu lesen: Die Variable calcFunction ist 

ein Pointer auf eine beliebige Methode der Klasse CalcMethodCollection, 

die einen uint32 als Parameter nimmt und einen uint32 als return-Value 

liefert. 

Das bedeutet also, dass man dieser Variable alle Methoden zuweisen kann, 

die diese Bedingung erfüllen. In Zeile 80 erzeugen wir eine Instanz unserer 

CalcMethodCollection, die den Kontext für einen Aufruf bietet. In Zeile 83 

sieht man, wie man die Zuweisung an unsere Variable bewerkstelligt: Man 

weist einen Pointer auf die Methode zu. Hierbei braucht man, im Gegensatz 

zu Funktionen und static Methoden, tatsächlich den & Operator um den 

Compiler davon zu überzeugen, dass man wirklich die Adresse der Methode 

zuweisen will. 

Jetzt habe ich allerdings zuvor noch groß davon gesprochen, dass man 

ja eine Methode nur im Kontext der Instanz eines Objekts aufrufen kann. 

Bisher ist aber von einer solchen Instanz noch keine Rede, obwohl man sie 

bei der Zuweisung eigentlich erwartet hätte. Des Rätsels Lösung zeigt sich in 

den Zeilen 84–85: Der Kontext wird beim Aufruf der Methode hergestellt! 

Die Zeilen 87–89 zeigen, dass man auch virtual Methoden an einen solchen 

Funktionspointer zuweisen kann. Dass dadurch auch im Fall des Aufrufs 

über einen Funktionspointer die Eigenschaft des Polymorphismus erhalten 

bleibt, zeigen die Zeilen 92–93: Hier wird nur die zuvor zugewiesene Methode 

in einem anderen Kontext aufgerufen, nämlich im Kontext einer Instanz 

eines von CalcMethodCollection abgeleiteten Objekts. Dass hierbei erwartungsgemäß 

die entsprechende Methode in der abgeleiteten Klasse aufgerufen 

wird, zeigt der Output des Programms: 

c a l l i n g calcFunction ( 3 ) : 6 

c a l l i n g calcFunction ( 3 ) : 1 0 

c a l l i n g calcFunction ( 3 ) : 1 7 

Dadurch bedingt, dass man bei Pointern auf nicht static Members immer 

beim Aufruf die Verbindung zu einem Objekt hergestellt werden muss, hat 

man nicht mehr ganz die Flexibilität, die man bei Pointern auf Funktionen 

und static Members hatte. Man kann nicht einfach “irgendeine” Methode 

aufrufen, die jemand einmal zugewiesen hat, ohne die Klasse und sogar das 

Objekt dazu zu kennen. Aus diesem Grund stehe ich auf dem Standpunkt, 

dass man Pointer auf Methoden eigentlich auch wirklich nicht Funktionspointer 

nennen sollte, sondern Methodenpointer. Dadurch ist nämlich auch 

bereits im Namen ausgedrückt, dass sie eine andere Natur haben und anders 

zu behandeln sind. 

Vorsicht Falle: Neben allen Stolpersteinen, die Funktionspointer von Natur 

aus zu bieten haben (siehe Abschnitt 10.7 aus Softwareentwicklung in 

C ), möchte ich auf eine Falle hinweisen, in die gerade begeisterte Neulinge 

sehr gerne tappen: Funktions- und Methodenpointer können vorsichtig, sel-

15.4 Besondere Keywords, Diagraphs und Trigraphs 475 

ten und sauber angewandt Code flexibler und auch übersichtlicher machen. 

Ein Übermaß an solchen Pointern allerdings macht Code absolut undurchschaubar 

und unwartbar. Vor allem ist dieses Übermaß sehr schnell erreicht! 

Deshalb möchte ich folgenden Tipp geben: Man sollte immer zuerst sehr 

eingehend darüber nachdenken, ob das Ziel, das man erreichen will, nicht 

auch mit sauberen OO Mitteln erreichbar ist. Nur, wenn wirklich Klassen, 

Objekte und Ableitungshierarchien mit allen ihren Eigenschaften, nicht zum 

gewünschten Erfolg führen, sollte man über den Einsatz von Funktions- und 

Methodenpointern nachdenken! 

15.4 Besondere Keywords, Diagraphs und Trigraphs 

Aus Gründen der Vollständigkeit möchte ich auch auf das Thema der sogenannten 

Diagraphs und Trigraphs eingehen, sowie auf besondere Keywords, 

die in C ++ für den Fall existieren, dass gewisse Zeichen auf den Entwicklungsmaschinen 

der Entwickler nicht zur Verfügung stehen. Das Problem, über 

das wir hier sprechen, hat seinen Ursprung darin, dass die Characters [, ], 

{, }, \ und | in manchen europäischen Zeichensätzen schlicht und ergreifend 

nicht vorhanden sind. Stattdessen sind ihre Positionen an besondere, 

sprachabhängige Zeichen vergeben, wie es in einigen der ISO-646 Character 

Sets der Fall ist. Hat man aber diese Zeichen nicht zur Verfügung, wie soll 

man dann ein C ++ Programm schreiben? Um hier Abhilfe zu schaffen, gibt 

es zwei Möglichkeiten, von denen in jedem Fall die erste zu bevorzugen ist: 

1. Man installiert zum Entwickeln zumindest einen Zeichensatz, in dem diese 

Characters zur Verfügung stehen und konfiguriert sowohl den Editor 

als auch das Keyboard entsprechend. 

2. Wenn das aus irgendwelchen Gründen wirklich überhaupt nicht geht, 

bietet C ++ eine Alternative an, die in der Folge besprochen wird. 

Kommen wir zuerst zum Teil der in C ++ lebensnotwendigen Character- 

Sequenzen, die über Keywords zur Verfügung stehen. Verwendung dieser 

Keywords resultiert immerhin noch in lesbarem Code und deshalb sehe ich 

die Verwendung derselben noch als akzeptabel an. Die Rede ist hier von den 

logischen und den Bitoperatoren, die man auch wie folgt schreiben kann:


Operator alternatives Keyword 

&& and 

|| or 

! not 

!= not_eq 

& bitand 

&= and_eq 

| bitor 

|= or_eq 

~ compl 

^ xor 

^= xor_eq 

Das bedeutet also, dass z.B. der Ausdruck 

my_var && your_var 

auch als 

my_var and your_var 

geschrieben werden kann. Wenn es vermeidbar ist, sollte man es nicht tun, 

aber immerhin ist es lesbar. Es gibt Entwickler, denen die Keywords im 

laufenden Code lieber sind als die Originaloperatoren und die sie deswegen 

auch ohne besondere Notwendigkeit verwenden. Ob man dies zulässt ist 

Geschmackssache und eventuell im Coding Standard festzuschreiben. 

Vorsicht Falle: Manche Entwickler sind schon in die Falle getappt, Variablennamen 

wie z.B. and zu vergeben. Abgesehen davon, dass ein solcher 

Name mit an Sicherheit grenzender Wahrscheinlichkeit schwachsinnig ist, ist 

auch der Compiler gar nicht so glücklich darüber, denn es handelt sich ja 

hierbei um ein reserved Keyword mit besonderer Bedeutung. 

Weniger lesbar sind da schon die sogenannten Diagraphs, also Kombinationen 

aus zwei Characters, die für ein besonderes Zeichen stehen und die im 

laufenden Programmcode Verwendung finden: 

Zeichen alternativer Diagraph 

{ 

[ 

# %: 

Als ob Diagraphs nicht schon schlimm genug wären, stellt sich auch ein 

anderes Problem: Was tut man, wenn man in Strings bzw. in Character 

Konstanten diese Zeichen benötigt? Hierzu kann man die Diagraphs nicht 

verwenden, sondern dazu werden die sogenannten Trigraphs, also Kombinationen 

aus drei Characters, herangezogen:

15.5 volatile Objekte 

15.6 RTTI und dynamic cast im OO Kontext 477 

Zeichen alternativer Trigraph 

{ ??< 

} ??> 

[ ??( 

] ??) 

\ ??/ 

~ ??- 

| ??! 

^ ??’ 

# ??= 

Es grenzt zwar schon an einen Overkill, für das Keyword volatile einen eigenen 

Abschnitt zu schreiben, aber für manche, sehr seltene (!) Anwendungen 

ist volatile einfach notwendig und eine Erklärung fand im laufenden Text 

einfach beim besten Willen keinen vernünftigen Platz. 

Manchmal muss man den Compiler daran hindern, besondere Optimierungen 

vorzunehmen, die auf Annahmen des Optimizers über die Datenhaltung 

hinter einer Variable beruhen. Das Standardbeispiel für einen solchen Fall 

ist das Auslesen eines Zeitgebers über eine Pseudo-Konstante. Nehmen wir 

einfach an, wir hätten folgende Deklaration im Programm: 

extern const long timer_clock_; 

Beim Optimieren kann der Compiler im Normalfall zu Recht annehmen, 

dass sich am Inhalt von timer_clock_ nichts ändert, denn es handelt sich ja 

hier um eine Konstante. Dies wäre in unserem Fall aber fatal, denn hier war 

etwas Anderes beabsichtigt: Es sollte nur verhindert werden, dass jemand 

im Programm irrtümlich versucht, an timer_clock_ einen Wert zuzuweisen. 

Hinter dieser Konstanten verbirgt sich jedoch der Zeitgeber und die Variable 

timer_clock_ verändert ihren Wert sehr wohl im Lauf der Zeit, denn sie 

repräsentiert die laufende Uhrzeit. 

Schreibt man die Deklaration um in 

extern const volatile long timer_clock_; 

so hat man damit dem Compiler mitgeteilt, dass eine Optimierung, die auf die 

Eigenschaft, dass der Wert von timer_clock_ konstant bleibt, nicht zulässig 

ist. Damit wird der Compiler von solchen Schritten Abstand nehmen und 

das Auslesen des Zeitgebers funktioniert wie erwartet. 

15.6 RTTI und dynamic cast im OO Kontext 

In Abschnitt 3.6.1 wurden bereits die Grundprinzipien von RTTI besprochen. 

Da zu diesem Zeitpunkt die OO-Mechanismen von C ++ noch nicht bekannt


waren, musste ich in dieser Besprechung allen Lesern Teile der Information 

vorenthalten. Diese fehlenden Teile möchte ich nun hier nachliefern, gemeinsam 

mit interessanten Eigenheiten von dynamic_cast. 

Bisher bekannt ist, dass man mittels typeid den Typ einer Variable erfahren 

kann. Nicht wirklich erklärt wurde, was typeid nun genau liefert 

und was man alles damit tun kann. Hier wenden wir uns am besten einem 

Beispiel zu (rtti_demo.cpp): 

1 // rtti demo . cpp − demo , what can be done with r t t i 

2 




6 



9 using std : : type info ; 

10 using std : : bad typeid ; 


12 

13 

14 

15 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

16 class DummyBase 

17 { 

18 public : 

19 virtual void doSomething ( ) 

20 { 

21 cout


55 const type info &info dummy1 = typeid (dummy1) ; 

56 const type info &info dummy2 = typeid (dummy2) ; 

57 

58 cout ”


Wir haben es hier mit den Deklarationen von drei verschiedenen Klassen 

zu tun, die sicherlich keine nähere Erklärung brauchen. Interessanter sind 

hier schon die Zeilen 54–56, in denen man sieht, dass typeid als return- 

Value eine const Reference auf ein type_info Objekt liefert. Was daran so 

besonders interessant ist, wird gleich noch besprochen, wenden wir uns aber 

zuerst einmal den Zeilen 58–59 zu. In diesen wird überprüft, ob info_base 

vom Typ DummyBase ist. Dies geschieht durch Vergleich der beiden entsprechenden 

type_info Objekte mittels ==. Ein entsprechendes Overloading von 

== ist Teil von type_info. 

Auf dieselbe Art stellen wir auch in den Zeilen 62–63 fest, wie es sich 

mit dem Typ von dummy1 verhält. In den Zeilen 66-67 jedoch passiert im 

Programm etwas ganz Böses: Es werden hier die Pointer auf zwei type_info 

Objekte verglichen um die Gleichheit der Typen festzustellen. Genau das ist 

auch der Punkt, warum zuvor erwähnt wurde, dass es interessant ist, dass 

typeid eine Referenz liefert: Es ist nicht garantiert, dass zu ein und demselben 

Typ immer nur ein einziges type_info Objekt existiert. Das bedeutet, 

dass die Referenzen, die man erhält nicht unbedingt auf dasselbe Objekt zeigen 

müssen. Im Fall von dynamic Libraries wäre eine solche Garantie auch 

unmöglich abzugeben. In unserem Programm aber wird auf diesen Umstand 

keine Rücksicht genommen und es werden einfach die Pointer miteinander 

verglichen. Der Output weiter unten zeigt, dass das genau hier funktioniert, 

es kann allerdings auch fehlschlagen! 

Mittels typeinfo kann man ganz einfach feststellen, ob zwei Objekte genau 

denselben Typ haben, wie man in den Zeilen 75–76 sehen kann. Man 

kann typeid natürlich auf verschiedenste Dinge anwenden, z.B. kann man 

auch den Typ des Resultats einer Operation überprüfen, wie sich in Zeile 96 

erkennen lässt. Auch Funktionspointer besitzen einen Typ. Dies zeigt sich 

an Zeile 97. Dass typeinfo auch eine Exception werfen kann, zeigt sich allerdings 

in den Zeilen 102–103: Hier wird versucht, den Typ eines Objekts 

herauszufinden, indem der Pointer auf das Objekt dereferenziert wird. Das 

wäre auch prinzipiell noch kein Problem und in der Praxis vollkommen legitim 

und üblich. Leider aber handelt es sich genau in diesem speziellen Fall 

um einen 0 Pointer. Wenn dieser Pointer also auf “nichts” zeigt, dann kann 

dieses “Nichts” auch keinen Typ haben. Dementsprechend wirft typeid in 

diesem Fall eine Exception. Würden wir nicht den Typ des Objekts erfahren 

wollen, das sich hinter base_ptr verbirgt, wofür wir den Pointer dereferenzieren 

müssen, sondern den Typ von base_ptr selbst, dann würde es hier 

kein Problem geben. Ein Aufruf von 

typeid(base_ptr) 

würde ganz einfach das entsprechende type_info Objekt liefern, dass einem 

Pointer auf ein DummyBase Objekt entspricht. Was kann man also aus diesem 

Programm bisher lernen?


• Die type_info Objekte unterstützen sowohl den == als auch den != Operator. 

Aussagen über Typen können nur gesichert getroffen werden, wenn 

diese beiden verwendet werden. 

• Keinesfalls dürfen Pointer auf type_info Objekte miteinander verglichen 

werden, denn es ist nicht garantiert, dass es zu einen bestimmten Typ nur 

ein einziges type_info Objekt gibt. 

• Bisher noch nicht erwähnt, aber trotzdem interessant ist, dass type_info 

Objekte die Methode 

bool before(const type_info&) 

unterstützen, die eine Sortierung zwischen solchen Objekten möglich macht. 

Vorsicht Falle: Was sich auch immer bei verschiedenen Implementationen 

als Reihenfolge durch Verwendung von before ergibt sagt überhaupt 

nichts über Ableitungshierarchien aus! Manche Entwickler treffen leider 

Fehlannahmen wie z.B. “ein type_info Objekt der Basisklasse wird genau 

vor dem der davon abgeleiteten Klassen gereiht”. Dies ist falsch, 

auch wenn es manchmal tatsächlich so aussehen könnte, als ob es zutreffen 

würde. 

• Die Methode name dient dem Herausfinden des (internen!) Typnamens 

eines Objekts. 

• Ein Aufruf von type_info kann eine bad_typeid Exception werfen, wenn 

keine Chance besteht, den gefragten Typ herauszufinden. Dies ist bei einem 

dereferenzierten 0 Pointer der Fall. 

So nett die Anwendungsmöglichkeiten von typeid auch sind, eines kann man 

damit nicht tun, nämlich Typkompatibilitäten feststellen, die sich durch 

die Ableitungshierarchie ergeben. Dazu müssen wir unseren bekannten 

dynamic_cast Operator heranziehen und eine Eigenheit desselben ausnützen, 

die bisher noch nicht bekannt ist: In Abschnitt 9.4.4 wurde bereits erwähnt, 

dass dynamic_cast eine bad_cast Exception wirft, wenn ein Cast nicht 

zulässig ist. Das ist allerdings nur die halbe Wahrheit. In Wirklichkeit ist 

dynamic_cast vollständig so definiert: 

• Mittels dynamic_cast können (ausschließlich) Casts zwischen Pointern auf 

Objekte oder zwischen Referenzen auf Objekte durchgeführt werden. 

• Wendet man dynamic_cast auf Pointer an, dann können folgende zwei 

Fälle passieren: 

1. Wenn der Cast zulässig ist, so wird ein Pointer auf das gewandelte Objekt 

geliefert. 

2. Wenn der Cast nicht zulässig ist, so wird ein 0 Pointer geliefert. Es wird 

in diesem Fall keine Exception geworfen! 

Dieses Verhalten ist sehr sinnvoll, denn damit kann man dynamic_cast dazu 

verwenden, Kompatibilitäten festzustellen, ohne eine Exception befürchten 

zu müssen, wie z.B. in Zeile 70 zu sehen ist. Für alle Leser, die mit


Java zu tun haben: Dieses Verhalten entspricht im Prinzip dem, was man 

dort mit instanceof erreicht. 

• Wendet man einen dynamic_cast auf Referenzen an, dann sieht die Welt 

ein wenig anders aus: 

1. Wenn der Cast zulässig ist, so wird eine Referenz auf das gewandelte 

Objekt geliefert. 

2. Wenn der Cast nicht zulässig ist, so wird eine bad_cast Exception geworfen, 

wie man z.B. in Zeile 83 sieht. 

Der Output des Programms bestätigt, dass es sich bei den soeben besprochenen 

Dingen nicht nur um Theorien handelt: 

i s base of type DummyBase? −> 1 

i s dummy1 o f type DummyBase? −> 0 

i s dummy1 o f type DummyClassOne ( bad v e r s i o n )? −> 1 

i s dummy1 compatible with DummyBase? −> 1 

i s dummy1 o f type DummyClassTwo? −> 0 

i s dummy1 o f the same type as dummy2? −> 0 

i s dummy1 compatible with dummy2? −> 0 

oops − dynamic cast f a i l e d . . . 

typeid o f expr : i 

typeid o f main : FiiPPcE 

typeid o f 0 pointer : oops − typeid f a i l e d . . . 

15.7 Weiterführendes zu Exceptions 

In Kapitel 11 wurde alles besprochen, was man im normalen Programmieralltag 

wissen muss, um vernünftig mit Exceptions umgehen zu können. Hier 

möchte ich noch ein wenig weiterführende Information liefern, die manchmal 

sehr nützlich sein kann. Vor allem geht es um Situationen, bei denen man 

in der Entwicklungsphase von Software beim Debugging verzweifelt, denn 

ein Programm wird partout immer zwangsweise vom System beendet, obwohl 

man sich doch eigentlich keines Fehlers bewusst ist. Trotzdem man 

alle nur vorstellbaren try ... catch Konstrukte geschrieben hat, werden 

gewisse Exceptions beim besten Willen nicht ihrer angedachten Behandlung 

zugeführt, sondern stattdessen geht das Programm ansatzlos in den Tiefflug 

über. 

Betrachten wir zuerst das einfachste Problem, das uns über den Weg 

laufen kann: Wir wissen aus verschiedenen Gründen nicht ganz genau, welche 

Exceptions aus einem Funktions- oder Methodenaufruf überhaupt geworfen 

werden können. Dies kann mannigfaltige Gründe haben: Wir können es mit 

Code zu tun haben, der keinen Gebrauch von throw Deklarationen macht 

und zu dem auch keine ausreichende Dokumentation vorhanden ist. Wir 

können es aber auch mit Template- oder Funktionspointer Implementationen 

zu tun haben, bei denen im Vorhinein gar nicht bekannt sein kann, welche 

Exceptions geworfen werden können, denn das hängt immer vom speziellen 

Fall ab. Wie dem auch immer sei, wir suchen nach einer Möglichkeit, alle

15.7 Weiterführendes zu Exceptions 483 

Exceptions zu fangen und aufgrund dessen, was wir gefangen haben, über die 

Behandlung zu entscheiden. Im Prinzip geht das in C ++ sehr leicht, wie man 

in der Folge sehen kann (catch_all_demo.cpp): 

1 // catch all demo . cpp − demo , how to catch a r b i t r a r y exceptions 

2 




6 



9 using std : : type info ; 

10 using std : : bad typeid ; 


12 

13 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

14 class OneException 

15 { 

16 } ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 class AnotherException 

20 { 

21 } ; 

22 

23 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

24 void doSomething ( ) 

25 { 

26 static uint32 c a l l c o u n t e r = 0; 

27 i f ( c a l l c o u n t e r ++ % 2) 

28 { 

29 cout


61 cout


Einfluss nehmen. Die erste Möglichkeit ist, bei einer Methode bzw. Funktion 

die Exception bad_exception durch eine throw Angabe als erlaubte Exception 

zu deklarieren. Darauf reagiert der Compiler und setzt nicht mehr Code 

ein, der das Programm beendet. Stattdessen setzt er Code ein, der im Fall einer 

nicht deklarierten Exception eine bad_exception wirft. Diese wiederum 

kann man nach altbekannter Manier fangen. 

Vorsicht Falle: Nicht alle Compiler folgen dieser Spezifikation, was natürlich 

wieder zu netten Überraschungen führen kann. Deshalb ist es sicherer, gleich 

zur in der Folge vorgestellten Methodik zu greifen, mit der man genau dieses 

Verhalten explizit implementieren kann. 

Die andere Möglichkeit, Einfluss zu nehmen, ist der unexpected_handler, 

der im Prinzip sehr ähnlich funktioniert, wie der new_handler, den wir bereits 

kennen gelernt haben. Sehen wir uns diese beiden Möglichkeiten am 

besten gleich am Beispiel an (unexpected_exc_demo.cpp): 

1 // unexpected exc demo . cpp − demo , how to deal with unexpected 

2 // exceptions 

3 





8 



11 using std : : bad exception ; 

12 using std : : set unexpected ; 

13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


16 { 

17 } ; 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 class AnotherException 

21 { 

22 } ; 

23 

24 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


26 throw( OneException , bad exception ) 

27 { 

28 static uint32 c a l l c o u n t e r = 0; 

29 i f ( c a l l c o u n t e r ++ % 2) 

30 { 

31 cout


43 throw bad exception ( ) ; 

44 } 

45 

46 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


48 { 

49 uint32 count = 0; 

50 

51 void ( ∗ old unexpected handler )() = 

52 set unexpected ( makeBadFromUnexpectedException ) ; 

53 

54 for ( count = 0 ; count < 2 ; count++) 

55 { 

56 try 

57 { 

58 doSomething ( ) ; 

59 } 

60 catch ( OneException &exc ) 

61 { 

62 cout


zumindest kann man noch Handlungen setzen, bevor das Programm über den 

Jordan geschickt wird. Warum man den Abbruch nicht verhindern kann, ist 

einleuchtend: Wird eine Exception geworfen, dann wird das Stack Unwinding 

so lange durchgeführt, bis man bei einem entsprechenden catch angelangt ist. 

Sollte keines gefunden werden, so ist dadurch auch main dem Unwinding zum 

Opfer gefallen. Wie soll man also dann noch im Programm weitermachen? Es 

gibt einfach keinen Punkt mehr, an dem man neu aufsetzen könnte. An einem 

kurzen Beispiel betrachtet, sieht das dann so aus (uncaught_exc_demo.cpp): 

1 // uncaught exc demo . cpp − demo f o r uncaught exceptions 

2 





7 



10 using std : : s e t t e r m i n a t e ; 

11 

12 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


14 { 

15 } ; 

16 

17 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


19 throw( OneException ) 

20 { 

21 cout


zurückkehrt. Man hat nur noch die Chance, selbst so definiert wie möglich 

auszusteigen, bevor das System das von sich aus übernimmt. In Zeile 32 passiert 

genau das. Würde man hier nicht mittels exit aussteigen, und wider 

Erwarten aus der Funktion wieder herauskommen, dann würde automatisch 

abort aufgerufen werden. Den Handler setzt man durch Aufruf der Methode 

set_terminate in Kraft. Der weltbewegende Output dieses sterbenden 

Meisterwerks liest sich dann so: 

throwing OneException 

preMortemExceptionProblemFunction c a l l e d 

time to say good bye . . . 

In Kapitel 11 wurde bereits eindringlichst gesagt, dass man unbedingt dafür 

sorgen muss, dass aus einem Destruktor keine Exceptions geworfen werden. 

Durch das catch(...) Konstrukt haben wir auch jetzt eine schöne Möglichkeit, 

innerhalb eines Destruktors auf alle Eventualitäten zu reagieren und 

heimtückische Exceptions, die aus aufgerufenen Teilen stammen, daran zu 

hindern, aus dem Destruktor hinaus zu fallen. Wie bereits erklärt kann ein 

Destruktor eben im Zuge eines Stack Unwindings aufgerufen werden und 

dann würden bösartigerweise plötzlich zwei Exceptions gleichzeitig auftreten. 

Wenn man darüber genau nachdenkt, dann kommt man allerdings zu 

der Erkenntnis, dass man Exceptions aus einem Destruktor theoretisch schon 

werfen könnte, wenn man nur sicherstellt, dass man nicht gerade im Zuge eines 

Stack Unwindings destruiert wird. Genau das ist auch wirklich der Fall, 

wie im folgenden Beispiel zu sehen ist (destructor_exc_demo.cpp): 

1 // destructor exc demo . cpp − demo f o r exceptions in d e s t r u c t o r s 

2 





7 



10 using std : : s e t t e r m i n a t e ; 

11 using std : : uncaught exception ; 

12 

13 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 


15 { 

16 } ; 

17 

18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

19 /∗ 

20 ∗ VeryBadClass 

21 ∗ 

22 ∗ throws an exception in the d e s t r u c t o r . . . 

23 ∗ 

24 ∗/ 

25 

26 class VeryBadClass 

27 { 

28 public : 

29 virtual ˜ VeryBadClass ( ) 

30 { 

31 cout

32 throw OneException ( ) ; 

33 } 

34 } ; 

35 


36 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

37 /∗ 

38 ∗ BadClass 

39 ∗ 

40 ∗ throws an exception in the d e s t r u c t o r . . . 

41 ∗ 

42 ∗/ 

43 

44 class BadClass 

45 { 

46 public : 

47 virtual ˜ BadClass ( ) 

48 { 

49 cout


98 } 

99 

100 s e t t e r m i n a t e ( old terminate handler ) ; 

101 

102 return ( 0 ) ; 

103 } 

Wir haben es hier mit einer BadClass und mit einer VeryBadClass zu tun. 

Die VeryBadClass zeichnet sich dadurch aus, dass sie ohne Rücksicht auf 

Verluste aus dem Destruktor eine Exception wirft. Die BadClass ist ein wenig 

rücksichtsvoller und wirft nur dann eine Exception, wenn nicht gerade ein 

Stack Unwinding im Gange ist. Ob das der Fall ist, findet man durch Aufruf 

der Funktion uncaught_exception in Zeile 50 heraus. Wenn diese Funktion 

true liefert, dann ist gerade ein Stack Unwinding im Gang, ansonsten nicht. 

In unserem main legen wir in den Zeilen 82–83 zwei Variablen vom Typ 

BadClass an. Sobald die erste der beiden im Zuge des Verlassens des umschließenden 

Blocks ihr Leben verwirkt hat, wirft sie aus dem Destruktor 

eine Exception. Dadurch wird das Stack Unwinding ausgelöst und im Zuge 

dessen wird auch die zweite Variable destruiert. Diese erkennt im Destruktor, 

dass sie sich mit dem Werfen von Exceptions gefälligst zurückhalten soll und 

verhält sich entsprechend brav. Dadurch gelingt es dem Programm, sich bis 

zum entsprechenden catch in den Zeilen 85–88 durchzukämpfen. 

Anders ist die Situation schon bei unserer VeryBadClass. Auch hier wird 

beim ersten Destruktoraufruf eine Exception geworfen, das ein Stack Unwinding 

zur Folge hat. Im Zuge dessen wirft aber auch noch die zweite Instanz 

dieser Klasse schwachsinnigerweise aus dem Destruktor eine Exception. Dadurch 

bleibt gar nichts Anderes mehr übrig, als das Programm zu beenden. 

Wie man am folgenden Output sieht, wird auch dafür wieder der entsprechende 

terminate Handler herangezogen, den wir schon von den uncaught 

Exceptions her kennen. 

BadClass d e s t r u c t o r 

stack unwinding not in progress . . . throwing OneException 

BadClass d e s t r u c t o r 

stack unwinding in progress . . . not throwing an exception 

caught OneException 

VeryBadClass d e s t r u c t o r 

VeryBadClass d e s t r u c t o r 

preMortemExceptionProblemFunction c a l l e d 

time to say good bye . . . 

Vorsicht Falle: Auch wenn man im Destruktor nach entsprechender Absicherung 

Exceptions werfen kann, muss ich zu äußerster Vorsicht mahnen! 

Destruktoren müssen so entworfen werden, dass diese Maßnahme nicht nötig 

ist, sonst landet man irgendwann in Teufels Küche. Die Problematik ist, dass 

man in gewissen Situationen Exceptions nicht werfen kann, weil gerade ein 

Stack Unwinding passiert. Was tut man aber in so einer Situation mit Exceptions, 

die einem im Destruktor von darin aufgerufenen Methoden um die 

Ohren geworfen werden? Ein silent Catch führt garantiert zur Katastrophe!

Teil III 

Ausgesuchte Teile aus der C++ Standard Library

16. Die C++ Standard Library 

Dieser dritte Abschnitt des Buchs ist einer überblicksmäßigen Besprechung 

der C ++ Standard Library gewidmet. Wie zu Beginn des Buchs erwähnt 

wurde, würde eine detaillierte Beschreibung der gesamten Funktionsweise 

und der Designentscheidungen, die zur derzeitigen Form der Library geführt 

haben, bei weitem den Rahmen sprengen. Deshalb beschränke ich mich hier 

darauf, kurz zu erklären, welchen Umfang die Standard Library hat und was 

man prinzipiell damit tun kann. Das Ziel dieses Kapitels ist es also, den 

Lesern ein Gefühl dafür zu vermitteln, bei welchen Problemstellungen sie 

selbst Hand anlegen müssen und wofür bereits wiederverwendbare Lösungen 

existieren. 

Die C ++ Standard Library ist üblicherweise bei Entwicklern unter dem 

Namen STL (=Standard Template Library) bekannt und dementsprechend 

wird auch hier im Buch in der Folge die Bezeichnung STL dafür verwendet. 

Diese Bezeichnung verrät auch bereits sehr viel über die Natur der Library: 

Sie enthält eine größere Menge an Templates zum Lösen von Standardproblemen, 

die sich Entwicklern im Alltag immer wieder stellen. 

16.1 Übersicht 

Es war gerade zuvor die Rede von Standardproblemen, die zum Entwicklungsalltag 

gehören, nun stellt sich also die Frage, welche dieser Probleme es 

wert sind, in eine Standard Library aufgenommen zu werden. Die Entwickler 

der STL scheinen die folgende, sehr logische und lobenswerte Sicht vertreten 

zu haben, als sie entschieden, welchen Umfang die STL haben soll: 

Was sind die prinzipiellen Low-Level Datenstrukturen und Algorithmen, 

die man bei beinahe jeder Problemlösung benötigt? Diese gehören ein für 

alle Mal befriedigend und möglichst allgemeingültig implementiert, sodass sie 

nicht noch unzählige Male von neuem implementiert werden müssen! 

Welche Entwickler kennen nicht die Situation, immer wieder bestimmte 

Datenstrukturen, wie z.B. Listen, Stacks, etc., von neuem implementieren 

zu müssen, da alle ihre anderen Implementationen so spezialisiert für eine 

bestimmte Anwendung sind, dass sie außerhalb dieser Anwendung wieder 

nicht vernünftig verwendet werden können. Nach der x-ten Implementation

494 16. Die C++ Standard Library 

beschließen die Entwickler, dass es nun wirklich an der Zeit wäre, eine allgemeingültige 

Version zu schreiben, die auch den anderen Leuten im Team 

oder in der ganzen Firma zur Verfügung stehen soll. Auf diese Art kam und 

kommt es ständig dazu, dass Dinge, die zum Teil bereits seit der tiefsten 

Steinzeit der Softwareentwicklung bekannt und gelöst sind, wieder und wieder 

von neuem geschrieben werden. Das bedeutet auch, dass gleichermaßen 

immer und immer wieder dieselben Fehler gemacht werden und unter großem 

Arbeits- und Zeitaufwand korrigiert werden müssen. Teilweise Schuld an diesem 

Phänomen hat auch das sogenannte not invented here Syndrom: “Diese 

Implementation kann bei meinem Problem nicht gut funktionieren, weil die 

Entwickler dies und das nicht bedacht haben / anders gemacht haben / etc.” 

Dass solche Kritik nicht so selten auch ihre Berechtigung hat, soll hier gar 

nicht in Frage gestellt werden. 

Die Entwickler der STL hatten also folgende Anforderungen zu erfüllen, 

um die Library auch wirklich für einen möglichst breiten Anwenderkreis einsetzbar 

zu machen: 

• Die STL soll allgemein, verständlich und sinnvoll genug gehalten sein, dass 

sie für Einsteiger und erfahrene Entwickler gleichermaßen einsetzbar ist. 

• Die STL soll nicht nur leicht und sinnvoll bei der Entwicklung von Applikationen 

einzusetzen sein, sondern sie soll auch einfach und sinnvoll als 

Basis-Library für andere Library-Entwicklungen dienen können. 

• Die allgemeinen Implementationen in der STL müssen effizient genug sein, 

dass sie gute Alternativen zu speziellen, sehr problembezogenen Implementationen 

darstellen. 

• Alle Algorithmen, die in der STL Anwendung finden, sollen entweder 

Policy-frei sein, oder eine Policy als Argument nehmen. Das bedeutet, dass 

es z.B. keinen Sortieralgorithmus in der STL geben darf, der auf Gedeih 

und Verderb aufsteigend sortiert und auch zwangsweise die Implementation 

der > < und = Operatoren von den einzelnen Elementen erwartet. Es 

kann ja auch sein, dass man z.B. absteigend sortieren will und dass man eine 

eigene Komparatorfunktion zum Vergleich von Elementen bereitstellen 

will. Dies muss dann über entsprechende selbst implementierbare Policies 

einstellbar sein. 

• Alle Teile der STL müssen so designed sein, dass sie immer nur genau eine 

einzige Aufgabe erfüllen, diese aber so gut wie möglich. Niemals darf eine 

Komponente zwei miteinander gekoppelte Rollen erfüllen, denn dies geht 

erstens zu Lasten der Allgemeinheit und zweitens erlangt man durch explizites 

Verknüpfen zweier spezialisierter Komponenten üblicherweise eine 

bessere Lösung. 

• Komponenten der STL müssen sicher in ihrer Verwendung sein. Das bedeutet, 

dass es nicht vorkommen darf, dass man besondere Interna einer 

Komponente kennen muss, um mit ihr sinnvoll arbeiten zu können und 

z.B. kein Speicherloch zu verursachen. 

• Komponenten der STL müssen typsicher sein.

16.1 Übersicht 495 

• Komponenten der STL müssen sowohl mit Standard-Datentypen als auch 

mit benutzerdefinierten Datentypen gleichermaßen verwendbar sein. 

• Komponenten der STL müssen Dinge so vollständig wie möglich implementieren. 

Das bedeutet, dass sie eine Aufgabe, die sie übernehmen, so 

vollständig implementieren müssen, dass es nicht notwendig ist, für eine 

Standardanwendung eine Erweiterung selbst schreiben zu müssen. Es 

hätte z.B. keinen Sinn, ein Template für eine Liste zu schreiben, in die 

man zwar Elemente einfügen kann, aber aus der man keine Elemente mehr 

entfernen kann. Wenn schon Liste, dann ordentlich :-). 

In kurzen Schlagworten umrissen bedeutet das also, dass das Ziel der STL 

ist, so allgemein wie möglich, so vollständig wie möglich und so robust wie 

möglich zu sein bei gleichzeitiger Wahrung der Intuitivität bei der Verwendung 

und der Effizienz der einzelnen Lösungen. Dass man die STL nicht 

vor fahrlässigem Missbrauch schützen kann, ist sonnenklar. Wie sollte man 

auch verhindern, dass jemand eine falsche Datenstruktur zur Lösung eines 

Problems in einer Applikation verwendet? In jedem Fall muss man der STL 

attestieren, dass sie bei korrekter und sinnvoller Verwendung auch wirklich 

sehr effizient und fehlerfrei arbeitet und Entwicklern sehr viel Zeit erspart! 

So einige Entwickler, die der Meinung waren, dass man die eine oder andere 

Datenstruktur auch besser implementieren kann, wurden sehr schnell eines 

Besseren belehrt. Deshalb kann ich an dieser Stelle allen Lesern nur den Rat 

geben, die STL auch wirklich zu benutzen anstatt selbst das Rad neu zu 

erfinden! 

Sehen wir uns also ganz kurz an, für welche Einsatzgebiete die STL bereits 

vorgefertigte Lösungen anbietet: 

Container: Hierzu werden Templates zum Arbeiten mit Vektoren, Listen, 

Mengen, Queues und Stacks angeboten. Im Prinzip also alles, was man 

im Programmieralltag an verschiedenen Arten von Containern braucht, 

sofern man es nicht gleich mit Datenmengen zu tun hat, die nach einer 

größeren Datenbank verlangen. 

Iterators: Zu den verschiedenen Containern werden, wo sinnvoll, Iterators angeboten, 

mit denen man den Inhalt eines Containers Element für Element 

in wohldefinierter Ordnung (also z.B. vorwärts und rückwärts) durchgehen 

kann. 

Allocators: Aus Gründen der Portierbarkeit will man Memory-Management 

Details, wie z.B. das Wissen über bestimmte Pointer-Typen, Objektgrößen 

und Speicher-Anlege- und Freigabe-Details, sauber kapseln. Alle 

Container der STL sind in Bezug auf die Allocators parametrisierbar, das 

bedeutet, dass sie z.B. nicht selbsttätig nach Gutdünken Objekte anlegen, 

sondern dass sie das Anlegen von einem entsprechenden Allocator 

anfordern. Auf diese Art werden Container unabhängig von speziellen 

Memory Modellen der verwendenden Applikationen. 

Strings: Zwei große Probleme treten bei der Verwendung von simplen char * 

als Strings in Programmen auf:


1. Die Gefahr von Memory Leaks und wild gewordenen Pointern ist 

extrem groß. 

2. Zeichentabellen, wie z.B. Unicode, die mehr als 8 Bits pro Zeichen 

verlangen, sind nachträglich nur extrem schwer bis überhaupt nicht 

in ein existentes Programm einzubauen. 

Die einzig sinnvolle Lösung zum sauberen Umgang mit Strings in Programmen 

ist daher ihre Kapselung in eine eigene Klasse bzw., aus 

Gründen der verschiedenartigen Zeichensatztabellen, in ein Template. 

Streams: Ob es sich nun um Input vom Keyboard, von einem File oder auch 

von einem String handelt und ob der Output auf den Bildschirm oder 

sonstwohin gehen soll, es handelt sich immer um einen Datenstrom. Dieser 

ist in seiner Länge prinzipiell nicht im Vorhinein definierbar und auch 

das Zeitverhalten (z.B. wann wird etwas geschrieben und wie viel) ist 

nicht limitiert. Genau um dieses Verhalten zu modellieren, gibt es die 

sogenannten Streams. 

Numerik: Verschiedene aus dem Bereich der Numerik kommende Datenstrukturen 

(z.B. verschiedene Array-Typen, komplexe Zahlen) und Algorithmen 

zum Rechnen mit diesen werden oft genug in der Praxis verwendet, 

dass sie in die STL Eingang fanden. In diesem Bereich der STL 

sind unter anderem die typischen Funktionen für den Sinus, Cosinus, 

Logarithmus, etc. und natürlich auch die Zufallszahlen enthalten. 

Algorithmen und Funktionsobjekte: In diesem Bereich der Library finden 

sich die typischen Algorithmen, die immer wieder auf Datenstrukturen 

angewandt werden. Vertreter hierfür sind z.B. Transformationen, das 

Vertauschen von Inhalten, etc. 

Wie es auch in den Anforderungen definiert ist, kann man natürlich auf Basis 

der Teile, die in der STL enthalten sind, eigene Komponenten schreiben, 

wie z.B. sehr spezielle Container etc. Um ein Gefühl für die mit der 

STL ausgelieferten Komponenten zu bekommen, ist den verschiedenen oben 

erwähnten Gruppen in der Folge jeweils ein kurzer Abschnitt gewidmet. 

Eine tiefer gehende Beschreibung vieler Design- und Anwendungsaspekte 

können interessierte Leser in [Stroustrup 1997] nachlesen. Ein sehr gutes 

und ausführliches Buch, das sich einzig und allein mit der STL beschäftigt, 

stellt [Musser et al. 2001] dar. Außerdem gibt es im Internet einige online- 

Manuals und Tutorials zur STL zum Download. Zu [Stroustrup 1997] möchte 

ich noch erwähnen, dass ich ganz absichtlich auf die Special Edition seines 

Buchs verweise und nicht auf die Standard Edition, da die Special Edition 

gerade durch die sehr tief gehende Diskussion der STL so “special” wird :-). 

Im Prinzip muss man zur STL sagen, dass ihr Inhalt sehr intuitiv verwendbar 

ist, sofern man sich einmal an die doch nicht ganz standardgemäße Namensgebung 

gewisser Methoden gewöhnt hat (z.B. implementiert eine Queue 

Methoden namens push und pop anstatt die sonst üblichen Bezeichnungen 

put und get zu verwenden). Ist man einmal über diese kleine Hürde hinweg, 

kann man den Umgang mit den Komponenten der STL auch einfach durch

16.2 Container 497 

Lesen der entsprechenden Header-Files und durch Ausprobieren sehr leicht 

in den Grundzügen erlernen. Lesern, die den Umgang mit fremdem Code 

noch nicht gewohnt sind, möchte ich diese Vorgangsweise sogar sehr ans Herz 

legen, um ein wenig Übung zu bekommen. 

16.2 Container 

Als Container werden in der STL einfache und assoziative Typen angeboten. 

Der Unterschied zwischen diesen beiden ist, dass die assoziativen Container 

eine Assoziation zwischen einem Key und einem Value quasi zum Nachschlagen 

implementieren. Die einfachen Container erlauben “nur” einer Speicherung 

und das Durchgehen bzw. auch, je nach Container, den indizierten 

Zugriff auf einzelne Elemente. 

16.2.1 Vektoren 

Beginnen wir mit den einfachen Containern, die auch oftmalig als Sequences 

bezeichnet werden. Ein sehr brauchbares Template ist der Vektor (Template 

vector), den wir uns einmal ganz kurz am Beispiel ansehen wollen 

(simple_vector_demo.cpp): 

1 // simple vector demo . cpp − j u s t a simple demo , how to 

2 // use the vector template 

3 



6 


8 

9 using std : : vector ; 

10 



13 


15 { 

16 vector a v e c t o r ; 

17 vector another vector ( 4 ) ; // vector with 4 elements 

18 

19 // never f o r g e t to make sure that there i s enough space ! ! ! 

20 a v e c t o r . r e s i z e ( 4 ) ; 

21 

22 a v e c t o r [ 0 ] = 1 0 ; 

23 a v e c t o r [ 1 ] = 2 0 ; 

24 a v e c t o r [ 2 ] = 3 0 ; 

25 a v e c t o r [ 3 ] = 4 0 ; 

26 

27 another vector [ 0 ] = 1 0 0 ; 




31 

32 for ( int count = 0; count < 4 ; count ++) 

33 {


34 cout


Zum Index-Operator möchte ich noch ein Wort verlieren: Dieser nimmt aus 

Gründen der Performance keine Überprüfung vor, ob der Index im erlaubten 

Bereich liegt. Sollte eine solche Überprüfung beim Zugriff aus Sicherheitsgründen 

gewünscht sein, so steht auch die Methode at(...) zur Verfügung, 

die als Parameter erwartungsgemäß eine Ganzzahl entgegennimmt. 

Die Elemente eines Vektors sind nicht nur direkt indiziert ansprechbar, 

sondern man kann auch entsprechende Iterators anfordern um die Elemente 

der Reihe nach durchzugehen (siehe auch Abschnitt 16.3). 

16.2.2 Listen 

Oft brauchen wir in unseren Programmen aber nicht einfach nur einen sauber 

gekapselten Ersatz für ein Array, sondern einen Container, der folgende 

besonderen Eigenschaften besitzt: 

• Wir wollen ohne Laufzeiteinbußen an beliebigen Stellen Elemente einfügen 

können. 

• Wir wollen ohne Laufzeiteinbußen Elemente von beliebigen Stellen wieder 

entfernen können und die verbliebenen Elemente sollen “nachrücken”. 

Dass wir bei diesen Forderungen mit einem Vektor nicht mehr weit kommen, 

ist leicht einzusehen. Wir brauchen hier eine verkettete Liste, denn 

nur diese Datenstruktur kann die notwendigen Eigenschaften bieten. Erwartungsgemäß 

findet sich eine solche in der STL als list Template. Diese Liste 

stellt die Methoden insert, erase und clear zur Verfügung um Elemente 

an einer bestimmten Stelle einzufügen, zu entfernen und die gesamte Liste 

zu leeren. Erwartungsgemäß weiß auch eine Liste wieder über die Anzahl 

der in ihr gespeicherten Elemente Bescheid und gibt dieses Wissen bei Aufruf 

von size auch preis. Eines ist allerdings bei der Liste bewusst nicht 

implementiert: Der Index-Operator, der direkten Zugriff auf ein bestimmtes 

Element erlauben würde. Dies ist auch einsichtig, denn um einen indizierten 

Zugriff zu erreichen, müsste jedes Mal die Liste von einem Ende her bis 

zum gewünschten Element durchgegangen werden, was mit einer Komplexität 

von O(n) einer ziemlichen Laufzeitkatastrophe gleichkommen würde. 

Deshalb wurde nach dem Motto “...und führe uns nicht in Versuchung...” 

der Index Operator gleich gar nicht implementiert. In einem kurzen Beispiel 

sieht die Verwendung der Basisfeatures einer Liste dann folgendermaßen aus 

(simple_list_demo.cpp): 

1 // s i m p l e l i s t d e m o . cpp − j u s t a simple demo , how to 

2 // use the l i s t template 

3 

4 #include < l i s t> 


6 


8 

9 using std : : l i s t ;


10 



13 


15 { 

16 l i s t a l i s t ; 

17 

18 a l i s t . push front ( 1 . 0 ) ; 

19 a l i s t . push back ( 5 . 0 ) ; 

20 

21 l i s t:: i t e r a t o r i n s e r t i o n i t e r a t o r = a l i s t . end ( ) ; 

22 i n s e r t i o n i t e r a t o r −−; 

23 a l i s t . i n s e r t ( i n s e r t i o n i t e r a t o r , 1 , 3 . 0 ) ; 

24 i n s e r t i o n i t e r a t o r −−; 

25 a l i s t . i n s e r t ( i n s e r t i o n i t e r a t o r , 1 , 2 . 0 ) ; 

26 

27 cout


Element immer vor dem Element einfügt auf das der Iterator verweist. 

Das Ändern der Position des Iterators um eins in Richtung Listenanfang 

bewerkstelligen wir durch Aufruf des -- Operators, der für den Iterator 

speziell definiert ist, wie man in Zeile 22 sieht. 

• Nun, da der Iterator auf das Element zeigt, vor dem wir ein Element 

einfügen wollen, rufen wir insert auf, wobei die Aufrufparameter folgendermaßen 

zu interpretieren sind: Der erste Parameter gibt an, vor welchem 

Element eingefügt werden soll. Der zweite Parameter gibt an, wie viele Elemente 

eingefügt werden sollen. Das bedeutet, dass man ein- und dasselbe 

Element auch 20 Mal einfügen kann, wenn man hier einfach 20 angibt. Der 

dritte Parameter ist das Element selbst. 

In den Zeilen 24–25 wiederholt sich dasselbe Spiel. Will man die Liste nun 

von Anfang bis Ende durchgehen, so holt man sich einen Iterator, der auf 

das erste Element zeigt, wie in Zeile 29 zu sehen ist. Die Schleife in den 

Zeilen 30–31 zeigt, dass der Iterator erstens kompatibel zu einem Pointer auf 

ein Element ist und dass man ihn mit dem abschließenden Element der Liste 

vergleichen kann, um zu wissen, wann es kein weiteres Element mehr gibt. 

Dass das ganze Spielchen auch so funktioniert, wie hier beschrieben, sieht 

man am Output, den das Programm liefert: 

i t e r a t i n g l i s t from the beginning : 

1 2 3 5 

Die Möglichkeiten, die eine Liste bietet, gehen weit über das Einfügen, Entfernen 

und Durchgehen von Elementen hinaus: Man kann Listen auch teilen, 

sortieren und mehrere Listen zu einer zusammenfügen. Dies geschieht über 

die Methoden splice, sort und merge. 

16.2.3 Double-Ended Queues 

Bisher kennen wir einerseits Vektoren, die effizienten indizierten Zugriff gestatten 

und Listen, die effizientes Einfügen und Löschen von Elementen erlauben, 

jedoch keinen indizierten Zugriff unterstützen. Relativ oft stoßen 

wir in Anwendungen auf einen recht speziellen Fall, der so häufig ist, dass 

ihm eine eigene Datenstruktur gewidmet ist: Wir benötigen einen Container, 

der es erlaubt am Anfang und am Ende einer Sequenz Elemente effizient einzufügen 

(nicht in der Mitte), der jedoch auch den schnellen indizierten Zugriff 

auf die einzelnen Elemente gestattet. Diese Datenstruktur nennt sich Deque 

(ausgesprochen: dek), was für double-ended-Queue steht. Das entsprechende 

Template nennt sich bezeichnenderweise deque, wie wir am kurzen Beispiel 

sehen können (simple_deque_demo.cpp): 

1 // simple deque demo . cpp − j u s t a simple demo , how to 

2 // use the deque template 

3 


5 #include


6 


8 

9 using std : : deque ; 

10 



13 


15 { 

16 deque a deque ; 

17 

18 // push elements at the f r o n t and the back 

19 a deque . push front ( 2 0 ) ; 

20 a deque . push back ( 3 0 ) ; 

21 a deque . push front ( 1 0 ) ; 

22 a deque . push back ( 4 0 ) ; 

23 

24 // u t i l i z e indexed a c c e s s 

25 for ( int count = 0; count < 4 ; count ++) 

26 cout

6 


8 

9 using std : : queue ; 

10 



13 


15 { 

16 queue a queue ; 

17 

18 // push elements ( they are appended at the back ) 

19 a queue . push ( 1 0 ) ; 

20 a queue . push ( 2 0 ) ; 

21 a queue . push ( 3 0 ) ; 

22 a queue . push ( 4 0 ) ; 

23 

24 cout


1 // simple priority queue demo . cpp − j u s t a simple demo , how to 

2 // use the p r i o r i t y q u e u e template 

3 



6 


8 

9 using std : : p r i o r i t y q u e u e ; 

10 



13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗ ElementWithPriority 

17 ∗ 

18 ∗ j u s t a dummy Element with a p r i o r i t y f i e l d 

19 ∗ 

20 ∗/ 

21 

22 class ElementWithPriority 

23 { 


25 uint32 p r i o r i t y ; 

26 uint32 data ; 

27 public : 

28 ElementWithPriority ( ) 

29 throw ( ) : p r i o r i t y ( 0 ) , data ( 0 ) { } 

30 

31 ElementWithPriority ( uint32 p r i o r i t y , uint32 data ) 

32 throw ( ) : p r i o r i t y ( p r i o r i t y ) , data ( data ) {} 

33 

34 ElementWithPriority ( const ElementWithPriority & s r c ) 

35 throw( ) 

36 { 

37 p r i o r i t y = s r c . p r i o r i t y ; 


39 } 

40 

41 virtual ElementWithPriority& operator = ( const ElementWithPriority & s r c ) 

42 { 

43 p r i o r i t y = s r c . p r i o r i t y ; 



46 } 

47 

48 virtual bool operator < ( const ElementWithPriority &cmp with ) const 

49 { 

50 return ( p r i o r i t y < cmp with . p r i o r i t y ) ; 

51 } 

52 

53 virtual operator uint32 ( ) const 

54 { 


56 } 

57 

58 virtual ˜ ElementWithPriority ( ) 

59 throw( ) { } 

60 } ; 

61 

62 


64 { 

65 p r i o r i t y q u e u e a p r i o r i t y q u e u e ;

66 


68 a p r i o r i t y q u e u e . push ( ElementWithPriority ( 1 0 , 1 0 0 ) ) ; 




72 

73 cout


als stack in der STL zur Verfügung. Dieses wird verwendet, wie im folgenden 

Beispiel gezeigt (simple_stack_demo.cpp): 

1 // simple stack demo . cpp − j u s t a simple demo , how to 

2 // use the queue template 

3 



6 


8 

9 using std : : stack ; 

10 



13 


15 { 

16 stack a stack ; 

17 


19 a stack . push ( 1 0 ) ; 

20 a stack . push ( 2 0 ) ; 

21 a stack . push ( 3 0 ) ; 

22 a stack . push ( 4 0 ) ; 

23 

24 cout


Elemente über bestimmte Schlüssel, sogenannte Keys, ansprechen zu wollen. 

Ein solcher Container hat also keine sequentielle Ordnung mehr, sondern 

speichert Key-Value Pairs. Auch das ist am einfachsten wieder an einem 

Beispiel zu zeigen (simple_map_demo.cpp): 

1 // simple map demo . cpp − j u s t a simple demo , how to 

2 // use a map 

3 



6 


8 

9 using std : : map; 

10 



13 


15 { 

16 map a map ; 

17 

18 a map [ ’ a ’ ] = 1 1 . 0 ; 

19 a map [ ’ x ’ ] = 1 . 3 ; 

20 a map [ ’ u ’ ] = 1 7 . 8 ; 

21 a map [ ’ b ’ ] = 0 . 7 ; 

22 

23 cout ”


das set Template zur Verfügung. In einem Set speichert man Elemente, 

die selbst Key-Funktionalität besitzen. Am Beispiel sieht dies so aus 

(simple_set_demo.cpp): 

1 // simple set demo . cpp − j u s t a simple demo , how to 

2 // use a s e t 

3 

4 #include < s e t> 


6 


8 

9 using std : : s e t ; 

10 



13 


15 { 

16 s e t a s e t ; 

17 s e t a n o t h e r s e t ; 

18 

19 a s e t . i n s e r t ( 1 0 ) ; 

20 a s e t . i n s e r t ( 2 0 ) ; 

21 a s e t . i n s e r t ( 3 0 ) ; 

22 a s e t . i n s e r t ( 4 0 ) ; 

23 

24 a n o t h e r s e t . i n s e r t ( 1 0 ) ; 




28 

29 cout ”


Wie bei map ist auch bei set ein duplicate Key nicht zulässig und analog 

zur multimap gibt es auch für Fälle, in denen dieses Verhalten benötigt wird 

ein multiset. Neben diesem gibt es noch eine weitere besondere Art eines 

Sets, das sich in der Praxis als sehr brauchbar erweist: Das Bit-Set, das als 

bitset Template zur Verfügung steht. Oft hat man, aus welchen Gründen 

auch immer, eine gewisse Anzahl von boolschen Variablen, die verschiedene 

Teilzustände repräsentieren. Jede dieser Variablen speichert im Prinzip 

nur ein einziges Bit an Information, jedoch wird ein x-faches an Speicherplatz 

dafür verbraucht (je nach Compiler und Architektur zwischen 8 und 

32 Bits). Bei Objekten, die vielfach im Programm vorkommen, kann das 

schon zur groben Speicherverschwendung entarten. Arbeitet man jedoch mit 

einem bitset, so kann man dies leicht in den Griff bekommen, ohne auf den 

Gebrauch von Bitmasken per Hand zurückgreifen zu müssen. Wie dies in der 

Praxis aussehen könnte, sieht man an folgendem Beispiel: 

1 // simple bitset demo . cpp − j u s t a simple demo , how to 

2 // use a b i t s e t 

3 

4 #include 


6 


8 

9 using std : : b i t s e t ; 

10 



13 

14 static const uint32 INITIALIZED BIT = 0; 

15 static const uint32 BROKEN BIT = 1; 

16 static const uint32 OPEN HANDSHAKE BIT = 2; 

17 static const uint32 ALIVE BIT = 3; 

18 static const uint32 CLOSE HANDSHAKE BIT = 4; 

19 static const uint32 CLOSED BIT = 5; 

20 static const uint32 NUM BITS = 6; 

21 


23 { 

24 b i t s e t c o n n e c t i o n s t a t u s = 0x0 ; 

25 

26 c o n n e c t i o n s t a t u s [ INITIALIZED BIT ] = 1 ; 

27 c o n n e c t i o n s t a t u s [ ALIVE BIT ] = 1 ; 

28 

29 cout ”


zelnen Bits intuitiverweise über den Index Operator. Natürlich ist der Index 

des ersten verfügbaren Bits 0, wie wir es bei Indizes generell gewohnt sind. 

Der Output des Programms sieht dann so aus: 

i s the connection i n i t i a l i z e d ? −> 1 

i s the connection a l i v e ? −> 1 

i s c l o s e handshake in progress ? −> 0 

Noch zu erwähnen wäre, dass sinnigerweise für Bit-Sets alle Bitmanipulations- 

Operatoren entsprechend definiert sind, so dass man mit einem Bit-Set ganz 

gleich arbeiten kann wie mit Ganzzahlen. 

16.2.9 Zusammenfassung der Container-Operationen 

Da ich bei den verschiedenen Containern immer nur einen geringen Teil ihrer 

Möglichkeiten gezeigt und besprochen habe, möchte ich an dieser Stelle 

eine kurze tabellarische Zusammenfassung geben, welche Operationen prinzipiell 

für die verschiedenen Container definiert sind. Die Tabellen enthalten 

die Operationen (Methoden und Operatoren), die im Prinzip für alle verschiedenen 

Standard-Container Gültigkeit haben. Je nach Spezialisierung 

bestimmter Container sind noch weitere Operationen definiert, die hier nicht 

angeführt sind (z.B. Bitmanipulationen beim bitset). Die Absicht hinter 

den folgenden Tabellen ist es, Lesern einen zusätzlichen Startpunkt zum Spielen 

mit den Standard Containern zu geben. Für eine detailliertere Diskussion 

möchte ich auf die entsprechende Spezialliteratur (z.B. [Musser et al. 2001] 

und [Stroustrup 1997]) verweisen. 

Elementzugriff 

front Erstes Element 

back Letztes Element 

[] Ungeprüfter Zugriff mit Index 

at Geprüfter Zugriff mit Index (nur vector und deque)


Generelle Operationen 

size Anzahl der Elemente 

empty Ist der Container leer? 

max_size Größe des größtmöglichen Containers 

capacity Für wie viele Elemente ist Platz reserviert? 

(nur vector) 

reserve Reserviere Platz für x Elemente (nur vector) 

resize Containergröße ändern (vector, list, deque) 

swap Elemente zweier Container austauschen 

get_allocator Kopie des Allocators anfordern 

== Ist der Content zweier Container identisch? 

!= Ist der Content zweier Container verschieden? 

< Ist ein Container lexikographisch kleiner? 

Stack und Queue Operationen 

push Element anfügen 

pop Element entfernen 

push_back Element am Ende anfügen 

pop_back Element vom Ende entfernen 

push_front Element als erstes anfügen (nur deque) 

pop_front Erstes Element entfernen (nur deque) 

Anm.: Die Operationen push_front und pop_front sind bewusst in der 

folgenden Tabelle noch einmal angeführt, da sie auch für Listen gelten, eine 

Liste aber weder ein Stack, noch eine Queue ist. 

Listenoperationen 

insert Element einfügen 

erase Element entfernen 

clear Container entleeren 

push_front Element als erstes anfügen 

pop_front Erstes Element entfernen 

Die folgende Tabelle wurde mit Assoziative Operationen betitelt, da die darin 

angeführten Operationen sowohl für Maps als auch für Sets gültig sind.


Assoziative Operationen 

[] Quasi-indizierter Zugriff mittels Key 

find Suche nach Key 

lower_bound Suche nach erstem Element mit Key 

upper_bound Suche nach erstem Element mit Key 

größer als gegebener Key 

equal_range Suche nach allen Elementen mit Key 

key_comp Liefert eine Kopie des Key-Komparator Objekts 

value_comp Liefert eine Kopie des Value-Komparator Objekts 

In der folgenden Tabelle schlägt leider zum wiederholten Mal das “Henne-Ei- 

Problem” zu: Einerseits wurden Iteratoren noch nicht erklärt, andererseits 

sind die entsprechenden Operationen Teil der Container. Deshalb wurden 

auch bereits Vorgriffe gemacht. Würde man die Reihenfolge der Behandlung 

der beiden Themen umstellen, so steht man vor demselben Problem: Es 

werden die Iterators erklärt, allerdings fehlt das Wissen um die Container, 

auf die sie sich beziehen. Nach kurzem Überfliegen von Abschnitt 16.3 sollte 

sich diese Diskrepanz aber in Wohlgefallen aufgelöst haben. 

Anfordern von Iteratoren 

begin Iterator, der auf das erste Element zeigt 

end Iterator, der um ein Element hinter das letzte Element zeigt 

rbegin Iterator, der auf das erste Element der reverse Sequence 

rend Iterator, der um ein Element vor das letzte Element der 

reverse Sequence zeigt 

In den Beispielen, die zur kurzen Demonstration verwendet wurden, wurde 

bereits von der Möglichkeit Gebrauch gemacht, Datentypen vom entsprechenden 

Container-Template zu erfragen. Die folgende Tabelle enthält die 

Zusammenfassung aller verfügbaren Datentypen, die man von einem Container 

erfahren kann.

16.3 Iterators 513 

Abfragbare Datentypen 

key_type Typ des Key-Objekts 

value_type Typ des Value-Objekts 

allocator_type Typ des Allocators 

size_type Typ für indizierten Zugriff 

difference_type Typ für Unterschied zwischen Iteratoren 

iterator Typ des Iterators, der sich wie 

value_type* verhält 

const_iterator Typ des Iterators, der sich wie 

const value_type* verhält 

reverse_iterator analog zu iterator 

(umgekehrte Reihenfolge) 

const_reverse_iterator analog zu reverse_iterator 

(umgekehrte Reihenfolge) 

reference Typ des Iterators, der sich wie 

value_type& verhält 

const_reference analog zu reference, nur const 

mapped_type Typ von mapped_value 

(nur assoziative Container) 

key_compare Typ des Key Komparators 

(nur assoziative Container) 

16.3 Iterators 

Bisher wurden Iterators zwar bereits im Zuge von kurzen Vorgriffen erwähnt 

und auch verwendet, aber eine genaue Erklärung dazu bin ich noch schuldig 

geblieben. Die sogenannten Iterators lösen ein immer wieder auftretendes 

Problem, über das man bei der Verwendung von Containern stolpern kann: 

Man stelle sich vor, es gäbe eine Implementation einer Liste, die man ganz 

einfach durch Aufruf der Methoden first...next...next...etc. Element für 

Element durchlaufen kann. Die Information, welches Element nun das aktuelle 

ist, würde im Container selbst stecken. Nun stelle man sich weiters vor, 

was passiert, wenn aus mehreren Programmteilen heraus zugleich ein und 

dieselbe Liste durchlaufen würde. Das funktioniert schlicht und ergreifend 

nicht, denn sobald aus einem Teil heraus next aufgerufen würde, nähme man 

dem anderen Teil ja damit ein Element weg. Diese Programmteile würden 

sich also gegenseitig durcheinander bringen und das ist sicher nicht im Sinne 

des Erfinders. 

Ganz anders verhält es sich da schon, wenn die Information über das aktuelle 

Element außerhalb des eigentlichen Containers gespeichert wird und 

genau das ist die Natur des Iterators: Ein Iterator bezieht sich immer auf 

ein aktuelles Element, das sich aufgrund irgendeiner Art einen Container zu 

durchwandern ergeben hat. Egal also, ob ein Programmteil mit einem Iterator 

vor, zurück, hin oder her wandert, es wird dadurch niemals ein anderer


Programmteil in seiner Arbeit des Durchwanderns beeinflusst, solange dieser 

einen eigenen Iterator besitzt. 

Ein Iterator bezieht sich also auf das aktuelle Element und über ihn findet 

auch die “Navigation” durch den Container statt. Navigation über Iterators 

bedeutet, dass man die Elemente eines Containers immer in einer bestimmten 

Ordnung zu Gesicht bekommt, die man vorwärts oder rückwärts durchlaufen 

kann. Man bewegt sich dabei immer um ein Element in eine Richtung. Salopp 

gesagt bedeutet dies, dass sich die Elemente eines Containers durch den 

Iterator so präsentieren, als wären sie in einer verketteten Liste gespeichert. 

Jede Navigationsoperation zum nächsten, vorherigen oder welchem anderen 

Element auch immer, verändert das aktuelle Element, auf das der Iterator 

zeigt. Je nachdem, was man nun tun will, gibt es eine Reihe verschiedener 

Typen von Iterators, die neben der Navigation die eine oder andere besondere 

Zusatzaufgabe zu erledigen haben: 

• Es gibt solche, die nur zum lesenden Zugriff auf Elemente verwendet werden. 

Wenn einfach nur von Iterator die Rede ist, sind in der Regel genau 

diese gemeint. 

• Es gibt solche, die dazu verwendet werden, in eine Datenstruktur an einer 

bestimmten Stelle, die man vorher heraussucht, Elemente einzufügen. Solche 

werden im allgemeinen Sprachgebrauch von Softwareentwicklern als 

Inserters bezeichnet. Man kann sich leicht vorstellen, dass beim Erlauben 

von schreibenden Zugriffen ein erheblicher Synchronisationsaufwand 

vonnöten ist, um nicht Inkonsistenzen in anderen Programmteilen zu verursachen, 

die gleichzeitig einen Container lesender- oder ebenfalls schreibenderweise 

iterieren. 

• Es gibt solche, die man ganz bewusst zum verkehrten Durchlaufen einer 

Datenstruktur verwendet. Diese werden als reverse Iterators bezeichnet, 

wenn sie nur für den lesenden Zugriff gedacht sind, als reverse Inserters, 

wenn sie auch zum Einfügen von Elementen gedacht sind. Warum die 

Bezeichnung reverse so besonders herausgestrichen wird, wird in Abbildung 

16.1 skizziert. 

• Es gibt dann auch noch den Typ der Checked Iterators, die sich dadurch 

auszeichnen, dass bei Navigationsoperationen überprüft wird, ob diese 

Operation beim aktuellen Inhalt des Containers überhaupt noch möglich 

ist (z.B. nach dem Ende einer Sequence kann man nicht noch einmal um 

ein Element weiter rücken). 

In der STL sind für alle verschiedenen Container entsprechende Iterators 

definiert. Wenn man einen Iterator von einem Container anfordert, so kann 

man dies prinzipiell auf eine der folgenden vier Arten tun, die den Startpunkt 

der folgenden Navigationsoperationen definieren: 

begin fordert einen Iterator an, der auf das erste Element im Container 

zeigt. Ein Anfordern des Elements vom Iterator liefert also das erste 

Element.

16.3 Iterators 515 

end fordert einen Iterator an, der um ein Element hinter das letzte Element 

zeigt. Ein Anfordern des Elements vom Iterator liefert also gar kein 

Element, sondern end! Diese Vereinbarung wurde deshalb getroffen, da 

alle Einfügeoperationen, die über Iterators angeboten werden, so definiert 

sind, dass sie das neu dazugekommene Element immer vor dem aktuellen 

Element einfügen. Würde der Iterator also direkt auf das letzte Element 

zeigen, so könnte niemals ein Element hinter dem letzten Element der 

Liste eingefügt werden. 

rbegin fordert einen Iterator an, der auf die Elemente des Containers in 

verkehrter Reihenfolge zeigt. Ein Anfordern des Elements vom Iterator 

liefert also nun das letzte Element. 

rend fordert einen Iterator an, der um ein Element hinter das letzte Element 

in verkehrter Reihenfolge zeigt. 

Iterators in der STL gehen also von folgender logischer Sicht aus: Wenn man 

“verkehrt” im Container navigiert, dann ist der Beginn trotzdem “vorne”, 

nur die Elemente präsentieren sich in umgekehrter Reihenfolge. Das ist auch 

der Grund, warum es für einen reverse_iterator einen eigenen Datentyp 

gibt. 

Verwirrend? Keine Sorge, mit einem kleinen Beispielchen wird das Ganze 

klarer (simple_iterator_demo.cpp): 

1 // simple iterator demo . cpp − j u s t a simple demo , how to 

2 // use the i t e r a t o r s 

3 



6 


8 

9 using std : : vector ; 

10 



13 


15 { 

16 vector a v e c t o r ( 1 0 ) ; 

17 

18 for ( int count = 0 ; count < 1 0 ; count++) 

19 a v e c t o r [ count ] = count ; 

20 

21 vector:: i t e r a t o r f o r w a r d i t e r a t o r = a v e c t o r . begin ( ) ; 

22 vector:: r e v e r s e i t e r a t o r backward iterator = 

23 a v e c t o r . rbegin ( ) ; 

24 

25 cout


35 cout

e v e r s e−i t e r a t i n g vector : 

9 8 7 6 5 4 3 2 1 0 

. . . and back to the s t a r t : 

0 1 2 3 4 5 6 7 8 9 

16.4 Allocators 517 

In Abbildung 16.1 findet sich eine schematische Darstellung des soeben Beschriebenen. 

Die Kästchen stellen die einzelnen Elemente dar, die Pfeile 

zwischen den Kästchen stehen für eine Navigationsrichtung und sind jeweils 

mit ++ bzw. -- gekennzeichnet, um zu zeigen, welcher Operator für einen Iterator 

nun in welche Richtung navigiert. Zusätzlich ist noch zu sehen, worauf 

die Iteratoren zeigen, die man mittels begin, end, rbegin und rend anfordert. 

In der Graphik ist auch zu erkennen, warum ein Iterator und ein reverse 

Iterator verschiedene Datentypen sein müssen, denn sie zeigen in Bezug auf 

die Navigation ja völlig unterschiedliches Verhalten. 

Iterator: 

begin() end() 

reverse Iterator: 

rbegin() 

++ ++ 

++ ++ 

0 1 

... 

8 9 

−− −− 

−− −− 

++ ++ 

++ ++ 

9 8 

... 

1 0 

−− −− 

−− −− 

++ 

−− 

++ 

−− 

rend() 

Abbildung 16.1: Iterator und reverse Iterator schematisch dargestellt 

16.4 Allocators 

Allocators werden an dieser Stelle nur der Vollständigkeit halber erwähnt, 

um allen Lesern bewusst zu machen, wie die STL beim Anfordern von Memory 

vorgeht. Die STL geht davon aus, dass intern keine fixen Annahmen 

getroffen werden dürfen, auf welche Art für welche Objekte Memory angefordert 

werden soll (wie schon erwähnt, die STL ist Policy-frei!). Würden die 

in der STL implementierten Datenstrukturen grundsätzlich Objekte hardcodiert 

mittels new und delete anfordern, so könnte es sein, dass sie damit in 

speziellen Fällen gegen die Intention der Applikation verstoßen, denn sowohl 

für Elemente in Containern als auch für interne Objekte der Datenstrukturen 

könnte ein spezielles Memory Management erwünscht sein.


Aus diesem Grund gibt es in der STL das Prinzip von Allocators, die 

in Belangen des Memory Managements angesprochen werden. Ein Allocator 

ist nichts anderes als ein vorgeschriebenes Interface, in dem die Methoden 

deklariert sind, die von der STL für die Memory Verwaltung verwendet werden. 

Im Normalfall sind diese Allocators für Benutzer der STL unsichtbar, 

denn es gibt natürlich entsprechende Standard-Implementationen davon (die 

ganz einfach new und delete verwenden). Sollte man aber in das Memory 

Management eingreifen wollen, so kann man selbst besondere Allocators 

implementieren und den verschiedenen Datenstrukturen der STL diese zur 

Verwendung übergeben. 

Das bedeutet also, dass Benutzer der STL in den allermeisten Fällen 

nichts mit Allocators zu tun haben werden. Jedoch sollten sie im Hinterkopf 

behalten, dass es in besonderen Fällen nicht notwendig ist, Datenstrukturen 

per Hand nachzuprogrammieren, bloß weil z.B. Garbage-Collection 

erwünscht ist. Man kann einfach weiter die Komponenten der STL verwenden 

und implementiert einfach entsprechende Allocators, die Garbage-Collection 

unterstützen. Mehr ist nicht notwendig. Um nähere Details über Allocators 

zu erfahren möchte ich an dieser Stelle auf die entsprechende Spezialliteratur 

(z.B. [Musser et al. 2001] und [Stroustrup 1997]) verweisen. 

16.5 Strings 

Diskussionen über Strings haben sowohl in C als auch in C ++ eine sehr lange 

Tradition. Die Möglichkeit, die gefährlichen char * in eine Klasse zu 

kapseln, wurde von den Entwicklern bereits zu Urzeiten von C ++ dankend 

angenommen und auf diese Art entstand eine nicht mehr überschaubare Menge 

von mehr oder weniger guten String Implementationen. Leider konnten 

und können Entwickler immer wieder der Versuchung nicht widerstehen, im 

Applikationscode direkt mit den Low-Level char * zu arbeiten. Die Begründungen 

dafür sind mannigfaltig, jedoch bis auf sehr wenige und sehr 

spezielle Ausnahmen nicht aufrecht zu halten, denn die Nachteile, die man 

sich damit erkauft, gewinnen im Normalfall deutlich Überhand gegenüber 

den geringen Vorteilen in sehr speziellen Situationen. 

Um zu verstehen, warum ausgerechnet Strings ein sehr heikles Thema 

sind, das gehörig zur Qualität von Software beiträgt, führen wir uns einfach 

einmal folgende Punkte vor Augen: 

• Strings werden im Regelfall nicht einfach als Konstanten verwendet, sondern 

es finden in allen Programmen Unmengen von String Manipulationen 

statt. Strings werden miteinander verknüpft, durchsucht, in Tokens 

zerlegt, neu zusammengesetzt und noch vieles mehr. Alle diese Operationen 

sind potentielle Fehlerquellen, denn im Normalfall wird für Strings 

praktisch ausschließlich mit dynamischer Memory Verwaltung gearbeitet. 

Mit statischen Arrays kommt man hier nicht mehr sehr weit. Außerdem

16.5 Strings 519 

kann man davon ausgehen, dass sehr viel Kreativität vonnöten ist, die entsprechenden 

Manipulationen performant genug zu implementieren, dass sie 

nicht zur Laufzeitkatastrophe werden. 

• Verschiedene Systeme unterstützen verschiedenste Zeichensätze. Es sind 

daher bei plattformübergreifenden Programmen auch verschiedenste Umwandlungsverfahren 

zu implementieren. Wenn man im gesamten Programm 

verstreute Low-Level char * zusammensuchen müsste, um die Umwandlungen 

korrekt einzubauen, würde dies zum undurchführbaren Unterfangen. 

• Ein Character, der in einem String verwendet wird, muss nicht unbedingt 

ein char sein! Leider ist genau diese Tatsache vielen Entwicklern nicht 

bewusst, aber aus guten Gründen werden immer häufiger Zeichensätze 

verwendet, die 16 oder sogar 32 Bit Characters voraussetzen (z.B. Unicode). 

Was es bedeutet, alle Vorkommen von char * (und auch char, 

die von gewissen Manipulationsroutinen geliefert werden) in einem großen 

Programm zu finden und entsprechend zu ändern, kann man sich leicht 

vorstellen. 

Neben diesen Betrachtungen gibt es noch andere, wie z.B. Mehrsprachigkeit, 

die in vielen Programmen eine Rolle spielen. Die Anforderungen an Strings 

sind auf jeden Fall deutlich zu sehen: 

• Ein String muss unbedingt in eine Klasse gekapselt werden. Die Verwendung 

von Low-Level char * in Programmen ist absolut unzulässig. 

• Eine String-Klasse darf sich keinesfalls auf die Verwendung von char für 

einen Character kaprizieren. Auch die implementierten Methoden zur Manipulation 

müssen entsprechend allgemein geschrieben sein, dass sie für 

verschiedenste Datentypen zu brauchen sind. 

• Genauso wenig wie die String-Klasse selbst dürfen sich spezielle (externe) 

Funktionen zur Manipulation auf char für einen Character beschränken. 

• Da es immer noch viele althergebrachte Klassen, Funktionen und Methoden 

gibt, die aus historischen Gründen in gewissen Situationen mit char * 

arbeiten, muss eine String-Klasse eine entsprechende Typumwandlung unterstützen, 

wenn diese beim verwendeten Zeichensatz überhaupt sinnvoll 

ist. Fehlverwendung (z.B. Cast auf char *, obwohl der Basis Character 

des Strings ein unsigned short ist) muss zu einem Compilerfehler führen. 

Dass all diese Anforderungen (und noch einige zusätzliche, die man sich 

überlegen kann) geradezu nach der Implementation eines Strings als Template 

schreien, ist sonnenklar. Genau das wurde auch in der STL gemacht 

und steht in Form des basic_string Templates zur Verfügung. Das Template 

basic_string ist mit dem Datentyp parametrisierbar, der für einen 

Character verwendet werden soll. Um ein Maximum an Performance zu erreichen 

und um I/O Operationen mit Strings einfach und effizient gestalten 

zu können, setzt basic_string noch voraus, dass der Typ, der für einen


Character verwendet wird, keine benutzerdefinierten Copy-Operationen besitzt, 

sondern dass eine einfache Speicherkopie ausreichend ist. Es ist leicht 

nachzuvollziehen, dass es einen riesigen Unterschied macht, ob man einen 

String Zeichen für Zeichen über Copy-Constructor Aufrufe kopiert oder ob 

man einfach einen gesamten Memory-Block ohne besondere Behandlung kopiert. 

Man kann nun diskutieren, ob dies dem Requirement widerspricht, dass 

STL Komponenten Policy-frei sein müssen, jedoch sollte man sich vor Augen 

halten, dass ohne diese Einschränkung das basic_string Template aufgrund 

der ungleich schlechteren Performance im Vergleich zur eingeschränkten 

Lösung schlicht und ergreifend im Alltag keine Verwendung finden würde. 

Vor allem muss man sich auch vor Augen führen, dass ein Character in einem 

String mit praktisch 100%iger Wahrscheinlichkeit einer der primitiven 

Ganzzahlendatentypen sein wird und keine spezielle Klasse. 

Um die Eigenschaften von bestimmten Character Datentypen für einen 

String zugänglich und handhabbar zu machen, gibt es in der STL das 

char_traits Template und die entsprechenden Spezialisierungen für die 

normalerweise verwendeten Ganzzahldatentypen. Wenn man nicht selbst 

einen ganz besonderen String mit einem ganz besonderen Character Datentyp 

braucht, muss man sich um die char_traits keine besonderen Gedanken 

machen. 

Neben dem Template wurden auch gleich zwei konkrete Ausprägungen 

über typedef vorweggenommen: 

1. string für einen String mit char als Character-Datentyp. 

2. wstring für einen “wide” String mit wchar_t als Character-Datentyp. 

Leider ist die Anzahl der Bits für wchar_t nicht festgelegt und beträgt, 

je nach Plattform, entweder 16 oder 32. Mir ist keine Plattform (und 

auch kein Zeichensatz) mit 64 Bit Characters bekannt, aber wer weiß... :- 

). Deshalb kann ich zur Verwendung von wstring nur den Tipp geben, 

davon auszugehen, dass damit Strings mit Unicode Characters auf den 

verschiedenen Plattformen zur Verfügung stehen und dass die Compilerbauer 

sich um die Interna (hoffentlich :-)) schon gekümmert haben. 

Um ein wenig Gefühl zu bekommen, wie man mit einem string umgeht, 

werfen einen Blick auf ein kurzes Beispiel (simple_string_demo.cpp): 

1 // simple string demo . cpp − j u s t a simple demo , how to 

2 // use a s t r i n g 

3 

4 #include < s t r i n g> 


6 


8 

9 using std : : s t r i n g ; 

10 using std : : wstring ; 

11 



14


16 { 

17 s t r i n g s t r i n g 1 ; 

18 s t r i n g s t r i n g 2 ( ” j u s t i n i t i a l i z i n g ” ) ; 

19 s t r i n g s t r i n g 3 ( ” another s t r i n g ” ) ; 

20 

21 s t r i n g 1 = s t r i n g 2 + ” ” + s t r i n g 3 ; 

22 cout


tation umwandeln muss, um sie am Bildschirm ausgeben zu können. In einem 

Programm hat man es aber einerseits mit vielen Objekten als Instanzen 

vieler verschiedener Klassen zu tun, andererseits mit vielen verschiedenen 

Input- und Output-Devices. Den Begriff Device möchte ich hier nicht als 

Hardware-Einheit, wie z.B. Bildschirm oder Festplatte, verstanden wissen, 

sondern vielmehr als eine beliebige Datensenke, auf die man Daten schreiben 

kann bzw. auch als eine beliebige Datenquelle, von der man Daten lesen 

kann. 

Auch hier wurde die traditionelle Sicht der Dinge von der Entwicklung 

überholt, denn wer behauptet, dass man es immer mit byteorientierten Operationen 

zu tun haben muss? Je nach Datenquelle bzw. -senke kann ein 

Datenwort beliebig lang sein. 

Setzen wir also die Einzelteile einmal zu einer modernen Sicht der Dinge 

zusammen: Es gibt Devices, die auf eine bestimmte Art bedient werden wollen 

und die mit verschiedenartigen Datenströmen umgehen können. Es gibt 

in einem Programm Objekte, die mit diesen Devices zu tun bekommen, weil 

sie entweder auf diese geschrieben oder von diesen gelesen werden wollen. 

Die sogenannten Streams sind nun die Teile eines Programms, die eine Verbindung 

zwischen beiden Welten herstellen, sodass Entwicklern das Leben so 

leicht wie möglich gemacht wird: Sie führen die Transformation zwischen der 

Welt der Devices und der Welt der Objekte durch. Dadurch sind Entwickler 

z.B. nicht mehr gezwungen, bei jeder Schreiboperation per Hand eine Byterepräsentation 

eines Objekts zu generieren und diese dann als Datenblock in 

entsprechendem Format an das Device zu senden. Selbiges gilt für das Lesen 

von Objekten: Wenn ein Programm die Eingabe einer Zahl erwartet, dann 

wollen die Entwickler beim besten Willen keinen irgendwie gearteten String 

in die Hand bekommen und diesen von Hand umwandeln. Es sollte ja wohl 

genügen, für spezielle Klassen einmal eine Umwandlung zu implementieren 

und diese wird dann automatisch verwendet. 

Außerdem, und das ist einer der ganz wichtigen Punkte bei Streams, will 

man einfach einen virtuellen Datenstrom benutzen, ohne z.B. Rücksicht auf 

Blockgrößen und andere Details zu nehmen. 

Wir hatten es bisher bereits öfters mit drei speziellen Streams zu tun: 

cin, cout und cerr, die Standard-Input, Standard-Output und Standard- 

Error eines Programms bezeichnen. Diese speziellen Streams wurden immer 

in Zusammenhang mit den Operatoren >> für den Input und

16.6 Streams 523 

diese Objekte werden auch genau in dieser Reihenfolge zum Device gesandt. 

Das haben wir bisher auch immer mit cout, als einen Vertreter 

der Output Streams gemacht. 

2. Ein Input Stream ist ein Mechanismus, der die genaue Umkehrung zum 

Output Stream darstellt. Er holt sich Low-Level Daten vom Device und 

füllt entsprechende High-Level Objekte mit diesen. 

Ich möchte hier nicht allzu genau auf die Interna der Implementation der 

verschiedenen Streams eingehen. Prinzipiell genügt es zu wissen, dass es 

ein Template basic_ostream gibt, über das die prinzipiellen Output Operationen 

definiert sind. Weiters werden zwei spezielle Standard-Ausprägungen 

definiert, nämlich ostream und wostream. Diese stellen konkrete Ausprägungen 

für die Ausgabe von char bzw. wchar_t Datenströmen dar. Ganz gleich 

verhält es sich bei den Input Streams: Auch hier gibt es ein basic_istream 

Template und die zwei Ausprägungen istream und wistream. 

Der Output von primitiven Datentypen mittels des 


6 


8 

9 using std : : ostream ; 




13 

14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗ FullName 

17 ∗ 

18 ∗ Just a dummy demo c l a s s 

19 ∗ 

20 ∗/ 

21 

22 class FullName 

23 { 

24 friend 

25 ostream &operator


37 

38 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

39 /∗ 

40 ∗/ 


8 

9 using std : : ostream ; 




13 


14 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

15 /∗ 

16 ∗ FullName 

17 ∗ 

18 ∗ Just a dummy demo c l a s s 

19 ∗ 

20 ∗/ 

21 

22 class FullName 

23 { 

24 friend 



74 /∗ 

75 ∗/ 

76 ostream &operator > (istream &stream,const Whatever &obj) 

Naiv betrachtet ist das alles also keine große Hexerei, weniger naiv betrachtet 

allerdings ist die Sache viel haariger: Woher will man denn wissen, 

dass der Input, der von irgendwo kommt, auch so gestaltet ist, wie man ihn 

erwartet? Nehmen wir einfach nur unsere FullName Klasse her und nehmen 

wir weiters an, dass wir einen solchen Namen von cin lesen wollen. Wer 

sagt uns, dass ein Benutzer wirklich einen Vornamen und einen Nachnamen 

eintippt? Oder nehmen wir an, dass wir von einem File lesen (ja, auch dafür 

gibt es entsprechende Streams). Wer sagt uns, dass nicht z.B. das Ende des


Files bereits nach dem Vornamen erreicht ist? In das Lesen und Analysieren 

von Input-Daten kann man unglaublich viel Intelligenz und Kreativität stecken, 

bis man wirklich einigermaßen sauber und sicher mit allen möglichen 

Eventualitäten umgehen kann. Allein das wäre ein größeres Kapitel wert, 

jedoch würde dieses den Rahmen des Buchs sprengen. Deshalb belasse ich es 

hier bei einer kurzen Erwähnung der Methoden, die man zur Verfügung hat, 

um eine Implementation sauber zu gestalten. 

Wenden wir uns zuerst einmal den allgemeinen Methoden zu, die es erlauben, 

den Status eines Streams abzufragen: 

bool good(): Liefert Auskunft darüber, ob die bisherigen Operationen so 

weit gut gelaufen sind, dass auch eine weitere Lese- oder Schreiboperation 

funktionieren könnte. Sollte man als return-Value false bekommen, 

dann funktioniert sicher keine weitere Operation. Sollte man true 

bekommen, dann wird allerdings keine Garantie übernommen, dass die 

darauf folgende Operation auch erfolgreich ist, denn ein Problem lässt 

sich ja erst erkennen, wenn es bereits aufgetreten ist. 

bool eof(): Liefert bei einem istream true, wenn das Ende des Streams 

erreicht wurde und daher keine weiteren Daten mehr zum Lesen zur 

Verfügung stehen. 

bool fail(): Liefert true, wenn jegliche folgende Operation sicher fehlschlagen 

würde. 

bool bad(): Liefert true, wenn der Stream korrupt ist. Ist quasi die Inverse 

zu bool good(). 

iostate rdstate(): Liefert als return-Value die I/O Status Flags. 

void clear(iostate flags = goodbit): Löscht bestimmte (oder ohne 

expliziten Parameter alle) I/O Status Flags. 

void setstate(iostate flags): Setzt bestimmte I/O Status Flags. 

bool operator !() const: Kurzform für !my_stream.fail(). 

Um den Input etwas gezielter als nur mit dem Operator


basic_istream &get(CharType *buffer, streamsize max, 

CharType delim): Analog zur vorhergehenden Methode, nur wird der 

Delimiter über den Parameter delim bestimmt. 

getline: Mit denselben Parametersätzen, die auch die vorigen beiden get 

Methoden akzeptieren, gibt es analoge getline Methoden, die genau 

dasselbe tun. Der Unterschied zwischen den beiden Methoden ist, dass 

get den Newline-Delimiter im Stream stehen lässt, während getline ihn 

für sich beansprucht und entfernt. 

basic_istream &read(CharType *buffer, streamsize num): Liest 

höchstens num Characters. Nimmt keinen Delimiter, aber wenn das Ende 

des Streams erreicht wird, dann kann es sein, dass weniger als num 

Characters gelesen wurden. 

basic_istream &ignore(streamsize num = 1, 

int_type delim = char_traits::eof): Überspringt num 

Characters im Stream bzw. so viele Zeichen, bis es auf den Delimiter 

stößt, der durch delim vorgegeben ist. Per Default ist der Delimiter das 

Ende des Streams. 

Man sieht, durch die Low-Level Methoden eines Input Streams steht die Welt 

offen für saubere Analysen und robustes Lesen. Allerdings kann man auch 

leider nicht verleugnen, dass das Erstellen einer sauberen Lese-Operation, 

die auf alle Eventualitäten reagieren kann, wirklich sehr mühsam ist. Das ist 

leider der Preis, den man für robuste Programme zahlen muss. 

Wie bereits erwähnt, kann man mit Streams nicht nur Keyboard Input 

lesen und auf den Bildschirm ausgeben. Ebenso gibt es entsprechende 

vorgefertigte File Streams und auch String Streams, die es erlauben, 

einen String quasi als Device für einen Stream (egal ob Input oder Output) 

zu verwenden. Dadurch ist es leicht, z.B. formatierten Output eines 

Objekts in einen String zu schreiben, ohne dies explizit per Hand machen zu 

müssen. Wenden wir uns zuerst in einem kurzen Beispiel den File Streams 

zu (simple_filestream_demo.cpp): 

1 // simple filestream demo . cpp − j u s t a simple 

2 // demo , how to work with f i l e streams 

3 




7 


9 

10 using std : : i f s t r e a m ; 

11 using std : : ofstream ; 




15 

16 

17 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

18 /∗ 

19 ∗/


21 { 

22 ofstream j u s t a f i l e ( ” a f i l e . txt ” ) ; 

23 


24 j u s t a f i l e


1 // simple stringstream demo . cpp − j u s t a simple 

2 // demo , how to work with s t r i n g streams 

3 




7 


9 

10 using std : : i s t r i n g s t r e a m ; 

11 using std : : ostringstream ; 




15 

16 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

17 /∗ 

18 ∗/ 


20 { 

21 s t r i n g a s t r i n g ; 

22 ostringstream t h e s t r i n g s t r e a m ; 

23 uint32 a number = 17; 

24 double a double = 1 3 . 2 8 ; 

25 

26 t h e s t r i n g s t r e a m a double ; 

38 

39 cout

16.7 Numerik 531 

den muss, werden diese Art des Extrahierens sehr zu schätzen wissen. Der 

folgende Output beweist, dass alles wirklich so einfach funktioniert, wie hier 

beschrieben :-). 

I ’ ve got a pair 1 7 , 1 3 . 2 8 

extracted values : 

a s t r i n g = Pair : 

a number = 5 

a double = 12 

Bisher haben wir uns damit zufrieden gegeben, dass wir z.B. bei Basisdatentypen 

keinen Einfluss auf die Formatierung des Outputs genommen haben. 

Manchmal ist es allerdings notwendig, hierbei einzugreifen. Man möchte 

z.B. einmal eine Ganzzahl als Hex-Darstellung ausgeben oder die Anzahl der 

Kommastellen bei einer Gleitkommazahl bestimmen, etc. Das notwendige 

Werkzeug hierzu findet sich in basic_ios und dessen Basis ios_base. Eine 

genaue Besprechung dieser Features würde jedoch wieder einmal entschieden 

zu weit führen, deswegen belasse ich es hier bei dem Hinweis, in welchen 

Templates man nachsehen und sein Glück versuchen soll. 

16.7 Numerik 

Die meisten Programme brauchen außer einfacher Arithmetik nicht wirklich 

besondere Verfahren. Wenn man jedoch zu technischen Simulationen, Mustererkennungsverfahren 

oder Ähnlichem kommt, dann ändert sich die Situation 

drastisch. In diesen Bereichen wimmelt es nur so von mathematischen Spezialitäten, 

vor allem von Vektor- und Matrizenrechnungen. Ich nehme nun 

nicht an, dass sich ein Großteil der Leser dieses Buchs ausgerechnet in solchen 

Bereichen bewegt :-). 

Aus diesem Grund möchte ich mich hier auf die Teile beschränken, die 

für alle Leser einigermaßen interessant sind. Der allerwichtigste Teil in diesem 

Bereich handelt von den Limits, die Zahlen durch die maschineninterne 

Repräsentation auferlegt sind. Zu diesem Zweck gibt es das Template 

numeric_limits (zu finden im Header ), das darüber sehr detaillierte 

Auskunft gibt. Die folgenden Spezialisierungen dieses Templates stehen 

zur Verfügung: 

numeric_limits 









numeric_limits






Was man nun über diese Zahlen-Datentypen erfahren kann, eröffnet 

uns ein Blick auf die Members, die numeric_limits zur Verfügung stellt 

(DataType steht wieder für den konkreten Typ): 

static DataType denorm_min(): Liefert den minimalen denormalisierten 

Wert einer Gleitkommazahl, falls denormalisierte Werte von dieser unterstützt 

werden. Ansonsten wird der minimale normalisierte Wert geliefert. 

Hat für Ganzzahlen keine Bedeutung. 

static const int digits: Enthält die Bitbreite der Zahl. Für vorzeichenbehaftete 

Ganzzahlenwerte ist diese Zahl die Anzahl der Bits minus 

1, denn das Vorzeichenbit wird hier nicht gezählt. Für unsigned Typen 

ist dies die Anzahl der Bits und für Gleitkommatypen ist dies die Zahl 

der Bits in der Mantisse. Der Wert ist nur aussagekräftig für Zahlen, die 

is_bounded als true deklariert haben. 

static const int digits10: Enthält die maximale Anzahl der Stellen der 

Zahl, wenn sie zur Basis 10 dargestellt wird. Auch dieser Wert ist nur 

aussagekräftig für Zahlen, die is_bounded als true deklariert haben. 

static DataType epsilon(): Liefert die erreichbare Genauigkeit als Unterschied 

zwischen der Zahl 1 und dem kleinsten darstellbaren Wert, der 

größer als 1 ist. Gilt nur für Gleitkommatypen. 

static const bool has_denorm: Enthält true, wenn denormalisierte Werte 

erlaubt sind, sonst false. Als denormalisiert wird ein Datentyp bezeichnet, 

der eine variable Anzahl von Bits für den Exponenten besitzt. 

Gilt nur für Gleitkommatypen. 

static const bool has_infinity: Enthält true, wenn der Typ eine Repräsentation 

für (positives!) Unendlich besitzt. Gilt nur für Gleitkommatypen. 

static const bool has_quiet_NaN: Enthält true, wenn der Typ eine Repräsentation 

für ein quiet not-a-number besitzt, wie sie z.B. bei einer 

Division durch 0 als Ergebnis entsteht. Gilt nur für Gleitkommatypen. 

static const bool has_signaling_NaN: Enthält true, wenn der Typ eine 

Repräsentation für ein signaling not-a-number besitzt, wie sie z.B. bei 

einer Division durch 0 als Ergebnis entsteht. Gilt nur für Gleitkommatypen. 

static DataType infinity(): Liefert die Repräsentation für (positives) 

Unendlich. Die Abfrage ist natürlich nur sinnvoll, wenn beim Datentyp 

has_infinity == true. Gilt nur für Gleitkommatypen. 

static const bool is_bounded: Enthält true, wenn die Menge der Werte, 

die durch diesen Typ repräsentiert werden können, endlich ist. Dies 

ist für alle eingebauten Datentypen aus C ++ der Fall.

16.7 Numerik 533 

static const bool is_exact: Enthält true, wenn der Datentyp eine exakte 

Repräsentation eines Wertes hält. Dies ist natürlich für alle Ganzzahldatentypen 

der Fall, ebenso für Fixkommazahlen (mit denen wir in 

C ++ üblicherweise nichts zu tun haben) und für rationale Zahlen (mit denen 

wir im Normalfall ebenso wenig zu tun haben). Gleitkommazahlen 

sind nicht exakt. 

static const bool is_iec559: Enthält true, wenn sich der Datentyp an 

den IEC 559 Standard hält. Gilt nur für Gleitkommazahlen. 

static const bool is_integer: Enthält true, wenn es sich um einen 

Ganzzahldatentyp handelt. 

static const bool is_modulo: Enthält true, wenn der Datentyp modulo 

ist. Ein Datentyp ist dann modulo, wenn es möglich ist, zwei positive 

Zahlen zu addieren und als Ergebnis eines Überlaufs eine dritte Zahl zu 

erhalten, die kleiner ist. 

static const bool is_signed: Enthält true, wenn der Typ vorzeichenbehaftet 

ist. 

static const bool is_specialized: Gibt Information darüber, ob das 

numeric_limits Template für den aktuellen Datentyp in Form einer 

besonderen Template-Spezialisierung vorliegt. 

static DataType max(): Liefert den maximalen endlichen Zahlenwert. 

Nur gültig für Datentypen bei denen is_bounded == true. 

static const int max_exponent: Enthält den maximalen positiven Exponenten, 

so dass 2 max exponent noch im gültigen Bereich liegt. Gilt nur 

für Gleitkommazahlen. 

static const int max_exponent10: Enthält den maximalen positiven 

Exponenten, so dass 10 max exponent10 noch im gültigen Bereich liegt. Gilt 

nur für Gleitkommazahlen. 

static DataType min(): Liefert den minimalen endlichen Wert. Bei Gleitkommazahlen, 

die Denormalisierung unterstützen, muss min den minimalen 

normalisierten Wert liefern. Gilt nur für Datentypen, bei denen 

is_bounded == true. 

static const int min_exponent: Enthält den minimalen negativen Exponenten, 

so dass 2 min exponent noch im gültigen Bereich liegt. Gilt nur 

für Gleitkommazahlen. 

static const int min_exponent10: Enthält den minimalen negativen 

Exponenten, so dass 10 min exponent noch im gültigen Bereich liegt. Gilt 

nur für Gleitkommazahlen. 

static DataType quiet_NaN(): Liefert die Repräsentation für ein quiet 

not-a-number. Nur gültig, wenn has_quiet_nan == true. 

static const int radix: Enthält die Basis (oder auch den Radix) der 

Repräsentation des Exponenten. Im Normalfall ist diese Basis 2, deshalb 

wurde auch bei max_exponent und bei min_exponent 2 in die Formel 

aufgenommen. Sollte die Basis ungleich 2 sein (sehr selten), dann ist die 

Formel entsprechend abzuändern zu radix ... exponent . Im Prinzip könnte


es auch vorkommen, dass die Basis für Ganzzahlentypen ungleich 2 ist, in 

der Praxis hat diese Betrachtung allerdings im Normalfall keine Relevanz. 

static DataType round_error(): Liefert das Maß für den maximal möglichen 

Rundungsfehler. Gilt nur für Gleitkommatypen. 

static const float_round_style round_style: Enthält die Rundungsmethode 

für den Datentyp. Folgende Werte können angenommen werden: 

round_toward_zero, round_indeterminate, round_to_nearest, 

round_toward_infinity oder round_toward_neg_infinity. Ist nur 

sinnvoll für Gleitkommatypen, denn Ganzzahlentypen unterstützen immer 

round_toward_zero, also Kommastellen “abschneiden”. 

static DataType signaling_NaN(): Liefert die Repräsentation für ein signaling 

not-a-number. Nur gültig, wenn has_signaling_nan == true. 

static const bool tinyness_before: Enthält true, wenn vor dem Runden 

ein tinyness-Check stattfindet (soll heißen, eine Zahl, die winzig klein 

ist, kann nicht irrtümlich durch Rundung zu einer “echten” 0 mutieren). 

Gilt nur für Gleitkommazahlen. 

static const bool traps: Enthält true, wenn Trapping für diesen Typ 

implementiert ist. 

Man sieht, es lässt sich für jeden Zahlentyp praktisch alles herausfinden, was 

man für Berechnungen wissen muss. Jetzt stellt sich nur noch die Frage, 

welche Berechnungen man überhaupt außer der einfachen Arithmetik von 

Seiten der Standard Library zur Verfügung gestellt bekommt. Hier gibt es 

einmal die “normalen” mathematischen Funktionen, die in zu finden 

sind. Dazu zählen sin, cos, log und viele andere. Ich überlasse hier den 

Lesern das Stöbern in den Headers bzw. in den Manuals. Aus historischen 

Gründen sind auch noch einige mathematische Funktionen in zu 

finden, wie z.B. abs. Es lohnt sich also, auch in diesem Header zu suchen :-). 

Mathematische Vektoren, Slices und entsprechende Operationen, die ich 

hier nicht genauer behandeln möchte, sind im Header angesiedelt. 

Komplexe Zahlen und zugehörige Operationen finden sich im Header 

. Wer auf der Suche nach einem Zufallszahlengenerator ist, wird 

aus historischen Gründen in den Headers fündig werden. 

16.8 Algorithmen und Funktionsobjekte 

Zu guter Letzt möchte ich noch den kurzen Hinweis liefern, dass die STL 

auch eine ganze Reihe von Algorithmen zum Suchen, Sortieren, Permutieren, 

Ersetzen, etc. von Elementen in Sequences und anderen Datenstrukturen 

enthält. Auch existieren Basis-Templates für sogenannte Funktionsobjekte, 

die in Algorithmen und in Kombination mit Algorithmen Verwendung finden 

und natürlich auch um eigene Implementationen ergänzt werden können. 

Eine genaue Darstellung derselben überlasse ich allerdings hier der Spezialliteratur, 

denn eine naive Anwendung von vorgefertigten Algorithmen kann

16.8 Algorithmen und Funktionsobjekte 535 

sehr negative Auswirkungen auf ein Programm haben (vor allem auf seine 

Laufzeit :-)). Eine detaillierte Beschreibung der Algorithmen und sinnvoller 

Anwendungen derselben würde wiederum am Ziel dieses Buchs vorbei gehen.

A. Coding-Standard 

Der hier angeführte Coding-Standard ist ein Vorschlag, wie ein solcher aussehen 

könnte. Zu erwähnen wäre, dass die hier abgedruckte Version eine 

sinnvolle Minimalversion für kleine Projekte darstellt. Für große Projekte 

sind entsprechend weitere Regeln zu ergänzen. 

A.1 Generelle Regeln 

Die folgenden Prinzipien sind essentiell für die Lesbarkeit, Wartbarkeit und 

Erweiterbarkeit eines Programms: 

Einfachheit: Das Prinzip der Einfachheit ist auch als das KISS-Prinzip (Keep 

It Small and Simple) bekannt. Kurz gesagt sollen Methoden, Funktionen 

und natürlich auch Operatoren genau eine, für ihren Abstraktionslevel 

adäquate, atomare Aufgabe erfüllen. Niemals sollen mehrere Aufgaben 

auf einmal erledigt werden, genauso wenig, wie Aufgaben erledigt werden 

sollen, die in einen anderen Abstraktionslevel gehören (=Durchgriff nach 

unten oder oben). Parameterlisten sollen so kurz und übersichtlich wie 

möglich gehalten werden. Methoden, Operatoren und Funktionen sollen 

als Faustregel niemals mehr als 60 Zeilen lang sein. Eine durchschnittliche 

Länge von ca. 30 Zeilen ist zu bevorzugen. Seiteneffekte sind absolut zu 

vermeiden! 

Das Prinzip der Einfachheit bedingt auch, dass Klassen keine fetten Interfaces 

haben dürfen. 

Intuitivität: Das Prinzip der Intuitivität bedeutet, dass man den geschriebenen 

Source-Code “wie ein Buch” lesen und verstehen können muss, 

und zwar ohne Kommentare im Source-Code und ohne Erklärungen des 

Programmierers! Damit ist impliziert, dass Variablen-, Methoden- und 

Funktionsnamen sprechend (=selbsterklärend) und genau ihrer Funktionalität 

entsprechend benannt sein müssen. Einbuchstabenvariablen, 

wie z.B. i, sind nicht erlaubt. Unnötige Kommentare werden als störend 

erachtet und sollen dementsprechend weggelassen werden. Ein typisches 

Beispiel für solche unnötigen Kommentare wäre: 

count++; // and here the counter is incremented

538 A. Coding-Standard 

Einheitlichkeit: Verwandte Teile im Source-Code müssen denselben Prinzipien 

folgen. Wenn z.B. eine Funktion copy als ersten Parameter die 

Destination und als zweiten Parameter den Source nimmt, dann müssen 

verwandte Funktionen, wie z.B. move, sich an dieselben Konventionen 

halten. Genauso gilt dies auch für Klassen und ihre Methoden. Nehmen 

wir z.B. eine Klasse die einen Knoten für z.B. eine einfach verkettete 

Liste repräsentiert. Wenn in dieser Klasse der nachfolgende Knoten über 

Aufruf von next() erreichbar ist, dann darf er nicht in einem Knoten 

für eine doppelt verkettete Liste auf einmal über Aufruf von successor 

erreichbar sein. 

A.2 Coding-Rules 

Die hier angeführten Regeln helfen, den Source-Code so weit wie möglich zu 

vereinheitlichen und damit die Arbeit in einem Team zu erleichtern: 

• Die Sprache für Source-Code ist Englisch. Dies gilt für alle Teile eines 

Programms, von Variablennamen über Methoden- und Funktionsnamen 

bis hin zu Kommentaren im Source-Code. 

• Der Gebrauch von Block-Kommentaren (/* comment */) ist zu vermeiden. 

Stattdessen müssen Zeilenkommentare (// comment) eingesetzt werden. 

Dies macht Source-Code robuster gegen Änderungen und erleichtert 

das Debugging. 

Eine Ausnahme zu dieser Regel bilden die Dokumentations-Headers, die 

zur Beschreibung von Variablen, Funktionen und Methoden dienen. Diese 

sind in Block-Kommentaren zu schreiben. Der Grund ist, dass verschiedene 

Programme, die diese Dokumentation automatisch extrahieren können, 

mit solchen Block-Kommentaren besser umgehen können als mit Zeilenkommentaren. 

• Wenn es sich nicht vermeiden lässt, z.B. algorithmische Details in Form 

von Kommentaren in den Source-Code einzubringen, dann ist ein Block 

mit einer vollständigen Erklärung des Algorithmus vor der Implementation 

des Algorithmus selbst zu schreiben. Es darf die Kommentierung des 

Algorithmus nicht im laufenden Source-Code Zeile für Zeile erfolgen, denn 

sonst wird der Code durch die Kommentare unleserlich. Natürlich sind wenige, 

kurze Kommentare in Form von Cross-References zur vollständigen 

Erklärung manchmal sinnvoll und deshalb erlaubt. 

• Sollten jemals Codezeilen in das Programm Eingang finden, bei denen beim 

Lesen der Zeile nicht sofort klar ist, was sie tut, dann muss dies in einem 

kurzen Kommentar dort festgehalten werden. Jedoch sollte man sich immer 

sehr gut überlegen, ob es nicht eigentlich ein besseres, leichter lesbares 

Konstrukt gibt, das keinen Kommentar benötigt, um verstanden zu werden. 

• Globale Variablen sind nach allen Möglichkeiten zu vermeiden!!!!

A.2 Coding-Rules 539 

• C-Style Casts sind zu vermeiden. Stattdessen müssen die “echten” C ++ 

Casts static_cast, dynamic_cast, etc. Anwendung finden. 

• Wenn aus irgendwelchen Gründen böse Hacks im Source-Code temporär 

nicht vermeidbar sind (z.B. Zeitdruck), so sind diese unbedingt in hackstart 

und hack-end Kommentare zu fassen, damit man sie einfach wieder 

finden und ausbessern kann. Die hack-... Kommentare haben die folgende 

Form: 

// FIXXME () -> 

[..... the code with the hack .....] 

// END FIXXME () 

Hier gehört das Keyword FIXXME immer mit zumindest zwei ’X’ geschrieben, 

denn damit kann man leicht nach ihm suchen. Je nachdem, wie 

schlimm der Hack ist, können auch mehrere ’X’ vorkommen. Als Faustregel 

für die Abstufung gilt, dass der SVH (=Schlimmste Vorstellbare Hack) 

mit 5 ’X’ geschrieben wird. 

• Klassendeklarationen müssen von ihren Definitionen getrennt und in einem 

separaten Header File gespeichert werden. 

• Alle Klassen müssen einen virtual Destruktor besitzen. 

• Alle Klassen müssen sowohl den Copy-Constructor als auch den Zuweisungsoperator 

explizit implementieren. Wenn keine Implementation der 

beiden gewünscht ist, dann müssen sie als Dummies implementiert und 

auf private gesetzt werden. 

• Alle Headers müssen durch Definition und entsprechende Abfragen von 

Preprocessor Macros vor Mehrfachinklusion geschützt werden. Das entsprechende 

#define muss der folgenden Namenskonvention entsprechen: 

file_name_h___ 

wobei file_name_h natürlich dem Namen des Headers entspricht und dieser 

von genau 3 Underlines gefolgt sein muss. Die Verwendung von führenden 

Underlines wird deshalb nicht empfohlen, da führende Underlines den 

Compilerherstellern vorbehalten sind. 

Zu dieser Regel gibt es noch eine Ausnahme, die allerdings in der Praxis 

sehr selten zum Tragen kommt: Hat man mehrere Headers, die verschiedenen 

Versionen ein und derselben Klasse entsprechen und hat man diese 

z.B. als my_class_v1.h, my_class_v2.h, etc. benannt, so kann man auch 

einen “gemeinsamen” Schutz vor mehrfacher Inklusion erreichen, indem 

man in allen Headers einfach die Versionsnummer weglässt. Es würde also 

in diesem Fall überall das Macro my_class_h___ verwendet werden. 

• Namen von Bezeichnern müssen den folgenden Konventionen genügen: 

Klassen: 

AlleWorteCapitalizedOhneUnderlines

540 A. Coding-Standard 

Structures: 

GleichWieKlassen 

Unions: 

GleichWieKlassen 

Exceptions: 

KlassennameEndetMitException 

Methoden und Funktionen: 

erstesWortKleinRestCapitalizedOhneUnderlines 

Konstanten: 

GROSS_MIT_UNDERLINES 

Member Variablen: 

klein_mit_underlines_und_underline_am_ende_ 

Lokale Variablen: 

klein_mit_underlines 

Globale Variablen: 

gleich_wie_member_variablen_ 

• Neben diesen generellen Konventionen gibt es auch eine spezielle Konvention, 

die sich auf die Semantik von Methoden bezieht: 

Schreibende Zugriffsmethoden auf Member Variablen müssen setXXX und 

ihre lesenden Äquivalente getXXX benannt werden (z.B. setMaxUsers, 

getMaxUsers). Eine Ausnahme dabei bilden Zugriffe auf boolsche Variablen: 

Hier wird die lesende Methode semantisch sinnvoll mit isXXX, 

hasXXX, allowsXXX o.ä. benannt (z.B. setReadOnly, isReadOnly). 

• Die Struktur des Source-Codes muss den folgenden Prinzipien genügen: 

– Jedes File muss einen Header besitzen, in dem zumindest der Filename, 

und eine kurze Beschreibung des Inhalts zu finden sind. In der Praxis 

hat es sich eingebürgert, dass weiters der Name des Autors, das Erstellungsdatum, 

das letzte Änderungsdatum, eine Versionsnummer und ein 

Copyright-Statement im Header stehen. 

– Geschwungene Klammern für Code-Blöcke müssen in einer eigenen Zeile 

stehen. Die Einrückung der Klammern entspricht genau dem umschließenden 

Block. Der eingeschlossene Block selbst muss genau um 

2 Spaces eingerückt sein (hier sind in der Praxis Werte zwischen 2–4 

gängig). Einrückungen dürfen ausschließlich mit Spaces gemacht werden, 

Tabs sind verboten, denn sonst kann es mit verschiedenen Editor- 

Einstellungen und beim Drucken Probleme geben. 

– Vor jeder Operator-, Methoden- oder Funktionsdefinition muss eine Linie 

der folgenden Form stehen, damit eine Funktion beim Lesen des Source- 

Codes visuell hervorsticht: 

//-------------------------------------------------- 

Diese Linie soll in der Regel mit 60–70 ’-’ geschrieben werden. 

– Zwischen dieser Linie und dem Header der Funktion muss in kurzen 

Worten beschrieben werden, wozu diese Funktion dient. Bei größeren 

Projekten muss auch beschrieben sein, was bei den einzelnen Parametern

A.3 Design Guidelines 541 

erwartet wird, welche Randbedingungen gelten, welche Return-Values zu 

erwarten sind und wie diese zu interpretieren sind. 

A.3 Design Guidelines 

Dieser Abschnitt enthält einige generelle Richtlinien, die helfen sollen, sauberen 

und robusten Code zu schreiben. 

• Membervariablen dürfen niemals public zugreifbar sein. 

• Interne und externe Zugriffsmethoden dürfen niemals vermischt werden. 

Wenn Methoden zum Zugriff für die Außenwelt gedacht sind und entsprechend 

public zugreifbar sind, so dürfen diese klassenintern nicht verwendet 

werden. Z.B., wenn man ein Paar von Methoden setVariable, 

getVariable als public zur Verfügung stellt, dann dürfen diese intern 

nicht für den Zugriff verwendet werden. Stattdessen muss der direkte Zugriff 

auf die Membervariable erfolgen. Der Grund dafür ist einfach zu erkennen: 

In public Methoden werden alle möglichen Schutzmechanismen 

eingebaut, die eine Fehlverwendung ausschließen sollen. Man will aber eine 

Klasse nicht vor sich selbst schützen :-). 

Sollten tatsächlich auch intern Methoden für gewisse Zugriffe benötigt werden, 

so sind diese getrennt und entweder protected oder in seltenen Fällen 

sogar private zu implementieren. 

Durch diese Maßnahme erreicht man eine saubere Trennung zwischen dem 

public Interface und der internen Implementation einer Klasse. 

• Prinzipiell ist protected einer Deklaration von private vorzuziehen. Außer, 

wenn man einen ganz besonders guten Grund hat, Teile einer Klasse in 

Stein zu meißeln, ist dies deshalb sinnvoll, da man hierdurch Anpassungen 

durch Ableitung vornehmen kann, was bei private nicht mehr gegeben 

ist. 

• Seiteneffekte und unerwartetes (d.h. nicht aus dem Namen ersichtliches) 

Verhalten von Methoden, Operatoren und Funktionen sind um jeden Preis 

zu vermeiden!!!! 

• Niemals dürfen sogenannte silent Catches implementiert werden, also Catches 

von Exceptions, die ganz einfach sang- und klanglos ignoriert werden. 

• Exceptions dürfen niemals zu Standard Flow-Control Zwecken verwendet 

werden. 

• Abstrakte Methoden in Basisklassen sind unbedingt solchen mit sinnlosen 

dummy Implementationen vorzuziehen.

B. Vollständige Implementation des Memory 

Spiels 

In Kapitel 10 wurde das Design des Spiels besprochen und es wurden ein 

paar kurze Auszüge aus der Implementation vorgestellt. In der Folge finden 

interessierte Leser den gesamten Source Code des Spiels. Dieser ist natürlich 

auch auf der beiliegenden CD-ROM zu finden. 

Um Platz zu sparen habe ich mir bei den einzelnen Methoden in der Implementation 

alle Beschreibungen erspart, denn diese sind bereits vollständig 

in den Headers in Kapitel 10 enthalten. Dies ist auch vollkommen übliche 

Praxis, denn eine Kopie der Beschreibung führt nur zu unnötiger Redundanz 

und zu erheblichem Wartungsaufwand. Nach einigen Änderungen ist es vor 

allem mit ziemlicher Sicherheit zu erwarten, dass die Beschreibungen in den 

Headers nicht mehr konsistent zu den Beschreibungen in den .cpp Files sind. 

B.1 Implementationen der einzelnen Klassen 

Zu den Implementationen der Klassen, die in der Folge abgedruckt sind, 

möchte ich keine weiteren Erklärungen abgeben. Der Code sollte verständlich 

genug geschrieben sein, dass er als selbstdokumentierend anzusehen ist. 

B.1.1 Das Hauptprogramm 

1 //memory main . cpp − main program that s t a r t s memory 

2 


4 


6 #include ”memory commandline arg handler . h” 






12 



15 


17 { 

18 // i n s t a n t i a t e the commandline handler , d e c l a r e the

544 B. Vollständige Implementation des Memory Spiels 

19 // required arguments ( row / column ) and l e t i t parse 

20 // the commandline . 

21 CommandlineHandling commandline handler ( 3 ) ; 

22 MemoryCommandlineArgumentHandler arg handler ; 





27 commandline handler . handleCommandline ( argc , argv ) ; 

28 

29 // analyse the number of rows and columns 

30 uint32 rows = arg handler . getRows ( ) ; 

31 uint32 c o l s = arg handler . getCols ( ) ; 

32 i f ( ( rows < = 0 ) | | ( c o l s 9 ) | | ( c o l s > 9)) 

34 { 

35 c e r r

B.1.2 Implementation von Vector 

B.1 Implementationen der einzelnen Klassen 545 

1 // s i m p l e v e c t o r . cpp − implementation o f the vector 

2 



5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 Vector : : Vector ( uint32 num elements , 

8 ObjectDeletor & d e l e t o r ) : 

9 elements ( 0 ) , 

10 num elements ( num elements ) , 

11 d e l e t o r ( d e l e t o r ) 

12 { 

13 i f ( ! num elements ) 

14 return ; 

15 elements = new void ∗ [ num elements ] ; 

16 // the f o l l o w i n g i n i t i a l i z a t i o n i s slow , but f o r demo 

17 // purposes i t ’ s ok and easy to read . 

18 while ( num elements−−) 

19 elements [ num elements ] = 0 ; 

20 } 

21 

22 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

23 Vector : : Vector ( const Vector & s r c ) : 

24 d e l e t o r ( DontDelete : : getInstance ( ) ) 

25 { 

26 } 

27 

28 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

29 Vector : : ˜ Vector ( ) 

30 { 

31 i f ( ! elements ) 

32 return ; 

33 

34 // i t ’ s no problem here to decrement t h i s v a r i a b l e 

35 // because the o bject i s deleted anyway . 

36 while ( num elements −−) 

37 d e l e t o r . deleteObject ( elements [ num elements ] ) ; 


39 } 

40 

41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 void Vector : : setElementAt ( uint32 index , void ∗ element ) 

43 { 


45 return ; 

46 i f ( elements [ index ] ) 

47 d e l e t o r . deleteObject ( elements [ index ] ) ; 

48 elements [ index ] = element ; 

49 } 

50 

51 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

52 void ∗ Vector : : getElementAt ( uint32 index ) const 

53 { 


55 return ( 0 ) ; 

56 return ( elements [ index ] ) ; 

57 } 

58 

59 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

60 void ∗ Vector : : getAndRemoveElementAt ( uint32 index ) const 

61 { 


63 return ( 0 ) ;


64 void ∗ r e t = elements [ index ] ; 

65 elements [ index ] = 0 ; 

66 return ( r e t ) ; 

67 } 

B.1.3 Implementation von CommandlineHandling 

1 // simple commandline handling . cpp − implementation o f the 

2 // commandline handling c l a s s 

3 



6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 void CommandlineHandling : : declareArgument ( 

9 uint32 index , uint32 type , ArgumentHandler ∗ handler ) 

10 { 

11 i f ( ( type > HIGHEST ARG TYPE ) | | 

12 ( index >= static cast(max num args ) ) | | 

13 ( ! handler ) ) 

14 return ; 

15 switch ( type ) 

16 { 

17 case UINT32 ARG: 

18 { 

19 uint32 ∗ type element = new uint32 ( type ) ; 

20 types . setElementAt ( index , type element ) ; 

21 handlers . setElementAt ( index , handler ) ; 

22 } 

23 break ; 

24 default : 

25 // nothing to be done , but d e l e t e the handler because 

26 // the c a l l e r r e l i e s on t h i s behaviour ! 

27 delete handler ; 

28 } 

29 } 

30 

31 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

32 void CommandlineHandling : : handleCommandline ( int32 num args , 

33 char ∗ args [ ] ) 

34 { 

35 i f ( num args > max num args ) // don ’ t handle more than what 

36 num args = max num args ; // has been declared 

37 for ( int32 current = 0 ; current < num args ; current++) 

38 { 

39 uint32 ∗ element type ; 

40 i f ( ! ( element type = static cast( 

41 types . getElementAt ( current ) ) ) ) 

42 continue ; 

43 switch (∗ element type ) 

44 { 

45 case UINT32 ARG: 

46 { 

47 uint32 converted arg = s t r t o l ( args [ current ] ,NULL, 1 0 ) ; 

48 reinterpret cast( 

49 handlers . getElementAt ( current))−> 

50 argumentNotification ( current ,& converted arg ) ; 

51 break ; 

52 } 

53 default : 

54 break ; 

55 } 

56 }

57 } 


B.1.4 Implementation von SimpleOutputHandling 

1 // simple output handling . cpp − implementation o f the 

2 // simple output handling c l a s s 

3 


5 


7 


9 

10 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

11 void SimpleOutputHandling : : addDisplayable ( 

12 Displayable & d i s p l a y a b l e ) 

13 { 

14 i f ( ( num displayables >= d i s p l a y a b l e s . getMaxNumElements ( ) ) ) 

15 return ; 

16 d i s p l a y a b l e s . setElementAt ( num displayables ++,&d i s p l a y a b l e ) ; 

17 d i s p l a y a b l e . d i s p l a y a b l e R e g i s t e r e d (∗ this ) ; 

18 } 

19 

20 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

21 void SimpleOutputHandling : : writeOutput ( ) 

22 { 

23 for ( uint32 current = 0 ; current < num displayables ; 

24 current++) 

25 { 

26 static cast( 

27 d i s p l a y a b l e s . getElementAt ( current))−> 

28 writeDisplayRep ( output context ) ; 

29 } 

30 } 

B.1.5 Implementation von GameCard 

1 // game card v3 . cpp − implementation o f GameCard 

2 


4 

5 const uint8 GameCard : : FRONT SIDE; 

6 const uint8 GameCard : : BACK SIDE; 

B.1.6 Implementation von MemoryGameCard 

1 // memory game card v5 . cpp − implementation o f MemoryGameCard 

2 



5 


7 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 /∗


10 ∗ @param front symbol the f r o n t symbol o f the card 

11 ∗ @param back symbol the symbol f o r the back o f the card 

12 ∗/ 

13 

14 MemoryGameCard : : MemoryGameCard( const char ∗ front symbol , 

15 const char ∗ back symbol ) : 

16 GameCard(BACK SIDE ) , Displayable ( ) 

17 { 

18 i f ( front symbol ) 

19 { 

20 front symbol = new char [ s t r l e n ( front symbol ) + 1 ] ; 

21 strcpy ( front symbol , front symbol ) ; 

22 } 

23 else 

24 { 

25 front symbol = new char [ 1 ] ; 

26 front symbol [ 0 ] = ’ \0 ’ ; 

27 } 

28 

29 i f ( back symbol ) 

30 { 

31 back symbol = new char [ s t r l e n ( back symbol ) + 1 ] ; 

32 strcpy ( back symbol , back symbol ) ; 

33 } 

34 else 

35 { 

36 back symbol = new char [ 1 ] ; 

37 back symbol [ 0 ] = ’ \0 ’ ; 

38 } 

39 } 

40 

41 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

42 /∗ 

43 ∗/ 

44 


46 { 

47 delete [ ] front symbol ; 

48 delete [ ] back symbol ; 

49 } 

B.1.7 Implementation von MemoryGameboard 

1 //memory gameboard . cpp − implementation o f the Memory Gameboard 

2 



5 #include ” s i m p l e t e x t d i s p l a y a b l e . h” 

6 #include ” s i m p l e i n t d i s p l a y a b l e . h” 


8 

9 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

10 MemoryGameboard : : MemoryGameboard( uint32 num rows , 

11 uint32 num cols ) : 

12 num rows ( num rows ) , 

13 num cols ( num cols ) , 

14 num cards front side up ( 0 ) , 

15 row vector ( 0 ) , 

16 r o w h e a d i n g d i s p l a y a b l e s ( 0 ) , 

17 c o l h e a d i n g d i s p l a y a b l e s ( 0 ) , 

18 e o l d i s p l a y a b l e s ( 0 ) , 

19 container output handling ( 0 ) , 

20 c o n t a i n e r o u t p u t c o n t e x t (0)


21 { 

22 i f ( ( num rows ∗ num cols ) % 2) // not an even number 

23 num rows ++; 

24 

25 row vector = new Vector ( num rows , 

26 VectorDeletor : : getInstance ( ) ) ; 

27 for ( uint32 current row = 0 ; current row < num rows ; 

28 current row ++) 

29 row vector −>setElementAt ( 

30 current row ,new Vector ( num cols , 

31 DisplayableDeletor : : getInstance ( ) ) ) ; 

32 } 

33 

34 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

35 MemoryGameboard : : ˜ MemoryGameboard ( ) 

36 { 

37 // no need to d e l e t e any d i s p l a y a b l e s r e g i s t e r e d with 

38 // i t , because they are a l l stored in our v e c t o r s 

39 // and deleted from there 

40 delete container output handling ; 

41 

42 // t h i s a l s o d e l e t e s a l l the column v e c t o r s which in 

43 // turn d e l e t e a l l the cards . 

44 delete row vector ; 

45 

46 // t h i s a l s o d e l e t e s a l l the heading d i s p l a y a b l e s 

47 delete r o w h e a d i n g d i s p l a y a b l e s ; 

48 

49 // t h i s a l s o d e l e t e s a l l the heading d i s p l a y a b l e s 

50 delete c o l h e a d i n g d i s p l a y a b l e s ; 

51 

52 // t h i s a l s o d e l e t e s a l l the e o l d i s p l a y a b l e s 

53 delete e o l d i s p l a y a b l e s ; 

54 

55 delete c o n t a i n e r o u t p u t c o n t e x t ; 

56 } 

57 

58 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

59 void MemoryGameboard : : d i s p l a y a b l e R e g i s t e r e d ( 

60 SimpleOutputHandling &handler ) 

61 { 

62 // already r e g i s t e r e d with some handler , no f u r t h e r 

63 // setup necessary 

64 i f ( r o w h e a d i n g d i s p l a y a b l e s ) 

65 return ; 

66 

67 uint32 num displayables = ( num rows ∗ num cols ) + // cards 

68 num rows + 1 + // EOL elements 

69 num rows + 1 + // c o l headings 

70 num cols ; // row headings 

71 r o w h e a d i n g d i s p l a y a b l e s = new Vector ( 

72 num cols , DisplayableDeletor : : getInstance ( ) ) ; 

73 c o l h e a d i n g d i s p l a y a b l e s = new Vector ( 


75 e o l d i s p l a y a b l e s = new Vector ( 


77 c o n t a i n e r o u t p u t c o n t e x t = handler . getOutputContextClone ( ) ; 

78 container output handling = new SimpleOutputHandling ( 

79 num displayables , ∗ c o n t a i n e r o u t p u t c o n t e x t ) ; 

80 

81 // j u s t because some compilers have a wrong treatment f o r 

82 // v a r i a b l e s in c o n t r o l statements . . . 

83 uint32 row count = 0; 

84 uint32 col count = 0; 

85 

86 // generate the top l i n e with the column headings and


87 // r e g i s t e r i t 

88 IntDisplayable ∗ heading = 0; 

89 TextDisplayable ∗ text = 0; 

90 // a space needs to be the f i r s t element o f the headings 

91 text = new TextDisplayable ( ” ” ) ; 

92 c o l h e a d i n g d i s p l a y a b l e s −>setElementAt ( 0 , text ) ; 


94 // the r e s t of the heading l i n e contains the consecutive 

95 // numbers of the columns 

96 for ( col count = 1 ; col count setElementAt ( c o l count , heading ) ; 


101 } 

102 // an e o l i s placed at the end o f the l i n e 


104 e o l d i s p l a y a b l e s −>setElementAt ( 0 , text ) ; 


106 // now f o r each row : 

107 // ( 1 ) generate the row heading and r e g i s t e r i t 

108 // ( 2 ) r e g i s t e r a l l cards in the row . 

109 // ( 3 ) generate an EOL d i s p l a y a b l e and r e g i s t e r i t 

110 for ( row count = 0 ; row count < num rows ; row count++) 

111 { 

112 heading = new IntDisplayable ( row count + 1 ) ; 

113 r o w h e a d i n g d i s p l a y a b l e s −>setElementAt ( row count , heading ) ; 


115 for ( col count = 0 ; col count < num cols ; c o l c o unt++) 

116 { 

117 // not very e f f i c i e n t but e a s i e r to read 

118 container output handling −>addDisplayable ( 

119 ∗dynamic cast( 

120 internalGetCard ( row count , c o l count ) ) ) ; 

121 } 


123 e o l d i s p l a y a b l e s −>setElementAt ( row count + 1, text ) ; 


125 } 

126 } 

127 

128 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

129 void MemoryGameboard : : putAllCardsFrontSideUp ( ) 

130 { 

131 for ( uint32 current row = 0; current row < num rows ; 

132 current row++) 

133 { 

134 for ( uint32 c u r r e n t c o l = 0; c u r r e n t c o l < num cols ; 

135 c u r r e n t c o l++) 

136 { 

137 // not very e f f i c i e n t but e a s i e r to read . . . 

138 MemoryGameCard ∗ current card = internalGetCard ( 

139 current row , c u r r e n t c o l ) ; 

140 i f ( current card ) 

141 current card−>putFrontSideUp ( ) ; 

142 } 

143 } 

144 num cards front side up = num rows ∗ num cols ; 

145 } 

146 

147 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

148 void MemoryGameboard : : putAllCardsBackSideUp ( ) 

149 { 

150 for ( uint32 current row = 0; current row < num rows ; 

151 current row++) 

152 {


153 for ( uint32 c u r r e n t c o l = 0; c u r r e n t c o l < num cols ; 

154 c u r r e n t c o l++) 

155 { 

156 MemoryGameCard ∗ current card = internalGetCard ( 

157 current row , c u r r e n t c o l ) ; 

158 i f ( current card ) 

159 current card−>putBackSideUp ( ) ; 

160 } 

161 } 

162 num cards front side up = 0; 

163 } 

164 

165 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

166 void MemoryGameboard : : putCardFrontSideUp ( uint32 row , uint32 c o l ) 

167 { 

168 i f ( ( row >= num rows ) | | 

169 ( c o l >= num cols ) ) 

170 return ; 

171 MemoryGameCard ∗ card = internalGetCard ( row , c o l ) ; 

172 i f ( card && 

173 ( card−>g e t V i s i b l e S i d e ( ) ! = MemoryGameCard : : FRONT SIDE) ) 

174 { 

175 card−>putFrontSideUp ( ) ; 

176 num cards front side up ++; 

177 } 

178 } 

179 

180 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

181 void MemoryGameboard : : putCardBackSideUp ( uint32 row , uint32 c o l ) 

182 { 

183 i f ( ( row >= num rows ) | | 

184 ( c o l >= num cols ) ) 

185 return ; 

186 MemoryGameCard ∗ card = internalGetCard ( row , c o l ) ; 

187 i f ( card && 

188 ( card−>g e t V i s i b l e S i d e ( ) ! = MemoryGameCard : : BACK SIDE) ) 

189 { 

190 card−>putBackSideUp ( ) ; 

191 num cards front side up −−; 

192 } 

193 } 

194 

195 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

196 MemoryGameCard ∗MemoryGameboard : : getCard ( 

197 uint32 row , uint32 c o l ) const 

198 { 

199 i f ( ( row >= num rows ) | | 

200 ( c o l >= num cols ) ) 

201 return ( 0 ) ; 

202 return ( internalGetCard ( row , c o l ) ) ; 

203 } 

204 

205 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

206 void MemoryGameboard : : putCardOnBoard (MemoryGameCard ∗ card , 

207 uint32 row , uint32 c o l ) 

208 { 

209 i f ( ( row > num rows ) | | 

210 ( c o l > num cols ) | | 

211 ( ! card ) | | 

212 internalGetCard ( row , c o l ) ) // already occupied 

213 return ; 

214 reinterpret cast( 

215 row vector −>getElementAt ( row))−>setElementAt ( c o l , card ) ; 

216 i f ( card−>g e t V i s i b l e S i d e () == MemoryGameCard : : FRONT SIDE) 

217 num cards front side up ++; 

218 }


B.1.8 Implementation von SimpleInputHandling 

1 // simple input handling . cpp − implementation o f SimpleInputHandling 

2 


4 


6 #include ” simple word event . h” 

7 

8 using std : : cin ; 

9 

10 bool SimpleInputHandling : : s t o p d i s p a t c h e r l o o p = f a l s e ; 

11 EventHandler ∗ SimpleInputHandling : : event handler = 0; 

12 

13 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

14 void SimpleInputHandling : : runDispatcher ( ) 

15 { 

16 i f ( ! event handler ) 

17 return ; 

18 s t o p d i s p a t c h e r l o o p = false ; 

19 while ( ! s t o p d i s p a t c h e r l o o p ) 

20 { 

21 char word read [MAXWORDLENGTH] ; 

22 

23 cin >> word read ; 

24 WordEvent event ( word read ) ; 

25 event handler −>handleEvent ( event ) ; 

26 } 

27 } 

B.1.9 Implementation von MemoryGameControl 

1 //memory game control . cpp − implementation o f the game c o n t r o l 

2 



5 


7 #include ” memory card symbol generator . h” 


9 #include ” simple word event . h” 

10 



13 

14 const char MemoryGameControl : :CARD BACK SYMBOL [ ] ; 

15 

16 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

17 void MemoryGameControl : : putCardsOnGameboard ( ) 

18 { 

19 uint32 num rows = gameboard . getNumRows ( ) ; 

20 uint32 num cols = gameboard . getNumCols ( ) ; 

21 uint32 num pairs = ( num rows ∗ num cols ) / 2 ; 

22 MemoryCardSymbolGenerator symbol generator ( num pairs ) ; 

23 

24 // random d i s t r i b u t i o n here i s numerically very weak , 

25 // but f o r demonstration purposes . . . 

26 srand ( num pairs ) ; 

27


28 MemoryGameCard ∗ card = 0; 

29 char symbol [ ] = ”x” ; // symbols here are only one char long ! 

30 while ( num pairs−−) 

31 { 

32 symbol [ 0 ] = symbol generator . getNextSymbol ( ) ; 

33 card = new MemoryGameCard( symbol ,CARD BACK SYMBOL) ; 

34 putCardOnBoardRandomly( card , num rows , num cols ) ; 

35 card = new MemoryGameCard( symbol ,CARD BACK SYMBOL) ; 

36 putCardOnBoardRandomly( card , num rows , num cols ) ; 

37 } 

38 } 

39 

40 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

41 void MemoryGameControl : : putCardOnBoardRandomly( 

42 MemoryGameCard ∗ card , uint32 num rows , uint32 num cols ) 

43 { 

44 for ( ; ; ) 

45 { 

46 uint32 row = rand () % num rows ; 

47 uint32 c o l = rand () % num cols ; 

48 i f ( gameboard . getCard ( row , c o l ) ) 

49 continue ; 

50 gameboard . putCardOnBoard ( card , row , c o l ) ; 

51 break ; 

52 } 

53 } 

54 

55 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

56 void MemoryGameControl : : handleEvent ( const Event &event ) 

57 { 

58 switch ( event . getType ( ) ) 

59 { 

60 case Event : :WORDEVENT: 

61 { 

62 const char ∗ word = dynamic cast( 

63 event ) . getWord ( ) ; 

64 i f ( ! word ) 

65 break ; 

66 i f ( c o o r d w a i t s t a t u s == WAITING FOR ROW AND COL) 

67 { 

68 switch ( word [ 0 ] ) 

69 { 

70 case ’ q ’ : 

71 SimpleInputHandling : : stopDispatcher ( ) ; 

72 return ; 

73 case ’ s ’ : 

74 gameboard . putAllCardsFrontSideUp ( ) ; 


76 return ; 

77 case ’ h ’ : 

78 gameboard . putAllCardsBackSideUp ( ) ; 


80 return ; 

81 } 

82 } 

83 coordWasPassed ( word ) ; 

84 break ; 

85 } 

86 default : 

87 break ; 

88 } 

89 } 

90 

91 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

92 void MemoryGameControl : : coordWasPassed ( const char ∗ word ) 

93 {


94 uint32 converted arg = s t r t o l ( word ,NULL, 1 0 ) ; 

95 i f ( converted arg == 0) 

96 return ; 

97 switch ( c o o r d w a i t s t a t u s ) 

98 { 

99 case WAITING FOR ROW AND COL: 

100 stored row num = converted arg − 1; 

101 c o o r d w a i t s t a t u s = WAITING FOR COL; 

102 break ; 

103 case WAITING FOR COL: 

104 actOnCard ( stored row num , converted arg − 1 ) ; 

105 c o o r d w a i t s t a t u s = WAITING FOR ROW AND COL; 

106 break ; 

107 default : 

108 break ; 

109 } 

110 } 

111 

112 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

113 void MemoryGameControl : : actOnCard ( uint32 row , uint32 c o l ) 

114 { 

115 i f ( c u r r e n t c a r d p a i r . whichCardsAreSet () == 0) // card one 

116 { 

117 c u r r e n t c a r d p a i r . turnCardOneFrontSideUp ( row , c o l , 

118 gameboard ) ; 


120 return ; 

121 } 

122 c u r r e n t c a r d p a i r . turnCardTwoFrontSideUp ( row , c o l , 

123 gameboard ) ; 


125 i f ( c u r r e n t c a r d p a i r . cardSymbolsMatching ( gameboard ) ) 

126 { 

127 i f ( gameboard . getNumCardsBackSideUp()


13 symbols ( num symbols remaining , CharDeletor : : getInstance ( ) ) 

14 { 

15 fillVectorWithSymbols ( ) ; 

16 distributeSymbolsRandomlyInVector ( ) ; 

17 } 

18 

19 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

20 void MemoryCardSymbolGenerator : : fillVectorWithSymbols ( ) 

21 { 

22 uint32 count = num symbols remaining ; 

23 char l e t t e r = ’A’ ; 


25 { 

26 symbols . setElementAt ( count ,new char ( l e t t e r ) ) ; 

27 i f ( ( ( l e t t e r >= ’A’ ) && ( l e t t e r < ’ Z ’ ) ) | | 

28 ( ( l e t t e r >= ’ a ’ ) && ( l e t t e r < ’ z ’ ) ) | | 

29 ( ( l e t t e r >= ’ 0 ’ ) && ( l e t t e r < ’ 9 ’ ) ) ) 

30 l e t t e r ++; 

31 else 

32 { 

33 switch ( l e t t e r ) 

34 { 

35 case ’ Z ’ : 

36 l e t t e r = ’ a ’ ; 

37 break ; 

38 case ’ z ’ : 

39 l e t t e r = ’ 0 ’ ; 

40 break ; 

41 } 

42 } 

43 } 

44 } 

45 

46 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

47 void MemoryCardSymbolGenerator : : distributeSymbolsRandomlyInVector ( ) 

48 { 

49 // d i s t r i b u t e the symbols randomly by swapping them 

50 // in the vector . Please note that the f o l l o w i n g 

51 // implementation i s numerically weak in r e s p e c t to 

52 // the use of the random number generator . 

53 uint32 count = num symbols remaining ∗ SYMBOL SWAP FACTOR; 

54 srand ( count ) ; // s e t the seed ( should be done b e t t e r . . . ) 


56 { 

57 int swap pos1 = rand () % num symbols remaining ; 

58 int swap pos2 = rand () % num symbols remaining ; 

59 char ∗ swap help = static cast( 

60 symbols . getAndRemoveElementAt ( swap pos1 ) ) ; 

61 symbols . setElementAt ( swap pos1 , static cast( 

62 symbols . getAndRemoveElementAt ( 

63 swap pos2 ) ) ) ; 

64 symbols . setElementAt ( swap pos2 , swap help ) ; 

65 } 

66 } 

67 

68 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

69 char MemoryCardSymbolGenerator : : getNextSymbol ( ) 

70 { 

71 i f ( num symbols remaining ) 

72 return (∗ static cast( 

73 symbols . getElementAt(−−num symbols remaining ) ) ) ; 

74 return ( ’ \0 ’ ) ; 

75 }


B.1.11 Implementation von MemoryCardpair 

1 // memory cardpair . cpp − implementation o f MemoryCardpair 

2 


4 

5 #include ”memory cardpair . h” 

6 

7 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

8 void MemoryCardpair : : turnCardOneFrontSideUp ( 

9 uint32 row , uint32 c o l , MemoryGameboard &gameboard ) 

10 { 

11 card1 row = row ; 

12 c a r d 1 c o l = c o l ; 

13 c a r d s e t s t a t u s |= CARD ONE SET; 

14 MemoryGameCard ∗ card = gameboard . getCard ( row , c o l ) ; 

15 i f ( ! card ) 

16 return ; 


18 return ; 

19 gameboard . putCardFrontSideUp ( row , c o l ) ; 

20 c a r d s e t s t a t u s |= CARD ONE TURNED; 

21 } 

22 

23 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

24 void MemoryCardpair : : turnCardTwoFrontSideUp ( 

25 uint32 row , uint32 c o l , MemoryGameboard &gameboard ) 

26 { 

27 card2 row = row ; 

28 c a r d 2 c o l = c o l ; 

29 c a r d s e t s t a t u s |= CARD TWO SET; 

30 MemoryGameCard ∗ card = gameboard . getCard ( row , c o l ) ; 

31 i f ( ! card ) 

32 return ; 


34 return ; 

35 gameboard . putCardFrontSideUp ( row , c o l ) ; 

36 c a r d s e t s t a t u s |= CARD TWO TURNED; 

37 } 

38 

39 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

40 bool MemoryCardpair : : cardSymbolsMatching ( 

41 MemoryGameboard &gameboard ) 

42 { 

43 i f ( ( c a r d s e t s t a t u s & CARD SET BITS) ! = CARD SET BITS) 

44 return ( false ) ; // not both cards were s e l e c t e d 

45 MemoryGameCard ∗ card1 = ( c a r d s e t s t a t u s & CARD ONE SET) ? 

46 gameboard . getCard ( card1 row , 

47 c a r d 1 c o l ) : 0 ; 

48 MemoryGameCard ∗ card2 = ( c a r d s e t s t a t u s & CARD TWO SET) ? 

49 gameboard . getCard ( card2 row , 

50 c a r d 2 c o l ) : 0 ; 

51 i f ( ( ! card1 ) | | ( ! card2 ) ) 

52 return ( false ) ; // at l e a s t one o f the cards does not e x i s t 

53 return ( ! strcmp ( card1−>getFrontSymbol ( ) , card2−>getFrontSymbol ( ) ) ) ; 

54 } 

55 

56 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

57 void MemoryCardpair : : turnCardsBackToTheirOriginalState ( 

58 MemoryGameboard &gameboard ) 

59 { 

60 i f ( c a r d s e t s t a t u s & CARD ONE TURNED) 

61 gameboard . putCardBackSideUp ( card1 row , c a r d 1 c o l ) ; 

62 i f ( c a r d s e t s t a t u s & CARD TWO TURNED) 

63 gameboard . putCardBackSideUp ( card2 row , c a r d 2 c o l ) ;

64 } 

65 


66 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

67 void MemoryCardpair : : c l e a r ( ) 

68 { 

69 card1 row = 0; 

70 c a r d 1 c o l = 0; 

71 card2 row = 0; 

72 c a r d 2 c o l = 0; 

73 c a r d s e t s t a t u s = 0; 

74 } 

B.1.12 Variablen für die konkreten Deletors 

1 // c o n c r e t e o b j e c t d e l e t o r s . cpp − implementations o f the 

2 // concrete d e l e t o r s 

3 


5 

6 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

7 // a l l s t a t i c instance member v a r i a b l e s 

8 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 

9 DontDelete DontDelete : : d e l e t o r ; 

10 CharDeletor CharDeletor : : d e l e t o r ; 

11 Uint32Deletor Uint32Deletor : : d e l e t o r ; 

12 VectorDeletor VectorDeletor : : d e l e t o r ; 

13 DisplayableDeletor DisplayableDeletor : : d e l e t o r ; 

B.1.13 Das MemoryMakefile 

1 OBJS = memory game control . o \ 

2 memory main . o \ 

3 memory card symbol generator . o \ 

4 memory cardpair . o \ 

5 memory gameboard . o \ 

6 game card v3 . o \ 

7 memory game card v5 . o \ 

8 simple input handling . o \ 

9 simple output handling . o \ 

10 s i m p l e v e c t o r . o \ 

11 simple commandline handling . o \ 

12 c o n c r e t e o b j e c t d e l e t o r s . o 

13 

14 CC = g++ 

15 LD = g++ 

16 EXTRA CCINCLUDES = 

17 CC FLAGS = −c $ (EXTRA CCINCLUDES) −Wall 

18 EXTRA LIBDIRS = 

19 EXTRA LIBS = 

20 EXECUTABLE = memory 

21 LD FLAGS = −o $ (EXECUTABLE) $ (EXTRA LIBDIRS) $ (EXTRA LIBS) 

22 

23 memory : $ (OBJS) 

24 $ (LD) $ (LD FLAGS) $ (OBJS) 

25 

26 memory game control . o : memory game control . cpp \ 

27 memory game control . h \ 

28 simple event handler . h \ 

29 simple event . h \ 

30 u s e r t y p e s . h \


31 memory gameboard . h \ 

32 s i m p l e d i s p l a y a b l e . h \ 

33 simple output context . h \ 

34 simple output handling . h \ 

35 s i m p l e v e c t o r . h \ 

36 o b j e c t d e l e t o r . h \ 

37 memory game card v5 . h \ 

38 game card v3 . h \ 

39 s i m p l e t e x t o u t p u t c o n t e x t . h \ 

40 memory cardpair . h \ 

41 memory card symbol generator . h \ 

42 simple input handling . h \ 

43 c o n c r e t e o b j e c t d e l e t o r s . h \ 

44 simple word event . h 

45 $ (CC) $ (CC FLAGS) memory game control . cpp 

46 

47 memory main . o : memory main . cpp \ 

48 simple commandline handling . h \ 

49 u s e r t y p e s . h \ 



52 simple argument handler . h \ 




56 memory commandline arg handler . h \ 






62 memory game control . h \ 




66 simple input handling . h 

67 $ (CC) $ (CC FLAGS) memory main . cpp 

68 

69 memory card symbol generator . o : memory card symbol generator . cpp \ 

70 memory card symbol generator . h \ 


72 u s e r t y p e s . h \ 





77 simple argument handler . h 

78 $ (CC) $ (CC FLAGS) memory card symbol generator . cpp 

79 

80 memory cardpair . o : memory cardpair . cpp \ 


82 u s e r t y p e s . h \ 










92 s i m p l e t e x t o u t p u t c o n t e x t . h 

93 $ (CC) $ (CC FLAGS) memory cardpair . cpp 

94 

95 memory gameboard . o : memory gameboard . cpp \ 

96 memory gameboard . h \






101 u s e r t y p e s . h \ 





106 s i m p l e i n t d i s p l a y a b l e . h \ 

107 s i m p l e t e x t d i s p l a y a b l e . h \ 


109 simple argument handler . h 

110 $ (CC) $ (CC FLAGS) memory gameboard . cpp 

111 

112 game card v3 . o : game card v3 . cpp \ 


114 u s e r t y p e s . h 

115 $ (CC) $ (CC FLAGS) game card v3 . cpp 

116 

117 memory game card v5 . o : memory game card v5 . cpp \ 



120 u s e r t y p e s . h \ 



123 s i m p l e t e x t o u t p u t c o n t e x t . h 

124 $ (CC) $ (CC FLAGS) memory game card v5 . cpp 

125 

126 simple input handling . o : simple input handling . cpp \ 

127 simple input handling . h \ 



130 u s e r t y p e s . h \ 

131 simple word event . h 

132 $ (CC) $ (CC FLAGS) simple input handling . cpp 

133 

134 simple output handling . o : simple output handling . cpp \ 





139 u s e r t y p e s . h \ 


141 c o n c r e t e o b j e c t d e l e t o r s . h 

142 $ (CC) $ (CC FLAGS) simple output handling . cpp 

143 

144 s i m p l e v e c t o r . o : s i m p l e v e c t o r . cpp \ 


146 u s e r t y p e s . h \ 


148 c o n c r e t e o b j e c t d e l e t o r s . h 

149 $ (CC) $ (CC FLAGS) s i m p l e v e c t o r . cpp 

150 

151 simple commandline handling . o : simple commandline handling . cpp \ 

152 simple commandline handling . h \ 

153 u s e r t y p e s . h \ 



156 simple argument handler . h \ 



159 simple output context . h 

160 $ (CC) $ (CC FLAGS) simple commandline handling . cpp 

161 

162 c o n c r e t e o b j e c t d e l e t o r s . o : c o n c r e t e o b j e c t d e l e t o r s . cpp \




165 u s e r t y p e s . h \ 



168 simple output context . h 

169 $ (CC) $ (CC FLAGS) c o n c r e t e o b j e c t d e l e t o r s . cpp 

170 

171 a l l : memory 

172 

173 clean : 

174 rm $ (OBJS) $ (EXECUTABLE)

Literaturverzeichnis 

[Coplien 1991] Coplien J. O.: Advanced C ++ Programming Styles and Idioms, Addison 

Wesley (1991). 

[Gamma et al. 1998] Gamma E., Helm R., Jonson R., Vlissides J.: Design Patterns 

- Elements of Reusable Object-Oriented Software, Addison Wesley (1998). 

[Meyer 1997] Meyer B.: Object-Oriented Software Construction, Second Edition, 

Prentice Hall (1997). 

[Musser et al. 2001] Musser D. R., Derge G. J., Saini A.: STL Tutorial and Reference 

Guide: C ++ Programming with the Standard Template Library (2nd 

Edition), Addison Wesley (2001). 

[Myers 1999] Myers G.J.: Methodisches Testen von Programmen, Oldenbourg 

(1999). 

[Ottmann, Widmayer 1996] Ottmann, T., Widmayer P.: Algorithmen und Datenstrukturen, 

Spektrum Akad. Vlg., Hdg. (1996). 

[Schmaranz 2001] Schmaranz K.: Softwareentwicklung in C, Springer Heidelberg 

(2001). 

[Sedgewick 1992] Sedgewick R.: Algorithmen, Addison Wesley (1992). 

[Stroustrup 1997] Stroustrup B.: The C ++ Programming Language, Third Edition 

- Special Edition, AT&T (1997).

Index 

? :, 75 

#define, 138 

#else, 137 

#endif, 137 

#if, 137 

#ifdef, 137 

#ifndef, 137 

#include, 27, 136 

– Project Header, 136 

– System Header, 136 

1-er Komplement, 60 

Ableitung, 160, 164 

– Class Template, 428 

– virtual, 236 

Access Specifiers, 173, 201 

– private, 174 

– protected, 174 

– public, 174 

ADD, 257 

Ambiguität, 92, 209, 213, 359, 416 

and, 475 

and eq, 475 

Architectural Design Document, 257 

Array 

– dynamisch, 31, 122 

– Indizierung, 31 

– Initialisierung, 32 

– – explizit, 32 

– – implizit, 33 

– mehrdimensional, 34 

– statisch, 31 

associative Array, 507 

Ausnahmezustand, 311 

auto, 370 

automatic Memory, 370 

bad alloc, 333 

bad cast, 245, 333 

bad exception, 485 

bad typeid, 333, 481 

Base-Pointer, 115, 120 

basic ios, 531 

basic istream, 523 

basic ostream, 523 

basic string, 519 

big Endian, 133 

bitand, 475 

bitor, 475 

bitset, 509 

Block, 73 

bool, 13, 15 

break, 76, 81 

C-Style Cast, 70 

call-by-reference, 103, 118 

– auf Pointer, 126 

call-by-value, 85 

calloc, 365 

case, 76 

Cast, 61 

– C-Style, 70 

– Compiletime-checked, 67 

– const cast, 70, 112, 463 

– Downcast, 241 

– dynamic cast, 245, 246, 478, 481 

– reinterpret cast, 67, 69, 133, 247 

– remove-const, 70 

– Runtime-checked, 69 

– static cast, 67, 247 

– unchecked, 67 

– Upcast, 241 

catch, 312, 317 

catch(...), 484 

cerr, 522 

char, 13, 14 

char traits, 520 

Character-Code, 14 

cin, 522 

Class 

– friend, 247 

class, 171 

– Ableitung, 200 

– abstrakt, 232

564 Index 

– Access Specifiers, 173 

– – private, 174 

– – protected, 174 

– – public, 174 

– and struct, 171 

– Class Member, 192 

– – Deklaration, 193 

– Class Method, 193 

– copy Konstruktor, 179, 184 

– copy Konstruktor implizit, 186 

– default Konstruktor, 179 

– – implizit, 183 

– Destruktor, 175, 215 

– Konstruktor, 175, 215 

– – Basisklasse, 204 

– public Interface, 174 

Class Method, 163 

Class Member, 192 

– Deklaration, 193 

Class Method, 193 

Class Template, 419 

– Ableitung, 428 


Compiletime-checked Cast, 67 

compl, 475 

conditional Expression, 75 

const, 47, 109 

– Bindung an, 131 

– Methode, 222 

const cast, 70, 112, 463 

continue, 81 

copy Konstruktor, 179, 184 

– implizit, 186 

cout, 27, 29, 522 

Datentyp, 13 

– Aggregat, 37 

– bool, 13, 15, 30 

– boolscher, 13 

– char, 13, 14 

– Character, 13 

– double, 13, 18 

– float, 13, 18 

– floating-point, 13 

– Ganzzahlen, 13 

– – Vorzeichenbit, 30 

– generisch, 405 

– Gleitkommazahlen, 13 

– int, 13, 16 

– integraler, 13 

– long, 17 

– long double, 18 

– long int, 17 

– long long, 17 

– long long int, 17 

– mischen von, 19 

– natürliche Größe, 14 

– primitiver, 13 

– Qualifier, 14 

– – long, 14 

– – short, 14 

– – signed, 14 

– – unsigned, 14 

– short, 17 

– short int, 17 

– signed char, 15 

– struct, 37 


– union, 41 

– unsigned, 17 

– unsigned char, 15 

– unsigned int, 17 

– unsigned long, 17 

– unsigned long int, 17 

– unsigned long long, 18 

– unsigned long long int, 18 

– unsigned short, 17 

– unsigned short int, 17 

– wchar t, 13, 15 

– Zeichen, 13 

DDD, 260 

default, 77 

default Konstruktor, 179 


default Parameter, 89 

– Regeln, 90 

Definition, 20 

– Funktion, 28 

– Reference, 105 

Deklaration, 20 

– Class Template, 419 

– const, 47 

– extern, 21, 22, 46 

– Function Template, 407 

– Funktion, 28, 88 

– static, 46 

delete, 119 

– 0-Pointer, 122 

– void *, 265 

delete[], 124 

deque, 501 

Destruktor, 175, 215 

Detailed Design Document, 260 

Diagraph, 476 

do ... while, 80 

doppelte Genauigkeit, 18

double, 13, 18 

double Precision, 18 

Downcast, 241 

dynamic Binding, 223 

dynamic cast, 245, 246, 478, 481 

– bad cast, 333 

dynamische Speicherverwaltung, 370 

dynamische Memory Verwaltung, 119 

dynamisches Array, 122 

einfache Genauigkeit, 18 

End of Line, 29 

endl, 29 

erweiterte Genauigkeit, 18 

Exception, 311, 482 

– bad alloc, 333 

– bad cast, 245, 333 

– bad exception, 485 

– bad typeid, 333, 481 

– catch, 312, 317 

– catch(...), 484 


– fangen, 312 

– in Destruktor, 328, 488 

– in Konstruktor, 325 

– Kopie, 318 

– re-throw, 324 

– silent throw, 317 

– silent Catch, 329 

– Stack Unwinding, 312 

– temporäres Objekt, 318 

– throw, 312, 316, 318 

– try, 317 

– uncaught, 323 

– weiterwerfen, 324 

– werfen, 312 

explicit, 189, 191 

export, 448 

Expression, 73 

extended Precision, 18 

extern, 21, 22, 46 

false, 16 

Fehlerbehandlung, 311 

Fehlersignalisierung, 311 

float, 13, 18 

for, 80 

free, 119, 365 

free Memory, 370 

friend, 247 

Function Template, 407 


– Overloading, 414 

Funktion, 28, 85 

– Ambiguität, 92 

– default Parameter, 89 

– Definition, 28 

– Deklaration, 28, 88 

– inline, 96 

– Kopf, 85 

– main, 29 


– Parameter, 85 

– return-Value, 28, 85 

– Rumpf, 85 

Funktionskopf, 85 

Funktionspointer, 125, 470 

Funktionsrumpf, 85 

generische Funktion, 407 

generischer Datentyp, 405 

goto, 82 

HAS-A Relation, 164 

Heap, 370 

Identifier, 13 

if ... else, 74 

ifstream, 528 

impliziter Pointer, 104 

Inheritance, 160 

– einfach, 161 

– mehrfach, 161, 205 

Initialisierung, 20, 188, 189 

– dynamic Memory, 121 

– explizit, 22 

– – Array, 32 


– – Array, 33 

– – struct, 39 

– Konstruktoraufruf 

– – explizit, 189, 191 

– – implizit, 188, 192 

– Reference, 105 

– vs. Zuweisung, 350 

inline, 96, 233 



int, 13, 16 

ios base, 531 

iostream, 29 

IS-A Relation, 164 

istream, 523 

istringstream, 530 

Iterator, 513 

Klasse, 156, 162 

Index 565

566 Index 

– Ableitung, 160, 164 

– Class Method, 163 

– Class-Member Variable, 162 

– Inheritance, 160 

– Member Variable, 162, 164 

– Methoden, 162 

– multiple Inheritance, 161, 205 

– single Inheritance, 161 

– Vererbung, 160 

– – einfach, 161 

– – mehrfach, 161, 205 

Kommentar, 27 

Komplement, 60 

Konstanten, 47 

Konstruktor, 175, 215 

Lifetime, 46 

– temporäres Objekt, 254 

list, 499 

Literals, 23 

– bool, 24 

– char, 24 

– – Escape Sequenz, 24 

– Ganzzahlen, 23 

– – dezimal, 23 

– – hexadezimal, 23 

– – long, 24 

– – oktal, 23 

– – unsigned, 23 

– Gleitkomma, 24 

– – float, 25 

– String, 24 

– – Unicode, 24 

– Unicode, 24 

– wchar t, 24 

little Endian, 133 

logical Constness, 70, 114, 463 

logische Konstantheit, 70, 114 

logische Konstanz, 463 

long, 14, 17 

long double, 18 

long int, 17 

long long, 17 

long long int, 17 

lvalue, 57 

main, 29 

malloc, 119, 365 

map, 507 

Matrix, 35 

Member, 38 

memchr, 366 

memcmp, 366 

memcpy, 366 

memmove, 366 

memset, 366 

Methode 

– abstrakt, 232 


– pure virtual, 234 

– struct, 169 

Methoden, 162 

Modul, 162 

Modularität, 3 

multimap, 507 

multiple Inheritance, 161, 205 

multiset, 509 

mutable, 114, 463 

Name-Mangling, 88 

Namespace, 453 

– Alias, 460 

– unnamed, 460 

– using, 458, 459 

namespace, 453 

new, 119 

– bad alloc, 333 


new[], 122 

– Base-Pointer, 122 

new handler, 397 

not, 475 

not eq, 475 

NULL, 118 

numeric limits, 18, 531 

Objekt, 156 

ofstream, 528 

Operator 

– binär arithmetisch, 57 

– Operatorentabelle, 55 


– Precedence, 54 

– Rang, 54 

– unär arithmetisch, 58 

Operator Overloading, 335 

– binäre Operatoren, 336 

– delete, 363 

– delete mit zwei Parametern, 381 

– delete[], 371 

– globales delete, 385 

– globales delete[], 385 

– globales new, 385 

– globales new[], 385 

– new, 363 

– – bad alloc, 366 

– new(), 374

– new[], 371 

– Typumwandlung, 354 

– unäre Operatoren, 336 

Operatorentabelle, 55 

Optimierung, 99 

or, 475 

or eq, 475 

ostream, 523 

ostringstream, 530 

Overloading, 86, 88 

– const / non-const, 250 

– Function Template, 414 


– Operator, 335 

Overriding, 202 

Performance, 99 

– objektiv, 99 

– subjektiv, 99 

physical Constness, 463 

physikalische Konstanz, 463 

Placement Operator, 374 

Pointer, 103, 114 

– , 118 

– Arithmetik, 123 



– dereference, 117 

– dynamic Memory, 119 

– Funktionspointer, 125, 470 

– Interpretation, 115, 117 

– mehrfach, 128 

– NULL, 118 

– untypisiert, 133 

– void *, 133 

Pointerarithmetik, 104, 123 

Polymorphismus, 223 

Preprocessor, 135 

– #define, 138 

– #else, 137 

– #endif, 137 

– #if, 137 

– #ifdef, 137 

– #ifndef, 137 

– #include, 27, 136 

– Anweisung, 135 

priority queue, 503 

private, 174 

Programmzeile, 73 

protected, 174 

public, 174 

public Interface, 174 

pure virtual Method, 234 

Qualifier, 14 

– long, 14 

– short, 14 

– signed, 14 

– unsigned, 14 

queue, 502 

Index 567 

realloc, 119, 365 

Reference, 103 

– als return-Value, 107 

– const, 109 


– impliziter Pointer, 104 


reinterpret cast, 67, 69, 133, 247 

remove-const Cast, 70 

return, 85 

RTTI, 62, 477 

Run-Time-Type-Information, 62, 477 

Runtime-checked Cast, 69 

Scope, 46 

– Member, 170 

– static, 461 

Scope Operator, 170, 195, 458 

Selection Statements, 74 

self Pointer, 346 

set, 508 

set new handler, 397 

set terminate, 488 

set unexpected handler, 485 

short, 14, 17 

short int, 17 

signed, 14 

signed char, 15 

silent Catch, 329 

silent throw, 317 

single Inheritance, 161 

single Precision, 18 

sizeof, 19 

Stack, 370 

stack, 506 

Stack Unwinding, 312 

Standard Output, 27 

Standard Template Library, 493 

Startadresse, 115, 120 

Statement, 73 

– Block, 73 

– conditional Expression, 75 

– Selection, 74 

– zusammengesetzt, 73 

static, 30, 46, 192, 193, 461 

– const, 198

568 Index 

static Binding, 223 

static Memory, 370 

static cast, 67, 247 

STL, 493 

– Algorithmus, 496, 534 

– Allocator, 495, 517 

– basic string, 519 

– bitset, 509 

– char traits, 520 

– Container, 495 

– – assoziativ, 497 

– – einfach, 497 

– Container Operationen, 510 

– deque, 501 

– Funktionsobjekt, 496 

– Iterator, 495, 513 

– list, 499 

– map, 507 

– multimap, 507 

– multiset, 509 

– Numerik, 496 

– priority queue, 503 

– queue, 502 

– set, 508 

– stack, 506 

– String, 495 

– string, 520 

– vector, 497 

– wstring, 520 

Stream, 496, 521 

– basic ios, 531 

– basic istream, 523 

– basic ostream, 523 

– cerr, 522 

– cin, 522 

– cout, 522 

– ifstream, 528 

– ios base, 531 

– istream, 523 

– istringstream, 530 

– ofstream, 528 

– ostream, 523 

– ostringstream, 530 

– wistream, 523 

– wostream, 523 

Streams 

– cout, 27 

string, 520 

struct, 37, 168 




– – Anordnung, 40 


– – Definition, 170 


switch, 75 

Template, 405 

– Class, 419 

– – Ableitung, 428 


– Codemenge, 431 

– export, 448 

– Function, 407 


– – Overloading, 414 

– Methoden, 445 

– Spezialisierung, 432 

– – Definition, 434 


temporäre Objekte, 253 

temporäre Variable, 112 

this, 346 

throw, 312, 316, 318 

Trigraph, 477 

true, 16 

try, 317 

Typdefinition, 49 

Type-Identification, 62 

type info, 65, 480 

Typecast, 61 

typedef, 49 

typeid, 63, 478 

– bad typeid, 333, 481 

Typumwandlung 


uncaught exception, 490 

unchecked Cast, 67 

unexpected handler, 485 

Unicode, 15 

union, 41, 465 

– anonymous, 44, 468 

– Destruktor, 468 

– Konstruktor, 468 



– Speicherbedarf, 41 

unnamed Namespace, 460 

unsigned, 14, 17 

unsigned char, 15 

unsigned int, 17 

unsigned long, 17 

unsigned long int, 17 

unsigned long long, 18 

unsigned long long int, 18

unsigned short, 17 

unsigned short int, 17 

Upcast, 241 

using, 29, 458, 459 

Variable, 13 

– auto-Variable, 370 


– global, 29, 370 

– Life Cycle, 46 

– Life-Cycle, 178 

– Lifetime, 46, 77 

– Scope, 46, 77 

– temporär, 112 

Varianten, 41 

vector, 497 

Vererbung, 160 

– einfach, 161 

– mehrfach, 161, 205 

virtual, 223 

– Destruktor, 230, 231 

virtual Table, 223 

void, 86 

volatile, 477 

wchar t, 13, 15 

while, 79 

Wiederverwendbarkeit, 3 

wistream, 523 

wostream, 523 

wstring, 520 

xor, 475 

xor eq, 475 

Index 569 

Zeichensatztabelle, 15 

– Annahmen über, 20 

zusammengesetztes Statement, 73

Über den Autor 

Klaus Schmaranz ist Mitglied des Instituts 

für Informationsverarbeitung 

und computergestützte neue Medien 

(IICM) der Technischen Universität 

Graz. Im Rahmen seiner Forschungsund 

Projekttätigkeit ist er technischer 

Leiter mehrerer sehr großer Softwareprojekte 

im Bereich massiv verteilter 

Komponenten- und Objektsysteme. 

Der Einsatz dieser Systeme reicht 

vom allgemeinen Informations- und 

Knowledge-Management Bereich über 

den medizinischen Bereich bis hin zur 

Der Autor auf dem Weg zu einer 

Projektbesprechung 

Luft- und Raumfahrtunterstützung. Im Rahmen dieser Projekttätigkeiten 

gibt es auch eine sehr enge Kooperation mit dem Deutschen Zentrum für 

Luft- und Raumfahrt (DLR). 

Neben dieser Forschungs- und Projekttätigkeit hält der Autor an der TU- 

Graz eine Reihe von Vorlesungen zu verschiedenen Themen im Bereich der 

Softwareentwicklung. Dies umfasst sowohl einführende Vorlesungen in die 

strukturierte Entwicklung mit C, C ++ und Java als auch sehr spezielle Vorlesungen 

zum Thema Softwareentwicklung für große Programmbibliotheken, 

verteilte Objektsysteme, verteilte Komponentensysteme und Übertragungsprotokolle.

Softwareentwicklung in C++ - ASC

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?