Kapitel 1: Introduktion [kapitel]

Forord
Objekt-orienteret programmering er blevet den helt store trend i løbet af de
sidste to-tre år. Ikke fordi det er en ny teknik, men fordi adskillige nye
systemer og sprog for nylig er udviklet til direkte at understøtte den. Desværre
er termen OOP mange steder et hi-tech synonym for "god", og bruges i flæng
som superlativ i forbindelse med markedsføring og reklame.
Det er i sig selv ikke et væsentligt problem, men kan lede til, at mange får en
forkert forståelse for det ny paradigme og dets konsekvenser. Objekt-orienteret
teknologi er ikke bare et nyt værktøj, som med (u)sædvanlig lethed kan
integreres i programudviklingen. Det kræver en ny tankegang, en ny opfattelse
af programkonstruktion og projektstyring, en revideret opfattelse af
arbejdsgangen fra design til færdigt produkt.
På det punkt er objekt-orienteret teknologi på et tidligt stadie. Størstedelen af
litteraturen koncentrerer sig enten om specifikke sprog eller om forslag til
designmetoder og formel specifikation. De fleste har svært at kombinere de ny
metoder med deres egen hverdag som programmører og softwareingeniører,
når de ikke er i stand til at relatere dem til de sprog og værktøj, de benytter i
traditionelle miljøer. I denne bog forsøger jeg at beskrive både et konkret
system, programmeringssproget C++, og rene formelle metoder for programkonstruktion
efter objekt-orienterede principper, med det formål at både reelle
eksempler og underbyggende teori bliver klargjort for læseren.
Og det er nødvendigt med en bred forståelse. Objekt-orienteret programudvikling
har så mange fortrin fremfor traditionelle teknikker, at de kan være
svære at overskue. Det tager tid at blive fortrolig med den anderledes måde at
tænke på. Derfor er denne bog bygget op omkring forskelle mellem kendte
fremgangsmåder og objekt-orienterede. Med konkretiserede opstillinger af
kendte, reelle problemer vises og bevises fordelen ved den objekt-orienterede
praksis. Jeg mener nemlig, at den eneste måde at lære en ny programmeringsteknik
på, er at skrive programmer efter den.
Men tro ikke, at det blot drejer sig om at skrive programmer. Det ligger i
ordet paradigmeskift, at der er brug for en kovending i selve indstillingen.

ii
Indlærte procedurer skal aflæres igen; det er svært og tidskrævende. Jeg vil
anslå, at det typisk tager en til to måneder at sætte sig ind i tankegangen, to til
tre måneder at lære at skrive programmer efter den og op til seks måneder at
blive virkelig produktiv. Men tiden er givet godt ud og vil hurtigt komme
tilbage, når den virkelige gevinst ved OOP viser sig: genbrug af software. Et
nyt projekt anskues som en modifikation af et tidligere projekt, ikke som en
helt ny udfordring.
Jeg vil gerne rette en tak til Sten Lawætz, Christian Ravn og Peter Raabye for
råd og forslag, til Borland Scandinavia for hjælp til fordanskning af alle de nye
termer og til Niels Persson for engagement og udholdenhed. Særlig tak til
Bjarne Stroustrup for hans arbejde med udviklingen af C++, et sprog med
virkelige muligheder.
Forord til anden udgave
Der er en stigende udvikling indenfor objekt-orienteret teknologi. Gennem det
sidste år er dusinvis af professionelle oversættersystemer og CASE-værktøj
nået markedet, og objekt-orienteret analyse og design bliver mere og mere
formaliseret. De relationelle databaser taber markedsandele til objektorienterede
databaser og der tilbydes kurser som aldrig før.
C++ har også udviklet sig. Da første udgave af denne bog udkom, var dybere
kendskab til C++ en sjældenhed. I dag er det en velset kvalifikation for
jobansøgende programmører. Som ventet har C++ vundet indpas i de fleste
udviklingsafdelinger, hvor C før var det herskende sprog. Lærekurven for
tusindvis af programmører er begyndt.
For C++'s vedkommende findes desværre stadig ikke en færdig standard.
ANSI-komiteen, der arbejder på en samlet pakke af omkring 25 objektorienterede
standarder (X3-gruppen) forventer først at være færdig omkring
sensommeren 1993. Der er imidlertid visse nyheder i sproget, som forventes at
være sikre i den kommende standard, blandt andet de parameteriserede typer.
Denne nye udgave behandler sproget, som der foreligger som produkt fra
AT&T i version 3.0. Der er nye afsnit om skabeloner, og XCLklassebiblioteket
bygger også nu på typeparameterisering. Fejlbehandling, som
er beskrevet i appendiks A, ventes ikke at blive godtaget af ANSI, og behandles
derfor ikke i bogens hovedafsnit.
Der er også lagt mere vægt på objekt-orienteret analyse i kapitel 5, hvor et
afsnit om genbrugs- og abstraktionsmekanismer gennemgår, hvordan større
projekter gribes an. Derudover er alle bogens afsnit blevet revideret, rettet for
fejl og mangler samt opdateret til den nye version.
Tak rettes til Sten Lawætz, Christian Ravn, Christian Gabe, Torben Hansen

og Peter Berggreen for konstruktiv kritik. Errare humanum est.
Frederiksberg, oktober 1991 og januar 1993
Maz Spork
(halgrim@diku.dk)
iii

Indhold
KAPITEL 1INTRODUKTION
1.1 Hvorfor en ny programmeringsmetode? 1
1.1.1 Lineær programmering 2
1.1.2 Struktureret programmering 3
1.1.3 Modulærprogrammering 4
1.2 Dataabstraktion 4
1.3 Objekt-orienteret programmering 5
1.4 Programmeringssproget C++ 7
1.5 Terminologi og konventioner 9
1.6 Organiseringen af denne bog 10
KAPITEL 2C++
2.1 Introduktion 13
2.2 Udviklingsmiljøet 14
2.2.1 Erklæring og definition 15
2.2.2 Præprocessering 15
2.2.3 Typesystemet 17
2.2.4 Standard-input/output 17
2.3 Grundlæggende syntaks 18
2.3.1 Kommentarer 18
2.3.2 Afstand 19
2.3.3 Navne 19
2.3.4 Sætninger 20
2.3.5 Udtryk 21
2.4 Typer 21
2.4.1 Symbolske variable 23
2.4.2 Fundamentale typer 26
2.4.3 Pointer-typer 28
2.4.4 Reference-typer 29
2.4.5 Vektor-typer 29
i

ii
2.4.6 Literale konstanter 30
2.4.7 Symbolske konstanter 33
2.4.8 Opremsninger 34
2.4.9 Brugerdefinerede typer 35
2.4.10 Typekonvertering 36
2.5 Operatorer 39
2.5.1 Aritmetiske operatorer 39
2.5.2 Bitvise operatorer 40
2.5.3 Logiske og relationelle operatorer 41
2.5.4 Tildelings-operatorer 42
2.5.5 Reference-operatorer 43
2.5.6 Særlige operatorer 45
2.5.7 Evalueringsrækkefølge 47
2.5.8 Præcedens 47
2.6 Funktioner 48
2.6.1 Skop, blokke og levetid 50
2.6.2 Prototyper 51
2.6.3 void 52
2.6.4 main() 52
2.6.5 Funktionskald 53
2.6.6 Afledte typer som parametre 54
2.6.7 Returværdier 57
2.6.8 Rekursion 59
2.6.9 Overstyrede funktionsnavne 59
2.6.10 Underforståede parametre 60
2.6.11 Uspecificerede parametre 61
2.6.12 inline-funktioner 62
2.6.13 Evalueringsrækkefølge 62
2.7 Kontrolstrukturer 63
2.7.1 if/else 63
2.7.2 while/do 65
2.7.3 for 66
2.7.4 break, continue og goto 67
2.7.5 switch/case 68
2.8 Datastrukturer 70
2.8.1 Medlemsreferencer 72
2.8.2 Bitfelter og union'er 72
2.8.3 Anonyme strukturer 74
2.8.4 Indlejrede strukturer 75
2.8.5 Funktioner som medlemmer 77
2.8.6 Fremad-referencer 78

2.8.7 Dereference af medlemmer 79
2.9 Lageradministration 80
2.9.1 Lagringsklasser 81
2.9.2 new og delete 82
2.10 Præprocessering 84
2.10.1 Inkludering af headerfiler 84
2.10.2 Makroekspansioner 84
2.10.3 Betinget oversættelse 88
2.11 Mere om pointere, vektorer og referencer 90
2.11.1 Pointere 90
2.11.2 Pointeraritmetik 91
2.11.3 Vektorer 92
2.11.4 Initiering af vektorer 94
2.11.5 Vektorer og pointere 95
2.11.6 Pointere og vektorer i funktioner 98
2.11.7 Pas på med pointere 100
2.11.8 Pointere og vektorer i datastrukturer 101
2.11.9 Pointere og nul 102
2.11.10 Pointere og void 103
2.11.11 Pointere og typekonvertering 103
2.11.12 Pointere og const 104
2.11.13 Referencer 106
2.11.14 Typedefinitioner 109
2.12 I/O og standardbiblioteket 110
2.12.1 Output 111
2.12.2 Input 112
2.12.3 Filbaseret I/O 112
2.13 Opgaver til kapitel 2 113
2.14 Referencer og udvalgt litteratur 115
KAPITEL 3DATAABSTRAKTION
3.1 Introduktion 117
3.1.1 Biblioteker 119
3.1.2 Grænseflader 119
3.2 Et eksempel-problem 120
3.2.1 En løsning i C 121
3.2.2 Gennemgang af C-løsningen 124
3.3 Klasse-begrebet 127
3.3.1 Medlemsfunktioner 129
iii

iv
3.3.2 Underforståede medlemsreferencer 131
3.3.3 Overstyrede funktionsnavne 131
3.3.4 Underforståede parametre 132
3.3.5 Indkapsling 133
3.3.6 struct, class og union 136
3.3.7 Klasser og skop 137
3.3.8 Private medlemsfunktioner 138
3.3.9 Klasse-baseret vs. objekt-baseret indkapsling 138
3.3.10 Klasser som moduler 139
3.3.11 Indkapslede typeerklæringer 140
3.3.12 Anonyme klasser 142
3.3.13 Statiske medlemsvariable 143
3.3.14 Statiske metoder 145
3.3.15 Konstante objekter 146
3.3.16 Konstante metoder 148
3.3.17 Overstyrede konstante metoder 150
3.3.18 Første løsning i C++ 152
3.4 Initiering og nedbrydning af objekter 154
3.4.1 Konstruktøren 155
3.4.2 Hvornår kaldes en konstruktør 156
3.4.3 Konstruktører uden parametre 158
3.4.4 Konstruktører med ét parameter 159
3.4.5 Konstruktører med flere parametre 159
3.4.6 Klasser med flere konstruktører 159
3.4.7 Konstruktører med underforståede parametre 160
3.4.8 Initieringslister 161
3.4.9 Destruktøren 164
3.4.10 Hvornår kaldes en destruktør 165
3.4.11 Anden løsning i C++ 166
3.4.12 Kopiering af objekter 169
3.4.13 Kopi-konstruktøren 171
3.4.14 Statiske objekter 172
3.4.15 Pointere og referencer til objekter 172
3.4.16 Dynamiske objekter 174
3.4.17 Vektorer af objekter 176
3.5 Overstyring af operatorer 178
3.5.1 Operator-funktioner 179
3.5.2 Hvad kan overstyres 180
3.5.3 Overblik 181
3.5.4 Overstyring af fortegns-operatorer 182
3.5.5 Overstyring af binære operatorer 183

3.5.6 Overstyring af relationelle operatorer 183
3.5.7 Overstyring af tildelings-operatorer 184
3.5.8 Overstyring af særlige operatorer 185
3.5.9 Retningslinier for operator-overstyring 186
3.5.10 Operator-funktioner som klassemedlemmer 187
3.5.11 friend-funktioner 188
3.5.12 Mere om kopiering af objekter 190
3.5.13 Midlertidige objekter 192
3.5.14 Overstyring af indekserings-operatorer 193
3.5.15 Overstyring af funktionskalds-operatorer 196
3.5.16 Overstyringer af operator-funktioner 197
3.5.17 Overstyringer i standardbiblioteket 199
6.5.18 Mere om this 200
3.5.19 Tredje løsning i C++ 203
3.6 Brugerdefineret typekonvertering 204
3.6.1 Konverterings-funktioner 206
3.6.2 Eksplicit konvertering 207
3.6.3 Implicit konvertering 208
3.6.4 Konstruktører og konvertering 208
3.6.5 Konverteringer i flere led 209
3.6.6 Objektets underforståede værdi 211
3.6.7 Fjerde løsning i C++ 212
3.7 Klasser og pointere 216
3.7.1 Pointere til medlemsdata 216
3.7.2 Pointere til medlemsfunktioner 217
3.8 Parameteriserede typer 218
3.8.1 Eksempler på parameterisering 218
3.8.2 Skabeloner 221
3.9 Design af abstrakte datatyper 226
3.9.1 Samspil mellem klasser 226
3.9.2 Fejlbehandling i abstrakte datatyper 234
3.9.3 Brugerdefineret lageradministration 237
3.9.4 Objekt-I/O 242
3.9.5 Samarbejde med andre sprog 244
3.10 Anvendelser for abstrakte datatyper 247
3.10.1 Klassen LinkedList 247
3.10.2 Klassen AssocArray 250
3.10.3 Klassen Random 254
3.10.4 Klassen Set 256
3.11 Opgaver til kapitel 3 262
3.12 Referencer og udvalgt litteratur 264
v

KAPITEL 4OBJEKT-ORIENTERET PROGRAMMERING
vi
4.1 Introduktion 265
4.1.1 Det objekt-orienterede paradigme 266
4.1.2 Terminologi 268
4.2 Et eksempel-problem 270
4.2.1 En løsning med abstrakte datatyper 271
4.2.2 Klassen Koordinat 271
4.2.3 Klassen Transformation 274
4.2.4 Klassen Figur 278
4.2.5 Klasserne Punkt, Linie og Firkant 278
4.2.6 Gennemgang af ADT-løsningen 282
4.2.7 En forbedret ADT? 283
4.3 Arv 286
4.3.1 Type-ækvivalens 286
4.3.2 Lineær arv 288
4.3.3 Tilgangsspecifikationer 291
4.3.4 Tilgang fra klient-kode 294
4.3.5 protected tilgang 299
4.3.6 Tvetydigheder ved lineær arv 301
4.3.7 Konstruktion af afledte objekter 303
4.3.8 Destruktion af afledte objekter 307
4.3.9 Typekonvertering under arv 308
4.3.10 En løsning med nedarvning 309
4.3.11 Problemer med lineær arv 316
4.4 Polymorfe klasser 319
4.4.1 En isotrop oftattelse af klasser 320
4.4.2 Bindingstidspunkter 321
4.4.3 Virtuelle funktioner 322
4.4.4 Dynamisk binding som indkapsling 325
4.4.5 Virtuelle metoder i detaljer 328
4.4.6 Polymorfe metoder 330
4.4.7 Polymorfe datastrukturer 333
4.4.8 Initiering af polymorfe klasser 335
4.4.9 Nedbrydning af polymorfe klasser 336
4.4.10 Abstrakte klasser 337
4.4.11 En løsning med virtuelle metoder 340
4.5 Multipel arv 345
4.5.1 Multipel arv med uafhængige baseklasser 347

4.5.2 Tvetydigheder ved multipel arv med uafhængige baseklasser 351
4.5.3 Multipel arv med relaterede baseklasser 354
4.5.4 Virtuelle baseklasser 356
4.5.5 Initiering og nedbrydning af multipelt afledte objekter 363
4.5.6 Typekonvertering under multipel arv 366
4.5.7 Multipel arv og polymorfi 369
4.5.8 Virtuelle klasser og polymorfi 376
4.5.9 Problemer med virtuelle klasser 378
4.6 Opgaver til kapitel 4 379
4.7 Referencer og udvalgt litteratur 380
KAPITEL 5OBJEKT-ORIENTERET PROGRAMKONSTRUKTION
5.1 Introduktion 381
5.2 Hvornår skal man bruge objekter? 385
5.2.1 Overvejelser om klasser 385
5.2.2 Fremgangsmåder 389
5.2.3 Organisering af kildetekst 392
5.3 Organisering af klasser 395
5.3.1 Overvejelser om arv 396
5.3.2 Alternativer til arv 402
5.3.3 Medlemsvariable 410
5.3.4 Metoder 411
5.3.5 Adgangskontrol 416
5.3.6 Polymorfi og genbrug 422
5.3.7 Generalitet 424
5.3.8 Overvejelser om multipel arv 425
5.3.9 Overblik 432
5.4 Grænseflader 434
5.4.1 Grænsefladen til klienten 435
5.4.2 Grænsefladen til den afledte klasse 437
5.5 Klasser som processer 439
5.5.1 Algoritmers transparens 439
5.5.2 Datastrukturers transparens 440
5.5.3 Modulærprogrammering 442
5.5.3 Differentialprogrammering 442
5.5.4 Funktionoider 443
5.5.5 Delte objekter 445
5.5.6 Arv og brugerdefineret lageradministration 445
5.6 Containerklasser 448
vii

5.6.1 Objekters ejerforhold 448
5.6.2 Polymorfe containere 449
5.6.3 Programmering med containere 451
5.6.4 Gennemløb af containere 454
5.7 Bestandighed 455
5.7.1 Objekters levetid 456
5.7.2 Implementation af bestandige objekter 457
5.7.3 Administration af bestandige objekter 460
5.7.4 OODBMS 462
5.8 Klassebiblioteker 464
5.8.1 Klassebibliotekets anvendelse 464
5.8.2 Klassebibliotekets indhold og opbygning 466
5.8.3 Topologi 467
5.9 Genbrugsmekanismer i C++ 469
5.9.1 Domæneananlyse 471
5.9.2 Abstraktionsmekanismer 473
5.9.3 Granularitet og genbrug 477
5.9.4 Identifikation af abstraktioner og entiteter 478
5.9 Udviklingsmæssige overvejelser 479
5.10.1 Evolutionære ændringer 480
5.10.2 Dokumentation 481
5.10.3 Udviklingstekniske følger 482
5.11 Opgaver til kapitel 5 483
5.12 Referencer og udvalgt litteratur 483
KAPITEL 6STANDARDBIBLIOTEKET I C++
viii
6.1 Introduktion 485
6.1.1 Klasser og objekter i biblioteket 487
6.2 Standard I/O 489
6.2.1 Output 490
6.2.2 Input 492
6.3 Formatering 496
6.3.1 Manipulatorer 500
6.3.2 Formatering uden I/O 502
6.4 Strømstatus og fejlbehandling 505
6.5 Filer 507
6.6 Brugerdefinerede udvidelser 513
6.6.1 Klassespecifikke overstyringer af in- og outputoperatorerne 514
6.6.2 Brugerdefinerede manipulatorer 515

6.7 Opgaver til kapitel 6 517
6.8 Referencer og udvalgt litteratur 518
KAPITEL 7KLASSEBIBLIOTEKET XCL
7.1 Introduktion 519
7.1.1 Funktionalitet i XCL 520
7.1.2 Opbygning af klassehierarkiet 521
7.1.3 Hierarkiet og standardbiblioteket 522
7.2 Abstrakte klasser 522
7.2.1 Klassen Object 523
7.2.2 Klassen ContainerBase 526
7.2.3 Klassen Container 527
7.2.4 Klassen Sortable 530
7.3 Værktøjsklasser 531
7.3.1 Klassen Nil 532
7.3.2 Klassen ObjectManager 534
7.3.3 Klassen SharedObject 536
7.3.4 Klassen Iterator 537
7.4 Generelle datatyper 538
7.4.1 Klassen String 539
7.4.2 Klassen Complex 541
7.5 Containerklasser 541
7.5.1 Klassen GenericList::GenericNode 542
7.5.2 Skabelonklassen GenericList 542
7.5.3 Skabelonklassen GenericArray 546
7.5.4 Klassen LinkedList 546
7.5.5 Klassen Association 549
7.5.6 Klassen Dictionary 550
7.5.7 Klassen Queue 552
7.5.8 Klassen DeQueue 554
7.5.9 Klassen Stack 555
7.5.10 Klassen Array 556
7.5.11 Samarbejde mellem containerklasser 558
7.6 Objekt-I/O 559
7.7 Udvidelser og tilpasninger 564
7.8 Opgaver til kapitel 7 570
7.9 Referencer og udvalgt litteratur 570
ix

APPENDIKS A FREMTIDSUDSIGTER 573
A.1 ANSI C++ 573
A.2 Fejlbehandling 574
A.3 Parameteriserede typer 580
A.4 Typeidentifikation på kørselstidspunktet 580
APPENDIKS BGODE RÅD TIL C-PROGRAMMØRER 583
APPENDIKS C ANDRE OBJEKT-ORIENTEREDE SPROG 595
C.1 Hvornår er man objekt-orienteret? 595
C.2 Pascal-varianter 596
C.3 Eiffel 597
C.4 Smalltalk 597
C.5 Actor 599
APPENDIKS D OBJEKT-ORIENTERET ORDBOG 601
APPENDIKS EBIBLIOGRAFI 607
APPENDIKS FKILDETEKST 611
STIKORDSREGISTER 659
x

Figurer
1-1 Placeringen af C++ blandt andre vigtige sprog 8
2-1 Afhængigheder mellem filer 16
2-2 Intervaller for signed og unsigned char-typer 27
2-3 Præcisionen af kommatal centreres omkring 1 og -1 28
3-1 Ejerforhold for statisk datamedlem 144
3-2 Grafisk repræsentation af en hægtet liste 248
4-1 Lineær arv, multipel arv og hierarki af klasser 268
4-2 Grafisk transformation 274
4-3 Et associativt opbygget hierarki 287
4-4 Nedarvning fra Figur 290
4-5 Det afledte objekts reelle indhold 309
4-6 Ny acyklisk orienteret graf (dag), hvor Firkant nedarver fra Linie 316
4-7 Skjulte datamedlemmer i polymorfe klasser (konceptuel model) 329
4-8 Et kald til en virtuel funktion. 329
4-9 Multipel arv 346
4-10 Multipel arv i fauna-hierarkiet 347
4-11 Himmellegeme-delhierarki 349
4-12 Multipel arv i Figur-hierarkiet 350
4-13 Multipel arv med relateret baseklasse 354
4-14 Multipel arv med urelaterede baseklasser 355
4-15 Et tvetydigt baseobjekt i en hægtet liste 359
4-16 Et entydigt baseobjekt i en hægtet liste 360
4-17 Sammenblanding af virtuelle og ikke-virtuelle baseklasser 364
4-18 Virtuelle funktioner som "klister" mellem baseklasser 371
4-19 En incidensmatrix implementeret med hægtede lister 372
4-20 Arvetræ for en incidensliste (adjacency list) 374
4-21 En grafstruktur til implementation i AdjacencyNode-subhierarkiet 374
4-22 En graf repræsenteret ved hægtede lister 375
5-1 Afhængigheder mellem moduler i LinkedList-hierarkiet 393
5-2 Generisk kode som klister-element mellem klienter og klasser 423
xi

xii
5-3 Modulær dekomposition og rekomposition 425
5-4 Hierarki af klasser i et vinduessystem 429
5-5 Dualisme i klassens grænseflade 435
5-6 Brugerdefineret typekonvertering har polymorfe egenskaber 427
5-7 En adressetabel udgør programmørkontrolleret polymorfi 461
5-8 Klassetopologisk opbygning: enkelt træ eller skov af træer 467
5-9 Balancen i et objekt-orienteret design 473
6-1 Standardbibliotekets klassehierarki 487
7-1 Hierarkisk fordeling af klasserne i XCL 520
7-2 Den interne (fundamentale) repræsentation af hægtede lister i XCL 545
7-3 Struktur over liste af printerkøer 559

Tabeller
2-1 Eksempler på typer på forskellige processorer 26
2-2 Aritmetiske operatorer 39
2-3 Bitvise operatorer 40
2-4 Logiske og relationelle operatorer 41
2-5 Kombinerede tildelings-operatorer 42
2-6 Reference-operatorer 42
2-7 Særlige operatorer 46
2-8 Operatorernes associativitet, prioritet og syntaks 49
3-1 Funktionsoversigt i C-løsningen 121
4-1 Den afledte klasses tilgang ved arv med forskellige tilgange 300
5-1 Et eksempel på et semantisk katalog over klasser 429
6-1 Klasser i standardbiblioteket 487
6-2 Objekter i standardbiblioteket 488
7-1 Propagation gennem dumpOn()-metoder i komplekst objekt 562
xiii

Programeksempler
xiv
3-1 Kommatals-aritmetik 120
3-2 En C-specifikation på et komplekst tal 122
3-3 En C++-specifikation af et komplekst tal 152
3-4 En C++-specifikation af et komplekst tal med kons- og destruktører 167
3-5 En C++-specifikation af et komplekst tal med operatoroverstyringer 203
3-6 En C++-specifikation af et komplekst tal med typekonverteringer 212
3-7 Dynamiske strenge 227
3-8 En hægtet liste 248
3-9 En associativ liste 250
4-1a En koordinat-ADT 271
4-1b En todimensionel transformationsklasse 275
4-1c En generel figur-klasse 278
4-1d En konkret figur-klasse 279
4-1e Flere konkrete figur-klasser 280
4-2 En kombineret figur-klasse 283
4-3 En generel figur-baseklasse 310
4-4 En nedarvet punkt-klasse 312
4-5 En nedarvet linie-klasse 312
4-6 En nedarvet rektangel-klasse 314
4-7 En indirekte nedarvet rektangel-klasse 314
4-8 Anvendelse af nedarvede klasser 315
4-9 Vektor af pointere til baseklasser 318
4-10 Figurklasser med virtuelle funktioner 324
4-11 Typeuafhængighed for Roter() og Forstoer() 327
4-12a En klasse, der både er klient og arving 333
4-12b Polymorfe datastrukturerer i anvendelse 334
4-13 Virtuelt kald fra konstruktør 336
4-14 En abstrakt figur-klasse 340
4-15 Virtualiseret version af eksempel 4-12 341
4-16 Eksplicitte kopi-rutiner 343
4-17 Et generelt himmellegeme 347

4-18 Multipel arv med urelaterede baseklasser 354
4-19 Hægtet liste med polymorfe hægter 356
4-20a En sorteret liste med polymorfe hægter 357
4-20b En indekseret liste med polymorfe hægter 358
4-21 En sorteret, indekseret polymorf liste 358
4-22 Konkretisering af hægte-klassen 362
4-23 Multipel arv med virtuelle funktioner 369
4-24a En abstrakt incidenshægte 372
4-24b En headnode, en egentlig knude i grafen 373
4-24c En knude i grafen, ref. til en HeadNode 373
5-1a Vektor-repræsenteret stak af heltal 416
5-1b Hægtet liste-repræsenteret stak af heltal 417
5-2a En endimensionel mængde-klasse 420
5-2b En todimensionel mængde-klasse 420
5-3 En generel lineær semafor 444
5-4 Lageradministrationsklassen CustMemMgr 445
5-5 Et generelt, associérbart objekt 452
5-6 Anvendelse af associérbare lister 453
6-1 iostream anvendt på fundamentale typer 490
6-2 Uformateret I/O med iostream 491
6-3 Søgning i et istream-objekt 495
6-4 Filtrering af kommentarer fra kildetekst 495
6-5 Brugerdefinerede formateringer 497
6-6 Anvendelse af manipulatorer 500
6-7 In-core formatering 502
6-8 Klientkontrolleret buffering i ostrstream 503
6-9 Konvertering fra tegn til objekter 504
6-10 Anvendelse af strømmenes statusflag 507
6-11 Læsning og skrivning af filer med fstream 509
6-12 Ordtælling i filer med fstream 510
6-13 Kopiering af filer med fstream 510
6-14 Genanvendelse af samme strøm-objekter 511
xv

Introduktion
Denne bog handler om problemløsning. Når vi skriver programmer på vores
computere, søger vi at finde en løsning på et problem, som vi har defineret. Der
findes utallige værktøj til at hjælpe os i denne proces, både teoretiske metoder
og fysiske værktøj. Men der er sket noget væsentligt de sidste par år. Førhen
var vi glade, når problemet var løst, og programmerne virkede, som de skulle.
Hvert projekt fulgte samme procedure, og programmøren måtte hver gang
genopfinde hjulet for at tilpasse løsningen til problemdefinitionen. I dag står
nogle ting mere klart om fremtiden for software engineering: programmerne er
efterhånden så komplekse, at de hidtidige metoder for udvikling er for svage.
Med 100 programmører i et udviklingsprojekt er antallet af fejl store og
kilderne er svære at finde. Vi kan ikke længere forsvare at starte fra bunden,
hver gang vi begynder på et nyt projekt.
1.1 HVORFOR EN NY PROGRAMMERINGSMETODE?
Mange metoder har gennem tiden været brugt som hjælp i store projekter. Problemet har dog
været, at disse metoder har krævet for meget af den individuelle programmør. Det har været
programmørens ansvar at overholde reglerne, men metoderne har ikke kunnet tvinge ham eller
hende til det. Dertil kommer, at redskaberne (sprogene, CASE-værktøjerne, de integrerede
miljøer) altid har været bagud i forhold til omfanget af de problemer de er lavet til at løse. Først
efter problemet er blevet defineret, er redskabet blevet udviklet.
Objekt-orienteret programudvikling (OOP) har mange indbyggede løsninger på disse
problemer. Ideen er ikke ny, men har været kendt og brugt i over 20 år. Der er dog en forskel på,
om et sprog tillader en bestemt form for udviklingsmetode, og om det understøtter denne metode.
Det er muligt at skrive objekt-orienterede programmer i C eller Pascal, men det kræver en stor
indsats fra programmørens side. Disse sprog understøtter ikke denne metode, og gør
programmeringsmiljøet ustabilt. Til gengæld kræver objekt-orienteret programmering en ganske
anden måde at angribe problemerne på.
Hvad er det helt konkret, der er i vejen med sprog som C og Pascal - vi har løst vores problemer
xvi
1

i disse sprog i to årtier med gode resultater. Der er intet i vejen med for eksempel procedurale
programmeringssprog, når der tænkes på de problemer, de er beregnet til at løse. Men store,
komplekse programmer som OS/2 vidner om, at morgendagens problemer ikke kan løses med
lethed, når vi bruger de konventionelle programmeringssprog og -metoder. Disse problemer
omfatter
• at udviklingsprojekter, som kræver en stor skare af programmører, er svære at
kontrollere. Det er med de konventionelle metoder svært at sikre, at de regler, der
fremsættes, overholdes af alle.
• at allerede skrevne programmer er svære at genbruge, fordi de er for specialiserede. Det
er i konventionelle sprog vanskeligt at skrive generiske programmer, der senere kan
tillægges en konkret betydning.
• at fejlfindingsprocesser er svære, når selve programmeringssproget ikke understøtter
udviklingsmetoden direkte. Det er aldrig entydigt hvor og af hvem en fejl kommer fra.
• at kildekoden til programmet, som ofte består af mange filer, skal gennemgå store
modifikationer rent behandlingsmæssigt for at lave en mindre ændring. Det er farligt,
fordi man risikerer at introducere nye fejl i allerede gennemtestet kode.
Lad os tage en kort opremsning af programmeringsmetodernes historie, før vi kommer ind på
objekt-orienteret programmering.
1.1.1 Lineær programmering
Computerprogrammering er en ung videnskab. De første programmérbare computere er under 40
år gamle, og gennem disse år har udviklingen vist en klar tendens: at programmere er blevet mere
og mere et spørgsmål om behov for programmøren som menneske. De første programmer blev
skrevet i binær kode, som blev tastet ind i computeren ad mekanisk vej med fysiske kontakter.
Senere, da lagerkapaciteten blev forøget, blev reelle højniveau-computersprog udviklet, og
programmøren kunne nu i stedet for binær kode tænke i rækker af kommandoer, som mindede
mere om naturligt sprog, og var lettere at arbejde med.
De første sprog var designet til at løse mindre opgaver - for det meste mindre trivielle
udregninger - og det var derfor ikke særdeles krævende (efter vore dages begreber) for sproget at
behandle disse programmer. Desuden var programmerne sjældent på over et par hundrede linier
store. Men som computernes styrke og kapacitet voksede, voksede opgaverne med dem (en af de
universelle love om computere). De tidlige lineære programmeringssprog kunne ikke bruges til
disse nye opgaver. De lineære programmer bestod ofte af en eksekveringssekvens fra start til slut,
uden kald til subrutiner. Når programmet ændrede sekvens, var det i form af ubetingede hop, men
hvorfor og hvordan sekvensen ændrede sig, var svær at se klart. Alle data var globale, og kunne
følgelig manipuleres fra alle steder i programmet. Det var klart ikke muligt at skrive bare semikomplekse
programmer i disse sprog, der mest af alt minder om de sprog, der findes på mindre
1.1 Hvorfor en ny programmeringsmetode? 17

programmérbare lommeregnere i dag.
1.1.2 Struktureret programmering
Det blev hurtigt klart, at nye sprog måtte udvikles for at klare de nye opgaver, som de hurtigere
og bedre computere kunne udføre (en anden universel lov: vi er altid bagud i software, forud i
hardware og visioner). I slutningen af 60'erne kom revolutionen med struktureret programmering,
hvor programmerne opdeles i mindre dele efter de opgaver, de udfører. Mindre funktioner og
procedurer varetager mere specialiserede opgaver, og indgår i en helhed i en større opgave.
Funktionerne har så lidt med hinanden at gøre som muligt, og indeholder egne, lokale data.
Information kan flyde fra funktion til funktion efter formelle regler. Hver lille funktion kan
opfattes som et miniprogram, som, når det bliver samlet med de andre, blev til en applikation.
Målet var at gøre livet lettere for programmøren og samtidig gøre programmerne nemmere at
læse og vedligeholde. Et struktureret program skrives ved at bryde opgaven op i mindre, logisk
sammenhængende dele, og skrive disse dele hver for sig. Det gør det lettere at isolere problemer,
fordi en fejl kan føres tilbage til den funktion, som behandler en bestemt del-opgave. Selve
sproget gav en vis støtte til programmøren, som nu havde en chance for at forstå, hvad der
foregik. Selve eksekveringssekvensen blev mere tydelig i kildeteksten.
Med struktureret programmering blev et andet, meget kraftigt koncept introduceret, nemlig
abstraktion. Abstraktion defineres i struktureret programmering som muligheden for at kunne
bruge en facilitet uden at skulle bekymre sig om, hvordan den udfører sit arbejde. I et struktureret
program er det nok at vide at en given funktion udfører en operation, ikke hvordan den gør det -
så længe den virker kan den bruges (og genbruges) af programmøren. Dette kaldes funktionel
abstraktion og er hjørnestenen i struktureret programmering.
I dag er struktureret programmering og struktureret design ikke til at komme udenom. Alle
programmeringssprog understøtter de faciliteter, der kendetegner struktureret programmering,
selv BASIC er blevet struktureret! Det er ikke svært at forestille sig grunden til dette: Struktureret
programmering er en bedre metode end lineær programmering til at udvikle og vedligeholde
programmer.
Til gengæld voksede opgaverne igen. Problemet blev nu, at der ingen logisk sammenhæng var
mellem kode og data, og at større projekter med mange programmører havde svære tider med at
få deres respektive dele af et stort projekt til at kunne tale sammen.
1.1.3 Modulærprogrammering
Modulærprogrammering løser en del af disse problemer. I de fleste konventionelle proceduralt
orienterede sprog er det, som vi skal se, muligt at skjule irrelevante data fra klienten (i denne bog
benyttes termen klient om den programmør, der anvender og bygger videre på de programmer,
som andre konstruerer). Denne form for dataabstraktion er et skridt på vejen mod mere solide
programmer, fordi kode og data klumpes sammen i enheder. I C er det muligt at opdele
programmet i et antal separate kildefiler, der indeholder statiske data, som kun kendes i den fil de
er defineret i - heraf modulariteten. Bruges objektkoden fra dette modul af andre, kan de statiske
18 Introduktion 1

data ikke ses - de er private for modulet. Sproget Modula-2 går et skridt videre og har en formel
tilgangsmetode til private data, nemlig en sprogunderstøttet import- og eksportfacilitet af
moduler. Mens struktureret programmering tilstræber at associere data, som har med bestemt
kode at gøre, med denne kode, tvinger modulærprogrammering programmøren til dette. Eller
rettere: data skal isoleres med koden, og kun koden skal kunne være tilgængelig for andre.
Dette har vist sig at være en god idé. Men modulærprogrammering var mere en
programmeringsmetode end et programmeringssystem. Ideen med at samle kode og data er først
for alvor virkningsfuld, når den bliver brugt på den rigtige måde, men hvis sproget ikke støtter
metoden, vil der altid være faldlemme og ulemper. Der er derfor brug for en mere klar metode til
afgrænsning af grænseflader, afhængigheder og tilgang.
1.2 DATAABSTRAKTION
Dataabstraktion gør for data, hvad funktionel abstraktion gør for kode. Ideen med modulariteten
er at samle programmer og data, der har med hinanden at gøre, under samme tag. Dette kendes
fra C og Pascal, hvor struct- og record-konstruktioner gøres lokale til den funktion, der
bruger dem. C++ tillader, at vi samler data og kode i klumper for dermed at begrænse disse datas
virkefelter eller skop til de relevante funktioner. Dette kaldes indkapsling, og sikrer, at
datastrukturer kun manipuleres direkte af den kode, der har lov til det. Andre dele af programmet
må kalde en funktion for at ind- eller udlæse disse data. Hermed kan ansvaret for en inkonsistens
eller redundans i data føres tilbage til de dele af programmet, der ejer dem. Ingen uvedkommende
kan røre ved dem - de kan slet ikke se dem. Hermed gøres programmerne sikrere og mere
robuste.
Dette introducerer dog et andet problem. På grund af klientens tvang til indirektion bliver
dennes programmer sjældent læsbare. Ægte dataabstraktion udvider derfor dette koncept med en
entydig grænseflade, så klienten ser de omhandlede data som en ny datatype, der kan manipuleres
på generel vis, ligeledes defineret af designeren af typen.
Dataabstraktion er en vigtig grundpille i forståelsen af objekt-orienteret programmering.
Normalt har kun en oversætterdesigner mulighed for at skabe reelle nye datatyper. I de sprog, vi
kender, findes allerede abstrakte datatyper, for eksempel C's double. Denne decimaltalstype
findes sjældent direkte i hardware, og oversætteren erstatter hver manipulation med et
underforstået funktionskald. I C-udtrykket
a = b * c + d,
hvor alle variable er af typen double, vil den færdige objektkode indeholde underforståede
kald til en multiplikations- og en additionsrutine. Men vi har lov at bruge samme syntaks i vores
udtryk, som var det en heltalsberegning. Operatorerne har dermed forskellige betydninger, som
afhænger af den semantiske kontekst, og siges at have polymorfe egenskaber. Dette foregår
selvfølgelig uden programmørens indblanding, og vi tænker ikke på det til daglig.
Det er denne abstraktion, der i C++ er indbygget i selve sproget. Som programmører kan vi
designe nye datatyper og lade klienten anvende dem som var de indbyggede eller fundamentale
typer. Vi specificerer blot den grænseflade, vi ønsker typen skal have, og beder klienten om ikke
1.1.3 Modulærprogrammering 19

at bekymre sig om hvordan den reelt er implementeret. De nye typer, vi designer, kalder vi
abstrakte, fordi de i realiteten kan være af enhver art. Udtrykket abstrakte datatyper er en smule
misvisende, fordi typerne ikke forekommer abstrakte i brug, men derimod aldeles konkrete. Det
skal forstås sådan, at klienten kan abstrahere fra implementationen af typen og koncentrere sig
om sit eget problem.
1.3 OBJEKT-ORIENTERET PROGRAMMERING
Jeg har nævnt, at objekt-orienteret programmering kræver en ny holdning til opbygning af
programmer. Skabelsen af abstrakte datatyper og grænsefladen til deres brug nødvendiggør, at
programkonstruktionen må foretages særdeles anderledes. I stedet for at tænke på, hvordan
bestemte data manipuleres, som det gøres i proceduralt orienteret programmering, skal vi
fokusere på, hvad der skal gøres med disse data. Hvor vi hidtil har benyttet os af datastrukturer og
kontrolstrukturer som definition på et program, skal vi bruge ideen om objekter og beskeder eller
signaler objekterne imellem. Vi kan omskrive Niklaus Wirths frase datastrukturer + algoritmer
= programmer til objekter + beskeder = programmer.
Men hvad er et objekt egentlig? Det indeholder de nødvendige data eller datastrukturer for at
beskrive et emne eller en entitet, tilsammen med de funktioner - metoder - der skal til for at
manipulere emnet. Mulighederne er med denne simple definition endeløse: et objekt kan
indeholde en intern repræsentation af en bil, en skatteyder eller et psykofarmaka samt metoder til
at udregne kilometer/liter-forhold, fastsætte restskat eller bestemme bivirkninger. De fleste
objekt-orienterede sprog har en konstruktion til definition af et objekt. I C++ (og i de fleste andre
objekt-orienterede systemer) kaldes den for en klasse, og termerne klasse, abstrakt datatype og
brugerdefineret type benyttes i denne bog i reglen med samme betydning. Klasser udgør altså en
definition på en type, som kan instantieres i et objekt. En klasse og et objekt er ikke det samme;
et objekt er en forekomst af en klasse. Betegnelserne objekt, forekomst og variabel har i C++ stort
set den samme mening.
En stor del af objekt-orienterede sprogs styrke ligger i deres evne til at nedarve egenskaber fra
klasse til klasse. En generisk overordnet klasse kan nedarve sine egenskaber (data og metoder) til
en underordnet klasse, som så kan bygge videre på den. Den overordnede klasse, også kaldet
baseklassen, indeholder meget generelle strukturer, mens den underordnede eller afledte klasse
indeholder mere specifikke strukturer. For eksempel kan en overordnet klasse repræsentere et
transportmiddel, hvilket jo er et meget generelt koncept. Herefter kan en underordnet klasse, der
nedarver egenskaberne fra transportmiddel-klassen, beskrive en bil, mens en anden beskriver et
fly. Det kan endda ske i flere led, hvorved vi får adskillige mellemliggende klasser -
transportmiddel nedarver til køretøj, båd og flyvemaskine, som så igen nedarver til henholdsvis
personbil, bus og lastvogn, speedbåd, sejlbåd og færge samt propelfly, jetfly og svævefly. Den
resulterende struktur kaldes et klassehierarki.
Hvad er så den fordel ved arbejdet med klassehierarkier? Et hierarki set fra bunden består af
klasser af stigende generisk karakter. Generiske klasser kan bruges som overordnede for nye
klasser, som kan påføres hierarkiet som de bliver nødvendige. Denne form for
differentialprogrammering gør, at de tidligere definerede klasser (med grænseflader) ikke
behøver at gennemgå modifikationer, og vi opnår et vigtigt mål, nemlig genbrug af kode. Når vi
20 Introduktion 1

kan genbruge dele af programmer, vi allerede har skrevet uden at ændre i dem, har vi sparet tid.
Ikke kun i selve programmeringen, men i både analyse, design og test. En anden fordel ved
klassehierarkier er, at typen af et specifikt objekt - objektets reelle klasse - ikke nødvendigvis
behøver være kendt på oversættelsestidspunktet. Ved en teknik, der kaldes sen eller dynamisk
binding tillades identifikationen af det faktiske objekt fra et hierarki af relaterede objekter at vente
til kørselstidspunktet. Det giver programmøren mulighed for at sende en besked til et objekt uden
at kende den konkrete forekomst af objektet. For eksempel behøver programmøren kun viden
om, at en bestemt objekt-reference peger på et transportmiddel. Et bestemt funktionskald vil først
blive bundet til det objektet af den faktiske type (personbil, speedbåd osv.), når det foretages
under kørslen, og ikke under oversættelsen. I C++ realiseres dette med virtuelle funktioner og
abstrakte klasser, som tillader denne polymorfi. Teknikken lader os således benytte funktioner og
programmoduler, der virker og er skrevet til et specifikt formål få nye anvendelser, igen uden at
ændre i dem.
Nøgleordet er genericitet. Programudviklingen i fremtiden skal fokusere klart på, hvordan
systemerne kan opdeles i moduler af forskellig generisk karakter. Disse moduler, klasser,
delhierarkier eller komplette hierarkier bliver til et slags software-modstykke til integrerede
kredse, som man kan sammenstykke til en komplet applikation. Denne fremgangsmåde er
grunden til, at designfasen skal koncentreres om en differentiering af substansen i de forskellige
programdele.
1.4 PROGRAMMERINGSSPROGET C++
Programmeringssproget C++ bruges som referencesprog i denne bog, og dele af den kan i vidt
omfang bruges som lærebog i sproget. C++ er opfundet og først implementeret af danskeren
Bjarne Stroustrup i starten af firserne på det amerikanske telefonselskab AT&Ts Bell
Laboratories. C++ er en efterfølger til sproget C, og er på nær nogle få områder kompatibelt med
ANSI C - den første implementation af sproget hed endda C with Classes. Det giver Cprogrammører
mulighed for at komme i gang med det samme og gå inkrementalt til værks med
de nye faciliteter. C findes på næsten alle systemer, hvilket begrænser de teknologiske barrierer
mod at installere C++. Standardiseringen af C++, foretaget af den amerikanske nationale
standardiseringskomite ANSI, giver os garanti for en ensartethed mellem implementationer af
sproget på forskellige systemer. ANSI C++ har været undervejs siden 1986 og foreligger nu i en
form, der ligger meget tæt på AT&Ts version 3.0 af sproget.
C++ er ikke det første sprog, som understøtter de objekt-orienterede principper. Xerox'
Smalltalk er for eksempel et fuldt integreret objekt-orienteret programmeringsmiljø, Ada fra
USA's forsvarsministerium gør meget ud af dataabstraktion og LISP tillader sen binding. C++ har
"lånt" meget fra bla. Simula og Algol, men har nogle klare fordele frem for andre objektorienterede
sprog, idet det i henhold til definitionen på paradigmet er meget rent. Samtidig kan
det, fordi det bygger direkte på C, anvendes til systemprogrammering og opbygning af meget
store og komplekse programmer. C++ er, ligesom C, et minimalt sprog - der findes mindre end
50 reserverede ord - men samtidig meget alsidigt og effektivt.
Mange programmører er aldrig hoppet på C-vognen, fordi de efter en evaluering har skønnet, at
sproget har alt for mange faldgruber og giver anledning til alt for mange fejl. C++ afhjælper
1.3 Objekt-orienteret programmering 21

meget af dette, men bibeholder stadig de fordele, som C-programmører holder af deres sprog for.
Den basale syntaks er den samme, og nyhederne ændrer ikke sprogets ansigt væsentligt. Det er
anslået, at en fuld forståelse for objekt-orienteret programmering og C++ tager omkring et år,
men samtidig at udbyttet vil spare meget mere tid.
Figur 1-1: Placeringen af C++ blandt andre vigtige sprog.
22 Introduktion 1

I appendiks B gennemgås C++ specielt for C-programmører. Her forklares, hvordan de
væsentligste problemer i C kan overkommes med elegance og lethed i C++, og hvordan man som
C-programmør bør forholde sig til et skift til C++.
1.5 TERMINOLOGI OG KONVENTIONER
Denne bog er bygget over skeletter af C++ kode. For at skelne mellem brødtekst og tekst med
syntaktisk relevans (programtekst), bruges forskellige skrifttyper. Når der i brødteksten refereres
til dele af programteksten, benyttes en ensartet skrifttype for at understrege, at der er
tale om den entydige skrivemåde.
Alle programmører har sine egne præferencer hvad angår formatering af kildetekst, og
forfatteren er ingen undtagelse. I alle kode-eksempler benyttes en indryknings-teknik som denne:
void strcpy (char* dst, const char* src) {
while (*src) {
*dst = *src;
dst++, src++;
}
*dst = '\0';
}
I mange eksempler findes desuden en "tom kommentar":
// ...
for at vise, at der mangler programtekst på dette sted. Denne programtekst behøves ikke for at
forstå eksemplet, men skal selvfølgelig skrives for at få eksemplet til at køre. De fleste eksempler
kunne med lethed håndoptimeres med øget effektivitet som mål, men med læsbarheden som
offer. Det er vigtigere, at en illustration i form af et program kan forstås uden besvær.
Når funktionsnavne bliver omtalt i teksten, vil de blive fulgt af en tom parantesomslutning, som
i en henvisning til funktionen strcpy() ovenfor. Parametre medskrives ikke i brødteksten;
parenteserne er kun til at identificere et funktionsnavn.
Der anvendes generelt versaler til symbolske konstanter. For eksempel,
const int SECONDSPERHOUR = 3600;
og små bogstaver til ikke-konstante objekter af fundamentale datatyper, som i
long time = 1000000;
mens navne på brugerdefinerede datatyper altid starter med en versal. Hvis navnet består af flere
ord, begynder disse også med versaler - ikke separeret med understregninger, som det er kutyme i
C, men derimod som biversaler. For eksempel,
1.4 Programmeringssproget C++ 23

class Matrix;
class Complex;
class ObjectManager;
class AssociativeArray;
Navne på forekomster af brugerdefinerede typer følger samme regler som navne på
brugerdefinerede typer - blot er det første bogstav ikke skrevet med stort. For eksempel,
Matrix metaData;
Complex fourierSeries [100];
ObjectManager theManager;
AssociativeArray diskCache;
Eftersom objekt-orienteret programmering først nu er ved at blive udbredt i større stil, findes
ingen standardiserede danske oversættelser af de mange nye ord, der beskriver principperne og
metoderne. De danske ord, jeg har valgt at bruge i denne bog er taget fra flere de facto standarder
fra bla. danske softwarehuse, forlag, fagblade samt forslag fra danskere, der benytter C++ i deres
daglige arbejde. Der findes en ordforklaring i appendiks D, så betydningen af eventuelle for
læseren nye og mystiske ord kan slås op.
Slutteligt skal det nævnes, at litteraturhenvisninger og referencer nævnes i kantede parenteser
med den primære forfatters efternavn samt årstallet på udgivelsen og et eventuelt seriebogstav
hvis der er tvetydigheder. I appendiks E findes en bibliografi.
24 Introduktion 1

1.6 ORGANISERINGEN AF DENNE BOG
Det er en vanskelig proces at skifte arbejdsmodel. Alle softwarefolk, der bruger veldefinerede
metoder og indarbejdede værktøj har det dårligt med at skulle skifte til noget andet. Det faktum,
at der findes så mange forskellige systemer betyder, at en helt generel indføring i objektorienteret
tankegang uden fokus på det konkrete og dagligdags er svær at skabe. Af den grund
henvender denne bog sig bedst til dem, der i forvejen kender til C og arbejdsgangen bag
programudvikling med dette sprog. Og som konsekvens af dette er store dele af bogen centreret
om konkrete forskelle mellem C og C++, ikke som konstruktioner i selve sproget, men som
betydningen af brugen af disse konstruktioner i lyset af de programmeringsmæssige problemer,
de søger at løse.
Bogen er opdelt i syv kapitler og seks appendices. Hvert kapitel slutter med et sæt opgaver og
en begrebsliste, som kan bruges til at sikre, at materialet fra kapitlet er blevet forstået korrekt. Et
løsningssæt til opgaverne findes som separat publikation.
Kapitel 2 er en uformel introduktion til selve programmeringssproget C++, dets syntaks,
datatyper og kontrolstrukturer og forskellige mønstre i programmeringen, der følger med.
Sådanne mønstre kaldes undertiden idiomer, fordi de ikke er dele af definitionen på sproget, men
er sæt af uskrevne regler for brugen af det. Et eksempel på en idiomatisk konstruktion fra C (og
C++) er
while (*q++ = *p++);
som kopierer en streng. Den er ikke en del af C, men vil være kendt som en fundamental
byggeklods for kyndige C-programmører. Det er netop byggeklodser som disse, der gør et sprog
anvendeligt og som essentielt differentierer programmeringssprog af samme type, fordi de
essentielt følger samme regler men har forskellig syntaks og dermed forskellige idiomatiske
manifestationer. Kapitel 2 søger at opridse disse idiomer.
Kapitel 3 indeholder en gennemgang af begrebet dataabstraktion og fører læseren gennem
koncepterne bag programmering med abstrakte datatyper. En bred forståelse for dataabstraktion
er nødvendig for anvendelsen af mange objekt-orienterede principper og bliver i dette kapitel sat
skarpt op mod de muligheder for abstraktion, der ligger i ældre sprog. Med udgangspunkt i et
eksempel-problem gennemføres en løsning med sproglige konstruktioner fra C++ lidt efter lidt -
inkrementalt - så det bliver gjort klart, hvor fordelene og faldlemmene ligger. Denne
fremgangsmåde, som bygger på en problemstilling og et løsningsmønster, der er forkert for så at
vise, hvorfor det er forkert og hvordan det kan gøres anderledes, kaldes løsning per absurdum.
Jeg viser således ikke blot, hvordan tingene bør gøres, men også hvordan de ikke bør gøres.
Kapitlet slutter med en gennemgang af designfasen i udviklingen af abstrakte datatyper og de nye
anvendelsesområder, de lægger op til. Til sidst findes et antal konkrete eksempler på anvendelser.
I kapitel 4 åbnes for substansen i anvendelsen af C++, nemlig for objekt-orienteret
programmering. Jeg har valgt en pragmatisk indgangsvinkel til introduktionen af hele
paradigmet, og starter derfor fra en programmeringsmæssig vinkel og går i kapitel 5 mere
analytisk til værks. Også i kapitel 4 benyttes en eksempel-problemstilling, som gradvist løses
med objekt-orienterede metoder som de fremlægges, så læseren får mulighed for at se fejlene ved
de traditionelle løsningsmodeller. Specifikt forsøges problemerne først løst med abstrakte
1.5 Terminologi og konventioner 13

datatyper for dernæst at vise, at det i et større perspektiv ikke lever op til alle vore krav. Kapitlet
behandler de konkrete sproglige konstruktioner i C++ såsom arv, grænseflader, typekonvertering,
polymorfi og multipel arv. Særligt behandles de problemer, som de forskellige faciliteter bærer
med sig.
Kapitel 5 lægger som nævnt en mere formel linie til det objekt-orienterede paradigme og
fokuserer på fasemodeller og organisation. Jeg mener, det er til læserens fordel at have noget
praktisk og håndgribeligt i baghovedet før en principiel og metodisk diskussion om anvendelser
og teknikker kan begyndes. I kapitlet gennemgås således de overvejelser for systemkonstruktion,
som indføringen af objekt-orienteret programmering gør nødvendig, især med henblik på at
opridse de muligheder og konsekvenser, de medfører.
Kapitel 6 er en gennemgang af standardbiblioteket i C++, det sæt af klasser og funktioner til
tegnbaseret I/O, som følger med de fleste oversættere. Dette bibliotek analyseres ud fra to vinkler,
dels så læseren får en detaljeret forståelse for opbygningen og dermed kan udnytte det til fulde og
dels, fordi opbygningen af klassehierarkiet bag biblioteket er en god kandidat for et studie.
I kapitel 7 præsenteres et konkret lille klassebibliotek, XCL, som indkapsler traditionelle
datastrukturer og algoritmer og som kan bruges som udgangspunkt for videre programudvikling.
Klassebiblioteket er af generel karakter, er hardware-uafhængigt og kan bruges som case study
for opbygningen af klassebiblioteker. Hele biblioteket gennemgås med referencer bagud i bogen
til de overvejelser, der har gjort sig gældende for specifikke klasser og implementationer.
Biblioteket findes i sin helhed i appendiks F.
De seks appendices indeholder henholdsvis en oversigt over alternative implementationer af
C++ med mulige fremtidige udvidelser og tilretninger, en samling af gode råd til Cprogrammører,
der ønsker at skifte til C++, en kort oversigt over andre objekt-orienterede
systemer på markedet, en liste over de danske oversættelser af engelsk fagsprog, der bruges i
bogen samt en bibliografi og den komplette kildetekst til klassebiblioteket fra kapitel 7.
14 Introduktion 1

C++
Dette kapitel giver en generel, men koncis, indføring i sproget C++. Hvis
læseren allerede kender C++'s syntaks og regler for kontrol- og datastrukturer,
kan kapitlet springes over, mens det for C-kyndige programmører bør
gennemlæses med henblik på de få fundamentale forskelle mellem de to sprog.
Det er nødvendigt at være fortrolig med syntaksen i C++ for at kunne forstå
eksemplerne senere i bogen. Kendes hverken til C++ eller C, henledes
opmærksomheden på litteraturlisten i slutningen af kapitlet. Det formodes, at
læseren kender de grundlæggende principper i procedurale sprog, samt fysiske
metoder og værktøjer i udviklingsprocessen.
2.1 INTRODUKTION
En stor del af C++'s styrke kommer fra, at det er afledt direkte fra C og derfor har en god base for
at udvikle sig i mange udviklingsmiljøer. De første oversættere blev implementeret som
translatører, dvs. programmer, som konverterer C++-kode til standard C-kode. Dermed var det
muligt at starte med udvikling i C++ med det samme. Den originale translatør, cfront, som blev
udviklet af Bjarne Stroustrup fra det amerikanske telefonselskab AT&T, er i dag flyttet til næsten
alle kendte systemer.
I takt med den øgede interesse omkring C++ begynder nu "rene" oversættere at komme på
markedet. Disse oversættere springer C-leddet over, og genererer objektkoden direkte med to
fordele til følge: oversættelsen sker hurtigere, og det bliver muligt at køre en symbolsk debugger
på koden, hvilket letter udviklingsarbejdet betragteligt.
For en vordende C++ programmør giver arven fra C en anden fordel, nemlig at han kan gå
inkrementalt til værks med de nye faciliteter. Han kan være produktiv samtidig med, at han
tilegner sig viden om et nyt sprog - det ses sjældent. De fleste eksempler i denne bog er bygget
op, så en C-programmør let vil kunne se, hvad der foregår og relatere det til sin viden om dette
sprog.
Men hvem henvender et objekt-orienteret sprog i C++'s skikkelse sig til? Først må det gøres
klart, at C++ ikke er et stort 4-generationssprog. Det er designet ud fra en minimalist-filosofi, som
siger, at "hvad programmøren selv kan programmere sig ud af, skal sproget ikke indeholde." C++
viderefører dermed ideen fra C, som ligeledes kun indeholder hvad er absolut nødvendigt.
Dernæst skal det siges, at C++ er et generelt programmeringssprog, som ikke favoriserer
1.5 Terminologi og konventioner 15
2

estemte problemer og løsningsmodeller fremfor andre. Vi kan skrive alle typer programmer i
C++, det være sig indenfor simulation, kunstig intelligens, procestyring, systemprogrammel,
kommunikation, grafiske brugerflader osv. Som eksempel kan nævnes, at AT&T har omskrevet
UNIX-operativsystemet i C++, mens FN bruger sproget til udvikling af simulationsprogrammel
til u-landsprojekter. Pointen er, at programmøren gennem sprogets faciliteter selv må skabe de
nødvendige "byggeklodser" for sit eget softwareprojekt. En konsekvens af denne filosofi er, at
C++ ikke indeholder faciliteter for I/O, men derimod appellerer til generalitet og flytbarhed ved
at forudsætte implementering af I/O ved hjælp af sproget selv.
Det er svært at spå om, hvilket objekt-orienteret sprog vil komme til at dominere i fremtiden.
Det har nemlig vist sig, at der er større forskelle end først antaget mellem objektorienterede
systemer, selvom de ofte sættes i samme bås. Dog har C++ to væsentlige fordele frem for mange
af konkurrenterne: det følger helt igennem de objekt-orienterede koncepter uden kompromiser,
og det er samtidig et system-orienteret sprog, som man kan skrive "rigtige" programmer i. Man
kan argumentere for, at et sprog som Smalltalk er mere holistisk, og derfor lettere at forstå, men
Smalltalk kan ikke bruges reelt til systemudvikling. Ligeledes er Ada ikke helt "rent", og er tillige
for tungt at danse med på mindre systemer. I appendiks C findes en oversigt over andre objektorienterede
systemer.
2.2 UDVIKLINGSMILJØET
Kildeteksten skrives normalt som tekstfiler i et redigeringsværktøj. Disse filer bliver af
oversætteren konverteret til objektkode, som indeholder dels den færdige målkode til en bestemt
maskinarkitektur og dels en symboltabel over funktioner og variable, der evt. skal bruges udefra.
Der er ofte flere objektfiler i et projekt. Et program består ofte af flere "moduler" som oversættes
separat, og programmet benytter sig hyppigt af standardrutiner, som ligger i et standardbibliotek.
Objektfilerne kædes sammen af en lænker, som finder og binder alle referencer filerne imellem.
Lænkerens output er et køreklart program, der startes af en loader, der normalt er integreret i
operativsystemet.
Der er fire principielle grunde til at fordele et program på flere fysiske kildefiler. For det første
nedsættes oversættelsestiden drastisk, da al kildetekst ikke skal oversættes, hver gang en mindre
ændring foretages. Dernæst kan et system ikke altid rumme en komplet oversættelse rent
hukommelsesmæssigt, hvis al kildekode findes i samme fil. For det tredje kan programmøren
opdele programmet i "moduler", som hvert repræsenterer en omsluttet del af hele programmet.
Og sidst ses fordelen af oversætter-lænker konceptet mere tydeligt, når to eller flere
programmører arbejder på samme projekt. Det er for meget besvær at skulle redigere i den
samme fysiske fil under udviklingen. En ekstra fordel ved separat lænkning er, at det tillader os at
blande objektmoduler fra forskellige sprog sammen i samme program.
2.2.1 Erklæring og definition
Et velskrevet C++-program består af to dele: erklæringer og definitioner. Disse to dele er
konceptuelt fordelt på separate filer. Erklærings-delen indeholder alle deklarationer af navne på
16 Introduktion 2.1

funktioner eller data i kildefilen, som skal kunne ses af fremmede kildefiler, mens definitionsdelen
indeholder den faktiske kode. Når et navn skal ses udefra, kaldes det offentligt. Erklæringsfilerne
kaldes normalt header-filer, og ender af den grund ofte i ".h", mens definitions-filerne
indeholder kildetekst, og har normalt enten endelsen ".c", ".cp", ".cpp" (for c-plus-plus) eller
".cxx" (to skæve plusser).
C++ har et meget stærkt typesystem og derfor meget strenge regler for brugen af typer. Derfor
behøves en specifikation af for eksempel funktioners parameterlister og returtyper. Ligger
funktionen fysisk i samme kildefil hvor den refereres fra, er det intet problem, så længe
erklæringen kommer før kaldet. Hvis funktionen imidlertid ligger i en anden fysisk kildefil, og
først bindes af lænkeren, skal en eksplicit erklæring indeholdes i kildefilen. Under gennemløbet
af kildekoden (normalt kun et enkelt), har programmøren via et specielt såkaldt direktiv lov til at
"inkludere" andre filer i den aktuelle. Dette bruges næsten udelukkende til inkludering af headerfiler,
som specificerer grænsefladen til den objektfil, man ønsker at binde til. I figur 2-1 ses to
kildefiler, proces.cpp og klient.cpp. proces.cpp tænkes at indeholde funktioner
og data, som klient.cpp skal bruge. Header-filen proces.h sikrer, at klient.cpp får
den rigtige grænseflade til funktioner og data i proces.cpp. proces.cpp inkluderer
imidlertid også header-filen, for derigennem at undgå redundans og sikre konsistens.
2.2.2 Præprocessering
Inklusion af filer foretages af den del af oversætteren, som hedder præprocessoren.
Præprocessoren arbejder ikke med kildetekst som syntakstekst, men bruges til forskellige
opgaver før den egentlige oversættelse. Kommandoer til præprocessoren skal skrives på en linie
for sig selv i kildeteksten, med start på det første tegn på linien, som skal være et #, se afsnit
2.10.
Blandt præprocessorens muligheder ligger definition og ekspansion af makroer samt betinget
oversættelse. Makroer er blot tegnsekvenser, som erstattes af andre sekvenser, før selve
oversættelsen tages op, men kan også bruges til at holde værdier, som har betydning for selve
oversættelsen, dvs. symboler, som ikke har noget direkte at gøre med det færdige, oversatte
program. Inklusion af andre filer (normalt header-filer) i en given kildefil foretages med
#include-direktivet, efterfulgt af navnet på filen, som skal substitueres på dette sted. Filnavnet
skal omsluttes af enten klammer eller citationstegn, for henholdsvis en standard-header, som
ligger i standard-kataloget for headerfiler, og bruger-skrevne header-filer, som ligger i det
aktuelle katalog eller via et stinavn givet i sætningen.
2.2.1 Erklæring og definition 17

Figur 2-1: Afhængigheder mellem filer
Makroer og betinget oversættelse spiller nært sammen. Betinget oversættelse betyder, at en del
af kildeteksten skal springes over og slet ikke skal ses af selve oversætteren. Der er flere
umiddelbare grunde til, at der eventuelt skal foretages betinget oversættelse under programmørens
kontrol via specielle præprocessor-direktiver, som minder meget om de generelle
if/else-strukturer, vi finder i selve sproget. Først kan en given kildetekst rumme muligheden
for at kunne producere kode til forskellige miljøer eller maskinkonfigurationer. Ved at
fremskynde sådanne betingelser fra kørselstidspunktet til oversættelsestidspunktet opnås både
sikrere og mindre programmer. Et eksempel på dette er kode, som bruges under fejlretningen i
programmerne - kode, som ikke skal være til stede i produktionsversioner. Disse kan med fordel
gøres til genstand for betinget oversættelse, så de med en enkelt ændring i kildeteksten helt kan
udelades fra programmet. Det er vigtigt at skelne betingelserne i præprocessoren fra de
forskellige betingede kontrolstrukturer i C++ (afsnit 2.7), da der er tale om to helt forskellige ting:
betingelser på oversættertidspunktet og på kørselstidspunktet. Betinget oversættelse er kun et
værktøj for udvikleren. #define erklærer makroer (afsnit 2.10), #if sætter betingelsen for
oversættelse indtil næste #endif eller #else.
2.2.3 Typesystemet
Som nævnt er C++ baseret på et stærkt typesystem, som kræver at der er overensstemmelse
18 Udviklingsmiljøet 2.2

mellem typerne af de objekter, der relateres i programmerne. I modsætning til konventionelle
programmeringssprog udvider C++ typesystemet, så programmøren kan konstruere egne,
specialdesignede typer - såkaldte brugerdefinerede typer eller abstrakte datatyper. For disse
typer gælder samme regler som for de indbyggede typer i sproget - de fundamentale eller
konkrete typer. Det giver sproget en styrke, som tillader en ensartet syntaks og forståelse for
programmernes og datamodellernes struktur og anvendelse.
2.2.4 Standard-input/output
En væsentlig detalje i C++ (og C), som kun findes i få andre sprog, er som nævnt fraværet af
indbyggede faciliteter for tegnbaseret input og output. Som følge af minimalist-designet kan
programmøren selv skrive den nødvendige kode.
Dog findes visse funktioner i et standardbibliotek, som findes på alle C++-systemer. Dette
bibliotek definerer fire kanaler eller strømme for I/O, nemlig standard input, standard output,
standard fejl-output samt en bufferet version af sidstnævnte. Disse strømme er normalt bundet til
tastaturet og skærmen, men kan omdirigeres ved kørselstidspunktet. Når et C++-program kalder
en standard-funktion, ved denne, hvor eventuelle data skal sendes videre. Fordi biblioteket netop
er standardiseret, sikrer denne metode, at C++-kode er relativ flytbar, altså at den kan flyttes fra et
system (for eksempel MS-DOS) til et andet (for eksempel UNIX) uden de store kvaler. Og da
oversætteren ikke behøver at vide noget om I/O, gør det arbejdet lettere for oversætterdesigneren,
hvis oversætteren skal flyttes. Det betyder også, at det står applikationsprogrammøren frit at
skabe sin egen I/O som han lyster.
Standardbiblioteket indeholder også et antal generelle funktioner og konstanter, som kan bruges
af applikationerne. Mere om dem i slutningen af kapitlet.
2.3 GRUNDLÆGGENDE SYNTAKS
Kildetekst i C++ gennemløbes en enkelt gang (single-pass) af oversætteren og analyseres på den
måde fra venstre mod højre. C++-programmerne skrives også i en først-A-så-B-stil, hvor de
trinvise instruktioner udgør programmerne. Det simpleste C++-program ser således ud:
#include
main () {
cout

Ethvert C++-program starter sin kørsel i main. De krøllede parenteser, Tuborg-parenteserne,
hører sammen og omslutter en blok, i dette tilfælde indholdet af funktionen main. Mere om
funktioner senere i kapitlet.
Linie 4 sender strengen "Goddag C++-verden!\n" til standardoutput-strømmen. En
streng i C++ består af en række enkelte tegn i sekvens, omsluttet af citationstegn. "\n" i
slutningen af strengen er et newline-tegn, og betyder, at følgende output skal fortsætte fra næste
linie (det, nogen stadig kalder vognretur). Mere om strenge senere.
2.3.1 Kommentarer
De fleste programmeringssprog giver programmøren mulighed for indsættelse af kommentarer
direkte i kildeteksten. Denne form for lavniveau-dokumentation er meget brugbar, da enkelte dele
af programmet kan uddybes i flydende tekst. Kommentarer ignoreres af oversætteren, og bruges
alene til at forklare andre (eller én selv), hvad der foregår.
Kommentarer i C++ skrives på en af to måder, enten som enkelt linie eller som en hel blok af
tekst:
// dette er en kommentar, der ender nu
/* dette er en kommentar, som fylder
tre linier
*/
De to skråstreger // fortæller oversætteren, at resten af linien er en kommentar, som skal
ignoreres. Tekst, der er omsluttet af /* ... */ ignoreres også, og kan spænde over flere
linier. Den første form er arvet fra BCPL (en fjern forfader til C++), mens den sidste er arvet fra
C.
2.3.2 Afstand
Kildetekstens elementer separeres af afstandstegn. Afstandstegn er linieskift, sideskift og
vognretur og mellemrum (ASCII 10, 12, 13 og 32). Reglerne for brugen af afstand er, at navne
skal separeres, hvis meningen ellers går tabt. Dette sker dog sjældent i C++. Eksemplet i afsnit
2.3 kunne se således ud, hvis afstandstegn ikke benyttedes:
#include
main(){cout

finde rundt i sin egen kode).
Brugen af afstand har for de fleste programmører en æstetisk betydning. Man "formaterer" sin
kildetekst, så meningen (semantikken) lettere kan forstås. Indholdet af funktioner, løkker osv. bør
"indrykkes", så det kan overskues, og så slutningen let kan lokaliseres. Brug afstand og
kommentarer med fornuft; det kan betale sig.
2.3.3 Navne
Hovedparten af et program består af brugerdefinerede navne på data og funktioner. Der er visse
syntaktiske regler for disse navne: de skal udelukkende indeholde alfanumeriske tegn, og skal
ydermere starte med et bogstav. Alfanumeriske tegn er alle tal (0 til 9), alle bogstaver (a til z, A
til Z - altså ikke danske tegn) samt understregningstegnet (_). Eksempler på lovlige navne er
Beaujolais minvar3 MO9CA _operatornew MON9CA
mens ulovlige navne for eksempel kan være
4NIC8 @@@@ 2MAT AMOUNT$
Heltal%
C++ har et antal reserverede navne, som har prædefinerede betydninger i sproget. Syntaksen i
C++ tillader ikke disse at blive brugt som brugerdefinerede navne. De reserverede navne er:
asm auto break case catch
char class const continue default
delete do double else enum
extern float for friend goto
if inline int long new
operator overload private protected public
register return short signed sizeof
static struct switch template this
throw typedef union unsigned virtual
void volatile while
Navne skal være unikke i C++, dvs. det er ikke tilladt at bruge samme navn i to eller flere
kontekster, hvis det kan lede til tvetydigheder. Det er dog tilladt at benytte ens navne, hvis der
ikke opstår konflikter, hvilket indebærer, at de eksisterer separat fra hinanden i programmet under
hvert sit skop - se afsnit 2.6.1.
2.3.4 Sætninger
Programmer opbygges af sætninger, som beskriver de enkelte databehandlinger. Sætninger er
2.3.2 Afstand 21

derfor interessante, fordi det er dem, som rent faktisk udfører arbejdet. Syntaksen i C++ kræver,
at der skal et semikolon (;) efter hver sætning. Således er et semikolon for sig selv en "tom
sætning":
; // intet sker her
Der er en klar konsistens i syntaksen for, hvornår der skal semikolon, som afviger en smule fra
andre semikolon-brugende sprog som Pascal og Modula-2, der bruger semikolon som generel
separator. C++ bruger afstand som separator, og har derfor kun brug for semikolon som
afslutning på sætninger. Grunden til, at denne diskussion er interessant er, at C++ tillader dig at
blande sætninger sammen på en meget fri måde, som ikke kendes fra andre sprog:
while ( (a = getchar()) != EOF) putchar (a);
Denne sætning er en løkke, som gennemløbes indtil en afbrydelses-tilstand er sand, eller mere
korrekt, indtil en gentagelses-tilstand bliver falsk. Hele linien er een sætning, som består af en
løkke med en betingelse, en tildeling og et funktionskald. Sætninger er således afsluttede,
enkeltstående sekvenser i programmet, som kan forstås og beskrives i en enkelt omgang. Der skal
ikke semikolon efter andet end hele sætninger.
2.3.5 Udtryk
I afsnit 2.4 tager vi fat på de forskellige datatyper i C++, men først skal vi se på, hvordan disse
typer arbejder sammen. I C++ sammensættes forekomster af forskellige typer i udtryk, som består
af et eller flere objekter. Objekterne i et udtryk kaldes for operanter (undertiden operander) og de
sættes sammen med operatorer. Operatorerne styrer, hvordan operanterne skal fortolkes i forhold
til hinanden eller i forhold til sammenhængen. Operatorer, der arbejder på én operant kaldes
fortegns-operatorer, mens de, der arbejder på to operanter kaldes binære operatorer. Et eksempel
på et udtryk er
a
som simpelthen er objektet a. Et sammensat udtryk, hvor to operanter ganges sammen med
multiplikations-operatoren * kan se således ud:
a * b
mens et udtryk, der består af to subudtryk kan eksemplificeres ved
a * b + c * d
2.4 TYPER
22 Grundlæggende syntaks 2.3

I C++ klassificeres alle data efter deres type. Type-begrebet betyder, at programmøren kan
relatere data med andre data, så oversætteren forstår det, og er i C++ udbygget til at omfatte
brugerdefinerede typer. At arbejde med datatyper er i grunden et spørgsmål om, hvordan et
bestemt mønster skal fortolkes i en given sammenhæng. For når det kommer til stykket, er
computerens lager organiseret i lineært adresserede bits, nuller eller ettaller. Lange rækker af
nuller og ettaller er svære at fortolke og arbejde med for programmører, fordi der ikke ydes hjælp
til at forstå strukturen i rækken.
På generelle computere beskrives lageret normalt i bytes (på dansk undertiden benævnt
oktetter), som er enheder af 8 binære cifre eller bits. I realiteten er lageret underlagt processorens
arkitektur, og er organiseret i maskin-ord, som er det mindste antal bits, som på én gang kan
adresseres. Maskinord er en kvantitet, som er bestemt af computerens arkitektur, og afhænger af
processorens databusbredde. Deres format er derfor hardware-afhængig og ikke entydig at
fortolke. For eksempel vil sekvensen af bits
1111000000000001
på en Intel-processor repræsentere decimaltallet 496, mens det på en Motorola-arkitektur vil være
61441 † . For at sikre, at programmer har en rimelig grad af flytbarhed, overtager oversætteren
behandlingen af de hardware-afhængige aspekter ved at indføre typer, som netop er karakteriseret
som hardware-uafhængige. En type er således en abstraktion af et numerisk, matematisk eller
andet begreb, som gør det lettere for programmøren at overskue en problemstilling i selve
programmets kildetekst. Eller med andre ord: en given bitstrøm er umulig at behandle uden at
kende strømmens type. Derfor et typesystem.
C++ har et antal indbyggede datatyper, som alle er arvet fra C. Typerne beskriver et antal
lagerenheder af fast længde samt de operationer, der kan udføres på dem. En type er således en
prægeplade for faktiske objekter af den type. Typen kan ikke manipuleres, men det kan objektet,
og vi siger derfor, at et objekt er en forekomst af en bestemt type.
Som nævnt i afsnit 2.2.3 indeholder C++ et antal fundamentale typer samt muligheden for at
udvide med egne brugerdefinerede typer. Senere i afsnit 2.4 behandles de forskellige
fundamentale typer i detaljer, men for at lette forståelsen i de mellemliggende afsnit skal et par af
dem kort opremses: typerne char, int og long repræsenterer alle heltal og forskellen
mellem dem er deres præcision - altså antallet af værdier, de kan indeholde. De arbejder sammen
med og kan tildeles konstante værdier - for eksempel tallet 42 - og er normalt forbundne med
henholdsvis tegn, små heltal og store heltal.
2.4.1 Symbolske variable
† Det hænger sammen med, at Motorola-processorer arbejder efter little-endian princippet, dvs. det mest
betydningsfulde ciffer står først i lageret. På en Intel-maskine er det omvendt, da den har det mindst betydningsfulde
først, og lægger tal ud i lageret på en big-endian måde. Disse benævnelser stammer fra Johnathan Swifts fortælling
om Gulliver's Rejser, i hvilken der berettes om en uoverensstemmelse over, hvorvidt man bør spise et æg fra den
store eller den lille ende.
2.3.5 Udtryk 23

I C++, som i de fleste andre programmeringssprog, udføres databehandlinger gennem
manipulationer af variable. Det letter programmeringen, fordi variablene giver os en symbolsk
abstraktion i form af et navn. Gennem navnet (på engelsk variablens identifier) kan vi manipulere
variablen (eller objektet) på forskellige måder og med sprogets kontrolstrukturer kan vi
strukturere brugen af variablene, så kompleksiteten minimeres.
Et objekt og en variabel har stort samme betydning i objekt-orienteret programmering. Den lille
spidsfindige forskel er, at en variabel henviser til en syntaksmæssig størrelse i kildeteksten (en
variabel med et eller andet navn) mens et objekt betyder en forekomst af en bestemt type (et
objekt med en eller anden type). I dette afsnit taler vi om syntaks, som er rettet mod objekternes
navne, og bruger derfor variable.
Variable repræsenteres af symboler. En C++-variabel har en unikt navn (afsnit 2.3.3), og skal
erklæres som en variabel af en bestemt type før den kan bruges. Erklæringen af en variabel v
med en type T foretages ved
T v;
hvorefter v kan opfattes som en abstraktion af typen T, for hvilken gælder et sæt regler for bla.
ind- og udlæsning, generel manipulation og oprettelse/nedbrydning. v er ydermere en symbolsk
variabel, dvs. en abstraktion, som lader os arbejde med et navn, som associerer det, som
variablen repræsenterer med et egentligt navn. Denne abstraktion tabes med det samme i
målkoden, fordi det færdigtoversatte program ikke bibeholder symbolikken. Den er kun til gavn
for udvikleren, som kan døbe en variabel et navn, som har forbindelse med dens indhold. For
eksempel vil et godt navn til en variabel, som beskriver en temperatur være celcius † .
Der er altså en forskel på de to former for abstraktion, som typesystemer giver programmøren:
den ene giver hardwareuafhængighed, den anden giver syntaksfrihed. Tildelinger af variable
foretages med et lighedstegn,
celcius = 5;
hvilket tildeler variablen celcius værdien 5.
Der skelnes mellem to slags udtryk i tildelinger, nemlig udtryk til venstre for et lighedstegn (en
lvalue, udtales "el-value") og udtryk til højre for (en rvalue, udtales "ar-value"). Venstre-udtryk
skal kunne fortolkes som en endelig adresse, hvori en værdi kan placeres, mens højre-udtryk skal
resultere i en håndgribelig værdi. Grunden til, at det er interessant er, at det højre-værdier og
venstre-værdier differentierer adressérbare objekter.
Symbolske variable er adressérbare, og har således to værdier, der beskriver dem. Den ene er
variablens dataindhold mens den anden er dens adresse. Et udtryk resulterer altid i enten en højreværdi
eller en venstre-værdi, men kun venstre-værdier (adressérbare objekter) kan stå til venstre
for lighedstegnet. Højre-værdier kan kun stå til højre for lighedstegnet, til venstre giver de ingen
mening. Som vi skal se i afsnit 2.4.6 er tallet 5 en literal konstant, som altid er en højre-værdi.
Den er ikke adressérbar, hvorfor sætningen
† Navnet temp er et dårligt valg, fordi det traditionelt associerer til det engelske temporary, altså midlertidig.
24 Typer 2.4

5 = celcius;
er meningsløs. Oversætteren vil ikke godtage denne sætning. Idet symbolske variable har to
associerede værdier kan de stå både til højre og til venstre for lighedstegnet, og fortolkningen af
dem afhænger derfor helt og aldeles af, om de i det aktuelle udtryk er venstre-værdier eller højreværdier.
For eksempel,
celcius = celcius + 10;
Her fortolkes den første celcius som en venstre-værdi, altså variablens egentlige position,
mens den anden fortolkes som dens faktiske og aktuelle værdi. Højre-værdier kan være en
kombination af subudtryk, opdelt af operatorer. Operatorer bruges til at associere og samle
variable i beregninger eller sammenligninger. Et sammensat udtryk kan se således ud:
areal = hoejde * bredde; †
hvor hoejde og bredde gennem en multiplikation resulterer i en højre-værdi. Venstreværdier
kan også bestå af sammensatte udtryk, som vi skal se senere i dette kapitel.
En tildeling kan forekomme på samme tid som en erklæring. Erklæringen og tildelingen
long x;
x = 1;
kan skrives kortere som
long x = 1;
i de fleste tilfælde, afhængig af skop og type. Parenteser bruges i komplekse udtryk til at
underkende de indbyggede regler for præcedens mellem for eksempel additions- og multiplikationssubudtryk,
som i
a = (5 + 3) * 4;
hvilket tildeler a produktet af 4 samt additionen mellem 5 og 3, altså 32. Skrives
a = 5 + 3 * 4;
vil den indbyggede præcedens mellem operatorerne (se tabel 2-2) gange 3 med 4, og så addere 5
med resultatet 17. Værdierne kan specificeres på mange forskellige måder, som beskrives i afsnit
† De danske bogstaver Æ, Ø, Å, æ, ø samt å kan ikke bruges i selve kildeteksten, da de ikke er lovlige tegn i navne.
Derfor bruges de sammensatte AE, OE, AA osv. i stedet. Dette gælder ikke for kommentarer, der ignoreres af
oversætteren.
2.4.1 Symbolske variable 25

2.4.6. I C++ (og C) er syntaksen meget generel, og tillader placering af tildelinger og erklæringer
næsten overalt. Dette leder i nogle tilfælde til sætninger, hvor meningen kan gå tabt for en hurtig
læser. I udtrykket
a = b = c + d;
tildeles både a og b summen af c og d. Syntaksen bruges, når flere variable skal tildeles eller
initieres med samme værdi. Parenteser kan benyttes i flerdelte tildelinger, hvorved de enkelte
elementer tildeles værdien indenfor den parentes, de står. I udtrykket:
a = (b = c) + d;
tildeles a summen af c og d, mens b tildeles værdien af c alene, grundet parenteserne.
Komma-tegnet har en særlig betydning i C++, idet det bruges til at sekvensere udtryk. To eller
flere erklæringer og/eller tildelinger kan samles i en enkelt sætning, separeret af kommaer:
int a, b = 2, c, d = 4; // 4 heltalserklæringer
a = b, c = d; // to tildelinger
Der er en spidsfindig forskel mellem initieringer (som int i = 5) og tildelinger (som i =
5), som skal vise sig at være meget væsentlig i forbindelse med abstrakte datatyper. En initiering
indebærer, at det pågældende objekt bliver konstrueret med en bestemt værdi mens en tildeling
blot ændrer et eksisterende objektets værdi.
2.4.2 Fundamentale typer
De indbyggede datatyper i C++ kaldes også samlet de fundamentale typer. Denne betegnelse er
opstået på grund af C++'s mulighed for at udvide typesystemet med brugerdefinerede datatyper.
De fundamentale typer er de, som sproget er født med, og som oversætteren selv kender til. De 6
fundamentale typer repræsenterer alle heltal eller kommatal med forskellig præcision: char,
short, int, long, float og double. De fire første er heltals-typer, de sidste to kommatalstyper.
Forskellen på de forskellige typer i de to "familier" er præcisionen, dvs. antallet af
forskellige tal, der kan repræsenteres i den pågældende type. C++-standarden siger to ting om
præcision, nemlig
1. at en char er mindre eller lig en short, en short mindre eller lig en int, og en
int mindre eller lig en long, samt at en float er mindre eller lig en double,
char

float

Figur 2-2: Intervaller for signed og unsigned char-typer.
En anden modifikator til en type er register-nøgleordet. C++ tillader i forskellige
sammenhænge, at programmøren blander sig i oversætterens arbejde. For variable gælder det, at
de i objektkoden behandles enten i CPU'ens interne registre alene, eller bliver skiftet ud mellem
CPU'en og lageret. Med register før en erklæring fortæller man oversætteren, at den
nærværende variabel bruges på en måde, som egner sig til intern CPU-behandling. Oversætteren
vil så vidt muligt forsøge at følge dette råd, men giver dog ingen garanti. En registervariabel
er oftest en afledt type, men kan også være en forekomst af en fundamental type. Der er
ingen forskel i brugen i forhold til normalt erklærede variable.
Erklæringen foretages således:
register int a;
I standardbiblioteket, der følger med de fleste oversættersystemer, findes en headerfil ved navn
limits.h, som beskriver de absolutte størrelser, maksimal- og minimalværdier samt intervaller
for de fundamentale typer i C++ i den pågældende implementation. Disse værdier er symbolske
konstanter og kan bruges for at sikre, at en påkrævet præcision overholdes.
2.4.3 Pointertyper
Figur 2-3: Præcisionen af kommatal centreres omkring 1 og -1.
C++ har en maskinnær opbygning. Af den grund findes både sproglige konstruktioner og afledte
typer, der mere eller mindre lader den grundlæggende maskinarkitekur skinne igennem til
programmøren. En af disse typer er pointeren.
28 Typer 2.4

Pointere har den egenskab, at de peger på data i stedet for at indeholde data. Forskellen er
temmelig subtil. Når en pointer peger på for eksempel en int, indeholder pointeren blot
adressen på denne variabel. Er en anden pointer rettet mod en char, er indholdet adressen på
denne variabel. Alle pointere er derfor i princippet helt ens: de indeholder en adresse i maskinens
lager. Forskellen er måden, hvorpå de data, der befinder sig på adressen, behandles. En
pointervariabel erklæres med en stjerne (*) efter typenavnet:
int* iptr; // iptr er en pointer til en int
Denne erklæring resulterer i en allokeret variabel, som indeholder plads nok til en adresse i
lageret. Den allokerer ikke en int! Før den kan bruges, må den tildeles en værdi, for eksempel
adressen på en anden variabel:
int i; // i er en int
iptr = &i; // iptr indeholder nu i's adresse
Nu kan indholdet af variablen i også manipuleres indirekte gennem iptr, ved brug af
operatoren *:
*iptr = 5; // i (*iptr) har nu værdien 5
int j = *iptr; // j har nu samme værdi som i (*iptr)
Denne operation kaldes dereference og betyder, at det ikke er pointeren men de data, som den
refererer, der er i fokus. Vi bruger pointere, fordi de tillader os at generalisere. En programdel,
der benytter pointere kan arbejde på forskellige forekomster af data afhængig af pointernes
værdier, mens en programdel, der arbejder direkte på forekomster er bundet til disse. Selve
pointerbegrebet og ideen om indirektion er fundamentet for udvikling af generisk kode. Som vi
skal se senere, kommer meget af styrken i objekt-orienteret programmering fra, at kompleksiteten
i pointerarbejdet skjules fra programmøren. I afsnit 2.10 gennemgås alle de særlige forhold ved
pointere, som på en og samme tid gør dem uvurderlige og besværlige at have med at gøre.
2.4.4 Referencetyper
Referencer opfører sig akkurat som pointere, med den ene undtagelse, at de indirekte data ikke
skal derefereres. En reference er således en pointer, som har samme syntaks i tildelinger og
udtryk som normale variable, men som peger på andre data. Man kan sige, at en reference er et
alias for en anden variabel. For eksempel,
char c; // c er en char
char& cref = c; // cref refererer c
Referencen cref kan nu bruges (på både højre og venstre side af en tildeling) som om den
egentlig var c:
2.4.3 Pointertyper 29

char ch = cref; // samme som char ch = c;
cref = 'a'; // samme som c = 'a'
Referencer benyttes mest i funktioners parameterlister, fordi det letter syntaksen, at de refererede
data ikke eksplicit skal manipuleres gennem *-operatoren. Dette kommer til udtryk i overstyring
af operatorer (afsnit 3.5), hvor referencer er helt nødvendige.
Læg igen mærke til forskellen mellem tildeling og initiering af variable. Under initiering af en
referencevariabel tildeles en værdi til selve referencen, mens det i senere tildelinger til referencen
er den refererede variabel, der tildeles en værdi - altså to helt forskellige operationer i referencens
sammenhæng, der ikke må forveksles.
2.4.5 Vektor-typer
En vektor er en samtidig erklæring af mere end én forekomst af samme type, som skal allokeres i
sekvens, dvs. lineært i lageret. En vektorerklæring foretages med en angivelse af størrelsen på
vektoren i kantede parenteser efter variabelnavnet, for eksempel
char Buffer [100]; // hundrede char-variable
En vektor er faktisk det samme som en pointer - en pointer kan tildeles en vektor. De ovenstående
erklæringer vil resultere i, at Buffer får typen "vektor af char", men er egentlig blot en
pointer til den første char i rækken af de hundrede. Forskellen i erklæringen er, at vektoren
faktisk allokerer plads til data.
Elementerne i vektoren kan refereres med indeks-operatoren, hvor indekset løber fra 0 til n-1,
hvor n er antallet af elementer. Er vektoren for eksempel allokeret med 32 elementer, indekseres
den fra 0 til 31 inklusive. For eksempel,
char c = Buffer [11]; // det 12. element i Buffer
Buffer [99] = '\n'; // det 100. element i Buffer
Vektorer bruges i forbindelse med pointere, pointermanipulation og -aritmetik samt løkker, da
gennemgange af vektorer i søgninger, sorteringer og opdelinger er de primære anvendelser. Mere
om disse emner, samt om multidimensionale vektorer, i afsnit 2.10.
2.4.6 Literale konstanter
I de foregående afsnit er tal som 5 og 0.00000001 dukket op flere steder. Sådanne værdier kaldes
literale konstanter og har ingen direkte type. De hedder literaler, fordi de helt bogstaveligt talt
kun kan beskrives i form af den værdi, de har. Literale konstanter er derfor data, som står
eksplicit beskrevet i kildeteksten og som bliver fysisk repræsenteret i objektkoden. C++ lader os
arbejde med tre typer af konstanter, heltal, kommatal og tegn. Det er muligt at specificere disse
30 Typer 2.4

tre typer på forskellige syntaksbestemte måder samt i forskellige talsystemer. Den oftest
benyttede konstant er heltallet, som er uundværlig i næsten alle kontrolstrukturer:
12345 (Decimal 12345)
0x2000 (Hexadecimal 2000 - decimal 8192)
0701 (Oktal 701 - decimal 449)
'8' (Tegnet '8' - ASCII decimalværdi 56)
Decimale konstanter er underforstået for heltal, og andre talsystemer må bruge en anden syntaks.
Det ses, at hexadecimale konstanter har en 0x før selve konstanten, at oktale konstanter altid
starter med et 0 samt at tegnkonstanter benytter apostrofer til at omslutte tegnet. Der skelnes
ikke mellem store og små bogstaver i hexadecimale heltalskonstanter, ligesom x'et kan være et
X. Tegnkonstanter bruges til at finde værdien af et bestemt tegn i det aktuelle tegnsæt, hvilket
oftest er ASCII (American Standard Code for Information Interchange). Samme numeriske
værdi kan altså opnås på mange måder. Tallet 42 kan beskrives som både 42, 0x2A og 052.
Den binære repræsentation af en literal konstant afhænger af, hvor stort tallet er i forhold til
præcisionen af de fundamentale typer i den pågældende oversætter. Uanset i hvilken
sammenhæng en literal konstant anvendes - som operant i et subudtryk eller en tildeling - vil den
fremstå i objektkoden i en form, som svarer til den type, der er nærmest. Konstanten 123 vil
typisk være en short int, mens 123456 typisk vil være en long int. Afhængigt af
udtrykket, som konstanten bruges i, vil oversætteren konvertere den konstante værdi til en given
anden type. Typekonvertering beskrives i afsnit 2.4.11. Programmøren kan imidlertid kontrollere
den absolutte størrelse på en literal konstant ved hjælp af en angivelse efter selve værdien. I
følgende eksempel tvinges konstanten til at være en long, selvom den sandsynligvis kunne
holdes i en int:
99L (L betyder long-konstant)
Det er naturligvis kun muligt at tvinge præcisionen opad; en konstant, som kun kan indeholdes i
en long kan ikke tvinges ind i en short.
Fortolkningen af den literale konstant som signed eller unsigned kan også kontrolleres
ved hjælp af en angivelse efter konstanten. En heltalskonstant er underforstået signed, men
kan tvinges til at være unsigned ved at klistre et U efter konstanten:
50000U (50000 som unsigned int-konstant)
Bogstaverne kan være enten store eller små og kan også blandes sammen. For eksempel,
30lu (30 som unsigned long-konstant)
Dette gælder også kommatal. Oversætteren forudsætter også her altid den mindst mulige
præcision, når en konstant lagres, men det er muligt at tvinge den til at gemme en floatkonstant
med
2.4.6 Literale konstanter 31

eller
65F (65 som kommatal)
65.
65.0
hvor decimaltalskommaet (et komma i Danmark, men et punktum i udlandet) tvinger den literale
konstant til at være et kommatal.
Læg mærke til, at der ikke skelnes mellem float og double, når det gælder konstanter.
Syntaksen er iøvrigt sjældent nødvendig, og bruges kun i forbindelse med specielle funktionskald
og initieringer af datastrukturer. Det er et spørgsmål om at fortælle oversætteren, at en bestemt
konstant ikke behøver mere præcision end man har behov for, så den ikke allokerer unødvendigt
plads og bruger unødvendig tid til konvertering. Oversætteren vil iøvrigt advare om brugen af
konstanter, der er for store i forhold til konteksten.
Kommatal, som har typen double eller float, kan skrives som konstanter i enten normal
eller "videnskabelig" form (med eksponent):
3.1415 (Omtrent π)
.5 (En halv)
5.5e60 (Et meget stort tal)
1E-77 (Et meget lille tal)
Som beskrevet kan tegnkonstanter specificeres med omslutning af apostrofer. Selvom C++ har
datatypen char, definerer sproget ikke, hvordan tegnsættet ser ud. Der er altså ingen
konvention om, hvilke værdier de forskellige tegn (bogstaver, symboler osv.) har på målmaskninen.
De fleste operativsystemer (UNIX, MS-DOS, OS/2) bruger dog ASCII-tegnsættet, og
standardbiblioteket i C++ har derfor visse ASCII-relaterede funktioner. Men selve sproget
definerer kun typen char som et heltal af tilstrækkelig båndbredde til at kunne rumme et tegn.
Et 'a' vil have en anden numerisk værdi på en ASCII-maskine end på for eksempel en
EBCDIC-maskine. For at sikre flytbarheden mest muligt kan tegnkonstanter indeholde et antal
maskinuafhængige kontroltegn, for eksempel linieskift og tabulatorfunktion. Kontroltegn
specificeres med et escape-tegn, den bagvendte skråstreg \:
'\b' Backspace
'\f' Sideskift (form feed)
'\n' Linieskift (newline)
'\r' Vognretur
'\t' Horisontal tabulering
'\v' Vertikal tabulering
De faktiske tegn \, ' og " (baglæns-skråstreg, apostrof og citationstegn) skrives som
32 Typer 2.4

tegnkonstant således:
'\\' Baglæns-skråstregen \
'\'' Apostrofen '
'\"' Citationstegnet "
Det er også muligt at udtrykke en numerisk tegnkonstant ved hjælp af escape-tegnet. Kun 8- og
16-talssystemet kan bruges i escape-sekvenser i tegnkonstanter:
'\0' Nul
'\010' Oktal 10, den decimale værdi 8
'\xFF' Hex FF, den decimale værdi 255
Strenge, som vi kender dem fra andre sprog, er meget begrænsede i C++. Strengen er ikke en
datatype i sig selv, men er repræsenteret som en lineær liste af char's, som slutter med '\0'
samt en pointer, der peger på det først tegn i listen, og kan ikke manipuleres direkte af C++.
Standardbiblioteket indeholder derfor en række funktioner, som arbejder på strenge. Det er vigtigt
at huske, at lovlig en C++-streng altid slutter i '\0', og at denne terminator tælles med i
lagerallokeringen. Derfor har strengen
"kyrie eleison"
en faktisk længde på 14 chars. Kontroltegn kan indsættes i strengkonstanter efter samme regler
som for tegnkonstanter:
"Første linie\nAnden linie\n"
Vær opmærksom på, at 'a' ikke er ækvivalent til "a", idet sidstnævnte er en konstant på to
chars, 'a' og '\0'. Læg også mærke til, at literale konstanter aldrig kan bruges på venstre
side af et lighedstegn.
2.4.7 Symbolske konstanter
Hvis en variabel i C++ aldrig modificeres gennem hele programmet, kan (og bør) den erklæres
som en symbolsk konstant. Hermed er det ikke tilladt at ændre dens værdi andre steder i
programmet (den er således ikke variabel). Forskellen mellem symbolske og literale konstanter
er, at en symbolsk konstant har en egentlig type og dermed samme semantiske egenskaber som
en variabel, mens literale konstanter er "dumme". Symbolske konstanter kan også være nyttige,
hvis der skal arbejdes med konstanter af typer, der ikke er fundamentale - afledte eller brugerdefinerede.
Objekter erklæres konstante med nøgleordet const:
const double pi = 3.1415926; // pi er altid pi
const a = 5; // int-type underforstået
2.4.6 Literale konstanter 33

En const skal altid initieres under erklæringen. Konstanter er brugbare i de tilfælde, hvor
kildeteksten skal kunne oversættes med forskellige indbyggede afhængigheder. For eksempel
kunne en konstant i kildeteksten specificere antallet af brugere i et flerbrugersystem, som sælges i
forskellige licens-konfigurationer. Eller for eksempel værdierne af forskellige tegn:
const brugere = 4; // 4-brugerversion
const ACK = 6; // ASCII-koder
const NAK = 21;
const SOX = 2;
const EOX = 3;
Læg mærke til, at en int ikke er det samme som en const int. Overvej følgende kodefragment:
const int i = 5; // ok: i tildeles en literal konstant
int j = i; // ok: j tildeles 5
i = j; // fejl: i er konstant
const int k = j; // ok: tildeling ved erklæring
Dette skyldes, at det ikke er muligt at dereferere (tage adressen på) en konstant type, hverken
implicit eller eksplicit (ved tildeling eller ved brug af en operator). Symbolske konstanter er ikke
adressérbare og kan følgelig (afsnit 2.4.1) ikke stå til venstre for et lighedstegn. Det faktum, at
konstante typer er forskellige fra variable typer har sin største betydning i forbindelse med
funktioner (afsnit 2.6) og interaktion med abstrakte datatyper (afsnit 3.3.15)
C-kyndige læsere vil bemærke, at symbolske konstanter spiller en langt mere omfattende rolle i
C++ end i ANSI C. De har for det første underforstået intern lænkning og kan altså ikke ses fra
andre objektmoduler. Det betyder, at en symbolsk konstant kan placeres i en headerfil uden
problemer fra lænkeren. For det andet kan de, på grund af kravet om explicit initiering, bruges i
konstante udtryk, for eksempel som angivelse af størrelsen på en vektor, og erstatter altså i vid
udstrækning makrodefinitionerne fra C.
2.4.8 Opremsninger
Et alternativ til const, som kan bruges til automatisk tildeling af værdier til symbolske
konstanter, hedder opremsninger (på engelsk enumerations). En opremsning erklærer et antal
symbolske konstanter og tildeler fortløbende værdier (startende ved 0) til disse. Fordelen er, at
symbolerne automatisk får forskellige værdier, programmøren samtidig kan abstrahere fra de
faktiske numeriske værdier og i stedet blot koncentrere sig om symbolerne. For eksempel,
enum { running, ready, waiting };
34 Typer 2.4

Denne sætning erklærer tre konstanter som medlemmer af opremsningen, running, ready
og waiting, og tildeler værdierne 0, 1 og 2 til disse. Opremsninger kan navngives, og de
individuelle konstanter kan, hvis det er nødvendigt, tildeles en værdi:
enum Attrs {
black, blue, red, magenta, green, cyan, yellow, white,
brown = 0x20, grey, marmelade, purple, manderine,
brightness = 0x40,
flash = 0x80
};
Navnet Attrs opfører sig som et heltal, og kan bruges i type-erklæringer. Attrs er i den
forstand en ny type, som har et antal lovlige konstant-tildelinger. black til white har de
konstante værdier 0 til 7, brown til manderine har værdierne 32 til 36 (decimal),
brightness har 64 og flash 128. Selvom det også er tilladt at tildele andre konstanter end
medlemssymbolerne til en forekomst af en opremsning, er det ikke programmeringsteknisk
fornuftigt, og oversætteren vil sandsynligvis give en advarsel om tildelinger mellem
opremsningstyper og heltal. Et nyt medlem af Attrs bør erklæres i stedet for at benytte literale
konstanter.
Det anvendelige ved enum-konstruktioner er, at et antal relaterede konstanter kan opremses i
en fart uden at skulle tildeles vilkårlige værdier, der adskiller dem fra hinanden. Er der for
eksempel tale om at identificere forskellige byer i Danmark kunne man forestille sig, at hver by
fik et nummer. Selve nummeret er ligegyldigt, det væsentlige er, at alle byer har et entydigt og
unikt nummer. Det sikres ved brug af opremsninger, uden at der påføres kildeteksten støj i form
af de faktiske værdier af de symbolske konstanter.
2.4.9 Brugerdefinerede typer
En brugerdefineret type er et særligt navn, der defineres af programmøren. Brugerdefinerede
typer er fundamentet for objekt-orienteret programmering, fordi de tillader semantiske udvidelser
af sproget. I dette afsnit vises blot, hvordan et brugerdefineret typenavn erklæres, mens
anvendelsen og implementationen får vente til kapitel 3.
En brugerdefineret type introduceres i typesystemet med enten class, struct, union,
enum eller typedef. Resultatet bliver et nyt typenavn, som kan bruges til at instantiere
variable, altså skabe reelle objekter med.
class Matrix; // en matrix-type
class Semaphore; // en semafor-type
class BigNum; // en multipræcisionstype
// ...
BigNum b; // et BigNum-objekt
2.4.8 Opremsninger 35

Matrix m; // et Matrix-objekt
Semaphore s; // et semafor-objekt
Brugerdefinerede typer følger alle regler, der gælder for fundamentale typer. Det er muligt at
kontrollere typernes indre opførsel, konverteringer mellem typer og betydningen af operatorer i
forbindelse med objekter af typerne. Alle disse forhold ved brugerdefinerede typer er her grebet
ud af en sammenhæng, der beskrives fyldestgørende gennem kapitel 3.
2.4.10 Typekonvertering
Når et udtryk blander forekomster af forskellige typer sammen, konverteres de enkelte subudtryk
til en fælles type efter visse regler. Der skelnes mellem tvungen (eller eksplicit) og underforstået
(eller implicit) typekonvertering, som sker henholdsvis under programmørens og under
oversætterens kontrol. Underforstået typekonvertering er et resultat af tvetydigheder mellem
objekter af forskellige typer, som blandes i samme udtryk. Den fælles type er altid mindst af
samme præcision som modtageren af udtrykket, altså variablen til venstre for lighedstegnet. Hvis
denne type har større båndbredde end en af operanderne (for eksempel en int til en long),
bibeholdes al information, men hvis det omvendte er tilfældet, tabes præcision. Følgende sidste
tildeling resulterer altid i en implicit typekonvertering:
double d = 3.5; // en double (ingen konvertering)
int a = 100; // og en int (ingen konvertering)
int b = a * d; // ganges sammen (konverteringer)
Tildelingen b = a * d vil typekonvertere alle led i subudtrykket på højre side af
lighedstegnet til den type, som alle andre typer går op i - dvs. den mest præcise type, der findes i
udtrykket. Alle led, som ikke har denne type vil blive konverteret underforstået, hvilket for dette
eksempel vil typekonvertere a til en double (fordi det er typen på d), gange med d,
typekonvertere resultatet til en int (fordi det er typen på b), og tildele det til b. Læg her
mærke til, at alle typekonverteringer arbejder på kopier af de variable, der findes i programmet -
d beholder sin værdi på 3.5 selvom den bliver typekonverteret.
Når information tabes i en underforstået typekonvertering, vil oversætteren normalt give en
advarsel om det:
double d = 2.33; // en double
int a = d; // tildeles en int (a == 2)
double e = a; // og tildeles tilbage (e == 2.0)
Her typekonvertere en double i d's skikkelse til en int, hvorved en del af præcisionen
(decimaltallet 0.33) tabes. a får værdien 2. Den efterfølgende e = a indeholder en
underforstået typekonversion mellem en int og en double, hvilket ikke har betydning for
præcisionen, da en double er "større" end en int. Men læg mærke til, at e ikke er lig d.
36 Typer 2.4

I reelle udtryk med flere operanter forekommer der også underforstået konvertering:
float f = 0.5;
double d = 2.5;
int a = 4;
long l = f + a * d;
Tildelingen til l vil medføre følgende underforståede typekonverteringer:
1. Subudtrykket a * d har højest prioritet ifølge reglerne for operator-præcedens (afsnit
2.5.7). Så først konverteres a til en double, fordi det omvendte ville resultere i tab af
præcision. Det er altid det "mindste" af de to led, der konverteres.
2. Så multipliceres den typekonverterede a (som double) med d.
3. Nu skal f konverteres til en double, da det nye subudtryk består af en float og en
double (resultatet af a * d).
4. Så adderes den typekonverterede f (som double) med resultatet fra før.
5. Det samlede resultat konverteres til den type, som modtagervariablen har, før den
tildeles, altså til en long.
Følgende regler gælder således under implicit typekonvertering:
a. hvis en af operanterne er en long double, konverteres den anden operant også til en
long double før operationen udføres. Ellers:
b. hvis en af operanterne er en double, konverteres den anden operant også til en
double før operationen udføres. Ellers:
c. hvis en af operanterne er en float, konverteres den anden operant også til en float
før operationen udføres. Ellers:
d. hvis en af operanterne er en long, konverteres den anden operant også til en long.
Ellers:
e. hvis en af operanterne er en char eller en short, konverteres den til en int.
Oversætteren vil normalt ved optimering fjerne eller transformere typekonverteringer, hvis det
ikke har betydning for præcisionen. Givet
float f = 2.5;
double d = 2.5;
2.4.10 Typekonvertering 37

int i = f + d;
vil f blive konverteret til en double, fordi præcisionen afhænger af de to kommatal. Men hvis
f var en int, vil d givetvis blive konverteret til en int, fordi resultatet også skal passe til en
int, og decimalværdien i d ingen betydning har i udtrykket.
Ved hjælp af tvungen typekonvertering (type-casting) kan objekter tvinges til at konvertere type
under programmørens kontrol. Tvungen typekonvertering finder anvendelse, når et kombineret
udtryk skal bruge specielle datastørrelser, hvis modtagerelementet ikke er en entydig type samt i
forbindelse med pointermanipulation, og beskrives under afsnittene om unions og pointere.
Objektet, der skal konverteres, sættes i parentes og skrives efter navnet på den type, der skal
konverteres til:
int d = int (float (i) + float (j));
C++ tillader en anden syntaks, som findes i klassisk C og ANSI C, og som er medtaget for
kompatibiltetens skyld:
int i;
long l = long (i); // normal C++ cast
long l = (long) i; // ANSI C cast
Den ny syntaks i C++ er en del mere konsistent i forhold til den måde, funktioner kaldes på, den
måde, brugerdefinerede typer konstrueres på samt den måde, variable initieringes på i dynamiske
allokeringer.
2.5 OPERATORER
Sættet af operatorer afgrænser metoderne, hvormed en eller flere datatyper kan behandles. En
operator udfører dermed en operation på et eller flere objekter og en sammensætning af en eller
flere operatorer og operanter udgør et udtryk. C++ benytter næsten alle tilgængelige specialtegn
som operatorer, som kan opdeles i 5 hovedgrupper plus en gruppe for ekstra betydninger af
særlige operatorer. De 5 hovedgrupper indeholder operatorer for aritmetiske, bitvise og logiske
udtryk samt for tildelings- og reference-operatorer. Alle operanter, der manipuleres, kan igen
være sammensatte udtryk med egne operatorer.
Der skelnes iøvrigt mellem operatorer, der arbejder på en enkelt og på to operanter. De, som
arbejder med en operant kaldes fortegnsoperatorer eller monadiske operatorer og kan for
eksempel være en negation mens de, der arbejder med to operanter kaldes dyadiske operatorer og
kan for eksempel være en addition. Der er også en enkelt triadisk operator, den særlige
aritmetiske if/else.
2.5.1 Aritmetiske operatorer
De aritmetiske operatorer (regne-operatorerne) i C++ er vist i tabel 2-2.
38 Typer 2.4

Operator Funktion
+
-
*
/
%
++
--
Addition
Subtraktion
Multiplikation
Division
Modulus (rest)
Optælling
Nedtælling
Tabel 2-2: Aritmetiske operatorer.
De fem første aritmetiske operatorer er dyadiske og kræver to operanter, en på hver side af
operatoren:
a + 5 // variablen a adderet med 5
14 % 8 // resten efter 14 divideret med 8
x * y // x gange y
De to sidste, op- og nedtælling, arbejder på en enkelt operant, og adderer eller subtraherer "1" fra
denne. Grunden til at "1" her skrives i anførselstegn er, at tallet et ikke altid betyder det samme,
men afhænger af størrelsen på de data, der er tale om. Op- og nedtælling efter evaluering betyder,
at operanten først ændres efter dens værdi er evalueret, mens op- og nedtælling før evaluering
ændrer værdien før den evalueres. Dette kan eksemplificeres således:
int a = 3, b = a; // erklær a og b som int med værdien 3
a++; // læg 1 til a, nu lig 4
int c = a++ * --b; // c = a * (b - 1), a = a + 1, b = b - 1
Efter disse tre linier vil c have værdien 8, a værdien 5 og b værdien 2. I fjerde linie er værdien
af a++ 4 (og ikke 5), fordi operatoren ++ kommer efter variablen, og dermed er en optællingsoperator
med evaluering før optællingen. Værdien af --b er 2 (og ikke 3), fordi b først
nedtælles, og så afgiver værdien i evalueringen.
2.5.2 Bitvise operatorer
Når vi taler om bitvise operatorer, arbejder vi med binær aritmetik. Her skal vi huske på, at alle
data i computeren lagres som binære repræsentationer. Vi kan for eksempel derfor udnytte, at en
char består af 8 bits.
Overdreven eller forkert brug af bitvise operatorer kan lede til ikke-flytbar kode, fordi typernes
størrelser ikke er absolut defineret. Der er imidlertid tidspunkter, hvor bitvise operationer ikke
kan udelades.
2.5.1 Aritmetiske operatorer 39

Operator Funktion
&
|
^
>>
2; // e == 5
Binær aritmetik bruges bla. i kommunikation med hardware, for eksempel en seriel port eller en
videocontroller. C++'s sæt af binære operatorer gør, at vi undgår at skulle skrive dele af
programmet i assembler eller maskinkode.
2.5.3 Logiske og relationelle operatorer
De logiske operatorer er vigtige. Det er dem, vi bruger i sammenligninger af data, samt til tests af
typen sand/falsk. Logiske operatorer kaldes også relationelle operatorer, fordi de opstiller en
relation mellem to operanter og lader resultatet være en funktion af dette. De logiske operatorer er
opridset i tabel 2-4.
Operator Funktion
&&
||
==
>
<
Logisk AND
Logisk inklusiv OR
Lig med
Større end
Mindre end
40 Operatorer 2.5

=

5 evalueres a to gange, hvilket er tidskrævende og besværligt. Den ækvivalente skrivemåde a
+= 5 evaluerer kun a en gang. Tildelings-operatorerne kan også læses som "udfør operation o
på variabel v og tildel til v." a += 5 læses som "læg 5 til a og tildel resultatet til a".
2.5.5 Reference-operatorer
Operator Funktion
=
+=
-=
*=
/=
%=
&=
|=
^=
>>=

2.3.6, en lineær liste af forekomster. Vektorens navn er derfor en pointer til (adressen på) det
første element i listen (med indeksværdien 0). Når en vektor erklæres med
char vek [10];
afsættes plads til 10 char-forekomster, som ligger efter hinanden i lageret og er nummereret
fra 0 til 9, ikke fra 1 til 10. Når et udtryk som
a = vek [5];
evalueres, multipliceres indekset (her 5) med størrelsen på data-elementet (her en char) og
adderes til vek (adressen på det første element). Resultatet er den adresse, som den ønskede
værdi befinder sig på. vek[n] er derfor af den type, som bruges i erklæringen af vek og er
kun et venstre-udtryk, hvis denne type er et venstre-udtryk.
Dereference af pointere med * følger samme regel. Hvis en variabel v er erklæret som
pointer til type T, vil udtrykket *v returnere en forekomst af typen T (*v's rvalue er en
forekomst af T). For eksempel,
char* a;
// ...
char b = *a;
Når adresse-på operatoren påhæftes et objekt i et udtryk, vil udtrykkets rvalue være en pointer
til det pågældende objekt:
char a; // en normal char
char* b; // en pointer til en char
b = &a; // b tildeles adressen på a
a = *b; // a tildeles b's dereference
Adresse-på operatoren kan aldrig bruges på venstre side af et lighedstegn. Dereferenceoperatorerne
* og & binder til højre (se afsnit 2.5.8), så
char a = 2, b = 3, *c = &b;
char d = a**c; // betyder a ganget med *c, altså 6
Både vektorer og pointere forekommer i flere led eller dimensioner, og her følger erklæringssyntaksen
stadig udtrykssyntaksen:
char a; // char
char* b; // pointer til char
char** c: // pointer til pointer til char
char*** d; // pointer til pointer til pointer til char
2.5.5 Reference-operatorer 43

*b = a; // *b tildeles a
**c = a; // **c tildeles a
***d = a; // ***d tildeles a
og måske lidt mere kryptisk:
b = *c; // *c er "pointer til char"
*d = c; // *d er "pointer til pointer til char"
*c = &a; // *c er "pointer til char"
**d = b; // **d er "pointer til char"
Det afgørende er, at typerne til højre og venstre for lighedstegnet, når det gælder pointere,
skal være ens. Man kan ikke tildele en pointer til en pointer til en char med en pointer til en
char. Med andre ord, hvis c er erklæret som char** (pointer til pointer til char), så vil
*d være en pointer til char og **d være en char.
2.5.6 Særlige operatorer
C++ har et antal ekstra operatorer, der enten arbejder i sammenhænge, vi ikke har
introduceret, eller som har helt specielle idiomatiske betydninger. I tabel 2-7 vises disse ni
operatorer, som bliver diskuteret nedenfor.
Kun ::, ->* og .* findes i C++ og ikke i C. Aritmetisk if/else anvendes som en
indbygget test i midten af andre udtryk, og kan bruges til at omgå de større kontrolstrukturer:
a = b == c ? d : e;
Denne sætning vil tildele a værdien af d, såfremt b er lig med c, ellers får a værdien fra
e. Det skal forstås sådan, at hvad der kommer før spørgsmålstegnet er et logisk udtryk (sandt
eller falsk), og at de to værdier til venstre og til højre for kolon-tegnet beskriver de to mulige
valg. Eller hvis vi læser fra venstre mod højre: er det logiske udtryk sandt, bruges den første
værdi, ellers den anden. Det kan være en fordel at bentyte paranteser til at gøre aritmetiske
if/else-sætninger mere læselige:
a = (b == c) ? (d) : (e);
Sekvensoperatoren - kommaet - bruges til adskillelse af tildelings- og erklæringsudtryk.
Brugen af denne operator garanterer, at udtrykkene evalueres fra venstre mod højre i den
rækkefølge, de står beskrevet i kildeteksten (se næste afsnit). For eksempel,
int a, b, c;
x = 3, y = 4, z = 5;
Resten af de særlige operatorer har betydninger i sammenhænge, vi endnu ikke har
44 Operatorer 2.5

ehandlet. De benyttes i følgende forbindelser: Skop-opløsning bruges til at referere data i et
andet logisk skop end det aktuelle. Operatorerne for medlems-valg bruges i sammenhæng
med datastrukturer. Eksplicitte typekonverteringer kan være nødvendige, når en type absolut
skal ændre "form" af en eller anden grund (for eksempel til en parameter). sizeof
returnerer størrelsen af en type, både en indbygget og en brugerdefineret, og bruges ofte til at
sikre flytbarheden i et program. sizeof er en operator, ikke en funktion, fordi den giver sit
resultat som konstant på oversættertidspunktet.
Operator Funktion
?:
,
::
->
->*
.
.*
()
sizeof
2.5.7 Evalueringsrækkefølge
I et udtryk som
i = a * b + c * d;
Aritmetisk if/else
Sekventierings-operator
Skop-opløsning
Medlems-reference (pointere)
Medlems-dereference (pointere)
Medlems-reference (forekomster)
Medlems-dereference (forekomster)
Tvungen type-konvertering
Størrelse på type
Tabel 2-7: Særlige operatorer.
er det ikke defineret, i hvilken rækkefølge, C++ evaluerer subudtrykkene (a*b) og
(c*d). Kun sekvensoperatoren (komma) samt logisk AND (&&) og OR (||) garanterer, at
operanten eller subudtrykket til venstre evalueres før det til højre. Pas derfor på med udtryk
som:
int j = 2, i = j++ * j;
hvor værdien af i bliver enten 4 eller 6, afhængig af den enkelte oversætter. Grunden til, at
rækkefølgen ikke er lineær fra venstre mod højre er, at oversætteren skal have mulighed for at
optimere den genererede kode i subudtrykket, hvilket ofte medfører en omstrukturering.
Denne omstrukturering er ikke entydig, og gør det umuligt at forudsige rækkefølgen af
evaluering.
2.5.6 Særlige operatorer 45

2.5.8 Præcedens
Operatorerne har forskellig prioritet eller præcedens i forhold til hinanden, hvilket ganske
simpelt er for at undgå en masse parenteser i kildeteksten. Subudtryk bundet af operatorer
med højere prioritet udføres før subudtryk med lavere prioritet. For eksempel bliver resultatet
af
int i = 4 + 3 * 2;
at i får værdien 10, ikke 14, da * rangerer højere end + (som på en regnemaskine).
Desuden binder operatorerne forskelligt (de har forskellig associativitet); fortegnsoperatorerne
(!, &, ~ osv.) og tildelingsoperatorerne (=, +=, != osv.) binder til højreoperanten,
mens alle andre operatorer binder til venstreoperanten. For eksempel,
int i = 5, j = 4 * -i; // j == -20
Her binder - til højre og * til venstre, så udtrykket fortolkes som (5) * (-i) og giver
således resultatet -20. På samme måde vil de to stjerne-operatorer det i følgende udtryk
fortolkes som dels en aritmetisk operator og en binær fortegnsoperator (dereferencen):
int x = 10, z = 20;
int* y = &z;
int r = x**y; // r == 200
I visse andre sprog er ** en operator, der står for potens. Den findes ikke i C++, men
fortolkes som to enkeltstående operatorer, hvis betydning afhænger af konteksten. Stod der
for eksempel z = x+**y var den første * en dereference og ikke en multiplikativ
operator. I C++ skal potensopløftning implementeres af programmøren. Operatorernes
præcedens og associativitet er vist i tabel 2-8.
Til slut en generel advarsel om typiske fejlkilder i C++-programmer. Det er næsten altid på
grund af en slåfejl eller syntaktisk misforståelse, at problemerne opstår, og det bliver desto
meget værre af, at sådanne fejl ofte er syntaktisk lovlige i C++. Oversætteren gør, hvad den
får besked på, og koden ser umiddelbart rigtig ud. Som eksempel kan følgende løkke vises,
som tæller variablen i ned sålænge den er størren end 0 (while-løkker diskuteres i afsnit
2.7.2):
while (i =! 0) i--;
Kan du se problemet? Det viser sig, at ulighedsoperatoren er vendt forkert (den hedder !=)
så der i virkeligheden står "i tildeles den logiske negation af den literale konstant 0", hvilket
jo altid er en sand værdi - og løkken fortsætter for evigt.
46 Operatorer 2.5

2.6 FUNKTIONER
Uanset C++'s muligheder indenfor objekt-orienteret programmering, bygger det syntaksmæssigt
på det proceduralt orienterede sprog C. Funktioner er et nøglekoncept, fordi det
tillader en dekomposition af kompleksiteten, hvorved databehandlinger af ekstern relevans
kan samles i mindre grupper.
En funktion består af et navn, en parameterliste og en returtype, samt kroppen af funktionen.
Det følgende eksempel definerer en areal-funktion i to dimensioner:
long areal (int bredde, int laengde) {
long c = bredde * laengde;
return c;
}
(P) (A) Operator Beskrivelse Eksempel
17
17
16
16
16
16
15
15
15
15
15
15
15
H
V
V
V
V
V
H
H
H
H
H
H
H
::
::
()
., ->
[]
sizeof
+, -
++, --
!
~
*, &
()
new, delete
klasseskop
globalt skop
funktionskald
medlemsvalg
vektorindeksering
angivelse af størrelse
fortegnsminus/plus
op- og nedtælling
logisk negation
bitvis negation
dereference, adresse
tvungen konvertering
lageradministration
a = Klasse::Medlem
a = ::Data
a = funktion ()
a = S.m, a = S->m
a = vek [n]
a = sizeof(double)
a = +b, b = -a
a = ++b, b = a--
a = !b
a = ~b
a = *b, b = &a
a = char (b)
a = new T, delete a
14 V .*, ->* medlemspointervalg a = T.*b, a = b->*c
13 V *, %, / multiplikative a = b * c
12 V +, - aritmetiske a = b + c
11 V bitvis skift a = b = c
2.5.8 Præcedens 47

9 V ==, != sammenlignende a = b != c
8 V & bitvis AND a = b & c
7 V ~ bitvis XOR a = b ~ c
6 V | bitvis OR a = b | c
5 V && logisk AND a = b && c
4 V || logisk OR a = b || c
3 V ?: aritmetisk betingelse a = b ? c : d
2 H =,+=,*=, osv. tildelingsoperatorer a *= b
1 V , kommaseparator a = 5, b = 7
Tabel 2-8: Operatorernes associativitet (A), prioritet (P) og syntaks.
Den første linie fortæller oversætteren, at funktionen hedder areal, at den skal returnere
data af typen long, samt at den skal kaldes med to parametre, eller argumenter, begge af
typen int. Funktionens krop (mellem de to krøllede parenteser) multiplicerer blot de to
parametre og returnerer resultatet med nøgleordet return.
Funktionen areal kan derefter kaldes andetsteds fra:
f () { // en funktion f()
long b = 5, l = 8; // to long's, b og l
long a = areal (b, l); // a lig areal's returværdi
}
I terminologien skelner vi mellem de to funktioner ved at kalde den ydre for den kaldende
funktion og den indre for den kaldte funktion eller målfunktionen. return kan forekomme
flere steder i en funktion, typisk i forbindelse med betingede kontrolstrukturer (afsnit 2.7), og
behøver derfor ikke at være den sidste sætning i funktionens krop. Funktionen returnerer altid
kontrol til kalderen, når en return-sætning mødes, eller når funktionens skop render ud.
2.6.1 Skop, blokke og levetid
Alle variable har en levetid, som begynder på det sted, hvor de erklæres, og ender i slutningen
af den blok, hvori erklæringen foretages. En blok er indholdet mellem to krøllede parenteser
({...}). Blokke kan indeholde andre blokke, men skal altid være indenfor en funktion. En
variabels skop er defineret som den eller de blokke, hvori den eksisterer og lovligt kan bruges,
starter ved erklæringen og slutter ved udgangen af blokken. På dansk har vi begrebet virkefelt,
der dækker over en del af ordet skop. I appendiks D findes en detaljeret oversigt over danske
oversættelser og begrundelserne for dem.
Variable kan defineres udenfor eller indenfor funktioner. Defineres de udenfor, kaldes de
48 Funktioner 2.6

globale, indenfor er de lokale til den aktuelle funktion. Lokale variable har altså et
indskrænket skop i forhold til resten af programmet. C++'s operator for skop-opløsning kan
hjælpe med lokalisering af en variabel i et andet skop, hvis en navnekonflikt opstår. For
eksempel,
int a = 5; // global a
f () {
int a = 7; // a lokal til f()
int b = a; // b tildeles den lokale a
int c = ::a; // c tildeles den globale a
}
Lokale variable "dør", når blokken udløber. I følgende eksempel forekommer der indlejrede
blokke med hver sine lokale data:
f () {
int a = 5; {
int b = 5; {
int c = 5;
} // her slutter c's skop
} // her slutter b's skop
} // her slutter a's skop
Heltalsvariablen c kendes kun i det inderste niveau. Fordelen med flere blokke er, at en
klump kode kan indsættes i en funktion omsluttet af parenteser med garanti for, at navnekonflikter
ikke opstår. Alle data, der erklæres indenfor blokken vil blive brugt fremfor "ydre"
data af samme navn. Men de fjernes, når blokken ender.
2.6.2 Prototyper
C++ har som beskrevet et stærkt, statisk typesystem. Da en funktion er en afledt type, skal
denne være erklæret før den kan bruges. Som omtalt i indledningen placeres denne erklæring
ofte i en headerfil, som andre programmer derefter kan benytte sig af. Hvis funktionen er helt
lokal, placeres erklæringen i begyndelsen af kildefilen. En funktions-erklæring i C++ ser
således ud:
double Potens (double, double);
Efter denne linie, som også kaldes en fremad-reference eller en prototype, ved overætteren, at
funktionen Potens() returnerer en double og skal have to parametre, begge double'r.
Hvor selve definitionen (med koden) af funktionen ligger er underordnet indtil lænkningstidspunktet.
Alle kald til Potens() vil blive sat korrekt op og type-checket.
2.6.1 Skop, blokke og levetid 49

Det er ikke altid nødvendigt, men dog en god idé, at have prototyper til alle funktioner. Hvis
en funktion ikke bruges, før den defineres, er prototypen ikke nødvendig. I så fald er selve
definitionen på funktionen nok for oversætteren i sikring af typekonsistens. Prototyper findes
i C++, fordi oversætteren læser hele programteksten fra start til slut én gang. Den skal således
have viden om funktioner, der kaldes før deres definition, medmindre de returnerer en int
og har en tom parameterliste. I klassisk C var prototyper ikke påkrævede, men i ANSI C blev
de tvungne og har vist sig at sikre korrekte funktionskald til biblioteker og andre moduler. Se
også afsnit 3.9.5 om mingelering af funktionsnavne i forbindelse med sammenblanding af
flere forskellige prototyper.
2.6.3 void
Hvis en funktion ikke har noget eksplicit output, forventes den ikke at returnere en værdi.
Retur-typen erklæres i så tilfælde som void. Void er engelsk for "tomhed". Det er ydermere
god praksis at skrive void i parameterlisten, hvis funktionen ikke har eksplicit input, altså
ikke modtager parametre fra kalderen. Funktionserklæringen
void f ();
er således identisk med
void f (void);
Det gælder kun for parameterlisten, mens returværdien underforstået returnerer en forekomst
af typen int. Følgende to erklæringer er helt ens:
int f ();
f ();
Det er imidlertid god praksis altid at angive returtypen på en funktion, også selvom den
returnerer en int.
2.6.4 main()
Et C++-program starter sin eksekvering i funktionen main(). Der kan følgelig kun være én
main(), og denne kalder typisk et antal initierings-funktioner, cykler gennem et par
behandlingsfunktioner og rydder til sidst op. Eksekveringen slutter efter main()'s skop,
dvs. når kroppen på funktionen slutter.
Information kan overføres fra loaderen (normalt en del af operativsystemet eller miljøet) til
main() i to variable. Normalt startes et program med en kommandolinie med et filnavn på
det program, der skal udføres, efterfulgt af eventuelle parametre, som i
cp source.doc dest.doc
50 Funktioner 2.6

Funktionen main() i programmet cp modtager information om parametrene i kommandolinien
i to variable, som valgfrit kan specificeres som parametre til funktionen:
void main (int argc, char** argv);
Det første parameter, argc, indeholder antallet af ord i kommandolinien (inklusive
programmets navn, her cp), og argv peger på de individuelle navne. argv er af typen
"pointer til pointer til char", og diskuteres nærmere i afsnit 2.11.1. Hvis main() ikke
behøver information fra miljøet, erklæres den parameterløs.
Hvis main() skal returnere en værdi til miljøet, for eksempel som fejlkode, erklæres den
som
eller
int main ();
int main (int argc, char** argv);
og den ønskede værdi afleveres tilbage til miljøet med return fra main(). Grunden til,
at det er tilladt at erklære main() på forskellige måder er, at den ikke har en prototype.
2.6.5 Funktionskald
En erklæret funktion kan kaldes fra alle andre funktioner, som kender navnet med følgende
syntaks:
double p = potens (3, 7); // 3 i syvende til p
De literale heltalskonstanter 3 og 7 overføres som parametre til funktionen potens(), som
returnerer en værdi, der tildeles til p. Funktionskald i C++ er normalt ved værdi, hvilket vil
sige, at det er indholdet af variablen, ikke selve variablen, der overføres som parameter og
returværdi (benævnes call-by-value). Følgende program
void plus (int a) { // læg 1 til a
a++;
}
void main () {
int a = 1;
plus (a);
cout

vil udskrive
a == 1
og ikke a == 2, som man kunne tro. Kaldet til plus() overfører a's værdi fra
main()'s a til plus()'s a, som oprettes og initieres ved funktionskaldet. Dermed er der
tale om to forskellige variable med samme navn, men med forskelligt skop, som behandles
uafhængigt.
Reglerne for typekonvertering gælder også i funktionskald. Hvis en funktion erklæres som
void seek (long l);
og kaldes med
int i;
seek (i);
vil oversætteren konvertere i til en long, før værdien tildeles l. Dette har ingen betydning
for i. C++ anvender altid call-by-value. De afledte typer kan imidlertid bruges til at
imitere andre sprogs muligheder for andre kaldemetoder, særligt call-by-reference, kald med
reference.
2.6.6 Afledte typer som parametre
Når data overføres som parametre fra en kaldende funktion til en målfunktion, konstrueres
altså en kopi af objekterne som initieres med de værdier, de originale objekter har. Et
parameter i en funktion er derfor det samme som en samtidig erklæring og initiering, blot står
initieringsværdien et andet sted i koden. De opfører som automatiske variable og har deres
skop indenfor hele målfunktionen. Umiddelbart før målfunktionen returnerer, destrueres
parameterobjekterne igen. Det er meget vigtigt at huske disse regler, især når vi i kapitel 3
introducerer brugerdefinerede typer, af hvilke vi selv er ansvarlige for konstruktionen og
destruktionen.
Parametre kan imidlertid være af andre typer end blot de fundamentale. Vi kan erklære
parametre som pointere, referencer, vektorer eller vi kan bruge vores egne brugerdefinerede
typer eller datastrukturer. Især pointere og referencer er nyttige som parametre, fordi
funktionen får mulighed for at arbejde på data, der ligger udenfor dens skop. Eksemplet
ovenfor med den fejlagtige funktion plus(), som lægger 1 til parametret, kan skrives om
med pointere, så den virker efter hensigten. Parametere som afledte typer erklæres
fuldstændigt som vi erklærer normale afledte objekter. Følgende omskrevne plus()
modtager en pointer:
void plus (int* a) { // læg 1 til *a
52 Funktioner 2.6

*a++;
}
void main () {
int a = 1;
plus (&a); // kald plus() med adressen på a
cout

double resultat = *kr * *kurs;
cout

void f (long& l) {
l += 42;
}
void main () {
int i = 10;
f (i); // overraskelse: i typekonverteres!
cout

eturneres flere steder i funktionen, for eksempel i forbindelse med en betingelse. Værdierne,
der returneres, kan være forskellige men skal være af samme type eller af typer, der kan
konverteres til samme type som erklæret før funktionens navn. Oversætteren vil normalt give
en advarsel, hvis der ikke specificeres en returværdi et sted i en funktion, der ikke er erklæret
void, og vil i øvrigt sikre, at typen, der returneres, er korrekt.
Returtyper kan ligesom parametertyper være afledte. Funktioner kan returnere pointere,
referencer, vektorer, datastrukturer eller brugerdefinerede objekter. Fordelene ved brug af
pointere eller referencer er de samme som for parametre, blot er de vendt om: den kaldende
funktion får adgang til objekter i den kaldte funktion. Her skal der passes på, at der ikke
returneres pointere eller referencer til automatiske variable i den kaldte funktion - de går ud af
skop, når funktionen ender. Følgende leder til dramatik:
int* f () {
int i = 5;
// ...
return &i; // ikke smart, i kendes kun i f()
}
int& g () {
int j = 5;
// ...
return j; // ikke smart, j kendes kun i g()
}
Oversætteren vil normalt advare om en sådan konstruktion. Når vi returnerer pointere eller
referencer fra funktioner, skal de enten være statisk allokerede objekter i funktionen (afsnit
2.9.1), dynamisk allokerede objekter i funktionen (afsnit 2.9.2), globale variable eller de
parametre, som funktionen modtager, såfremt de er pointere eller referencer.
2.6.8 Rekursion
Rekursion er en teknik, der indebærer, at en funktion kalder sig selv. Dette gøres i situationer,
hvor funktionen har svært ved at arbejde iterativt på data (for eksempel i løkker) men dog
alligevel skal foretage den samme behandling af mange ens data. I C++ kan en rekursiv
funktion for eksempel bruges til at traversere et binært træ:
struct BinaryNode {
void* Data;
BinaryNode* hoejre, *venstre;
};
56 Funktioner 2.6

void inorderTraversal (BinaryNode* n) {
if (n->hoejre) inorderTraversal (n->hoejre);
// ...
if (n->venstre) inorderTraversal (n->venstre);
}
Det udnyttes her, at returadresserne på de kaldte funktioner automatisk placeres på en stak af
maskinen, og lader denne underliggende egenskab være det bærende element i gennemløbningen
af data.
2.6.9 Overstyrede funktionsnavne
I C++ kan flere funktioner dele samme navn, så længe de adskiller sig i parameterlisterne. Det
betyder, at selve funktionsnavnet ikke behøver afspejle parametrene, hvis flere funktioner
med samme natur, men med forskellige interne data, skal bruges. Potens-funktionen overfor
kunne tænkes implementeret for typerne double, long og int. Uden overstyring var vi
tvunget til at skrive de tre funktioner med afvigende navne, som i
double doublePotens (double, double);
long longPotens (long, long);
int intPotens (int, int);
Muligheden for at overstyre funktionsnavnet giver os imidlertid lov til at dele det samme
navn i de tre funktioner † :
double Potens (double, double);
long Potens (long, long);
int Potens (int, int);
Oversætteren udleder udfra syntaksen i selve kaldet til funktionen hvilken af de tre versioner
af Potens(), der skal bruges. Det understreges, at parameterlisterne skal afvige i de
overstyrede funktioner; returtyperne er ikke nok:
int Random (); // et tilfældigt heltal: ok
double Random (); // et tilfældigt kommatal: fejl
Oversætteren vil ikke acceptere den anden funktionserklæring. Det skyldes, at der vil opstå
uløselige tvetydigheder ved kald af funktioner med identiske parameterlister. Hvis
† I tidligere versioner af C++ (før 2.0) var det påkrævet at specificere et overload-nøgleord før første erklæring
eller prototype på en funktion, som var genstand for overstyring. Dette er ikke længere påkrævet, men nøgleordet
tillades stadig for kompatibilitetens skyld, selvom det ignoreres af oversætteren.
2.6.8 Rekursion 57

Random(), var den lovlig, for eksempel kaldtes med
long x = Random ();
ville det ikke være muligt at vide, om det var den ene eller anden overstyrede version af
funktionen, der ønskedes kaldt. Brugen af overstyrede funktioner medfører en særlig intern
mingelering af navnene, så oversætteren og lænkeren kan arbejde unikt med dem, hvilket kan
give problemer i særlige tilfælde. Se afsnit 3.9.5.
2.6.10 Underforståede parametre
Et alternativ til overstyrede funktioner er brugen af underforståede parametre. En funktion
udskrivTal(), som tænkes at udskrive et tal i et bestemt talsystem, kunne se sådan ud:
void udskrivTal (int, int);
hvor de to parametre er selve tallet til udskrivning samt den radix, det skal skrives i.
Forestiller vi os, at vi ønsker et underforstået talsystem (for eksempel 10-talssystemet), kan vi
omskrive funktionen, så det andet parameter vil antage en default-værdi, hvis det ikke
medtages i kaldet:
void udskrivTal (int, int = 10);
Dermed undgås en ekstra overstyret funktion, der blot optræder som klister mellem kalderen
og den egentlige funktion, som den kalder med et ekstra parameter.
Læg mærke til to ting: For det første skal det underforståede parameter skrives i prototypen
(hvis den findes), og ikke i selve definitionen på funktionen. For det andet kan den
underforståede værdi udover at være en konstant, være en global, statisk variabel eller et
andet funktionskald:
void setDato (int = getdate (today)); // prototype
void setDato (int julianDay) { // definition
// julianDay antager default-værdi getDate(today)
// ...
}
2.6.11 Uspecificerede parametre
I visse typer af funktioner er det ikke muligt at specificere alle parametre. For eksempel kan
funktionen printf() i standardbiblioteket, som bruges til formateret output, udskrive data
af vilkårlige fundamentale og afledte typer. printf() har en parametererklæring som ikke
58 Funktioner 2.6

specificerer de faktiske typer samt antallet af dem. Det gøres med den specielle notation (...),
en ellipsis, som fortæller oversætteren, at "der er måske flere parametre".
Vi ved altså ikke på oversættelsestidspunktet, hvordan parameterspecifikationen ser ud, og
bliver derfor nødt til at programmere os ud af det. Standardbiblioteket indeholder et antal
makroer til kontrol af denne type funktioner - kode, som på kørselstidspunktet fortolker
parameterlisterne og initierer datastrukturer, som kan bruges i funktionen. De fleste
funktioner med et uspecificeret antal parametre af vilkårlige typer kommer fra C, og findes i
biblioteker, som blev skrevet, da der ikke var alternativer i selve sproget.
Følgende funktionserklæring
void sendData (int ...);
repræsenterer en parameterliste, som består af mindst en int. De uspecificerede parametre
skal altid komme til sidst i listen. Funktionen kan nu kaldes med for eksempel
sendData (MODEM, "ATZ\r"); // send kommando-streng
sendData (PRINTER, 27); // send et heltal
Funktionen skal bruge information, som ikke er tilgængelig fra oversætteren, og følgelig kan
oversætteren ikke type-checke parameterlister til en sådan funktion. Hvis der for eksempel
ikke tages hensyn til kommatal i sendData(), vil der opstå en fejl under kørslen.
Headerfilen indeholder de nødvendige makroer til initiering og
manipulation af parameterlister. Dog skal parameterlisterne organiseres sådan, at funktionen
har mulighed for at fortolke de forskellige parametres typer. Denne information skal komme
fra kalderens funktion. I C-biblioteket findes for eksempel en funktion
printf(), som formaterer forekomster forskellige fundamentale typer efter et mønster og
skriver dem ud. Denne funktion har prototypen
int printf (char* ...)
Pointeren, som modtages som førsteparameter, peger på en format-streng, som fortolkes på en
måde, der giver funktionen mulighed for at vide hvor mange parametre, der uspecificeret
følger efter. Hvis kalderen gør noget forkert, dvs. hvis format-strengen og de efterfølgende
parametre enten ikke stemmer overens i type eller i antal, så vil der opstå en kørselsfejl -
oversætteren har ikke nogen mulighed for at se sådanne fejl, og teknikken bør derfor helst
undgås. Uspecificerede parametre kan udgås ved brug af overstyrede funktionsnavne eller
underforståede parametre.
2.6.12 inline-funktioner
Ved brug af C++-nøgleordet inline før funktions-erklæringen vil oversætteren indsætte
hele funktionens krop i alle referencer i stedet for at foretage et regulært kald. Fordelen
herved er, at mindre funktioner med mange parametre kan udføres med en hastighedsfordel.
2.6.11 Uspecificerede parametre 59

Prisen er oftest en større objektfil:
inline int max (int a, int b) { return a >= b ? a : b; }
Alle kald til max vil resultere i en indsættelse af kroppen (mellem de krøllede parenteser) i
objektkoden på det sted, hvor kaldet foretages. Parameteroverførsel og kald undgås, koden
eksekveres hurtigere. Generelt er det ikke muligt at erklære funktioner, der indeholder
betingelser eller løkker som inline - prøv at forestille dig hvad der ville ske, hvis en
rekursiv funktion skulle være erklæret sådan.
Vi skal senere se, hvordan inline-funktioner er yderst anvendelige i abstrakte datatyper.
2.6.13 Evalueringsrækkefølge
Parameterlisten i et funktionskald evalueres i vilkårlig rækkefølge. Kommaet, som bruges
mellem parametrene, er ikke en sekvensoperator i den forstand, som den bruges i tildelinger
og udtryk. Evaluering fra venstre mod højre er derfor ikke garanteret, men er udefineret.
Undgå derfor funktionskald som:
f (a (), b ()); // kaldes a() eller b() først?
push (pop () / pop ()); // hvilken pop() kaldes først?
hvis a() skal kaldes før b() eller hvis rækkefølgen af kaldene til pop() har betydning,
hvilket de her har i forbindelse med en division. Det gælder også for manipulationer af data i
parameterlisterne:
f (a++, a);
Da udtrykkene a++ og a skal leveres til f(), og da evalueringsrækkefølgen ikke er
defineret, ved vi ikke, om oversætteren først evaluerer a eller a++. Resultatet er derfor
tvetydigt og kildeteksten er ikke garanteret flytbar.
C++ giver en udtalt frihed i syntaksen, men det er en frihed under ansvar. Det kan se pænt
ud at skabe kryptisk kode med et væld af funktionalitet på meget få linier, men det gavner
sjældent effektiviteten og er en klar ulempe for vedligeholdelsen. Brug af midlertidige
variable skader ikke effektiviteten og gør kildeteksten mere åbenbar og sikker.
2.7 KONTROLSTRUKTURER
Programmets "flow" gennem kørslen kontrolleres af C++'s 9 nøgleord for kontrolstrukturering.
Disse nøgleord baseres på en sand/falsk-situation, hvor dele af programmet springes
over, og andre vælges til videre kørsel.
De 9 nøgleord er if, else, while, do, for, switch, case, goto,
continue, og break.
60 Funktioner 2.6

2.7.1 if/else
Denne kontrolstruktur kendes fra alle proceduralt orienterede sprog, og har i C++ syntaksen:
if (udtryk) sætning;
if (udtryk) sætning; else sætning;
Sætningen udføres, hvis udtrykket evalueres til en værdi, der er forskellig fra nul, og springes
over, hvis udtrykket giver nul. Sætningen kan være sammensat, og skal i så fald omsluttes af
en blok. Med else har vi mulighed for at vælge forgrening på både sandhedsværdien og
usandhedsværdien (den omvendte) i samme struktur. Eksempler på if/else-strukturer i
C++:
// max() returnerer største int af 2
int max (int a, int b) {
if (a >= b)
return a;
else
return b;
}
// max() returnerer største int af 3
int max (int a, int b, int c) {
if (a >= b && a >= c)
return a;
else if (b >= c)
return b;
else
return c;
}
void outputChar (int a) {
if (a == 27) {
sendEscape ();
sendNull ();
}
else sendChar (a);
}
I if/else-strukturer skal man være påpasselig, hvis sætningerne er indlejrede. Spørgsmålet
er hvilken if en bestemt else refererer tilbage til. Overvej følgende eksempel:
2.6.13 Evalueringsrækkefølge 61

void f (int a, int b) {
if (a == 1)
if (b == 2)
g ();
else
h ();
}
Man skulle tro (ikke mindst på grund af indrykningnen), at g() kaldes, såfremt a er 1 og b
er 2, og at h() ellers kaldes. Det forholder sig imidlertid sådan, at en else binder til den
seneste if, så h() vil kun blive kaldt, hvis a er 1, og b ikke er 2. Her må vi tage
blokkene i brug:
void f (int a, int b) {
if (a == 1) {
if (b == 2)
g ();
}
else h ();
}
så oversætteren tvinges til at binde til den tidlige if.
2.7.2 while/do
En anden velkendt kontrolstruktur, while-sætningen, har følgende syntaks:
while (udtryk) sætning;
og udfører sætning sålænge udtryk er sandt, altså giver alt andet end nul. Som i ifsætningen
skal kontrolstrukturens krop omsluttes som blok, hvis den er sammensat af flere
sætninger. En while-struktur kan se ud som følger:
int decCif (int i) { // antal decimale cifre på et tal
int j = 0;
while (i) j++, i /= 10;
return j;
}
char Spejl (char b) { // lav et binært spejlbillede
char t = 0;
int j = 8;
62 Kontrolstrukturer 2.7

while (j--) {
t = 1;
}
return t;
}
while tester på udtrykkets sandhed i starten af løkken. Derved kan løkken helt springes
over. Det er også muligt at teste i slutningen af løkken, for at tillade mindst et gennemløb.
do-while kan sammenlignes med andre proceduralt orienterede sprogs repeat-sætninger.
Dette gøres med do-nøgleordet:
void f (int i, int j) {
do {
i /= j;
} while (i);
}
2.7.3 for
I C++ er kontrolstrukturer med for-sætninger blot en generalisering af while/do. En
for-sætning har følgende syntaks:
for (udtryk1; udtryk2; udtryk3) sætning;
og svarer direkte til følgende kombinerede strukture med while-nøgleordet:
udtryk1;
while (udtryk2) {
sætning;
udtryk3;
}
for-løkker fylder mindre i kildeteksten, og gør den mere naturlig og læsbar. De tre udtryk
skal læses som henholdsvis en initiering, en terminerings-test (afslutningstest) og en
opdatering. Eksempel på en for-struktur:
void f () {
int b = 1;
for (int a = 8; a; a--) b *= 2;
}
2.7.2 while/do 63

Hvis løkkens krop indeholder mere end én sætning, skal den omsluttes af en blok:
for (x = 0; x < 10; x++) {
y += x;
if (y % 100) y++;
}
Det er lovligt at placere kombinerede udtryk i for-strukturen, separeret med kommaer:
for (x = 0, f = 1; x < 20 && y; x++) y = (v [x] != 0);
Erklæringer af variable, der forekommer i for-løkkens er lokale til løkkens skop, og kendes
ikke efter løkkens slutning. Hvis et af de tre udtryk ikke behøves, kan de udelades:
for (; *p; p++) // gentag indtil p peger på '\0'
for (a = 0;;a++) // gentag for evigt
for (;;) // gentag for evigt
2.7.4 break, continue og goto
I løkker har vi undertiden behov for at slutte før tiden, hvis for eksempel en fejl pludselig
opstår. C++ har tre nøgleord for ikke-lineær styring af programmets flow: break, som
bryder ud af den inderste for- eller while-løkke, continue, som går til slutningen af
løkken samt goto, som hopper til et vilkårligt sted indenfor samme funktion.
Følgende funktion benytter break til tidlig afbrydelse. Funktionen konverterer et decimalt
beskrevet tal, der repræsenteres af en streng, til en long:
long atol (char* s) { // konvertér s til long
long j = 0; // returværdi
while (*s != '\0') { // sålænge der er tegn
if (*s > '9' || *s < '0') { // hvis ulovligt ciffer
j = 0; // returværdi nul
break; // bryd ud af while-løkken
}
j = j * 10 + *s % 10; // addér ciffer
s++; // næste ciffer
}
return j; // returnér resultatet
}
I 4. linie analyseres, hvorvidt det aktuelle ciffer er et lovligt decimalt tegn ('0' - '9'). Hvis det
ikke er tilfældet, brydes for-løkken i linie 6, og kontrollen fortsætter i linie 11. break
bruges på denne måde i forbindelse med løkker af for- og while-typen oftest til tidlig
64 Kontrolstrukturer 2.7

afbrydelse af disse, når grunden til afbrydelsen først bliver kendt i midten af løkken og
kræver, at efterfølgende processering ikke bliver udført.
continue ligner break, men forlader ikke løkken. Erstattes break i linie 6 med
continue, vil linie 8 og 9 springes over, og videre kørsel fortsætte fra linie 3. continue
bruges, hvis en situation opstår, som afslutter løkkens funktion, men som ikke kræver, at
løkken forlades:
while (*s != '\0') { // spring mellemrum over
if (*s == ' ') continue;
if (*s > '9' || *s < '0') { // hvis ulovligt ciffer
j = 0; // returværdi nul
break; // bryd ud af while-løkken
}
j = j * 10 + *s % 10; // addér ciffer
s++; // næste ciffer
}
Selv om goto ikke skønnes at have nogen brugbar funktion i moderne programmering, fordi
udnyttelsen af dette nøgleord skaber ustrukturerede og rodede programmer i kraft af det store
tab af abstraktion ved direkte hop, findes den dog alligevel. goto bryder
eksekveringssekvensen og fortsætter efter erklæringen af den etikette, der specificeres ved
goto-nøgleordet:
void f (int a) {
if (!a) goto error; // a må ikke være 0
// ... // forstæt med behandlingen
return; // returnér fra funktionen
error:
// ... // fejlbehandling
}
En etikette er et navn efterfulgt af et kolon (:). Etiketter er lokale til de funktioner, i hvilke de
defineres og kan ikke defineres udenfor funktioner. Både forlæns- og baglæns hop med
goto er tilladt, dog begrænset til den funktion, den befinder sig i samt med det ekstra
forbehold, at der ikke må være erklæringer mellem goto og etiketten, som i:
void f (int i) {
if (i > 0) goto ok; // fejl, kan ikke hoppe over...
char* s = "Error"; // ...denne linie
cout

2.7.5 switch/case
Ofte har et program brug for en flerledet if/else, især i situationer, hvor en
tilstandsvariabel er i fokus. For eksempel,
if (a == 1)
// ... behandl kode for a == 1
else if (a == 2)
// ... behandl kode for a == 2
else if (a == 3)
// ... behandl kode for a == 3
else
// ... hvis a er hverken 1, 2 eller 3
I sådanne tilfælde vil en switch-struktur både være mere læsbar og generere hurtigere kode
gennem specielle tabeller i målkoden:
switch (a) {
case 1: // behandl kode for a == 1
break;
case 2: // behandl kode for a == 2
break;
case 3: // behandl kode for a == 3
break;
default: // hvis a er hverken 1, 2 eller 3
break;
}
Der er et par vigtige forskelle mellem if/else og switch/case:
• Det er nødvendigt at slutte hver case med en break for at forlade switchstrukturen
og fortsætte efter den afsluttende Tuborg-klamme.
• Udtrykket efter en case skal være en konstant. Det er derfor ikke muligt at skrive
case b:, hvis b er en variabel af typen int; i så tilfælde må en flergrenet
if/else benyttes.
• Koden efter default køres hvis ingen af case'erne passer til værdien af den
variabel, der ligger i switch'en. default er således ækvivalent til den sidste
else i en flergrenet if/else-kontrolstruktur.
• To case'r med samme konstant kan ikke indeholdes i samme switch-struktur.
66 Kontrolstrukturer 2.7

• Det er muligt at udføre koden under flere case'r i en switch-sætning, ved
udeladelse af nøgleordet break.
break bruges i switch/case-strukturer til at slutte processeringen for en enkelt case.
Udelades break fortsætter programmet betingelsesløst i den næste case-indgang uden at
foretage nogen sammenligning med dennes værdi. Dette er i visse tilfælde en brugbar detalje,
hvis gensidig udelukkelse af de individuelle case-elementer ikke kræves:
switch (allokering) {
case '3': oprydning3 ();
case '2': oprydning2 ();
case '1': oprydning1 ();
}
Denne switch-sætning tænkes at rydde op i lageret ved endt kørsel af et program.
Variablen allokering indeholder antallet af forskelige lager-allokeringer, der er foretaget
ved opstart. En lineær, revers oprydning i en switch-sætning uden break-sætninger vil
kalde det korrekte antal oprydnings-funktioner. Manglende break-sætninger i slutningen af
case-indgange er typiske kilder til fejl og er derfor et udmærket sted at beynde en
fejlfindingssession.
Det er god praksis også at slutte den sidste case (eller default) med en break.
2.8 DATASTRUKTURER
En datastruktur er en eller flere forekomster af fundamentale eller afledte typer samlet under
et enkelt navn. Fordelen ved en sådan samling er, at en struktur kan behandles som en entitet,
hvorved de enkelte elementer kan ignoreres indtil de skal bruges. Strukturer hjælper også med
organiseringen af data, fordi konceptuelt sammenhængende data kan samles under ét navn og
således er lettere at overskue.
En typisk C++-datastruktur, der definerer objekter vedrørende et koordinat, ser således ud:
struct Koordinat { // ny type hedder Koordinat
int x, y; // og indeholder to int'er
};
Denne definition resulterer ikke i en forekomst af strukturen Koordinat, det er blot en
definition af strukturen, som kan bruges som en ny type. Forekomster af Koordinat kan
specificeres på følgende måde:
Koordinat startPunkt, endePunkt; // to forekomster
C++ vil behandle den ny struktur på samme måde som de indbyggede, fundamentale typer. I
2.7.5 switch/case 67

tildelinger, parameteroverførsler, samt returværdier fra funktioner, hvor variable af typen
koordinat er impliceret, vil oversætteren melde fejl, hvis typerne ikke stemmer overens.
Objekter af forskellige typer kan ikke stå i samme udtryk (medmindre der er defineret
specielle konverteringsregler forinden, se afsnit 3.6):
Koordinat a;
int b = a; // fejl, b er ikke et Koordinat
Indholdet af en ny type kaldes medlemmer af typen. x og y er således medlemmer af typen
Koordinat. Navne på medlemsdata er lokale til de strukturer, de defineres i - deres skop
ligger i de navne, som forekomster af strukturen har. Således kan flere strukturer indeholde
data af same navne:
struct Koordinat2D {
int x, y;
};
struct Koordinat3D {
int x, y, z;
};
uden en navnekonflikt opstår mellem medlemsvariablene. Det er tilladt at erklære en
forekomst af en datastruktur i selve definitionen på strukturen:
struct Koordinat {
int x, y;
} cursorPosition;
er det samme som:
struct Koordinat {
int x, y;
};
Koordinat cursorPosition;
Anonyme datastrukturer, dvs. strukturer, der kun findes som objekt og ikke som type,
behandles i afsnit 2.8.3.
2.8.1 Medlemsreferencer
De enkelte medlemmer i en struktur kan refereres gennem de to medlemsreference-operatorer
. og ->, for henholdsvis forekomster af strukturen og pointere til forekomster. I følgende
68 Datastrukturer 2.8

funktion findes arealet af et rektangel, defineret ved to absolutte punkter:
int Areal (Koordinat a, Koordinat b) {
int laengde = b.x - a.x;
int hoejde = b.y - a.y;
return laengde * hoejde;
}
Strukturerne tager form som brugerdefinerede datatyper, når de bruges som parametre, som
returværdier og i tildelinger:
Koordinat delta (Koordinat a, Koordinat b) {
Koordinat c;
c.x = b.x - a.x, c.y = b.y - a.y;
return c;
}
Pointere til forekomster af strukturer kræver en anden syntaks ved medlemsreferencerne:
Koordinat a; // forekomst af en koordinat
Koordinat* b; // pointer til koordinat
b = &a; // b skal pege på a
b->x = 100, b->y = 50; // referér *b's medlemsdata
Læg mærke til, at b->x er ækvivalent til (*b).x og blot letter syntaksen.
Det er generelt bedre at bruge pointere eller referencer til strukturer under funktionskald, da
langt mindre data skal passere fra kalderen til den kaldte funktion. En stor datastruktur (for
eksempel 1000 bytes) skal kopieres ved hvert funktionskald, hvis ikke pointer-variable
bruges.
2.8.2 Bitfelter og union'er
Datastrukturer har ofte megen spildplads, der opstår, fordi en eller flere medlemsvariable
gensidigt udelukker hinanden, eller fordi båndbredden på en bestemt variabel er mindre end
den mindste fundamentale type. Hertil har C++ to muligheder for at spare på pladsen, nemlig
bit-felter og union'er.
Bit-felter fortæller oversætteren, at en bestemt medlemsvariabel kræver et bestemt antal
bits. Flere bit-felter vil kunne pakkes sammen i en enkelt fundamental type:
struct Flag {
unsigned farve : 3; // 8 forskellige farver
unsigned blink : 1; // blink til/fra
2.8.1 Medlemsreferencer 69

unsigned fed : 1; // fed skrift til/fra
unsigned kursiv : 1; // kursiv skrift til/fra
unsigned unders : 1; // understreg til/fra;
};
Denne struktur definerer en "attribut" på skærmen, nemlig fremtoningen (farve, skriftform
osv.) af teksten. Sammenlagt behøves kun 7 bit, som kan normalt kan indeholdes i en char.
Det skal bemærkes, at brugen af bit-felter er en smule langsommere end brugen af rene
fundamentale typer, fordi de forskellige bits implicit hentes ud af en sådanne (en bit er ikke en
datatype på de gængse processortyper).
En union bruges til at dele en fysisk lagerplads mellem flere forskellige data-elementer.
Oversætteren vil allokere plads til det største af elementerne, og afhængig af referencen vil
den korrekte type blive returneret. Forskellen til en struct er blot, at alle medlemmer har
samme adresse. En union kunne tænkes at repræsentere en landekode, som enten kan
beskrives som en int (45 for Danmark, 1 for USA osv.) eller som to char's (DK for
Danmark, US for USA osv.). Syntaksen er som følger:
union landekode {
int nummer;
char ident [2];
};
En forekomst af landekode vil kunne benyttes således:
landekode land;
land.nummer = 45;
int l = land.nummer; // her bruges land som en int
land.ident [0] = 'D';
land.ident [1] = 'K';
char* m = land.ident; // og her som en char*
Det er programmørens ansvar, at det aktuelle indhold af en union bruges som det skal. Da
samme fysiske lager deles af de forskellige typer, kan problemer let opstå:
land.ident [0] = 'E', land.ident [2] = 'F';
int land.nummer = land.ident; // helt forkert resultat (!)
Indholdet af land er aktuelt et nummer, og en reference til ident vil give et udefineret
resultat. Oversætteren kan ikke checke for fejl i denne sammenhæng, så pas på.
2.8.3 Anonyme strukturer
70 Datastrukturer 2.8

Definitioner af struct og union kan være anonyme, dvs. erklæres uden et typenavn. For
struct'er gælder det, at strukturen skal følges af en erklæring af en forekomst af strukturen,
idet den ellers ikke vil kunne bruges til noget:
struct {
int x, y;
} koordinat;
Den ovenstående datastruktur findes kun som en enkelt forekomst, og kan ikke erklæres igen.
Det er ikke en teknik, der bruges ofte, men kan være en hjælp til at organisere globale data i
moduler, når der kun skal være en enkelt forekomst af disse data. Dermed mindskes risikoen
for navnekonflikter:
struct {
unsigned FPU_status;
int monitor_type;
int no_of_disks;
unsigned heap_size;
unsigned env_size;
} globals;
De forskellige medlemmer af den anonyme struktur refereres på normal vis med medlemsreference-operatoren.
union'er kan også være anonyme, men kan være det uden både typenavn og samtidig
erklæring af en forekomst. Programmet har adgang til medlemmerne i en anonym union
uden brug af medlemsreferencer:
union {
char char_buffer [100];
int int_buffer [100];
long long_buffer [100];
};
De tre medlemmer af denne union vil have samme startadresse i lageret, men vil kunne
bruges uden henvisning via en bestemt forekomst. Det er en god ide at erklære anonyme
union'er, hvis forskellige variable (specielt vektorer) aldrig bruges på samme tid, fordi det
sparer lagerplads. Det er dog tilladt at erklære en eller flere forekomster af en anonym
union efter definitionen, hvorved de samme regler gælder som for anonyme struct'er.
Anonyme struct'er finder også anvendelse i union'er, hvis en union skal indeholde
mere komplicerede blandinger af variable. For eksempel kan vi tænke os en union, som
indeholder en brøk. Brøken kan beskrives som enten en double, to int til tæller og
nævner eller som en long som den reciprokke værdi af tallet:
union Broek {
2.8.3 Anonyme strukturer 71

double v1;
struct { int v2, v3; }; // enkelt medlem af broek
long v4;
};
Opremsninger, enums, kan også være anonyme, efter samme regler som struct'er:
enum { black, red, blue, green = 4 } Palette;
Forekomsten palette er af en unavngiven type, men kan tildeles og sammenlignes med
værdierne black, red, blue og green.
2.8.4 Indlejrede strukturer
Strukturer kan indeholde andre strukturer som medlemmer, hvis abstraktionen søges hævet et
eller flere niveauer:
struct Polygon { // et sæt af koordinater
struct Koordinat {
int x, y;
} k [10]; // Polygon indeholder 10 Koordinater
};
Når indlejrede strukturer skal anvendes, benyttes reference-operatoren i flere gange i samme
sætning:
Polygon p;
p.k [3].x = 5; // det 3. koordinat i p
Det er meget brugbart at "indkapsle" strukturer i andre strukturer, og det giver mening af gøre
de indre strukturer anonyme. Læg imidlertid mærke til, at hvis en struktur, som er indeholdt i
en anden struktur, ikke er anonym, vil typenavnet være kendt også udenfor den ydre struktur
(se afsnit 3.3.9 om objekt-baseret og type-baseret indkapsling). For strukturens typenavn er
det altså ligegyldigt, hvor strukturen er defineret - det er mest et spørgsmål om logisk at samle
associerede strukturer i kildeteksten.
Når vi for alvor blander struct, union og enum sammen, giver det stor fleksibilitet.
Anonyme union'er har stor anvendelighed indeholdt i andre struct'er eller union'er,
idet den ydre struktur kan have forskelligt indhold afhængig af brugen. En struct
indeholdt i en union tillader, at for eksempel en long og to int'er deler lager:
struct Figur {
enum { // anonym opremsning
Cirkel, Firkant, Linie
72 Datastrukturer 2.8

} Slags; // medlemsvariabel
struct Koordinat { // indlejret struktur
int x, y;
} startPunkt; // medlemsvariabel
union { // anonym union
int Radius; // medlemsvariabel
struct { // anonym struct
int Bredde, Hoejde; // to medlemsvariable
} Dimensioner; // medlemsvariabel
Koordinat endePunkt; // medlemsvariabel
};
};
Denne lidt komplicerede struct Figur indeholder en optælling af figurtyper (Slags),
en erklæring af et typenavn (Koordinat), en forekomst af Koordinat og en anonym
union. Den anonyme union indeholder igen en int, to kombinerede int'er i en
anonym struct (Dimensioner) samt endnu en forekomst af Koordinat (hvilket er
grunden til, at denne ikke var anonym). Forekomster af Figur kan repræsentere enten en
cirkel, i hvilket tilfælde den arbejder med en radius, en firkant, i hvilket tilfælde den arbejder
med en vidde og en bredde eller en linie, i hvilket tilfælde den skal bruge et endepunkt. Her er
et par eksempler på brugen af Figur:
// en vindues-figurtype...
Figur Vindue;
Vindue.Slags = Firkant,
Vindue.startPunkt.x = 100,
Vindue.startPunkt.y = 100,
Vindue.Bredde = 64,
Vindue.Hoejde = 32;
// en panel-figurtype...
Figur Panel;
Panel.Slags = Linie,
Panel.startPunkt.x = 100,
Panel.startPunkt.y = 90,
Panel.endePunkt.x = 164,
Panel.endePunkt.y = 90;
// en håndtags-figurtype...
Figur Haandtag;
Haandtag.Slags = Cirkel,
Haandtag.startPunkt.x = 100,
Haandtag.startPunkt.y = 116,
Haandtag.Radius = 4;
2.8.4 Indlejrede strukturer 73

2.8.5 Funktioner som medlemmer
Medlemmer af strukturer kan være både dataobjekter og funktioner. Faktisk er en funktion et
objekt i den forstand, at det er muligt at tage adressen på den. Da C++ udvider konceptet om
medlemmer til også at omfatte funktioner betyder det, at vi kan indkapsle funktioner, der
arbejder på strukturens data i selve strukturen. For eksempel,
struct Cirkel { // en cirkel-type
Koordinat midtPunkt; // center for cirklen
int Radius; // radius
int Diameter () { // diameter-medlemsfunktion
return Radius * 2;
}
};
Funktionen Diameter() er i dette tilfælde en medlemsfunktion under strukturen
Koordinat. Diameter() kaldes udefra med samme syntaks som medlemsvariablene
refereres, nemlig med reference-operatorerne. Diameter() har selv adgang til medlemsvariable
i sin "egen" struktur uden brug af reference-operatorer. Et eksempel på brugen af
Cirkel:
Cirkel c;
c.midtPunkt.x = 100, c.midtPunkt.y = 100, c.Radius = 50;
int d = c.Diameter ();
Den umiddelbare fordel ved medlemsfunktioner er den samme som for medlemsdata,
nemlig at samle alle funktioner, der direkte manipulerer de indre variable under ét og samme
tag. Det giver en bedre anledning til brugen af brugerdefinerede datatyper, at både data og
kode kan samles i typen. Alle referencer sker gennem en forekomst af typen, i stedet for at
bruge forekomsten som parameter i et funktionskald.
Funktioner som medlemmer af datastrukturer er fundamentet for arbejdet med og
implementationen af abstrakte datatyper, og diskuteres i detaljer gennem kapitel 3.
2.8.6 Fremad-referencer
Der gælder de samme regler for referencer til datastrukturer som for referencer til funktioner:
de skal erklæres før de kan bruges, fordi C++ oversætter kildetekst til objektkode i et enkelt
gennemløb. Fremad-referencer til datastrukturer er nødvendige, hvis selve definitionen af
strukturen, hvor medlemmerne erklæres, er placeret fysisk senere i kildeteksten end brugen af
74 Datastrukturer 2.8

strukturen. Et eksempel, hvor det er helt nødvendigt at bruge en fremad-reference er i de
tilfælde, hvor to strukturer gensidigt henviser til hinanden:
struct Liste; // fremad-reference til struct Liste
struct Haegte { // en simpel hægte
Haegte* Naeste; // pointer til næste hægte
Liste* Ejer; // pointer til liste som "ejer" hægten
int Data; // hægtens data-element
};
struct Liste { // en simpel hægtet liste
Haegte* Rod; // pointer til første hægte
int Antal; // antallet af hægter i listen
};
Vi ser, at Haegte har en pointer til en forekomst af Liste samt at Liste har en pointer
til en forekomst af Haegte. Derfor skal en af de to strukturer (her Liste, fordi den
defineres sidst) erklæres med en struct Liste før den bruges som type første gang.
2.8.7 Dereference af medlemmer
Operatorerne -> og ., som kort blev remset op i afsnit 2.5.6, kan nu forklares i forbindelse
med datastrukturer. Vi husker, at en forekomst f, erklæret som pointer til type T, kan
derefereres med *f, som giver en forekomst af typen T. Ligeledes, hvis f er erklæret som
pointer til type T i strukturens a's skop, vil *a.f give en forekomst af typen T, fordi
medlemsreference-operatoren har højere prioritet end dereference-operatoren. Dette følger
således de normale regler:
struct T {
char* c;
};
T t;
char d = *t.c; // c i t derefereres
T* tptr = &t;
char e = *t->c; // c i *tptr (også t) derefereres
eller i flere niveauer:
struct T {
2.8.6 Fremad-referencer 75

T* next;
char c;
};
T t1, t2; // to T-objekter
t1.next = t2, t2.next = 0
T* tptr = t1;
t1->next->c = 'a';
Her ses, hvordan reglen om, at udtrykket til venstre for en medlemsreferenceoperator skal
være en struktur eller en pointer til en struktur giver mulighed for mangeledede indgange i
indlejrede strukturer. Det er sjældent, at der er brug for mere end to-tre referencer til
medlemmer i samme udtryk.
Operatorerne .* og ->* benyttes også i forbindelse med datastrukturer. De fungerer på
næsten samme måde som normale pointere til medlemmer, blot med den forskel, at de tager
hensyn til de objekt-orienterede mekanismer som bliver introduceret i kapitel 4. De arbejder
således på selve typen og ikke på objekter af typen, et forhold, der er meget væsentligt i
forbindelse med arv og polymorfi. I afsnit 3.7 beskrives disse to operatorers funktion i
detaljer. Her blot et eksempel på syntaksen:
struct Y { // en enkel struktur
char c;
};
char Y::*cptr = Y::c; // cptr peger på en char i Y
// bemærk: ingen objekter endnu
Y yobj; // erklær et Y-objekt
char ch = yobj.*cptr; // c-medlemmet i yobj gennem cptr
Syntaksen Y::*X, som benytter skop-opløsningsoperatoren, betyder, at objektet (her X)
erklæres som pointer til medlem i strukturen Y, ikke objektet Y. Ved at holde generaliteten
på strukturbasis kan objekterne udskiftes efter behag, en arbejdsmodel, der fremmer
udviklingen af genbrugelig kode.
2.9 LAGERADMINISTRATION
Lageradministration handler om organisering, placering og lokalisering af data. I de fleste
sprog, som benytter en separat oversættelse og lænkning, taler man om to typer af data,
nemlig data med intern lænkning og data med ekstern lænkning. Intern lænkning betyder, at
data ikke kan ses af andre objektmoduler end det aktuelle, dvs. at det slet ikke bliver
videregivet til lænkeren. Ekstern lænkning betyder, at navnet på dataelementet står skrevet i
76 Datastrukturer 2.8

objektfilen, og dermed kan ses og bruges af andre moduler.
Princippet for valget af intern og ekstern lænkning er som følger: hvis en funktion eller et
dataelement kun benyttes i den aktuelle kildefil, skal intern lænkning benyttes for at beskytte
mod navnekonflikter i de andre moduler. Kaldes nogle funktioner eller refereres nogle data
fra andre moduler, skal ekstern lænkning benyttes for at identificere de enkelte navne under
lænkning. Hvis der er tale om globale funktioner (funktioner, som ikke er medlemmer af
strukturer eller klasser), er de underforstået erklæret som eksterne, med mindre de erklæres
static. I så tilfælde er de helt lokale til den aktuelle kildefil. Det samme gælder for globale
data (som ikke er erklæret i en funktion eller datastruktur); de er kun lokale, hvis de erklæres
statiske. For eksempel,
// a.cpp
int f () { /* ... */ }
static int g () { /* ... */ }
// b.cpp
extern int f ();
static void g () { int i = f (); }
Når disse to filer oversættes, vil kun funktionen f() fra modulet a.cpp være synlig for
andre objektfiler. Denne funktion kaldes fra b.cpp, som derfor kræver, at funktionen har
ekstern lænkning. Erklæringen af f() som extern funktion i b.cpp betyder, at
funktionen er implementeret i en anden kildefil, og først kan indentificeres ved lænkningen.
Det er altså blot en prototype. Findes funktionen alligevel i den aktuelle kildefil, vil
extern-nøgleordet blive ignoreret, og funktionen vil have extern lænkning. externnøgleordet
er med andre ord underforstået for funktionsprototyper. For data skal nøgleordet
specificeres, hvis dataelementet benyttes i den aktuelle fil, men er erklæret i en anden.
Normalt organiseres kildefilerne, så deres tilsvarende headerfiler indeholder prototyper på
alle funktioner og datastrukturer. Når både kildefilen selv og alle andre moduler, som kalder
funktioner eller benytter datastrukturer fra denne, inkluderer samme headerfil, sikres
konsistensen af funktionskaldene og datamanipulationerne, fordi de samme prototyper gør sig
gældende.
2.9.1 Lagringsklasser
Ser vi bort fra intern og ekstern lænkning og koncentrerer os om en enkelt kildefil, foregår
dataallokeringen på en af tre måder, enten automatisk, statisk eller dynamisk.
• Automatiske variable er variable, som erklæres og har sine skop indenfor enkelte
funktion eller blokke. Funktionen
void f () {
auto int a;
2.9 Lageradministration 77

...
}
vil allokere plads til int'en a på det kørende programs stak, hver gang den kaldes,
altså under programmets kørsel. Det er nødvendigt, da a skal være helt lokal til
f(), især fordi f() kan være en rekursiv funktion (se afsnit 2.6.8). Det er derfor
underforstået, at variable, der erklæres indenfor en blok, er automatiske. Nøgleordet
auto før erklæringen er tilladt for læsbarhedens skyld, men er underforstået og
unødvendigt.
• Statiske variable er variable, som erklæres indenfor en funktion eller en blok, og
bliver allokeret på oversættelsestidspunktet. En statisk erklæring foretages med
nøgleordet static:
void f () {
static int a;
// ...
}
Brugen af static på denne måde vil danne en enkelt int a for funktionen
f(), uanset hvorfra f() kaldes. a vil huske sin værdi fra kald til kald, men er
stadig lokal til f(). Statiske variable i funktioner eller blokke bruges til at holde
værdier (for eksempel en indre status), som ikke må glemmes ved funktionens udløb.
Globale variable, som erklæres udenfor funktioner og blokke, er også statiske
variable. En global variabel vil kunne bruges i alle funktioner i alle moduler, med
mindre variabelnavnet er omdefineret indenfor den pågældende funktion eller blok
og med mindre den eksplicit er erklæret static, jvf. forrige afsnit. Brugen af
globale variable skønnes generelt at være problematisk, fordi alle dele af programmet
har tilgang til dem, og en eventuel fejl derfor er svær at lokalisere.
2.9.2 new og delete
Den sidste metode for lageradministration er dynamisk allokering og deallokering. Ved
dynamisk allokering forstås, at programmet (og programmøren) er ansvarlig for selv at
anmode om lager samt at frigive det til systemet igen, når det ikke længere skal bruges.
Dynamisk allokering bruges, hvis programmet på oversættelsestidspunktet ikke kender til
eksakte størrelser på de anvendte data. C++ har, i modsætning til forgængeren C, indbygget
dynamisk lageradministration. Ved statisk lagerallokation (for eksempel en int tabel
[100]) allokeres pladsen på oversættelsestidspunktet (100 int'er) og placeres i objektfilen.
Hvis programmet på et tidspunkt har brug for 101 elementer, er det grumme svært at gøre
noget ved det.
I standard C findes et antal biblioteksrutiner for dynamisk allokering af lager, familien af
78 Lageradministration 2.9

malloc()-funktioner samt de tilsvarende figivelsesfunktioner, free() og beslægtede.
Disse er funktioner, som eksplicit skal kaldes med en forespørgsel på lagerstørrelsen, og som
returnerer en pointer til det nyallokerede lager. I C++ er allokeringen (eller i hvert fald den
sproglige side af den) som nævnt indbygget i selve sproget, via de to operatorer new og
delete.
new og delete allokerer plads i et særligt område, heap'en, og bruges i forbindelse
med pointere. new skal følges af en type, og returnerer en pointer til den nyallokerede
forekomst af typen. For eksempel,
int* a; // en pointer til en int
a = new int; // anmod systemet om en int
// ...
delete a; // frigiv lagerpladsen igen
new kan følges af en vektor-operator, hvilket fortæller, at en vektor af en bestemt størrelse af
den pågældende type søges allokeret:
int* a; // en pointer til en int
a = new int [100]; // anmod systemet om 100 int'er
// ...
delete a; // frigiv de 100 int'er igen
Der er to faldgruber i forbindelse med new og delete, der er vigtige ikke at glemme. For
det første er det vigtigt at huske at delete allokeret lager igen, ellers frigives det aldrig til
systemet. Afhængig af operativsystemets struktur vil lagerpladsen ikke frigives før
programmet afsluttes (små systemer), før hele systemet nedlukkes (mellemstore systemer)
eller før der foretages en stor oprydning (garbage collection - store systemer). For det andet
skal programmøren være ompærksom på, at den pointer, som adresserede det just frigivede
lager ikke ændrer værdi ved delete. Pointeren er nu meget farlig at bruge indirekte, fordi
den peger på udefineret lager - en såkaldt dangling pointer eller reference. Eftersom
lagerpladsen er lagt tilbage i operativsystemets domæne, kan operativsystemet bruge det
samme fysiske lager til andre formål. Manipuleres området alligevel, kan det lede til
uforudsete resultater - i bedste fald en afslutning af applikationen. På mindre systemer vil hele
maskinen sandsynligvis crashe, mens større systemer vil afbryde programmet med en
reference-fejl, varetaget af operativsystemet.
new og delete kan bruges til dynamisk allokering og frigivelse af alle typer samt
vektorer, også af brugerdefinerede:
Cirkel* a = new Cirkel [100];
I denne sætning allokeres plads til 100 objekter af typen Cirkel.
2.9.2 new og delete 79

Læg mærke til, at data, som er dynamisk allokeret, følger samme regler for intern og ekstern
lænkning som data med andre typer af allokeringer. Er pointervariablen, som tildeles det
allokerede lager, således erklæret som global variabel uden static-specifikationen, vil
dette data via pointeren også kunne nås fra andre moduler.
2.10 PRÆPROCESSERING
Selv om C++-kildetekst normalt gennemløbes én gang af oversætteren, foregår det
konceptuelt i flere faser. Den første fase, præprocesseringen eller forbehandlingen af koden,
foretager forskellige statiske substitutioner, som ikke har syntaktisk eller semantisk relevans,
men som blot letter programmeringsarbejdet. Præprocessoren tager ikke hensyn til skop, så
kommandoer til præprocessoren har effekt fra det sted, de gives, til slutningen af den aktuelle
oversættelse. De skal begynde med et #, kun eventuelt forudgået af mellemrum, og kan
fortsættes på næste linie ved angivelse af en baglæns skråstreg, \.
2.10.1 Inkludering af headerfiler
Det oftest benyttede præprocesseringsdirektiv er det, der benyttes til inkludering af andre
kildefiler, #include. Præprocessoren vil indsætte den angivne fil (normalt en headerfil) på
det aktuelle sted i kildefilen, og gennemløbe denne før den videre oversættelse. Inklusioner
kan foregå i flere niveauer, dvs. en fil, som #include's kan selv #include andre igen
osv., normalt begrænset af filsystemets grænse for antallet af åbne filer. Der er to varianter:
#include
#include "filnavn"
Den første af disse vil søge efter den angivne fil i en udvidet søgesti på filsystemet, oftest i et
bibliotek eller katalog, hvor standard-headerfiler er placeret. Den anden vil blot se i det
aktuelle katalog, dvs. der hvor den aktuelle kildefil befinder sig. Forskellen på de to er, at
mange headerfiler skal deles mellem og bruges i mange applikationer, hvorfor de placeres i et
fælles katalog. Headerfiler, som er specifikke til en bestemt applikation, findes i et lokalt
katalog. Hvis filen med lokal søgning dog ikke findes, forsøges igen med den udvidede
søgesti. Man kan sige, at headerfiler, som inkluderes med citationstegn, er mere implementationsafhængige
end de, der inkluderes med klammer.
2.10.2 Makroekspansioner
En vigtig pointe i softwareudvikling er at sikre konsistens i kildeteksterne. Har man i et
bilforhandler-program for eksempel valgt, at der skal findes 6 biltyper, er det vigtigt, at tallet
6 bruges i al kode. Risikoen for, at man tager fejl eller glemmer dette tal, kan mindskes ved
80 Lageradministration 2.9

ug af makroer:
#define BILTYPER 6
// ...
for (i = 0; i < BILTYPER; i++) // ...
// ...
if (input > BILTYPER) // ...
Og hvis vi pludselig finder ud af, at vi faktisk kun har 5 biltyper, er det blot at ændre tallet ét
sted.
Makroer finder langt mindre anvendelse i C++ end i C, fordi C++ (og ANSI C) har
introduceret symbolske konstanter og inline-funktioner. Til gengæld har makroerne en anden
fordel, nemlig at de bliver præprocesseret i forhold til resten af koden. Præprocessering af
C++ kildetekst fortolker alle linier, som starter med # - det gælder også #include.
Forskellige implementationer af C++-oversættere har forskellige andre præprocessordirektiver.
Makroer defineres generelt således:
#define navn indhold af makroen
Her defineres en makro med navn navn til at indeholde indhold af makro. Makroens
navn er det første ord efter #define, og makroens indhold er resten af linien (til '\n'). Hvis
oversætteren efter makro-definitionen for eksempel støder på
et sødt navn
vil det af præprocessoren automatisk blive erstattet med
et sødt indhold af makroen
før selve oversætteren tager fat. Makroer kan også tage argumenter, som kan indgå i
ekspansionen af indholdet:
#define max(x,y) x > y ? x : y
Makroen max skal have to argumenter, når den bruges i kildeteksten. Det er ikke en
funktion; hele makroens "krop" vil blive indsat i kildeteksten umiddelbart før den oversættes.
max vil ændres fra
til
a = max (i, j);
a = i > j ? i : j;
2.10.2 Makroekspansioner 81

Der er et par farlige fælder i forbindelse med makroer. Da de ikke er genstand for nogen form
for semantisk analyse, kan der opstå mange fejl, der er svære direkte at se i programmet -
netop fordi man "skjuler" den faktiske kode i en makro. Her er et eksempel på en makro, der
ser helt tilforladelig ud, men som kan bruges helt forkert:
#define kubik(i) i * i * i // giv kubiktallet på i
int a = kubik (2); // ok, a bliver 8
int b = kubik (a++); // b bliver sandsyndlgvis 710
// og a ender med at blive 11
Grunden til, at b ikke bliver 512 og a ikke 9 er, at udtrykket i 3. linie erstattes med
int b = a++ * a++ * a++;
Fælden er altså, at argumentet fremstår flere gange i makroen. Et andet eksempel involverer
operator-præcedens:
#define mul(a,b) a * b // multiplicér a med b
int c = mul(5, 7); // ok, giver 35
int d = mul(2 + 3, 4 - 5); // d bliver 9, ikke -5
Her ligger fælden i, at man ikke kan se, hvad makroen erstatter koden med. Den sidste linie
bliver nemlig erstattet med
int d = 2 + 3 * 4 - 5;
hvilket ikke fremgår tydeligt af et kald til mul. Husk derfor altid at omslutte makroargumenter
med parenteser:
#define mul(a,b) (a)*(b)
Problemet med makroer er, at de bliver præprocesseret, og dermed erstatter koden allerede før
C++-oversætteren ser koden. Det kan lede til fejl, som er svære at lokalisere - dels fordi en
makro ikke altid opfører sig på samme måde, og dels, fordi de tillader en omskrivning af
beskyttede navne i C++. Det er nemlig muligt at omdefinere den syntaktiske betydning af for
eksempel int, case og void. En Pascal-fanatiker vil måske glæde sig over følgende
makroer:
#define BEGIN {
#define END }
#define THEN
82 Præprocessering 2.10

hvilket vil gøre C++-programmer skrevet med disse makroer garanteret ulæselige for andre
programmører. Brug makroer med fornuft, og lad være med at bruge dem, hvis det
overhovedet er muligt - der er ofte bedre måder. Eksempler på brugbare makroer er:
#define newline

2.10.3 Betinget oversættelse
Betinget oversættelse betyder, at visse dele af kildeteksten skal springes over af oversætteren,
og dermed helt ignoreres. Til dette formål findes de seks direktiver til præprocessoren if,
ifdef, ifndef, elif, else og endif. De arbejder alle på konstante udtryk, som
enten er definerede konstanter eller makroer.
Et eksempel på brugen af disse direktiver er følgende fragment:
#define DEBUG 1
for (int i = 1; i < 1000; i++) {
#if DEBUG
cout

sandsynlig oversætterfejl i retning af "struktur complex allerede defineret". Med en
betinget oversættelse i filen complex.h kan vi undgå dette problem:
// fil: complex.h
#ifndef COMPLEX_H
#define COMPLEX_H
struct complex { double r, i; };
#endif
hvorved hele headerfilen springes over, hvis navnet COMPLEX_H allerede er defineret,
hvilket det første gennemløb af filen vil gøre. Læg mærke til, at det kun gælder for
oversættelsen af det aktuelle modul. Et alternativ til #ifdef og #ifndef er den binære
operator defined, som returnerer 0, hvis det efterfølgende navn ikke er defineret.
Forskellen til de ovennævnte direktiver er, at denne kan kombineres i mere avancerede
udtryk. For eksempel,
#if defined (UK_VERSION)
#define hello Welcome to PlanKalkül
#elseif defined (DK_VERSION)
#define hello Velkommen til PlanKalkül
#elseif defined (FR_VERSION)
#define hello Bienvenu a PlanKalkül
#else
#error SPROG IKKE DEFINERET
#endif
I dette eksempel ses også brugen af et særligt direktiv, #error, som standser oversætteren
med en fatal fejlmeddelelse, givet efter direktivet.
2.11 MERE OM POINTERE, VEKTORER OG REFERENCER
Det er muligt at udvikle programmer, der ikke benytter de afledte typer *, & og []
(pointer, reference og vektor), men det er hårdt arbejde og resulterer i langsomme
programmer. Derfor er det vigtigt at forstå, hvordan de afledte typer fungerer i relation til de
fundamentale typer samt til hinanden. Husk altid på, at en afledt type ikke i sig selv repræsenterer
en fundamental type, men at den på en eller anden måde refererer en type. En god
huskeregel er, at erklæringen på en afledt type syntaksmæssigt afspejler den senere brug af
typen.
2.11.1 Pointere
2.10.3 Betinget oversættelse 85

Hvis T er en type, vil erklæringen T* skabe en pointer eller en "pegepind" til en T. Sagt på
en anden måde vil en pointer-variabel indeholde adressen på en variabel af fundamental type.
Den dybereliggende grund til at bruge pointere er, at de har en direkte parallel til CPU'ens
adresseregistre - hemmeligheden bag C++'s effektivitet ligger ikke mindst i, at pointerarbejdet
er meget naturligt for en computer. En dreven C++-programmør vil ofte strukturere sit
program med pointere, fordi de er mere effektive i målkoden.
En pointer erklæres således † :
int* t; // t er en pointer til en int
t kan nu bruges som indirekte reference til enhver variabel af typen int. Dette kaldes også
dereference, og gøres med en fortegns-stjerne (*):
int i = 5; // i er en int, initér med 5
int* t = &i; // t er en int-ptr, ininiér med i's adresse
int j = *t; // j er en int, initér med den int, som
// t peger på (samme som i, altså 5)
Af ovenstående tre sætninger ses, at initiering af en pointer skal ske med en adresse. Dette
gøres med den dertil indrettede adresse-på operator (&) eller med tildeling fra andre pointere.
Når en adresse på et objekt tildeles en pointervariabel siger vi, at vi tager adressen på
objektet. Ligeledes ses det, at begrebet "en adresse" ikke skal tages så højtideligt, som
posvæsenet gør det. Den faktiske værdi, som t indeholder (adressen på i), er faktisk
uinteressant. Det interessant er, at den peger på i. Som programmører kan vi faktisk være
ligeglade med, hvor i befinder sig.
En pointer kan også indeholde adressen på andre pointere:
int i = 5; // i er en int, initieres med 5
int* t = &i; // t er en pointer til en int
int** v = &t; // v er en pointer til en pointer til en int
int j = **v; // j initieres med 5
Det ses, hvordan erklæringen og dereferencen af v syntaksmæssigt afspejler hinanden.
Pointere til pointere er et ikke sjældent fænomen, og kan iøvrigt udvides til flere
indirektioner.
2.11.2 Pointeraritmetik
Der er ikke meget sjov ved pointerne, hvis de ikke kan gøres til genstand for manipulation.
Det er tilladt at bruge addition, subtraktion samt op- og nedtællingsoperatorerne i forbindelse
† C-programmører vil her opdage en mindre ændring i de uskrevne kosmetiske regler for kildetekstens udseende.
Pointer-operatoren * binder sig i C++ per definition til typen, og ikke til variablen, hvor det i C er omvendt. Det er
ingenlunde et krav fra C++-standarden, at denne syntaks skal følges, men det er mere klart at selve variabelnavnet
står frit - int* x siger, at x er en int-pointer. Det er selvfølgelig stadig syntaktisk lovligt at skrive int *x.
86 Mere om pointere, vektorer og referencer 2.11

med pointere. Netop dette er en syntaksmæssig faldgrube i C++, fordi det er svært at se, om
det er en direkte eller en indirekte operation, der er tale om.
Hvis p er en pointer til en type T, vil udtrykket
p++;
sætte p lig adressen på det næste element, der følger umiddelbart efter det aktuelle i
maskinens adresserum. Det er programmørens ansvar, at dette element er defineret, hvilket
oftest sikres gennem vektor-erklæringer. Den skalære værdi, der lægges til pointeren,
afhænger kun og helt af størrelsen på T, dvs. den type, p peger på. Det er altså ikke tallet 1,
som adderes i et lineært adresserum, men det antal maskin-ord, som den pågældende type T
optager. Dette antal er maskinafhængigt, fordi C++ som beskrevet i afsnit 2.3 kun garanterer
forholdet mellem de fundamentale typer, og ikke absolutte størrelser. Men programmøren
skal ikke bekymre sig om størrelserne på int, double osv., idet oversætteren altid har den
nødvendige information om maskinens natur, og vil allerede på oversættelsestidspunktet
generere den korrekte værdi for additionen. Det skal dog nævnes, at addition af pointere
normalt ikke er tilladt, fordi den faktiske værdi, en pointer har, i realiteten enten er relativ til
et eller andet punkt i lageret under oversætterens kontrol eller er en absolut adresse i lageret
afhængig af maskinarkitekturen. Udtryk som
char* p, *q;
// ...
char* r = p + q; // fejl: hvad menes med dette?
er derfor ulovlige. Kun heltalskonstanter kan adderes til pointere. Pointeraritmetik benyttes
ofte i forbindelse med vektorer, fordi vektorerne automatisk giver os lineære lister af bestemte
typer, som pointerne kan arbejde i.
2.11.3 Vektorer
Undertiden er det nødvendigt at arbejde med lister af ensartede fundamentale typer. Overvej
følgende problemstilling: 100 måleværdier er opsamlet, og skal bruges i en statistisk beregning.
I stedet for at holde de 100 værdier i 100 separate variable, bruges en vektor af den
pågældende type:
double data [100]; // erklær 100 double'r
Objektet data har her typen "vektor af 100 doubler", og indeholder ligesom en pointer
adressen på det første element i data. Tilgang til de enkelte elementer i vektoren foretages
med følgende syntaks:
a = data [5]; // det 5 (egt. 6.) element i vektoren,
// det samme som a = *(data + 5)
2.11.2 Pointeraritmetik 87

En tilgang til et element i en vektor kaldes en indeksering, og indekset på en vektor af
størrelse n løber fra 0 til n-1. For vektoren data er de lovlige indeks-værdier altså fra 0 til
99 inklusive (100 ialt). Hvis vi vil beregne middelværdien af de opsamlede data, givet ved
m=
n
∑
i=1
kan vi indeksere os gennem vektoren i en løkke:
data
n
const n = 100; // antal elementer
double m = 0; // resultatet initieres med 0
for (i = 0; i < n; i++) // i løber fra 0 til n - 1
m += data [i] / n; // addér elementet over antallet
Vektorer tillader altså ligesom pointere en generalisering af klumper af data. Vektoren data
kaldes en endimensionel liste, fordi den repræsenterer en enkelt række af tal. Det er, som med
pointere, muligt at bruge vektorer af vilkårlige dimensioner:
int matrix [4] [4]; // 4 x 4 int'er
Det er ofte en hjælp at bruge række/søjle-terminologi i to- eller flerdimensionale vektorer.
matrix har her 4 rækker med 4 søjler af int's. Læg mærke til, at de enkelte vektorstørrelser
for hver dimension står i en separat klamme; de skal ikke separeres af et komme
indenfor en enkelt klamme. Kommaet bruges, som beskrevet i afsnit 3.3, til sekvensering.
Indeksering i en flerdimensionel vektor følger samme syntaks som erklæringen af en sådan:
int a = matrix [3] [1]; // 3. række, 1. søjle
Beregningen af adressen på det pågældende element foretages af oversætteren. Den faktiske
fundamentale variabel, som skal udledes af en indeksering, findes ved at gange indekset med
størrelsen på den fundamentale type, og addere dette til adressen på det første element i
vektoren. Resultatet kaldes en effektiv adresse, og udregnes hver gang, en indeksering foretages.
Selvom vektorerne automatisk kan indekseres og allokeres med de rigtige størrelser, har
C++ ingen indbyggede funktioner til manipulation af vektorerne selv. Derfor er det ikke
muligt at skrive
double matrix [4] [4]; // ok, 4 x 4 int's
double kopi [4] [4] = matrix; // fejl, kan ikke tildele
88 Mere om pointere, vektorer og referencer 2.11
i

for at kopiere en vektor til en anden. Her spiller pointere og vektorer sammen på en måde, der
bedst kan forklares ved, at en vektorerklæring i realiteten er en pointer, når den bruges i et
udtryk. Idet en pointervariabel ikke kan tildeles til en vektor er ovenstående udtryk ikke
korrekt. Typen på matrix forstås af oversætteren som en double*[]. Skal vektorer
kopieres, må det enten ske manuelt element for element, som i
for (i = 0; i < 4; i++) // rækkerne
for (j = 0; j < 4; j++) // søjlerne
kopi [i] [j] = matrix [i] [j]; // kopiér (i,j)
eller ved hjælp af en funktion i standardbiblioteket, der kopierer lageret lineært i en mundfuld,
som i sætningen
memcpy (kopi, matrix, sizeof (double) * 4 * 4);
som typisk er implementeret i højoptimeret form. Der henvises til kapitel 6, hvor de
væsentligste dele af standardbiblioteket gennemgås, blot er det vigtigt at huske på, at den
fysiske størrelse (i bytes eller maskinord) af en vektor afhænger af den type, den er
komponeret af. En char-vektor af n elementer er således typisk meget mindre end en
float-vektor af n elementer. Her kan sizeof-operatoren, som det sker ovenfor, anvendes
til maskinuafhængig determinering af størrelsen på vektoren - se afsnit 2.5.6.
2.11.4 Initiering af vektorer
Som beskrevet indeholder C++ ingen indbyggede metoder til manipulation af vektorer. Det er
dog muligt at initiere en vektor med start-værdier under erklæringen. Syntaksen varierer en
smule, og afhænger af den fundamentale type, som vektoren er afledt af:
char a [2] = { 'D', 'K' };
int tabel [6] = { 2, 4, 8, 16, 32, 64 };
double piSerie [3] = { 3.1415, 6.2831, 9.4247 };
Det er ikke lovligt at foretage initiering efter en vektor allerede er erklæret:
char a [2];
a = { 'D', 'K' }; // fejl, kan ikke kopiere
For vektorer af typen char er det muligt at initiere med en tekst-streng omsluttet af
anførselstegn. Dette er igen kun lovligt under erklæringen af vektoren, og kan illustreres med
følgende sætninger:
char a [4] = "OOP"; // ok: a -> 'O','O','P','\0'
2.11.3 Vektorer 89

char b [4];
b = "OOP"; // fejl, kan ikke tage adresse
// af literal, ejheller kopiere
Husk, at en streng i C++ altid ender i et "usynligt" nul, altså den faktiske værdi '\0'. Derfor
er vektoren a ovenfor erklæret til længden 4, selvom kun initieres med 3 char. Nulterminerede
strenge kaldes undertiden ASCIIZ-strenge (for ASCII-Zero), og det understreges,
at dette kun er en konvention i sproget. Programmøren kan til alle tider lade strenge slutte
med andre værdier, eller huske længden på den bestemte streng, men standardbiblioteket i
C++ samt den indbyggede initeringsfunktion til char-vektorer forudsætter ASCIIZ. Også på
systemer med andre tegnsæt er nul-terminering mest anvendt.
Det er dog ikke nødvendigt at specificere størrelsen på en vektor, hvis en tildeling kommer
umiddelbart efter. Oversætteren vil selv tælle de pågældende elementer og allokere det
nødvendige lager:
char a [] = "OOP"; // længde 4
int primtal [] = { 1, 2, 3, 5, 7, 11, 13 }; // længde 7
Multidimensionale vektorer initieres med samme syntaks, dog skal for hver ekstra dimension
tilføjes ekstra Tuborg-klammer udenom (læg mærke til hvor der er, og ikke er, kommaer):
char a [4] [4] = { // fire rækker á fire søjler
{ 1, 2, 3, 4 }, // første række
{ 2, 4, 6, 8 }, // anden
{ 3, 6, 9, 12 }, // tredie
{ 4, 8, 12, 16 } // fjerde
};
2.11.5 Vektorer og pointere
Mens man i visse tilfælde kan bruge vektorer uden pointere, er det svært at jonglere med
pointere uden samtidig at arbejde med vektorer. Pointeraritmetik forudsætter defineret lager,
som vektoren tilbyder i erklæringen. Pointere og vektorer spiller sammen på følgende
nøglepunkter:
• En pointererklæring er "tom" i den forstand, at den kun fortæller oversætteren om
den indirekte reference. Vektoren, derimod, tillader allokering af de indirekte data,
som får en plads i lageret.
• Pointerens værdi (adressen på det indirekte element) kan ændres dynamisk i et
programforløb (pointeraritmetik, afsnit 2.11.2), mens en vektor er statisk fra
erklæringsøjeblikket.
90 Mere om pointere, vektorer og referencer 2.11

• Pointeren tillader indeksering vha. []-operatoren i samme stil som vektoren. Uanset
hvor en pointer peger hen, vil en indeksering med n finde det n'te element fra
pointerens værdi.
• I en pointer-erklæring er en initiering tilladt med samme syntaks som i en vektorerklæring:
char* p = "C++"
• En pointer til type T kan uden videre tildeles en vektor af type T, hvorved
pointeren peger på det første element i vektoren. Det omvendte er ikke tilfældet, da
en vektor er statisk.
• Operatorerne new og delete blander pointeren og vektoren i en sætning for
henholdsvis resultat og udtryk.
Vektor-indekseringer erstattes ofte med pointere og udtryk med pointeraritmetik for at øge
effektiviteten af et program. Som beskrevet under i afsnit 2.11.13 vil en indeksering i en
vektor medføre en underforstået beregning af en effektiv adresse. En pointer-variabel
indeholder i sig selv en effektiv adresse, og med pointeraritmetik kan programmøren selv
kontrollere denne adresse dynamisk. Eksemplet med middelværdien kan således omskrives til
const n = 100; // antal elementer
double m = 0; // resultatet initieres med 0
double* p = data; // p peger på vektoren
for (i = 0; i < n; i++) { // i løber fra 0 til n - 1
m += *p / n; // addér elementet over antallet
p++; // næste element
}
For hver iteration gennem løkken bruges de successive elementer i vektoren uden at en
indeksering skal foretages for hvert gennemløb. p++ vil opdatere p til at pege på det næste
element i serien. Det er muligt at blande dereferencer med pointeraritmetik, sålænge der ikke
forekommer tvetydigheder. Den centrale sætning i ovenstående fragment er
m = *p++ / n;
hvor p bliver opdateret efter dereferencen til det aktuelle element i data. Det er altså p,
der er genstand for optællings-operatoren, og ikke den double, der ligger på adressen p.
Operatorernes præcedens placerer ++ over *, så hvis vi vil optælle den af p refererede
double, må vi skrive
2.11.5 Vektorer og pointere 91

(*p)++;
En pointer kan som nævnt tildeles en vektor, hvis de begge er erklæret som afledning af af
samme type. Da en pointer udgør en effektiv adresse, kan den ligeledes tildeles det n'te
element i en vektor ved at tage adressen på dette element. Pointeren peger således ind et sted i
vektoren. For eksempel,
int v [10]; // 10 heltal
int* p = &v [4]; // p peger på index 4 i v (nr. 5)
Negative indeks er tilladt, men sjældent brugt:
int i = p [-2]; // == v [2]
Hvis der er tale om multidimensionale vektorer, følger syntaksen de samme regler. Hvis v er
en todimensionel vektor af typen int, vil en tildeling af en pointer til en int til elementet
på række 0, søjle 0 være:
int* p = &v [0] [0];
altså adressen (&) på dette element. Fordi v allerede er en afledt type "vektor af vektor", som
kan sidestilles med en "pointer til pointer", kan vi fjerne den sidste indeksering samt adressepå
operatoren:
int* p = v [0];
Udtrykket v [0] giver i sig selv adressen på søjle 0. Den indre natur i v er altså, at den
første dimension (rækkerne) indeholder adresserne på start-punkterne i den anden dimension
(søjlerne). I tre- eller flerdimensionale vektorer gentages dette princip. Kun det sidste led i
vektoren specificerer indekset til et faktisk objekt i lageret.
Som beskrevet kan de normale additions- og subtraktionsoperatorer benyttes i forbindelse
med pointere. Hvis adresserne på vektor-elementer er operanter i et udtryk til en pointer,
arbejdes der med antallet af elementer og ikke med maskin-ord:
int v [] = { 1, 2, 3, 4, 5, 6, 7, 8 };
int a = &v [5] - &v [2]; // giver 3
int* p = v + a; // p peger på v [3];
En vigtig detalje i pointer-vektor forholdet er, at [] har højere prioritet end *. Derfor:
char* v [8]; // vektor af pointere
char (*p) [8]; // pointer til vektor
Operatorerne new og delete, som styrer den dynamiske allokering, bruger vektor-
92 Mere om pointere, vektorer og referencer 2.11

operatoren [], hvis mere end ét element skal allokeres. Eksemplerne i vektor-afsnittet
bruger alle statisk allokering, dvs. de initierende data står i objektkoden. Hvis der er tale om
dynamisk allokering ved hjælp af operatorerne new og delete, bruges samme syntaks:
char* p = new char; // bed om en enkelt char
int* a = new int [1000]; // bed om 1000 int'er
float** m = new float [4] [4]; // bed om en 4x4 floatmatrix
Her er altså en mindre, dog ikke uvæsentlig, forskel mellem statisk og dynamisk allokering.
Statisk allokering forudsætter vektoren, fordi den effektive adresse skal kendes på oversættelsestidspunktet,
mens dynamisk allokering kræver en pointer, fordi den effektive adresse
først kendes på kørselstidspunktet. Men da en statisk og dynamisk funktionelt identisk
erklæring og allokering bruges med helt samme syntaks og efter samme semantiske regler, må
pointere og vektorer siges at være næsten ens i brug.
Det vigtigste er altid at huske, hvilken type der arbejdes med. Afledte typer som pointere i
flere led kan være temmelig forvirrende, ikke mindst på grund af syntaksen, men det kan
undertiden hjælpe at gå baglæns i erklæringerne og udtrykkene (og fjerne stjernerne
midlertidigt) indtil en fundamental type eller struktur findes. Der skal være overenssemmelse
mellem antallet af indirektioner på højre og venstre side af en tildeling, ligesom normale
udtryk skal kunne behandles entydigt. Gå derfor altid tilbage til erklæringerne på pointerne og
vektorerne og se, om det aktuelle udtryk i realiteten (gennem dereferencer eller indekseringer)
resulterer i objekter af de samme typer.
2.11.6 Pointere og vektorer i funktioner
Som alle andre typer kan pointere og vektorer leveres til en funktion som et argument eller
parameter:
int strlen (char* p) { // tæl antallet af chars
int i = 0;
while (*p++) i++;
return i;
}
Et kald til strlen() vil overføre værdien af en pointer, altså en effektiv adresse, til p,
som videre bruges i funktionen. Heri ligger en af de væsentligste forskelle mellem vektorer og
pointere, idet en pointer som parameter vil overføre en adresse, mens en vektor som
parameter vil overføre hele indholdet af vektoren. Husk på, at kalde-konventionen i C++ er, at
værdien, ikke selve variablen, overføres til funktionen. I denne forbindelse er det interessant
at huske, at et parameter i en funktion er en egentlig variabelerklæring, så hvis vi erstatter
pointeren med en vektor, som i
int strlen (char p []) { // vektor i stedet for pointer
2.11.5 Vektorer og pointere 93

...
}
vil det ikke have nogen betydning for funktionen. Erklæringen af p som vektor er i denne
forbindelse helt ækvivalent som pointererklæringen. Pointere som parametre er meget
brugbare, fordi funktionerne kan skrives uden forhåndsviden om, hvor data befinder sig og
tillader en generisk behandling af dem.
Ligesom alle andre objekter har en funktion også en adresse. Når et C++-program foretager
et funktionskald, overføres kontrollen (CPU'ens programtæller) til den adresse, hvorpå
funktionen befinder sig. I C++ er det muligt at arbejde med adresser på funktioner, igen for at
opnå genericitet - blot her af kode. En pointer kan erklæres som pegende til en funktion, og
via pointeren kan funktionen så senere kaldes. Dette kan være ekstremt nyttigt i visse
situationer. Syntaksen for erklæring og reference er:
int funk (); // funk er en funktion
int (*p) (); // p er pointer til en parameterløs
// funktion, som returnerer en int
p = funk; // tildel p adressen på funk
int a = (*p) (); // kald funktionen som p peger på
En fordel ved pointere til funktioner er, at generiske funktioner kan bibeholdes, selv om et
program skal udvides. Det kan være nok at skrive en servicefunktion samt udvide en eller
flere datastrukturer. Da pointeren blot indeholder en adresse, kan den flyttes rundt på samme
måde som alle andre pointere. Læg mærke til, at når vi tager adressen på en funktion, skal vi
ikke benytte &-operatoren. Funktionsnavnet er i forvejen en pointer, vi blot bruger med ()operatoren.
typedef void (*PLOT) (int, int); // ptr til plot-funktion
void Circle (int x, int y, int r, PLOT p) {
for (double i = 0; i < 2 * PI; i += PI / r * 24)
(*p) (x + sin (i) * r, y + cos (i) * r);
}
Ovenstående rutine til cirkeltegning modtager udover centrum-koordinat og radius også en
adresse på en plot-funktion. Denne funktion behøver ikke nødvendigvis altid at være den
samme; i nogle tilfælde skal den kunne sætte prikker på en skærm, men i andre tilfælde måske
skrive på en plotter, printer eller på en disk. Det interessant er imidlertid, at funktionen
Circle() ikke behøver ændring, hvis plot-funktionen skal udskiftes. Genericiteten tillader
os altså at blæse på væsentlige dele af programmets logisk separerede dele og simpelthen
abstrahere på deres anvendelse.
2.11.7 Pas på med pointere
94 Mere om pointere, vektorer og referencer 2.11

Pointeren gør livet lettere hvis man mestrer den, men kan også frustrere en, som udfordrer den
for meget. Når et C++-program kører, er der absolut ingen anden end programmøren, som har
ansvaret for, hvad pointerne laver. Oversætteren er fuldstændig ligeglad med, om en pointer
peger på defineret eller udefineret lager, om den har taget fejl af en vektors størrelse eller om
den pludselig har fået trukket for meget fra. Har en pointer først fået en forkert adresse og
derefter bliver derefereret, er katastrofale følger næsten en garanti, fordi lager, som ikke er
defineret, bliver manipuleret af pointeren. Pas derfor på med pointerne - de har en tendens til
at få tingene til at gå galt. Her er et eksempel på, hvad der kan ske med en ukontrollabel
pointer:
void Nulstil (int* p, int laengde) { // nulstil vektor
do { // fortsæt...
*p++ = 0; // nulstil element
if (laengde = 0) break; // ups: tildeling!
laengde--;
}
}
Fejlen i ovenstående funktion Nulstil(), som tænktes at nulstille en vektor af int af en
specificeret længde er, at sammenligningen med laengde, der bruges som kontrol for
afbrydelse af løkken, er fejlagtig, idet der er tale om en tildeling. Det er ikke en syntaksfejl,
men en strukturel fejl som resultat af den typiske sammenblanding af tildelingsoperatoren =
og sammenligningsoperatoren ==. Sandhedsværdien i if-sætningen er den literale konstant
0, hvorfor den aldrig bliver sand og løkken fortsætter dermed for evigt. Evige løkker med
pointeraritmetik og indirekte tildeling er roden til alt ondt i C++, fordi der ikke er kontrol på
kørselstidspunktet af lovligheden af adresseringen. Vær derfor altid meget omhyggelig med
lokale løkker, der benytter pointere indirekte - det er næsten altid her, det går galt.
2.11.8 Pointere og vektorer i datastrukturer
Datastrukturer, som i C++ defineres med nøgleordet struct, har i modsætning til vektorer
mulighed for at indeholde objekter af vilkårlige typer. Derfor benyttes medlemsreferenceoperatorerne
. og -> i forbindelse med henholdsvis forekomster af og pointere til
strukturer. Det tillader at identificere det ønskede medlem i en struktur, uanset hvordan
strukturen iøvrigt er allokeret. Når pointeraritmetik bruges i forbindelse med datastrukturer,
vil oversætteren behandle strukturen som et objekt på samme vilkår som de fundamentale
typer. Addition til en pointer, der peger på en struktur af typen S, vil involvere størrelsen på
en forekomst af strukturen, altså sizeof (S). Vektorer af strukturer erklæres således:
struct Ansat {
char* navn;
2.11.7 Pas på med pointere 95

int afdeling, loenramme, alder;
};
Ansat personale [100]; // 100 statisk allokerede
Ansat* temp = new Ansat [5]; // 5 dynamisk allokerede
og bruges således:
void printAnsat (Ansat* a) {
cout

funktioner. Hvis to strukturer skal kunne referere hinanden, kan vi advare oversætteren om
den ene (sidste) af dem med en prototype:
struct Liste; // vi definerer den senere
struct Haegte {
char* Data; // indhold af hægte
Haegte* Naeste; // pointer til næste hægte
Liste* Rod; // pointer til en liste
};
struct Liste {
Haegte* rod; // første haegte i hægtet liste
};
2.11.9 Pointere og nul
En pointer, som har værdien 0 (nul) peger ikke på lovlige data. Derfor kan en nul-tildeling til
en pointer benyttes for at vise, at pointeren er "inaktiv". At pointeren er lig med nul i
kildeteksten betyder ikke nødvendigvis, at hver bit i pointeren er 0 - pas derfor på med binære
operatorer og pointeraritmetik. Standardbiblioteket indeholder en const, NULL, som er
erklæret som den faktiske værdi 0 som en unsigned long. NULL bør være den eneste
konstant, som en pointer nogensinde sammenlignes med.
2.11.10 Pointere til void
Det er tilladt at erklære en pointer til "uspecificeret lager" med datatypen void:
void* p;
Denne erklæring betyder, at p er en pointer til en adresse i lageret, og intet mere. Fordelen
ved void-pointere er, at man kan jonglere med pointere til lageret i funktioner, som ikke
kender til den endelige natur i et givet lagerområde. Det er ikke tilladt at dereferere p, fordi
oversætteren ikke ved, hvad den skal gøre med data på p's adresse. void* erstatter
char*, som blev brugt som generel pointer i C.
Et eksempel på brugen af void* er en funktion, som allokerer lager. Funktionen kaldes
med en angivelse af, hvor meget lager (i bytes), som søges allokeret, og returnerer en voidpointer
til det allokerede lager:
void* malloc (unsigned long bytecount) {
if (!bytecount) return NULL;
void* lager;
2.11.8 Pointere og vektorer i datastrukturer 97

... allokér lagerplads ved operativsystemkald
return lager;
}
Funktionen malloc() returnerer en void*, som råt og brutalt peger på det allokerede
lager. Hvis pointeren skal benyttes i dereferencer, må den typekonverteres, før den kan
bruges.
2.11.11 Pointere og typekonvertering
Typekonvertering af pointere betyder at dereferencen, ikke selve pointeren, ændrer type. Hvis
tptr er en pointer til en type T og sptr er en pointer til type S, kan tptr tildeles
sptr via en tvungen typekonvertering:
T* tptr;
S* sptr;
tptr = (T*) sptr;
Det er brugbart i programmer, som arbejder med diffuse data, som er struktureret på en måde,
der ikke kendes på oversættelsestidspunktet. Det er dog programmørens ansvar, at de data,
som befinder sig på pointerens adresse er defineret som den type, de bliver konverteret til -
ellers bliver resultatet udefineret. Husk også, at en typekonvertering af en pointer kun er en
semantisk manøvre; hverken de indekserede data eller selve pointeren ændrer sig.
En anden anvendelse er i forbindelse med void-pointere, der som nævnt ikke kan
derefereres. Funktionen alloker() ovenfor returnerer en void* til frit lager, men skal
typekonverteres, før dette lager kan manipuleres:
char* p = (char*) alloker (100 * sizeof (char));
int* q = (int*) alloker (100 * sizeof (int));
ansat* r = (ansat*) alloker (100 * sizeof (ansat));
Det ses altså, at en void-pointer skal konverteres eksplicit, før den kan tildeles en pointer til
en anden type † . Det modsatte er ikke tilfældet; en pointer til en vilkårlig type kan konverteres
til en void-pointer underforstået, hvilket er meget anvendeligt i funktioner, der arbejder
generisk med pointere.
2.11.12 Pointere og const
En pointer kan for eksempel erklæres som const med
†
Dette er en væsentlig forskel mellem ANSI C og C++ - ANSI C tillader underforstået konvertering fra en vilkårlig
pointer til en void-pointer.
98 Mere om pointere, vektorer og referencer 2.11

const char* p; // p er pointer til const char
Denne sætning erklærer p som pointer til en const char. Det er altså ikke pointeren
selv, men dereferencen af pointeren, som er konstant. Dette betyder, at p gerne må ændres,
så den peger på et andet lagerområde, men lagerområdet som p peger på, kan ikke
manipuleres gennem p. Eksempler:
const char data [10]; // 10 konstante char's
const char* p; // p er pointer til const char
p = data; // ok: tildel p data
p++; // ok: næste element i data
char c = *p; // ok: hent element fra data
*p = c; // fejl: p peger på konstant data
char* q = p; // fejl: q og p har ikke samme type
En konstant pointer til en type T har en anden type end en ikke-konstant pointer til en T. Det
er lovligt at tildele en ikke-konstant pointer til en konstant pointer, fordi det ikke overtræder
reglerne for tilgang, men det omvendte kan ikke foretages uden manøvrer. For eksempel,
char data [10];
const char* p = data; // ok: konverteres underforstået
char* q = p; // fejl: kan ikke konvertere
Dette skal ses i lyset af, at parametre i funktioner kan erklæres som konstante pointere
hvorefter funktionerne kan anvendes med både konstante og ikke-konstante pointere i selve
funktionskaldene. Hvis en konstant pointer partout skal konverteres til en ikke-konstant,
bliver vi nødt til at konvertere den tvungent:
char* q = (char*) p; // ok: vi bestemmer selv
Det understreges blot igen, at tvungen typekonvertering sætter sprogets indbyggede
typekontrolsystem ud af kraft og derfor sker på eget ansvar.
Pointere til konstante typer finder stor anvendelighed som parametre i funktioner, hvorved
det gennem funktionen sikres, at der ikke skrives til det lager, som pointeren peger på. Det
gør, at en fejl i forbindelse med en pointer, hvilket er en meget hyppig og svært lokaliserbar
fejl, lettere kan findes, fordi de funktioner, som erklærer den som konstant, ikke kan skrive til
det refererede lager:
void Berserk (const char* p) {
for (;;) *p++ = 0; // fejl: kan ikke skrive til *p
}
Af funktionen Berserk() ses det tydeligt, at en const char* ikke erklærer en pointer,
2.11.12 Pointere og const 99

som har en fast værdi, men derimod en pointer til et lagerområde, som har fast værdi.
Undertiden har man dog brug for det omvendte:
char data [10];
char* const p = data; // konstant pointer til char
Denne sætning erklærer p som konstant pointer til char, dvs. en pointervariabel, som ikke
kan ændre sin værdi og derfor peger fast til det samme lagerområde. Det er altså præcis det
omvendte af en pointer til en konstant type, da det nu er pointeren selv, som er konstant og
lageret som er ikke-konstant. Konstante pointere er for eksempel brugbare i hardwareafhængige
rutiner, hvor en bestemt adresse altid har den samme betydning. Konstante
pointere, ligesom referencer, skal initieres på samme tidspunkt de erklæres.
En konstant pointer til et konstant objekt kan naturligvis også erklæres:
const char* const p; = data;
hvilket forhindrer både tildelinger til p og til *p. Dette kunne være en skrive-beskyttet, fast
adresse i lageret, for eksempel et input-register i en I/O-enhed.
2.11.13 Referencer
Den afledte type en reference er et alias, dvs. et andet navn for et objekt. Referencer findes
ikke i ANSI C, men er nye i C++, og bruges primært i forbindelse med kommunikation til
brugerdefinerede typer. Referencevariable er en mellemting mellem forekomster og pointere,
idet de arbejder med adresser og alligevel bibeholder syntaksen fra normal ikke-indirekte
databehandling. Eller sagt på en anden måde: Ligesom pointere er referencer henvisninger til
andre objekter, og ligesom fundamentale variable kræver de ingen specielle dereferenceoperatorer.
Syntaksen for erklæring af reference-variable er simpel:
int a; // erklær et heltal
int& b = a; // b er et andet navn for a
Dette eksempel erklærer et heltal og en reference, og tildeler referencen adressen på heltallet.
Her er adressen af objektet underforstået, fordi referencetypen arbejder på et niveau, der
automatisk derefererer objektet. a og b er to navne for samme fysiske heltalsvariabel i
lageret, så:
a = 5;
vil også resultere i, at b får færdien 5. Faktisk er de to variable, fordi de peger på samme
lager, den samme variabel. Enhver tildeling til a vil reflekteres i b, og vice versa. Selvom
referencetypen minder meget om pointertypen, er der en væsentlig forskel. Mens en (ikke-
100 Mere om pointere, vektorer og referencer 2.11

konstant) pointer kan ændre værdi vilkårlige steder i koden efter erklæringen, skal en
reference initieres under erklæringen og kan ikke tildeles andre værdier efter denne. Når
referencen er tildelt en forekomst af samme type, bibeholder den altså denne værdi gennem
helt sit skop. Tildelinger til referencevariablen vil automatisk arbejde med en indirektion, så
det er kun data i lageret, der ændres, og ikke referencevariablen selv. En reference kan altså
siges at være en pointer til en konstant adresse i lageret.
Referencernes betydning for grænseflader til objekter diskuteres i detaljer i kapitel 3. Der er
imidlertid en anden anvendelse for referencer, som involverer funktioner, der har brug for at
ændre på data i den kaldende funktion. Den gængse kaldemetode i C++ (og i C) hedder callby-value,
altså hvor værdien af variablen sendes fra den kaldende til den kaldte funktion. Har
man brug for at ændre på eksterne data (i forhold til den kaldte funktion), må man overføre
adressen på disse. Dette gøres normalt med pointere, hvor den kaldte funktion modtager en
pointer til et objekt. Problemet er imidlertid, at funktionen skal dereferere pointeren, hver
gang, den bruges. Med referencer er det muligt at skabe et alias for en variabel i den kaldende
funktion, mens man drager fordel af den underforståede dereference, hver gang variablen
bruges. Denne kaldemetode har betegnelsen call-by-reference, altså hvor en reference til et
objekt, og ikke objektets værdi, er det væsentlige i det pågældende parameter.
Der er en vigtig forskel mellem pointere og referencer som parametre i funktioner. En
pointer skal modtage en adresse, og man kan derfor regne med, at den kaldte funktion
sandsynligvis manipulerer data i lageret omkring denne adresse. Med reference-parametre er
det ikke muligt at se, at den kaldende funktion ændrer på eksterne data. Syntaksen for
funktionskaldet er nemlig det samme. Denne forskel mellem pointere og referencer har mest
psykologisk betydning i udviklingen, fordi man kan lade sig snyde af en funktions
bemyndigelser hvad angår rettigheder til tilgang.
Når en funktion modtager et reference-parameter, bliver forekomsten et alias for den
afgivne parameter i den kaldende funktion. Reglerne for samtidig erklæring og tildeling
følges dermed. Følgende funktion
void Kvadrat (double& d) {
d *= d;
}
modtager en reference til en double, som den manipulerer. Kald til denne funktion vil
ændre på det objekt, som bruges i parameterlisten i den kaldende funktion. For eksempel,
double x = 2.5;
Kvadrat (x); // x == 6.25
Referencer kan blive temmelig komplicerede. For eksempel betyder følgende erklæring
void funk (char&*); // prototype...
void (&run) (char&*) = funk;
at variablen run er "en reference til en funktion, som tager en reference til en pointer til en
2.11.13 Referencer 101

char som parameter", samt at den tildeles funktionen funk(). Det giver en mere elegant
syntaks i forhold til pointere, fordi funktionen kan kaldes med en normal syntaks - overvej
forskellen på pointere til funktioner og referencer til funktioner i brug:
void (&r1) (char&*) = funk; // r1 refererer funk
void (*r2) (char&*) = funk; // r2 peger på funk
char* p;
// ...
r1 (p); // kald gennem reference
(*r2) (p); // kald gennem pointer
Referencer kan også bruges som returværdier fra funktioner, igen for at undgå den manuelle
dereference:
int& allokerInt () { // returnerer reference
return *new int; // allokerer forekomst
}
void f () {
int& a = allokerInt (); // alt pr. reference
}
Returværdier af referencetyper er særdeles brugbare, idet selve funktionskaldet kan bruges
med den samme syntaks som normale operationer på den type, den returnerer. Følgende
funktion tildeler en værdi til en intern vektor, som er statisk erklæret:
int& Tildel (int nummer) { // returnerer reference
static int vektor [10];
return vektor [nummer];
}
void f () {
Tildel (5) = 4; // tildel 5. (egt. 6.) element
}
Denne måde at bruge et funktionskald på venstre side af lighedstegnet finder sin største
brugbarhed i forbindelse med operator-overstyring, som beskrives i afsnit 3.5, da det kan
være fordelagtigt at lade en lvalue være en funktion.
Når en funktion returnerer en reference, skal man passe på, at den returnerede værdi ikke
mister sit skop, idet funktionen slutter. I så fald får variablen, der modtager referencen, en
udefineret værdi. Hvis vi for eksempel definerede vektoren vektor i funktionen
Tildel() uden static-nøgleordet (hvorved den bliver en automatisk variabel), vil
lageret, som vektor optager, blive frigivet til systemet lige inden, den returnerer til den
102 Mere om pointere, vektorer og referencer 2.11

kaldende funktion:
int& Tildel (int nummer) {
int vektor [10];
return vektor [nummer]; // ups! vektor mister skop her
}
Oversætteren vil sandsynligvis advare eller fejle ved en sådan returnering. Der er også en
anden faldgrube i arbejdet med referencer som parametre, nemlig at en typekonflikt, der kan
løses med en underforstået konvertering, vil skabe en reference til et midlertidigt objekt, som
bliver genereret af oversætteren. Under normale omstændigheder er det ikke noget problem,
men med referencer kan det få uheldige konsekvenser. For eksempel,
void f (long&);
int i = 1;
f (i); // genererer reference til temporær
Her vil kaldet til f() automatisk generere en midlertidig long som resultat af den
underforståede konvertering, men da funktionen modtager en reference, er det således til
denne temporære variabel, der bliver den faktiske parameter. Oversætteren vil normalt advare
om, at kalderens variabel bliver konverteret og ikke vil kunne manipuleres af funktionen.
Det skal også fremhæves, at referencer egentlig ikke er rigtige objekter. Alle operationer,
der foretages på en reference sker i realiteten på det objekt, der refereres gennem referencen
og ikke på referencen selv. Der er ingen mulighed for at manipulere med eller sammenligne
de fysiske referencer. En konsekvens af dette er, at det ikke er muligt at arbejde med pointere
til referencer og følgelig heller ikke vektorer af referencer:
int x,y;
int& rvek [] = { x, y }; // fejl: kan ikke lagre referencer
2.11.14 Typedefinitioner
Typedefinitioner med typedef minder om makro-definitioner, men udføres ikke af
præprocessoren. typedef tillader introduktion af et nyt navn, som vil ligne en ny type i
sproget. Her er dog kun tale om pseudo-typer, fordi typedef ikke har mange fordele frem
for en generel makro. Metoden bruges igen for at sikre konsistens samt øge læsbarheden
gennem kildefilerne, og har følgende notation:
typedef unsigned char BYTE;
BYTE kan herefter bruges som en unsigned char. Selve typedef-sætningen vil blive
analyseret semantisk af oversætteren, hvilket ikke gælder for makroer, og en fejl i selve
typedef-erklæringen vil blive rapporteret. Der er således større anvendelighed af navne,
2.11.13 Referencer 103

som er erklæret på denne måde, idet komplekse erklæringer kan foretages. For eksempel,
typedef int (*PTF) (double, double);
erklærer PTF som en typedefinition af en pointer til en funktion, som returnerer en int og
som har en parameterliste på to double-objekter. Det gør det nemmere at arbejde med en
kompliceret erklæring, når den er typedef'et, navnligt som parametre. Overvej forskellen
på
og
void DoSomething (int (*p) (double, double), double);
void DoSomething (PTF p, double);
C-programmører udnytter i stor stil typedefinitioner til navngivelse af datastrukturer, så de
ikke behøver skrive struct allesteds i programmet, hvilket er nødvendigt i C. Dette er ikke
nødvendigt i C++, da en strukturerklæring introducerer et egentligt typenavn.
2.12 I/O OG STANDARDBIBLIOTEKET
Sproget C++ har ingen indbyggede metoder for input og output i sproget, men lader disse
opgaver blive løst med sproget. Grunden er, at I/O er meget forskellig fra arkitektur til
arkitektur, for ikke at nævne fra applikation til applikation, og C++ er et sprog, som søget bort
fra hardware-afhængighed. Med sproget selv som værktøj kan metoder til I/O skabes og
tilpasses forholdene.
C++ har imidlertid, ligesom C, et standardbibliotek til I/O. Biblioteket iostream indeholder
definitioner af klasser, funktioner og metoder til varetagelse af I/O †
. Dette afsnit beskriver
anvendelsen af standardbiblioteket; funktionaliteten uddybes i de næste kapitler.
Nøglekonceptet i C++'s standard-I/O er en strøm, som på engelsk hedder en stream. En
strøm er en slags rørledning, i hvilken man kan hælde data eller suge data op. Der findes fire
standard-strømme, én for input, én for output én for fejl-output og en for fuldt bufferet fejloutput.
Applikationen kan skrive og læse fra de tre standard-strømme uden at bekymre sig om
hvor data kommer fra eller er på vej hen. De strøm-erklæringer, der findes i headerfilen
er helliget konvertering fra fundamentale typer til tegn, samt omvendt, så
data kan ind- og udlæses fra og til tastaturet, skærmen, disken og så videre, helt i samme
filosofi som C-biblioteket stdio.h. I dette afsnit beskrives kun funktionaliteten i standardbiblioteket,
mens dets opbygning gennemgås i kapitel 6, hvor også udvidelser af databehandlingen
fra fundamentale til bruger-definerede typer forklares - dog skal det nævnes, at det
gamle C-bibliotek udmærket kan anvendes sammen med C++.
† Denne bog beskæftiger sig med AT&T's version 2.0 af stream-biblioteket. Der er et mindre antal afvigelser fra
tidligere versioner af dette bibliotek.
104 Mere om pointere, vektorer og referencer 2.11

En strøm er i mere klare termer en abstraktion af data-flow fra en kilde til en destination. To
generelle strømme er derfor defineret i standard-headerfilen , nemlig
istream (for input) og ostream (for output). Disse er to specielle datatyper, og indgår i
en større sammenhæng i biblioteket. Der er fire standard-definerede forekomster af
istream og ostream, nemlig strømmene
cin standard-input (svarer til stdin)
cout standard-output (svarer til stdout)
cerr standard-error (svarer til stderr)
clog standard-error med buffering (ingen ækvivalens i stdio)
cin, cout og cerr svarer til filbeskrivelserne 0, 1 og 2 på de fleste systemer. I dette
afsnit koncentrerer vi os om de helt centrale anvendelser af disse kanaler, så senere eksempler
kan absorberes, mens den indre virkemåde og mere avancerede og perifere brug beskrives i
kapitel 6.
2.12.1 Output
For en C-programmør vil følgende sætning se underlig ud:
cout

en anden operator, nemlig >>, til "hent følgende data". Læse-sætninger ser derfor således ud:
cin >> a;
og uddybes med "læs a fra cin", som er meget tæt på C-funktionskaldet (hvis a er en
int):
scanf ("%d", &a);
Læg igen mærke til, at vi ikke behøver fortælle cin om typen af a, mens vi skal fortælle
scanf() om både typen af og adressen på a.
2.12.3 Filbaseret I/O
Filmanipulation er nært beslægtet med standard-I/O, og startes med en erklæring af en type
ifstream (for input), ofstream for output eller fstream for bidirektionel I/O, alle
defineret i headerfilen . Følgende funktion kopierer en fil:
void Kopier (char* fra, char* til) {
ifstream fra_fil (fra); // en ny input-kanal
ofstream til_fil (til); // en ny output-kanal
char element;
while (fra_fil) { // sålænge der er data
fra_fil >> element; // hent et tegn
til_fil

2. Forklar betydningen af følgende prototyper:
char* f (char a);
char* g (char* (*b)(char d));
char** h (int i ...);
char j (char& k);
char l (char&* m);
3. Skriv strukturer til at beskrive følgende:
a) en hægte i en hægtet liste,
b) en hægte i et binært træ,
c) en hægte i en dobbelt kø (data udtages fra begge sider)
d) en n-vejs hægte i et n-vejs træ.
4. Giv eksempler på, hvornår rekursive funktioner bruges.
5. Hvad er resultatet af følgende udtryk, givet a == 1, b == 2 og c == 3:
a * b - c
a - b * c
a * b++ * c
-a --b --c
--a ---b ---c
a | b & c
c ^ a
++a & --c
6. Skriv funktioner, der gennemløber datastrukturerne fra opgave 2-3. Hvad er
forskellen på de forskellige gennemløb?
7. Forklar naturen af de forskellige lagringsklasser i C++.
8. Forklar begreberne literale konstanter og symbolske konstanter og diskutér
forskellene og anvendelsesområderne. Hvorfor tror du, at den klassiske C-standard
ikke omfattede symbolske konstanter?
9. Skriv erklæringer af følgende objekter:
a. pointer til char,
b. pointer til vektor af char,
c. vektor af pointere til char,
2.12.3 Disk I/O 107

d. pointer til funktion, der returnerer char,
e. reference til pointer til char,
f. reference til parameterløs funktion, der returnerer char.
10. Forklar begrebet implicit typekonvertering og overvej, hvorfor det har betydning i et
sprog som C++. Diskutér også, hvorfor mange andre computersprog ikke har
mulighed for eksplicit typekonvertering.
11. En reference er et andet navn for et objekt. Hvordan tror du, en reference i realiteten
bliver behandlet i programmet?
12. Hvis du fik til opgave at skrive et program, der skulle kunne køre på tre forskellige
maskiner og operativsystemer, hvilke faciliteter i C++ ville du drage nytte af hvad
angår både de maskinuafhængige dele og de maskinafhængige dele?
2.14 REFERENCER OG UDVALGT LITTERATUR
Der findes efterhånden en del gode engelsksprogede bøger om C++. Den endelige definition
på sproget er [Stroustrup 91], en komplet omend svært læselig bog. Bjarnes bog, som netop er
udkommet i anden udgave, læses bedst sammen med en mere pædagogisk anlagt bog, som for
eksempel [Lippman 91], som er en begynderbog. [Berry 88] indeholder mange eksempler på,
hvorfor og hvordan C++ hæver sig over C med mange eksempler på ulemperne ved C. Den
har også beskrivelser af C++ under specifikke miljøer som DOS og UNIX. En ANSIdefinition
af programmeringssproget C findes i [Kernighan 88]. For oversætterdesignere
indeholder [Ellis 90] mange gode eksempler på kodegenerering af de særlige sprogkonstruktioner
i C++.
108 Opgaver til kapitel 2 2.13

Dataabstraktion
Som beskrevet i indledningen er et af de store problemer i programudvikling at
få samling på programmerne, så de er lette at overskue, bruge, genbruge og
ikke mindst læse. Ved abstraktion af data forstås den teknik, som abstraherer
eller isolerer alle dele af et program (både kode og data) i moduler, som har
med et bestemt område at gøre samt definerer en passende grænseflade til disse
moduler. I C++ er en sådan isolation ensbetydende med en introduktion af nye
datatyper, der skræddersys til programmerne, som skal bruge dem.
3.1 INTRODUKTION
Alle programmeringssprog indeholder forskellige former for dataabstraktion. Det er en stor del af
ideen bag overhovedet at bruge et generelt programmeringssprog fremfor for eksempel
assembler. Hvis vi adderer to heltal er vi ikke interesserede i, hvordan programmet i sidste ende
rent teknisk foretager denne addition; vi befinder os på et abstraktionsniveau, hvor vi kan være
ligeglade. Adderer vi to decimaltal, er vi ligeledes uinteresserede i, hvordan oversætteren
behandler decimaltal. Typisk vil oversætteren klare både allokering af lager til forekomster af de
indbyggede typer og fortolkninger af betydningerne af de forskellige operatorer, som vi påfører
forekomsterne. Som programmører skal vi ikke fortælle hvad der rent faktisk skal ske med
forekomster af de fundamentale datatyper, det arbejde har oversætter-designeren gjort for os.
C++ tillader os at udvide sproget og introducere nye "abstrakte" datatyper ved at definere,
hvordan de skal administreres og behandles. At en datatype er "abstrakt" betyder ikke, at dens
definition er tvetydig på nogen måde. Termen bruges til at indikere, hvordan man som
programmør kan abstrahere et koncept fra et kompleks af programdetaljer ind i en datatype (hvis
semantik er defineret udenfor oversætteren) samt at understrege forskellen til de indbyggede
datatyper. En abstrakt datatype er, hvis den er ordentligt skrevet, lige så reel som de indbyggede.
Når vi som programmører tænker på datatyper, mener vi for det meste de indbyggede
fundamentale typer, som sproget tilbyder til repræsentation af heltal, strenge, kommatal osv.
Virkeligheden forholder sig imidlertid sådan, at der er mange andre typer end de, vi finder
indbygget i sproget. Ethvert program bygges op i to faser: først defineres alle repræsentationer af
data samt funktioner til manipulation af data, og dernæst skrives selve applikationen, som bruger
disse data og funktioner. Faktisk er den første fase en definition af specialiserede typer, fordi den
handler om de nederste, mest detaljerede lag i en applikation som opererer på et lavt
2.12.3 Disk I/O 109
3

abstraktionsniveau. Anden fase er det øverste, mere brugerorienterede lag, som kalder og bruger
typerne fra et højere abstraktionsniveau. De fleste programmer arbejder altså med en eller anden
form for strukturering af data, som, set helt fra oven, repræsenterer en type - eller klasse - fra det
virkelige liv. Denne klassifikation er grundlaget for arbejdet med dataabstraktion.
Når vi nærlæser et program i et proceduralt orienteret sprog, fremgår disse klasser ikke så klart i
selve koden. C's struct og Pascals record giver os mulighed for at kombinere en
mangfoldighed af data under et samlet navn - en datastruktur - som giver os to umiddelbare
fordele. For det første kan strukturen behandles samlet under dette navn, for eksempel som
parameter i en funktion, og for det andet kan vi arbejde med de individuelle medlemmer af
strukturen, for eksempel i en funktion, som behandler strukturen på en bestemt måde. Afhængigt
af abstraktionsniveauet kan vi altså arbejde enten på eller i datastrukturer, som vi behager og på
den måde afspejler en datastruktur et koncept fra den virkelige verden, som gør dem meget
brugbare i opbygningen af programmoduler.
Desværre, som vi skal se senere, giver datastrukturer kun brugeren mulighed for at abstrahere
data. Programmet skal stadig skrives med både helheder og detaljer i tankerne, når
datastrukturerne behandles. Det udmønter sig i implementations-problemer, fordi den logiske
sammenhæng mellem data og kode bliver eksplicit og derfor svag. Dataabstraktion, som vi finder
i sprog som Ada, Modula-2 og C++, kombinerer datastrukturen med de funktioner, som skal
arbejde i den på en logisk måde. Når typerne defineres i første fase af programmeringen,
repræsenteres de dermed i en klasse med både midler (data) og måder (kode), og giver en bedre
grænseflade til anvendelsen af typen i anden fase.
Denne grænseflade giver os også bedre mulighed for at integrere typerne i underliggende
programbiblioteker. De brugerdefinerede typer i C++ er nemlig skalérbare i den forstand, at de
med en enkelt definition kan benyttes i mange forskellige sammenhænge. Det betyder i praksis, at
komplicerede opgaver som I/O kan integreres med de brugerdefinerede typer på en måde, hvor
både typer og I/O-subsystemet kan skiftes ud, uden at der skal rettes i koden for nogen af delene.
3.1.1 Biblioteker
Alle programmeringsmiljøer har en form for bibliotek, som indeholder ofte brugte datastrukturer
og funktioner til behandling af disse. Bibliotekerne giver os flere fordele: de sparer tid, fordi vi
ikke behøver "genopfinde hjulet" hver gang, vi skriver en ny applikation, og de giver en vis
sikkerhed for, at standard-rutiner er gennemtestede og virker.
Funktionsbiblioteker, som vi kender dem fra C og Pascal, består af en samling af globale navne
på datastrukturer og funktioner med parameterlister, som kan bruges i alle programmer, der
henviser til biblioteket. Vi kalder forfatteren af en biblioteksfunktion en udbyder, og brugeren af
funktionen en klient af biblioteket. Udbyderens funktioner arbejder på de individuelle
medlemmer af strukturerne, og klienten arbejder på strukturerne som helhed. På den måde hæver
klienten sig et abstraktionsniveau over udbyderen og bruger dermed biblioteket modulært.
Hvordan bruges et bibliotek så rent praktisk? Det er hovedsageligt oversætterens
ansvarsområde: klienten angiver i sit program, at en bestemt biblioteksfunktion ønskes benyttet,
og oversætteren sørger for at samle klientens kode med bibliotekets kode. Alt hvad klienten
behøver at vide er syntaksen i referencen (samt selvfølgelig hvad funktionen gør). Et
funktionsbibliotek har imidlertid nogle væsentlige ulemper. Det er meget svært at udvide en
110 Introduktion 3.1

eksisterende funktion, hvis den ønskede virkning skal ændres bare en smule. Oftest omskrives
hele funktionen i klientens applikation, hvorved en stor del af fordelen ved biblioteket går tabt. Et
andet problem er, at store biblioteker med mange globale funktioner bliver svære at overskue.
Med over 1000 forskellige navne på funktioner og datastrukturer er det svært at huske navnet på
lige præcis den, man ønsker at benytte. I mere specialiserede systemer med multiprogrammerede
operativsystemer, får funktionerne tillige problemer med at holde rede på statiske lokale data. Det
kræver en semaforstyring, som skal styres fra alle de individuelle biblioteksfunktioner eller fra
ethvert klientprogram.
3.1.2 Grænseflader og informationsskjul
Kernen i problemet viser sig at være grænsefladen mellem klientens program og biblioteket.
Klienten hverken ønsker eller bør have med detaljerne i udbyderens bibliotek at gøre. For det
første tabes abstraktionen, hvorved koden bliver svær at forstå i relation til det problem, det skal
løse, og for det andet er der stor risiko for introduktion af fejl, da klienten ikke nødvendigvis ved
alt om bibliotekets struktur.
Med abstrakte datatyper skjuler vi implementationen fra klienten, som i de fleste tilfælde slet
ikke har adgang til at manipulere typen direkte. Filosofien kaldes informationsskjul (på engelsk
data hiding) og sørger for at ridse en klar grænseflade mellem udbyderdata og klientkode op.
Klienten er tvunget til at bruge udbyderens funktioner til manipulation af typens indre. Dermed
kan en konsistensfejl i en types indre data føres tilbage til udbyderens kode, da kun den har
mulighed for at ændre dem. At lokalisere en fejl bliver dermed et mindre problem, specielt i store
projekter.
I dette kapitel skal vi se, hvordan C++'s faciliteter for design af abstrakte datatyper gør livet
lettere for klienten. I kapitel 4 beskæftiger vi os med udvidelser af disse typer. Som beskrevet i
afsnit 2.2 ligger grænsefladen mellem klient og udbyder rent praktisk i en header-fil, som gør
oversætteren bekendt med navne, parameterlister osv. Selve bibliotekskoden findes i objekt-filer,
som oversættes separat og lænkes sammen på et senere tidspunkt.
3.2 ET EKSEMPEL-PROBLEM
I erkendelse af, at den eneste rigtige måde at lære et nyt programmeringssprog at kende er at
skrive programmer i det, opstiller vi et eksempel på et problem, som vi vil løse. For klart at
markere forskellene mellem proceduralt orienteret programmering og programmering med
abstrakte datatyper, starter vi med et eksempel i standard C - som nævnt i indledningen af dette
kapitel giver de fleste programmeringssprog os allerede en vis form for abstraktion:
/* eksempel 3-1: kommatals-aritmetik */
#include
#include
3.1.1 Biblioteker 111

void main () {
double a, b, c;
a = 5.9;
b = 2.7;
c = a * b - 4.8;
printf ("%lf", c);
}
Dette C-program erklærer 3 double'r, tildeler værdierne 5.9 og 2.7 til a og b, tildeler derefter
resultatet af udtrykket a gange b minus 4.8 til c og kalder derefter C's printf()-funktion
og udskriver c. Programmet vil skrive tallet 11.13. Dette lille program arbejder med den
fundamentale type double, som findes både i C og i C++. Nu antager vi, at vi har brug for at
foretage beregninger med komplekse tal, som ikke findes i sproget som type, hvorfor vi må
simulere den i vores egen software. Kravet er, at en klient skal kunne bruge en behændig syntaks
for manipulation af og beregning med komplekse tal, herunder aritmetik og udlæsning.
Biblioteket, som skal behandle forekomster af komplekse tal på lavt niveau, skal indeholde
funktioner af følgende slags:
• Allokering af et komplekst tal,
• Initiering af et komplekst tal,
• Tildeling af et komplekst tal,
• Addition af to komplekse tal,
• Subtraktion af to komplekse tal,
• Multiplikation af to komplekse tal,
• Udskrift af et komplekst tal og
• Oprydning efter endt brug af et komplekst tal.
Denne eksempel-problemstilling og foreslåede fremgangsmåde er meget typisk i C- og C++miljøer,
idet der lægges meget vægt på modulariteten af den kode, der skal behandle den ny
datastruktur.
3.2.1 En løsning i C
Et klassisk C-funktionsbibliotek indeholder makrodefinitioner (typedef-erklæringer) af
datastrukturer samt funktioner, som arbejder med disse. For typen COMPLEX † skal vi bruge et
antal funktioner, der er vist i tabel 3-1.
Funktionsnavn Beskrivelse
alloc_complex()
assign_complex_a()
Allokér en COMPLEX
Initiér en COMPLEX med reel og imaginær del
† Det er en uskreven konvention i C, at typedef'ede navne skrives med versaler.
112 Et eksempel-problem 3.2

assign_complex_b()
add_complex()
sub_complex()
mul_complex()
print_complex()
free_complex()
Initiér en COMPLEX med en anden COMPLEX
Addér to COMPLEX'e
Subtrahér to COMPLEX'e
Multiplicér to COMPLEX'e
Udlæs en COMPLEX
Deallokér en COMPLEX
Tabel 3-1: Funktionsoversigt i C-løsningen.
Funktionserklæringerne - prototyperne - placeres i en headerfil, complex.h, mens
implementationerne skrives i en kildefil, complex.cpp. Klienten benytter sig kun af
headerfilen og lænker sin kode til den allerede oversatte implementation fra kildefilen,
hvorved der til en vis grænse kan abstraheres fra denne konkrete implementation.
Specifikationen af dette bibliotek, headerfilen, er vist i eksempel 3-2a.
/* complex.h
* eksempel 3-2a: En C-specifikation af komplekse tal
*/
typedef struct { /* datatypen COMPLEX */
double re, im; /* reel og imaginær del */
} COMPLEX;
COMPLEX *alloc_complex ();
void free_complex (COMPLEX*);
void assign_complex_a (COMPLEX*, double, double);
void assign_complex_b (COMPLEX*, COMPLEX*);
void add_complex (COMPLEX*, COMPLEX*, COMPLEX*);
void sub_complex (COMPLEX*, COMPLEX*, COMPLEX*);
void mul_complex (COMPLEX*, COMPLEX*, COMPLEX*);
void print_complex (COMPLEX*);
Header-filen complex.h indeholder en typedef af en COMPLEX, som består af to
double'r samt 6 funktioner til manipulation af denne type. Implementationen af biblioteket
findes i eksempel 3-2b.
/* complex.c
* eksempel 3-2b: en C-implementation af et komplekst tal
*/
#include /* udskrift-funktioner mv. */
#include /* lager-allokering mv. */
#include "complex.h" /* specifikation på COMPLEX */
3.2.1 En løsning i C 113

COMPLEX *alloc_complex () {
COMPLEX *ny = (COMPLEX*) malloc (sizeof (COMPLEX));
ny->re = 0, ny->im = 0;
return ny;
}
free_complex (COMPLEX* a) {
free (a);
}
COMPLEX *assign_complex_a (COMPLEX* a, double r, double i) {
a->re = r, a->im = i;
return a;
}
COMPLEX *assign_complex_b (COMPLEX* a, COMPLEX* b) {
a->re = b->re, a->im = b->im;
}
COMPLEX *add_complex (COMPLEX* a, COMPLEX* b, COMPLEX* c) {
c->re = a->re + b->re, c->im = a->im + b->im;
return c;
}
COMPLEX *sub_complex (COMPLEX* a, COMPLEX* b, COMPLEX* c) {
c->re = a->re - b->re, c->im = a->im - b->im;
return c;
}
COMPLEX *mul_complex (COMPLEX* a, COMPLEX* b, COMPLEX* c) {
c->re = a->re * b->re - a->im * b->im;
c->im = a->re * b->im + a->im * b->re;
return c;
}
void print_complex (COMPLEX* a) {
printf ("(%f,%f)", a->re, a->im);
}
Denne implementation benytter sig i særdeleshed af pointere til strukturer (afsnit 2.11.8).
Funktionen alloc_complex() reserverer plads til en COMPLEX og returnerer en pointer
114 Et eksempel-problem 3.2

til denne mens free_complex() frigiver lageret, som er optaget af en bestemt
COMPLEX til systemet. add_complex(), sub_complex() og mul_complex()
foretager en aritmetisk operation på to COMPLEX'er og returnerer resultatet i en tredie.
print_complex() udskriver en COMPLEX. Som det ses, skal de fleste af funktionerne
have en adresse som parameter.
En klient af complex.c, som benytter sig af funktionerne og typen COMPLEX til en
simpel udregning kan se ud som i eksempel 3-2c.
/* cmpxtest.c
* eksempel 3-2c: test af C-biblioteket med komplekse tal
*/
#include
#include "complex.h"
main ()
{
COMPLEX *a = alloc_complex ();
COMPLEX *b = alloc_complex ();
COMPLEX *c = alloc_complex ();
COMPLEX *d = alloc_complex ();
COMPLEX *temp = alloc_complex ();
assign_complex_a (a, 5.8, 3.7);
assign_complex_a (b, 2.1, 4.4);
assign_complex_a (c, 6.9, 8.7);
print_complex (a); printf (" * ");
print_complex (b); printf (" - ");
print_complex (c); printf (" = ");
mul_complex (a, b, temp); /* dvs. *temp = *a * *b */
sub_complex (temp, c, d); /* dvs. *d = *temp - *c */
print_complex (d);
free_complex (a);
free_complex (b);
free_complex (c);
free_complex (d);
free_complex (temp);
}
Ovenstående C-program producerer følgende korrekte output:
3.2.1 En løsning i C 115

(5.8,3.7) * (2.1,4.4) - (6.9,8.7) = (5.28,7.58)
3.2.2 Gennemgang af C-løsningen
Dette lille bibliotek af C-funktioner udmærker sig ved sin modularitet. Alle funktioner, som
arbejder direkte på de individuelle medlemmer af datastrukturen COMPLEX er indeholdt i
implementationsfilen complex.c, mens klientens program alene arbejder med pointere til
forekomster af strukturen som helhed. Vi ser altså, at C, hvis man overholder visse regler for
struktur, støtter ideen om modulærprogrammering, fordi det tillader os at abstrahere fra alt
andet end headerfilen.
Hvori består så de programmeringstekniske problemer med en sådan implementation? Her
skal fokuseres på to aspekter, som har stor betydning for værdien af funktionsbiblioteket:
• Grænsefladen mellem specifikationen af typen COMPLEX og applikationen, som
arbejder med forekomster af den. Hvilke operationer skal klienten af COMPLEX
benytte, og er disse arrangeret på en fornuftig måde?
• Udvidelsesmulighederne for og vedligeholdelsen af typen COMPLEX. Er det let eller
svært at skrive nye funktioner til manipulation af forekomster? Kan disse integreres i
funktionsbiblioteket? Hvad er risici for introduktion af fejl?
Med disse i baghovedet kan vi opremse et antal konkrete problemer med typen COMPLEX:
• Syntaks. Manipulation af forekomster af COMPLEX gøres gennem specialiserede
globale funktioner, som kaldes fra applikationen, for eksempel kaldet til
mul_complex() i main(). Hvis to forekomster af COMPLEX skal
multipliceres, kan den sædvanlige syntaks, som vi kender fra de fundamentale typer
float, int osv., ikke bruges. Det gælder også erklæringer, og typen har med
andre ord en grænseflade til applikationen, som er helt egenartet. Det gavner mindst
af alt læsbarheden af koden.
• Semantik. Applikationen må i større beregninger selv varetage visse semantiske
opgaver. For eksempel er sprogets præcedens i forbindelse med operatorer sat ud af
spillet, fordi syntaksen er vendt fra de normale operatorer til eksplicitte
funktionskald. I main() i eksempel 3-2 udføres (rent semantisk) operationen d =
a * b + c på de komplekse tal, men multiplikations-operatorens højre prioritet i
forhold til addition må applikationen selv varetage. Funktionskald til manipulatorfunktioner
i complex.c skal med andre ord foretages i en bestemt rækkefølge.
• Lageradministration. Det er op til applikationen at sørge for administrationen af
lageret i tilknytning til forekomster af COMPLEX. Glemmer applikationen kaldet til
alloc_complex(), vil efterfølende manipulationer arbejde med en uinitieret
pointer med sikre katastrofale følger. Sproget giver ingen hjælp i form af advarsler
116 Et eksempel-problem 3.2

om manglende initiering. Ligeledes hvis applikationen ikke frigiver hver eneste
forekomst med kald til free_complex() når pointerens skop render ud, vil
lageret fyldes op med "gamle" data. De fundamentale datatyper understøttes af
sproget og allokeres/frigives automatisk. Det er selvfølgelig muligt at arbejde med
forekomster af COMPLEX i funktionskaldene, hvorved alloc_complex() og
free_complex() bliver unødvendiggjort, da C i så fald selv varetager allokering
og deallokering. Straffen er, at hele datastrukturen kopieres fra den kaldende til den
kaldte funktion. I dette eksempel ville to double'r kopieres, hvilket ikke synes
meget, men hvis vi for eksempel arbejdede med matricer af 6 gange 6 = 36
double'r, ville det tage lang tid at kalde en simpel funktion. Derfor arbejdes
generelt med pointere i C.
• Mellemregninger. Applikationen skal stå for alle eventuelle mellemregninger i
flerledede udtryk med forekomster af typen COMPLEX, hvortil der må bruges
midlertidige eller temporære variable. temp er et eksempel på dette i main().
Udtryk med forekomster af fundamentale typer oversættes med implicitte
midlertidige variable, som genereres og manipuleres af oversætteren. De midlertidige
variable i main() kan ikke indeholdes i funktionsbiblioteket, fordi de skal dele
arbejdsvariablenes skop - og det ligger i applikationen.
• Dokumentation. Idet grænsefladen til complex.c indeholder et antal globale
funktioner, hvis navne og parameterspecifikationer skal kendes af applikationen,
kræver COMPLEX en omfattende dokumentation i anvendelsen af datatypen. Det
kræver ydermere en del disciplin at overholde samme regler for brugen af datatyper i
et funktionsbibliotek, hvis nye typer (for eksempel matricer eller vektorer)
introduceres. Reglerne for funktionernes navne og parametre skal følges af
designeren af biblioteket, og her hjælper sproget ikke spor.
• Udvidelsesmuligheder. En udvidelse af biblioteket kan være svær, i visse tilfælde
umulig, hvis det eksisterende bibliotek ikke lægger den rette platform til grund. Hvis
vi for eksempel vil tilføje en funktion div_complex() til implementationen af
COMPLEX-typen, skal en ny funktion skrives og dokumenteres. C sikrer imidlertid
ikke, at implementationen og specifikationen har konsistens, hvilket gør en sådan
udvidelse genstand for fejl. Det bliver værre endnu, hvis vi får lyst til at udvide
biblioteket med funktioner til operationer mellem forekomster af typen COMPLEX
og den fundamentale type double (en meget relevant udvidelse). Vi må udvide
med en funktion for hver COMPLEX/double-operation, som alle skal have et unikt
navn. Addition mellem en COMPLEX og en double erklæres for eksempel med
navnet add_cmplx_dbl(), multiplikation med mul_cmplx_dbl() osv. Når
vi så også vil kunne operere mellem COMPLEX og int, float og long samt
eventuelle andre typedef'ede typer, får vi hundredevis af forskellige funktioner,
som vi skal huske navnene og parameterindholdet af. Dette er grunden til, at Cbiblioteker
har funktioner med underlige navne.
3.2.2 Gennemgang af C-løsningen 117

• Sikkerhed. Mens fordelen med opdelingen af COMPLEX-typen og de relaterede
funktioner i et separat modul er at skjule implementationen fra klienten, er det
imidlertid et problem at en hvilkensomhelst klient har adgang til de "indre" data, som
han eller hun alligevel aldrig behøver røre ved. Det betyder nemlig, at
biblioteksfunktionerne måske fejler, hvis en forekomst af en type modificeres
udenfor biblioteket. For typen COMPLEX er det ikke et problem, men hvis vi havde
med dynamisk allokering at gøre (hvis en COMPLEX for eksempel indeholdt
pointere), og et klient-program manipulerede med denne pointer, ville biblioteket
givetvis fejle. Beskyttelse af data fra klienten (ikke mindst for dennes egen skyld) er
derfor en stor fordel i forbindelse med sikkerhed i integriteten i de funktioner, der er
helliget dem.
Alle disse problemer er gode, datalogiske emner, der optager sprog- og oversætterdesignerne.
Eksempel 3-2 (a-c) viser, hvordan vi i C kan udnytte mulighederne for modulærprogrammering
ved at separere implementation (udbyderens kode) fra specifikation og
applikation. Men sproget undersøtter ikke selv disse. Det gør dem kun mulige.
C++ kan ikke trylle - der skal stadigvæk skrives kode for manipulation af komplekse tal i et
bibliotek skrevet i C++. Til gengæld understøtter C++ flere af de opremsede problemer på en
elegant måde. Vi gennemgår en implementation af programmet i C++ i flere trin for at se,
hvor de forskellige problemer finder sine løsninger.
3.3 KLASSE-BEGREBET
Som beskrevet giver generelle datastrukturer kun en indholdsmæssig abstraktion -
funktionerne til manipulation af strukturen skal stadig skrives separat. En fuldstændig
abstraktion af et koncept skal derfor, for at kunne skabe en bedre modularitet og grænseflade,
indeholde både
• data (forekomster af datatyper eller afledte typer) og
• metoder (medlemsfunktioner) til at manipulere disse.
I C++ kan vi, som beskrevet i afsnit 2.8.5, definere funktioner som medlemmer af en
datastruktur med den helt naturlige syntaks:
struct min_struktur {
int min_medlems_variabel;
void min_medlems_funktion () {
// ...
}
};
Medlemsfunktionen kaldes med reference til en forekomst af den struktur, som den er
118 Et eksempel-problem 3.2

medlem af, på samme måde som en medlemsvariabel refereres:
min_struktur X;
X.min_medlems_variabel = 5;
X.min_medlems_funktion ();
Begrebsverdenen i C++ definerer en struktur, som både indeholder datamedlemmer og
funktionsmedlemmer som en klasse, da den indeholder al information til repræsentation og
manipulation af et bestemt koncept. Vi klassificerer simpelthen vores kode og data som en
type og samler den i en struktur, som sproget understøtter. Sagt på en anden måde
indskrænker vi funktionernes skop til at ligge indenfor en bestemt navngiven blok, ligesom
vores data. De bliver på den måde en del af et modul, som giver større frihed i
programmeringen, end modul-opbygning i filer (som eksempel 3-2) gør.
Første skridt på vejen i en C++-implementation af vores komplekse tal som abstrakt
datatype er derfor at associere de funktioner, som opererer direkte på typen med selve typen:
struct Complex {
double re, im;
void assign (double = 0, double = 0);
void assign (complex&);
complex add (complex&);
complex sub (complex&);
complex mul (complex&);
void print ();
};
Vi har flyttet funktionerne assign_complex(), add_complex(),
sub_complex(), mul_complex() og print_complex() fra at være globale
funktioner ind i selve definitionen af typen. Funktionernes kvalificerede navne er nu
Complex::assign(), Complex::add(), Complex::sub(),
Complex::mul() og Complex::print(), og vi ser, at skopet på deres navne, ligesom
medlemsvariablene, ligger indenfor strukturen Complex. Hvor vi før kaldte funktionerne
mul_complex(), add_complex() og sub_complex() med pointere til forekomster
af komplekse tal, kalder vi nu funktionerne med underforstået reference til den forekomst, vi
ønsker at operere på. Complex::assign() modtager stadig blot en forekomst. En
erklæring og tildeling af et komplekst tal foretages nu således:
Complex a;
a.assign (0, 0);
Hvad indeholder en forekomst af typen Complex da nu? Med både data- og
funktionsmedlemmer kan det være svært at se, hvordan en Complex egentlig allokeres.
Men i virkeligheden er det en simpel procedure, idet alle funktionerne arbejder på
forekomster af en ensartet struktur, ændrer de sig ikke fra forekomst til forekomst. Derfor vil
3.2.2 Gennemgang af C-løsningen 119

C++ ved erklæringen
Complex a;
allokere plads til data-delen af typen Complex, dvs. to forekomster af double.
Funktionerne findes kun én gang, og arbejder identisk på alle forekomster af Complex:
Complex a, b; // to komplekse tal
a.assign (0, 0); // kald complex::assign() for a
b.assign (0, 0); // samme kald, men for b
For hvert kald til assign() giver C++ ekstra information til funktionen om, hvilken
forekomst af Complex, der er tale om. Der er altså ikke tale om noget overhead i lageret
ved at bruge funktioner som medlemmer af strukturer.
3.3.1 Medlemsfunktioner
Den ovenstående struct Complex indeholder kun erklæringer af funktioner.
Implementationerne af de faktiske funktioner, som i og for sig er identiske med dem, vi så i
eksempel 3-2b, kan skrives på to måder:
• Eksternt definerede medlemsfunktioner skrives udenfor selve klassedefinitionen
(struct-blokken) på et senere tidspunkt i kildeteksten. Sammenhængen med den
specifikke klasse udtrykkes med skop-opløsningsoperatoren (::).
• Internt definerede medlemsfunktioner skrives i selve klassedefinitionen, og står
dermed direkte i struct-blokken.
Forskellen er, om funktionen skal være inline eller ej (afsnit 2.6.12). Hvis funktionens
krop skrives som intern funktion, vil oversætteren erstatte funktionskaldet med den faktiske
kode i funktionen, mens eksternt definerede funktioner kaldes på normal vis.
Reglerne for hvilke funktioner, der skal være inline, er de samme som for normale
funktioner: fylder funktionen meget (har den for eksempel løkker eller andre
kontrolstrukturer) og kaldes den meget ofte, bør den ikke være inline. Hvis funktionen
derimod foretager sig meget lidt (for eksempel et par tildelinger), er det en god idé at skrive
den inline. Samspillet mellem antallet af kald og størrelsen på funktionen afhænger af
applikationen og systemet. Generelt kan det dog slås fast, at jo sjældnere en funktion kaldes,
jo mindre er incitamentet for at skrive den inline, fordi det ikke har væsentlig betydning
for programmets effektivitet.
For vores klasse Complex er assign() en oplagt kandidat for inline-funktion,
fordi den blot tildeler værdier til de to medlemsvariable re og im:
struct Complex {
120 Klasse-begrebet 3.3

double re, im;
void assign (double r, double i) {
re = r, im = i;
}
// ...
};
mens for eksempel print() kan være en normal ikke-inline funktion:
void Complex::print () {
printf ("(%f,%f)", re, im);
}
Det er også muligt at skrive en inline-funktion udenfor struct-blokken, hvilket gøres,
hvis man ønsker at holde selve definitionen på klassen rimelig overskuelig:
inline void Complex::assign (double r, double i) {
re = r, im = i;
}
Denne implementation af Complex::assign() er identisk med den ovenstående
implementation. Forskellen er kun syntaksmæssig.
3.3.2 Underforståede medlemsreferencer
Vi har lige set, hvordan funktionerne Complex::assign() og Complex::print()
henviser til medlemsvariablene re og im uden brug af medlemsreference-operatoren. Det
lader sig gøre, fordi funktionen af oversætteren får den nødvendige information om, hvilken
forekomst af Complex den arbejder på. Når klienten kalder
a.assign (0, 0);
bliver den underforståede reference til medlemmerne i Complex::assign() opfattet
som
a.re = 0, a.im = 0;
Funktionerne ved altså hvilke forekomster, de har med at gøre, da C++ vedligeholder en
underforstået reference til den aktuelle forekomst. Denne reference hedder this og er en
pointer til den aktuelle forekomst - eller med andre ord det underforståede objekt. Når en
medlemsfunktion refererer en medlemsvariabel fortolker C++ denne reference som
underforstået peget på af this:
3.3.1 Medlemsfunktioner 121

inline void Complex::assign (double r, double i) {
re = r, im = i; // dss. this->re = r, this->im = i
}
this kan bruges af medlemsfunktioner, men er unødvendig i reference af forekomster af
medlemsvariable. Den bruges mest som reference til hele forekomsten, for eksempel som
returværdi. Mere om this senere i afsnit 3.5.18.
3.3.3 Overstyrede funktionsnavne
Reglerne for overstyring af funktionsnavne, som de er beskrevet i afsnit 2.6.9 gælder også for
funktioner, som tilhører en klasse. Det tilladt på samme måde at skrive to eller flere
funktioner af samme navn, men med forskellige antal og/eller typer af parametre. Medlemsfunktionen
Complex::assign() er en god kandidat for overstyring:
struct Complex {
double re, im;
void assign (double r, double i) { re = r, im = i; }
void assign () { re = im = 0; }
void assign (Complex& c);
// ...
};
Hermed kan klienten kalde Complex::assign() med eller uden parametre efter behov:
Complex a, b, c;
a.assign (0, 5.25);
b.assign ();
c.assign (b);
I specifikationen af Complex ser vi, at der findes to funktioner assign(). Den ene
tildeler en complex en reel og en imaginær del, den anden tildeler en complex værdien
af en anden Complex.
3.3.4 Underforståede parametre
Funktioner med underforståede parametre (afsnit 2.6.10) er en anden måde at give klienten
flere måder at komme til samme data på. Funktionen complex::assign() kan skrives
med underforståede parametre med samme fordele som en overstyring af funktionen:
122 Klasse-begrebet 3.3

struct Complex {
double re, im;
void assign (double r = 0, double i = 0) {
re = r, im = i;
}
// ...
};
Det giver endda større frihed for klienten, som kan tildele på forskellig vis ved at kalde
assign() på følgende måder:
Complex a, b, c;
a.assign (6, 2.5); // sæt a.re til 6, a.im til 2.5
b.assign (8); // sæt b.re til 8, b.im til 0
c.assign (); // sæt både c.re og c.im til 0
Husk, at kun de sidste parametre kan være underforståede:
void assign (double r, double i = 0); // lovlig
void assign (double r = 0, double i); // ulovlig
3.3.5 Indkapsling
struct-nøgleordet definerer en datastruktur med både funktioner og data, og skjuler dermed
en vigtig del af de indre manipulationer af typen fra klienten. Vi har imidlertid et potentielt
problem: idet medlemsvariablene i en datastruktur er tilgængelige for klienten ved brug af
medlemsreference-operatoren (.), kan en medlemsfunktion ikke være sikker på, hvordan
medlemsvariablene ser ud.
Normalt bæres information fra medlemsfunktion til medlemsfunktion i medlemsvariable.
For eksempel kunne en medlemsvariabel i en klasse for lageradministration specificere
antallet af allokerede lagerenheder:
struct Memory {
void* mem_ptr; // addresse på det allokerede lager
int size; // størrelse på blokken
void alloc (int n); // allokér lager (n bytes)
void free (); // frigiv lageret igen
void init (); // nultil hele lageret
char* where (); // fortæl, hvor lageret ligger
};
3.3.4 Underforståede parametre 123

Medlemsfunktionerne i denne klasse bruger informationen i variablene mem_ptr og size
til at henvise til hvor lageret befinder sig og hvor meget, der er allokeret.
Memory::alloc() sætter de to variable op, og de andre funktioner bruger dem, når de
senere kaldes. Memory::where() returnerer for eksempel adressen på det allokerede
lager og Memory::init() nulstiller hele den blokken.
Klienten skal først erklære en forekomst af Memory og kalde alloc():
Memory diskBuffer;
diskBuffer.alloc (4000);
Hvis klienten nu pludselig tildeler diskBuffer.size en vilkårlig værdi med
diskBuffer.size = 8000; // ups!
og derefter kalder
diskBuffer.init ();
vil klassen skrive til dobbelt så meget lager, som den har allokeret, og med sikkerhed generere
en ulovlig lagerreference og/eller tvinge systemet i knæ. Problemet er, at klienten gør sig
afhængig af implementationen af klassen, og spolerer dermed hele ideen bag at skjule de til
klassen tilhørende variable. Selvom klienten ikke udøver en så fatal gerning, kan det have
andre konsekvenser at gøre sig afhængig af implementationen. For når det kommer til stykket,
kan udbyderen af klassen Memory på et senere tidspunkt bestemme sig for at omdefinere
betydningen af sine funktioner og data - for eksempel kunne size indeholde antallet af 16byte
blokke i stedet for rene bytes. I så fald ville klientens kode, fordi den gør sig
implementations-afhængig, fejle ved en genoversættelse. Dette gælder faktisk alle klasser:
måske ville vi få lyst til at ændre det format, vi internt repræsenterede en Complex på, til
float-typer eller angivelser af brøker. Hvis klientens kode eksplicit refererer til re og im,
vil den ikke kunne bruge en ny version af biblioteket.
Dette er en del af diskussionen om grænseflader. Der er brug for beskyttelse af de intimere
dele af en klasse, så klienten ikke kan komme til dem. Vi er interesserede i at indkapsle data,
som "ejes" af klassen, så ingen andre funktioner, end lige præcis dem vi tillader, kan røre ved
dem. Denne indkapsling kendes delvis fra C, Pascal og andre gængse sprog ved deres
muligheder indenfor modulærprogrammering ved at opdele et program i separate kildefiler,
mens mere moderne sprog som C++, Ada og Modula-2 imidlertid giver os en eksplicit
metode til at beskrive den. Det drejer sig om at beskrive hvilke dele af klassen, som ikke skal
ses udefra - som skal være private.
I C++ er nøgleordene public og private † løsningen på problemet. Med public
kan vi angive, at efterfølgende erklæringer på data og funktioner kan bruges direkte i
referencer fra klienten, mens private betyder, at de kun må bruges i de funktioner, som er
† Et tredie niveau, protected, bruges i forbindelse med objekt-orienteret programmering til definition af
adgangskriterier mellem to klasser og beskrives i kapitel 5.
124 Klasse-begrebet 3.3

medlemmer af klassen †† . Complex-klassen kan nu skjule de to indre variable re og im
fra klienten ved at indkapsle dem således:
struct Complex {
private: // privat del - kun tilgængelig fra
double re, im; // medlemsfunktionerne
public:
void assign (double = 0, double = 0);
void assign (Complex&);
complex add (Complex&);
complex sub (Complex&);
complex mul (Complex&);
void print ();
};
En klient af Complex kan nu kun ændre på re og im i en forekomst af typen ved at kalde
en medlemsfunktion. Hvis klientprogrammet indeholder en eksplicit reference til en af
variablene vil det resultere i en oversætterfejl - navnet er simpelthen ikke kendt i klientens
funktion.
De fleste klasser har private medlemmer. C++ har af denne grund en variant af struct,
som fra starten af blokken erklærer medlemmer som private. Varianten hedder class
og opfører sig bortset fra denne detalje akkurat som struct:
class Complex {
double re, im; // private data
public:
void assign (double = 0, double = 0);
void assign (Complex&)
complex add (Complex&);
complex sub (Complex&);
complex mul (Complex&);
void print ();
};
Tilgangs-nøgleordene kan forekomme flere gange i specifikationen af en klasse:
class X {
public:
int x, y; // public data
private:
float f; // private data
†† Vi kan også specifikt give en global funktion rettigheder til de indre variable med friend-nøgleordet.
friend-funktioner beskrives i afsnit 3.5.11 og friend-klasser i næste kapitel.
3.3.5 Indkapsling 125

private:
long l; // flere private data
};
Indkapsling giver altså abstrakte datatyper den klare fordel, at vi kan separere
implementationen fra specifikationen i en klasse, som derfor sikrer, at ændringer i klassen
ikke får betydning for klientprogrammet. Det har ydermere den anden fordel, at al kode, som
arbejder på medlemsvariable af en bestemt klasse findes i selve klassen, så lokalisering af fejl
bliver lettere.
3.3.6 struct, class og union
En struct i C++ er altså det samme som en class, men alle medlemmer af strukturen er
public. struct kan bruges, når skjulning af data ikke er betydningsfuld:
struct { // ...
giver samme resultat, og er simpelthen en kortere måde at udtrykke
class { public: // ...
En union er også en klasse i C++. union'er er identiske med struct'er, med den
væsentlige forskel, at alle datamedlemmer i union'en starter på samme adresse. Størrelsen
på en union er altså størrelsen på det største datamedlem. Der er imidlertid nogle
potentielle problemer med union'er, fordi oversætteren ikke kan type-checke brugen af
dem, da de jo per definition er tvetydige (se afsnit 2.8.2).
En union kan indeholde funktioner, som gør det lettere for en klient at komme til de
forskellige medlemmer. For eksempel kan vi definere en union til at indeholde en værdi i et
medlem af en symboltabel - enten en int, en long eller en double:
union value {
int i_value;
long l_value;
double d_value;
void assign (int i) { i_value = i; }
void assign (long l) { l_value = l; }
void assign (double d) { d_value = d; }
};
Funktioner som medlemmer af union'er har kun meget få rigtig brugbare anvendelser - de
hjælper ikke med problemerne med identifikation af den aktuelle type, der ligger i en
126 Klasse-begrebet 3.3

forekomst af en union på et givet tidspunkt. For at identificere den aktuelle status i en
forekomst af en union, dvs. spørgsmålet om hvilken af de indeholdte variable som sidst
blev tildelt en værdi, må denne information være indeholdt i en anden variabel. Det er muligt
at skrive en diskriminerende union, som indkapsles i en klasse sammen med den aktuelle
type-information samt funktioner til korrekt ind- og udlæsning af union'en.
3.3.7 Klasser og skop
Vi har set, hvordan en medlemsfunktion refererer medlemsdata underforstået. I afsnit 2.6.1 så
vi, hvordan globale data af samme navn kan refereres med skop-opløsningsoperatoren, så
tvetydigheder undgås:
int a;
void f () {
int a;
a = 1; // lokal a
::a = 1; // global a
}
Ordentligt skrevne programmer har ikke mange globale variable, og skopopløsningsoperatoren
bruges også mest i forbindelse med klasser. Her kan den bruges i
forbindelse med både data og funktioner, og oftest sidstnævnte:
class X {
void print (); // X::print() prototype
};
void print (); // global print() prototype
void X::print () {
::print (); // kalder global print()
}
Faldgruben i dette er, hvis man glemmer skop-operatoren. Sker dette for eksempel i kaldet til
::print() i X::print(), vil det resultere i en deadlock, fordi ::print() rekursivt
kalder sig selv igen og igen med et uafvendeligt stak-overløb til følge. Evalueringen af en
reference til en funktion eller dataelement i en klasse er: Først undersøges, om funktionen
findes i klassens skop med en præcist passende parameterliste (eventuelt overstyret og/eller
3.3.6 struct, class og union 127

med underforståede parametre) eller type, hvorefter det globale skop søges. Passer ingen af
disse, forsøges andre navne (i samme rækkefølge) med passende underforståede
typekonverteringer.
3.3.8 Private medlemsfunktioner
Medlemsfunktioner kan også erklæres private. En private medlemsfunktion kan ikke
kaldes fra klienten, men kun fra andre medlemsfunktioner. Den umiddelbare grund til at
bruge private medlemsfunktioner er, at en service-funktion, som bruges i flere
medlemsfunktioner, kan skjules helt fra andre dele af programmet. Hvis funktionen - for
eksempel en formateringsrutine - skulle være global, ville en stor del af ideen med
indkapsling forsvinde. Hvis den er public i den aktuelle klasse, ville den godt nok være
indkapslet, men kunne alligevel kaldes fra klienten.
I den offentlige administration har embedsmændende en speciel regel for tilgang til
information, som kaldes "need-to-know". Det betyder, at en embedsmand kun kan stille
spørgsmål, hvis hans arbejdsfunktion kræver svaret - ellers er der ingen grund til at spørge;
det kommer ham simpelthen ikke ved. Den samme regel gælder for medlemsfunktioner i
klasser: hvis en klient ikke har brug for at kalde en bestemt medlemsfunktion, skal denne
være private, på samme "need-to-know"-basis.
3.3.9 Klasse-baseret vs. objekt-baseret indkapsling
Medlemsfunktionerne, som de ses i specifikationen af klassen Complex, indeholder
parameterlister med kun en enkelt reference til en Complex. Reference-operatoren gør det
lettere at kalde funktionen, fordi vi ikke behøver at tage adressen af den Complex, vi ønsker
at kalde funktionen med, i selve funktionskaldet. Hvis vi ønskede at bruge samme
kaldemetode som i eksempel 3-2, skulle implementationen af funktionen arbejde udtrykkeligt
med pointere. Et kald til add() vil se sådan ud:
a.add (&b); // kald med adressen på b
Reference-operatoren giver, som beskrevet i afsnit 2.11.13, en bedre mulighed for automatisk
at referere et pointerobjekt uden at skulle dereferere (tage adressen på) objektet eksplicit.
Grunden til, at funktionen add() kun modtager et enkelt parameter er, at det andet led i
additions-operationen specificeres i kaldet og derfor er underforstået for funktionen. add()
kaldes med eksplicit reference til en forekomst (det ene led) og med en parameter (det andet
led). Men add() skal have adgang til de private variable for begge forekomster for at
foretage en addition.
Det har den også. Indkapsling i C++ er klasse-baseret, fordi en medlemsfunktion har tilgang
til private medlemmer i enhver forekomst af den pågældende klasse, og ikke blot den
specifikke forekomst, som den underforstået kaldes med. Complex::add() kan
manipulere med private data i alle forekomster af complex, sålænge den har forekomster at
128 Klasse-begrebet 3.3

arbejde med.
Implementationen af Complex::add() ser derfor således ud:
// addition af komplekst tal
Complex Complex::add (Complex& c) {
Complex temp; // et midlertidigt komplekst tal
temp.re = re + c.re; // addér de reelle dele
temp.im = im + c.im; // addér de imaginære dele
return temp; // returner resultatet
}
Complex::add() bruger ganske simpelt medlemsreference-operatoren for at komme til de
data, som privat er indeholdt i c. Sprog som Smalltalk er mere restriktive, idet de kun tillader
medlemsfunktioner adgang til den specifikke forekomst, de arbejder på. For at få tilgang, må
funktionen kalde en bestemt adgangsfunktion i samme klasse for den anden forekomst. Vi
siger, at Smalltalk har objekt-baseret indkapsling, mens C++ bruger klasse-baseret eller typebaseret
indkapsling.
3.3.10 Klasser som moduler
Det åbenlyse eksempel på en klasse, som bruges som eksempel her i kapitlet, er en numerisk
datatype. Men klasser kan også bruges til at indkapsle processer i C++. I mange tilfælde kan
vi drage fordel af, at en klasse giver os et begrænset skop for medlemmerne, idet vi kan
anskue en klasse som et "miniature-program":
enum colour_t {
black, blue, red, magenta, green, cyan, yellow, white
};
struct ansi_util {
void cls ();
void home ();
void colour (colour_t);
void clrline ();
void goto (int, int);
};
Denne klasse indeholder kun funktioner, og ingen data. Vi kan se denne klasse som en kapsel
for et antal relaterede funktioner, som her sender ANSI-koder til for eksempel en terminal.
Alle funktionerne kaldes med skop-reference til klassenavnet ansi_util, og gør det
dermed let at se, hvilken gruppe - eller modul - funktionen tilhører. Dette er det tætteste, C++
kommer på regulær modulærprogrammering:
3.3.9 Klasse-baseret vs. objekt-baseret indkapsling 129

ansi_util::cls ();
ansi_util::colour (white);
Vi indkapsler ganske simpelt et antal funktioner i en klasse, men erklærer ikke nogen
forekomster af klassen. Den eneste fordel er, at funktionsnavnene kan gøres rimelig generelle,
og at andre "moduler" - for eksempel en ibm_util - kan skrive med samme
funktionsnavne.
3.3.11 Indkapslede typeerklæringer
Klasser kan erklæres inde i hinanden, og en klasse, der er indkapslet i en anden, kaldes for en
indlejret klasse. Indlejrede klasser er lokale til den klasse, de erklæres i og er skjult fra resten
af programmet. Dette er en afvigelse fra tidligere versioner af C (før 3.0), hvor en indlejret
type altid var global, hvilket skabte problemer, hvis den havde associerede symbolske
konstanter, som, når de er defineret i klasser, er lokale til disse. Den nye standard betyder, at
C++ understøtter lokale skop for navne såvel som for objekter, en facilitet, der har vist sig
uundværlig i objekt-orienteret programmering. Overvej følgende klasseerklæringer:
class X { // en klasse
class X { // en indlejret klasse
int i;
};
public:
class Y { // en anden indlejret klasse
int i;
};
};
X x; // lovlig, X er i det globale navneskop
Y y; // ulovlig, Y er i X's skop
Z z; // ulovlig, Z er i X's skop (og er privat)
For at erklære en forekomst af Y må vi benytte skop-operatoren på samme måde, som når vi
erklærer medlemsfunktioner eksternt:
X::Y y; // ok: X::Y er tilgængelig for klienten
X::Z z; // fejl: X::Z er privat
Hvis der forekommer indlejringer i flere led, som i
struct A {
struct B {
struct C {
130 Klasse-begrebet 3.3

};
};
};
skal skop-operatoren benyttes hele vejen igennem til det kvalificerede navn på den indlejrede
type, der ønskes:
A::B::C c;
Det skal bemærkes, at både den indre og den ydre klasse følger de helt normale regler for
adgang til medlemsvariable i andre klasser. De har således ikke specielle friheder til at røre
ved data i hinanden, uanset at de har et fælles skop. Med andre ord, en indlejret klasse har
ikke noget typeforhold med den ydre klasse, og vice versa, så programmøren må selv sikre
sig, at de har et egentligt objekt at arbejde på af den anden klasse. I de følgende erklæringer
kan det ses, hvilke objekter de indlejrede klasser har adgang til.
int i; // global i
class ydre {
int i; // privat ydre::i
public:
int j; // public ydre::j
static k; // statisk ydre::k
class indre {
int l; // privat ydre::indre::l
void f () {
i = 0; // fejl: hvilken i?
j = 0; // fejl: hvilken j?
k = 0; // ok: ydre::k er nærmest
l = 0; // ok: indre::l findes i denne f()
::i = 0; // ok: global i er i f()'s skop
}
void g (ydre y) {
y.i = 0; // fejl: ydre::i er privat
y.j = 0; // ok: ydre::j er public
}
};
void f () {
l = 0; // fejl: indre::l, har ej objekt
}
};
3.3.11 Indkapslede typeerklæringer 131

I ydre::indre::f() kan vi se, hvordan det ikke er lovligt at forsøge at få adgang til
hverken private eller public dele af den omsluttende klasse ydre. indre har med
andre ord ingen særrettigheder til data (eller funktioner) i ydre selv om den er erklæret i
denne klasse. Kun statisk erklærede data i den (eller de) omsluttende klasser og/eller globale
data kan tilgås fra de indlejrede klasser. Funktioner i indlejrede klasser skal have et konkret
objekt at arbejde på - en indlejret klasse specificerer ikke et typeforhold, blot et leksikalt skop
for klassen. I ydre::indre::g() modtager funktionen en forekomst af ydre, hvilken
den kan arbejde på uden bekymringer så længe reglerne for private data ikke overtrædes. I
samme åndedrag skal det nævnes, at den omsluttende klasse heller ikke har adgang til
medlemmerne i den indlejrede klasse. Der bliver således ikke instansieret et objekt af den
indlejrede klasse, når et objekt af den omsluttende klasse instansieres. Det er grunden til, at
ydre::f() ikke har adgang til ydre::indre::l - funktionen ved simpelthen ikke,
hvilket objekt, der refereres til.
Disse regler for indkapsling af navne gælder også for enum, union og særligt for
typedef.
3.3.12 Anonyme klasser
Undertiden har vi brug for kun en enkelt forekomst af en given klasse, for eksempel en
printer-driver eller en fejl-opsamlings-klasse. Dette gøres med en erklæring af en klasse uden
typenavn, men med en samtidig erklæring af en forekomst. C-programmører vil være bekendt
med dette fra struct-erklæringer så som
struct {
int count; // antal af fejl
int last_error; // sidste fejl
void (*handler) () // pointer til fejl-funktion
} error_handler;
Fremgangsmåden for klasser er den samme som den for struct, enum og union, som
er beskrevet i afsnit 2.7.3. I C++ kan klasser erklæres uden typenavn på præcis samme facon:
class {
int count;
int last_error;
void (*handler) ();
public:
void set_handler ((*fptr) ()) {
handler = fptr;
}
132 Klasse-begrebet 3.3

void handle (int errno) {
count++;
last_error = errno;
(*handler) ();
}
} error;
Der findes kun ét objekt af denne unavngivne type, kaldet error. Klienten kan kalde
funktionerne i error på normal vis, for eksempel med
error.set_error (myhandler);
error.error (12);
men kan ikke skabe nye forekomster af typen. Der er imidlertid en lille ulempe ved denne
måde at skabe enkelt-instanser, nemlig at det er umuligt at skrive konstruktører og
destruktører - automatiske funktioner til opsætning og oprydning - som beskrives nærmere i
afsnit 3.4.
3.3.13 Statiske medlemsvariable
Klasser kan have statiske medlemsvariable, erklæret med static-nøgleordet. Statiske
medlemsvariable opfører sig på den måde, at alle forekomster af klassen deler samme
variabel. Følgende eksempel erklærer to forekomster af en klasse med en statisk og to
normale ikke-statisk variable:
class error {
int last_error;
void (*handler) ();
public:
static count; // int er underforstået her
void set_handler ((*fptr) ()) {
handler = fptr;
}
void handle (int errno) {
count++, last_error = errno;
(*handler) ();
}
};
error disk_error, keyboard_error;
De to forekomster af error, disk_error og keyboard_error har hver sine
last_error og handler medlemmer, men deler count-variablen.
3.3.12 Anonyme klasser 133

Figur 3-1: Ejerforhold for statisk medlem count.
Idet der kun findes en enkelt kopi af statiske medlemsvariable, vil de blive oprettet ved
programmets start. Deres levetid er altså hele programmet igennem, ligesom for statiske
variable i funktioner samt globale variable. Af den grund er det muligt at tildele en statisk
variabel i en klasse en værdi uden at gå igennem en forekomst af klassen, medmindre den er
private:
error::count = 0;
int a = error::count;
Statiske medlemsvariable kan ikke initieres med samme syntaks som andre statiske variable,
dvs. med en samtidig tildeling af en værdi. Initiering af statiske medlemsdata foregår med en
normal erklæring i det globale skop, normalt i implementationsfilen af klassen, for eksempel
som
int error::count = 0;
Denne erklæring og initiering virker både for private- og public-erklærede statiske
medlemsvariable. Det bør i øvrigt bemærkes, at C++ garanterer binær nulstilling af alle
uinitierede statiske variable.
Et alternativ til statiske medlemsdata er normale statiske ikke-medlems-variable med
globalt skop i implementationsfilen for en given klasse. En sådan variabel vil være indkapslet
i denne fil, og vil ikke være kendt i andre filer. Fordelen ved dette er, at det kun kræver en
modifikation af implementationsfilen (.cpp-filen), ikke specifikationsfilen (headerfilen .h),
hvis der skal foretages ændringer ved den statiske variabel. Dette går selvfølgelig ikke, hvis
inline-funktioner, som står i specifikationsfilen bruger den statiske variabel, og at alle
medlemsfunktioner, som refererer den statiske variabel kan placeres i .cpp-filen. Dermed
skal kun implementationsfilen genoversættes - ellers skal alle filer, som er afhængig af
specifikationen af klassen oversættes igen.
3.3.14 Statiske metoder
134 Klasse-begrebet 3.3

En klasse kan også indeholde statiske medlemsfunktioner. Disse har samme privilegier hvad
angår normale funktioner, men med den forskel, at de ikke kan kaldes med reference til en
forekomst af klassen med . eller -> operatorerne. En statisk medlemsfunktion har intet
underforstået objekt og har derfor ingen this-pointer. Den har kun adgang til alle private
dele af klassen, hvis den på en eller anden måde får en konkret forekomst af klassen at arbejde
med.
En statisk medlemsfunktion erklæres med nøgleordet static:
class X {
int i;
public:
static X* readFrom (ostream& input) {
X* xx = new X;
input >> xx->i;
return xx;
}
};
Fordelen ved statiske medlemsfunktioner er, at de kan kaldes uden at der findes en forekomst
af klassen. Ovenstående klasse X har en statisk medlemsfunktion readFrom(), som
indlæser et objekt af typen X. Hvis vi ønsker at indlæse en objekt af typen X uden først at
skulle oprette en forekomst af X, skal vi bruge en funktion vi kan kalde, som har adgang til
de private dele af klassen (husk, at C++ bruger klassebaseret indkapsling), men som ikke
arbejder på en bestemt forekomst af klassen.
Den statiske medlemsfunktion X::readFrom() kan kaldes fra et brugerprogram på
følgende måde:
void main () {
cout

sikrer, at bibliotekets data er konsistente.
struct ansiUtil {
static int cursor_x, cursor_y;
static void cursor_on ();
static void cursor_off ();
static void cls ();
};
ansiUtil::cls ();
ansiUtil::cursor_x = 0, ansiUtil::cursor_y = 0;
ansiUtil::cursor_on ();
Alle data og funktioner udvides syntaksmæssigt med det kvalificerede navn på det "modul",
som de tilhører. Dermed er det en let at se, hvor de hører til og dermed sværere at bruge dem
forkert.
3.3.15 Konstante objekter
Brugbarheden af konstanter blev behandlet i afsnit 2.4.6, hvor det blev gjort klart, at en
const X og en X er to forskellige typer. Konstante forekomster af brugerdefinerede typer
har præcis samme anvendelighed:
class hvadsomhelst { /* ... */ };
void f (const hvadsomhelst& x) {
hvadsomhelst y;
x = y; // fejl: kan ikke tildele konstant
hvadsomhelst t = x; // ok: kan godt kopiere konstant
hvadsomhelst* p = &x; // fejl: kan ikke tage x' adresse
// ...
}
Men hvad sker der, hvis klienten kalder en funktion i et konstant objekt, som ændrer på
objektets indre status? En sådan operation ændrer ikke åbenlyst på objektet, da der ikke
forekommer tildelinger af nogen art. En lille klasse kan illustrere dette:
class intVec { // liste af int
int *rep, antal;
public:
intVec (int i) { rep = new int [antal = i]; }
~intVec () { delete rep; }
void Add (int); // addér til vektor
136 Klasse-begrebet 3.3

void Print ();
// ...
};
void intVec::Add (int j) {
for (int i = 0; i < antal; i++) rep [i] += j, j = rep
[i];
}
void intVec::Print () {
for (int i = 0; i < antal; i++) cout

public:
intVec (int i) { rep = new int [antal = i]; }
~intVec () { delete rep; }
void Add (int) const; // addér til vektor
void Print ();
// ...
};
void intVec::Add (int j) const { // konstant funktion
for (int i = 0; i < antal; i++) rep [i] += j, j = rep
[i];
}
Denne funktion vil imidlertid ikke oversætte, fordi den ændrer i medlemsdata og samtidig er
erklæret som konstant. Det giver også mening, idet en funktion som Add(), der ændrer i
medlemsdata, ikke bør være konstant.
Retningslinierne for brugen af konstante medlemsfunktioner er derfor simple nok: hvis en
metode ikke ændrer i objektets data, bør den erklæres const, for at tillade kald til metoden
for et objekt af klassen, som er erklæret som en konstant. Det giver den størst mulige frihed
for konstanter af brugerdefinerede typer. Her er det vigtigt at huske, at selvom en const
ikke kan typekonverteres hverken underforstået eller tvungent til en ikke-const, er det
omvendte tilladt:
void f (const int x) { /* ... */ }
void g () {
int y = 10;
f (y); // y konverteres til const int
}
Alle metoder, som er erklæret konstante i en klasse kan derfor bruges med reference til både
konstante og ikke-konstante forekomster. intVec-klassen kan for eksempel indeholde en
Hash()-funktion, som returnerer en indeks-værdi til en søgetabel:
unsigned intVec::Hash () const {
unsigned r = 0;
for (int i = 0; i < antal; i++) r ^= (unsigned) rep [i];
return r;
}
Denne metode kan kaldes for både konstante og ikke-konstante forekomster af intVec
uden komplikationer:
138 Klasse-begrebet 3.3

typedef bool int;
bool hashCompare (const intVec& s) {
intVec t;
// ... indlæs t ...
return s.Hash () > // Hash() kaldes for konstant objekt
t.Hash (); // Hash() kaldes for normalt objekt
}
Læg mærke til, at den konstante metode kun har betydning for data, som er medlemmer af
klassen. Parametre, som eventuelt overføres til en konstant metode, er ikke konstante
medmindre de udtrykkeligt erklæres som sådanne. I følgende funktion
bool intVec::Compare (intVec& other) const {
bool r = 0;
for (i = 0; i < antal; i++) r |= rep [i] != other.rep
[i];
return r;
}
bliver rep, altså det underforståede objekts vektor af heltal, til en const int* const
og kan ikke hverken ændre sin egen værdi eller de data, den peger på. other er imidlertid
en ikke-konstant parameter til funktionen Compare(), så other.rep er en ikkekonstant
vektor, da den ikke er et medlem af det aktuelle objekt. Det er nødvendigt at erklære
denne som konstant parameter for også at sikre other som konstant:
bool intVec::Compare (const intVec& other) const {
bool r = 0;
for (i = 0; i < antal; i++) r |= rep [i] != other.rep
[i];
return r;
}
3.3.17 Overstyrede konstante metoder
Der er imidlertid eksempler på, at en metode skal udføre en forskellig operation afhængig af,
om den kaldes for et konstant eller et ikke-konstant objekt. Type-reglerne i C++ skelner
mellem konstante metoder og normale metoder, så en funktion kan overstyres med constnøgleordet
efter samme regler som afvigende parameterlister. Vi kan for eksempel forestille
os, at Hash()-funktionen overfor også gemmer resultatet i en medlemsvariabel.
class intVec {
3.3.17 Konstante metoder 139

int* rep, antal;
unsigned hashValue;
public:
// ...
unsigned Hash () const;
};
unsigned intVec::Hash () const {
unsigned r = 0;
for (int i = 0, i < antal, i++)
r ^= (unsigned) rep [i];
return hashValue = r;
}
Dette går naturligvis ikke for konstante objekter, fordi hashValue bliver tildelt i sidste
linie af funktionen, som således ikke kan være konstant. Oversætteren vil beklage sig over en
tildeling til en medlemsvariabel i en konstant medlemsfunktion. Men det skal stadig være
muligt at hashe konstante objekter. Derfor overstyres funktionen for konstante objekter på
følgende måde:
class intVec {
int* rep, antal;
unsigned hashValue;
public:
// ...
unsigned Hash (); // kaldes for ikke-konstanter
unsigned Hash () const; // kaldes for konstanter
};
unsigned intVec::Hash () {
unsigned r = 0;
for (int i = 0, i < antal, i++)
r ^= (unsigned) rep [i];
return hashValue = r;
}
unsigned intVec::Hash () const {
unsigned r = 0;
for (int i = 0, i < antal, i++)
r ^= (unsigned) rep [i];
return r;
}
Der skelnes nu mellem en Hash()-funktion for forekomster af intVec, som er erklæret
140 Klasse-begrebet 3.3

enten const eller ikke-const, og oversætteren binder kaldet til den funktion, der passer til
erklæringen af objektet: konstante metoder for konstante objekter og ikke-konstante metoder
for ikke-konstante objekter:
bool hashCompare (const intVec& s) {
intVec t;
// ... indlæs t ...
return s.Hash () > // Hash() const kaldes
t.Hash (); // Hash() kaldes
}
På den måde kan udbyderen af klassen styre, hvordan metoder, som har anvendelser for både
konstante og ikke-konstante objekter, men som afviger i detaljer, skal kaldes. Den primære
anvendelse af overstyring med konstante metoder er, når et objekt indeholder en
medlemsfunktion, som returnerer en reference og således kan bruges som et venstre-udtryk i
en tildelingssætning. Da det ikke er lovligt at tildele værdier til konstante objekter vil en
overstyring sikre, at der returneres den rette (kontante/ikke-konstante) variant af referencen,
så fejlen kan rapporteres af oversætteren.
3.3.18 Første løsning i C++
En indkapslet version af Complex-biblioteket i C++ ser nu ud som i eksempel 3-3a og 3-3b
for henholdsvis header og implementation. I eksempel 3-3c ses et eksempel på, hvordan
biblioteket bruges i en enkel udregning af typen d = a * b - c.
// complex.h
// eksempel 3-3a: en C++ specifikation af et komplekst tal
class Complex {
double re, im; // private data
public:
void assign (double r = 0, double i = 0) {
re = r, im = i;
}
void assign (const Complex& c) {
re = c.re, im = c.im;
}
Complex add (const Complex&) const;
Complex sub (const Complex&) const ;
Complex mul (const Complex&) const;
void print ();
};
3.3.18 Overstyrede konstante metoder 141

complex.cpp
// eksempel 3-3b: en C++ implementation af et komplekst tal
#include
#include "complex.h"
Complex Complex::add (const Complex &c) const {
Complex temp;
temp.re = re + c.re;
temp.im = re + c.im;
return temp;
}
Complex Complex::sub (const Complex& c) const {
complex temp;
temp.re = re - c.re;
temp.im = re - c.im;
return temp;
}
Complex Complex::mul (const Complex& c) const {
Complex temp;
temp.re = re * c.re - im * c.im;
temp.im = re * c.im + im * c.re;
return temp;
}
void Complex::print () {
cout

a.print (); // udskriv a
cout

før eventuelle tildelinger eller andre operationer udføres på en forekomst af typen.
I eksemplet med en lagerallokeringstype skal brugeren eksplicit kalde en alloc()funktion
efter at have erklæret en Memory-variabel, hvorefter lageret for eksempel kan
nulstilles:
Memory diskBuffer; // erklær en disk-buffer
diskBuffer.alloc (BUFSIZ); // alloker lager til bufferen
diskBuffer.init (); // nulstil bufferen
Dette er typisk i brugen af ressourcer i næsten alle sprog. Først erklæres ressourcen, dernæst
allokeres den fysiske ressource, og først da kan den bruges for alvor. Programmøren skal altså
huske at kalde visse vigtige funktioner under oprettelsen af en type (under et system som
Microsoft Windows fylder det klassiske Hello World-program flere hundrede linier, fordi
oprettelsen af et vindue kræver talrige allokerings- og definitionskald).
Samme problematik gælder for oprydning i en forekomst. Vi skal udtrykkeligt kalde en
speciel oprydnings-funktion, før objektets skop render ud. Memory-typen har en free()funktion,
som frigiver det allokerede lager til systemet. Hvis vi glemmer at kalde free(),
vil lageret aldrig gives tilbage. Reelt er problemet, at det er klientens ansvar at kalde
funktionerne for opstart og oprydning. For vi kan jo ikke garantere, at klienten husker det!
I C++ kan vi definere specielle medlemsfunktioner til opstart og oprydning i forekomster af
abstrakte datatyper, som kaldes implicit uden klientens indblanding, og som derfor garanterer,
at alt er i orden. Konstruktører (eng. constructors) kaldes ved erklæringen af et objekt, og
destruktører (eng. destructors) kaldes ved slutningen af objektets skop.
3.4.1 Konstruktøren
Konstruktør-funktionen konstruerer bogstaveligt talt objekter. Den kaldes for at allokere lager
til sig selv, tildele værdier til de indre data-medlemmer og foretage andre initieringer for nye
objekter. Næsten alle klasser har en eller flere konstruktører (konstruktør-funktioner kan
overstyres), som kaldes ifølge den måde, en forekomst af klassen erklæres på.
En konstruktør erklæres i den public-delen af en type, og har altid samme navn som
typen selv. Den kan have parametre ligesom andre funktioner, men har ingen returtype, da der
ikke er nogen steder at returnere værdier til fordi funktionen kaldes implicit. Hvis der ikke
findes nogen konstruktører i en klasse, vil oversætteren generere en underforstået konstruktør,
som nulstiller alle data-medlemmer i forekomsten efter en erklæring. Hvis en eller flere
konstruktører defineres, bliver den underforståede konstruktør fjernet og kan ikke kaldes. Det
sikrer, at objekterne initieres rigtigt, eller at fejlbrug af dem fanges på
oversættelsestidspunktet.
Klassen Memory er her defineret med en konstruktør i stedet for en speciel alloc()funktion:
class Memory {
char* mem_ptr; // addresse på det allokerede lager
144 Initiering og nedbrydning af objekter 3.4

int size; // størrelse på blokken
public:
Memory (int n) { // allokér lager (n bytes)
mem_ptr = new char [size = n];
}
// ...
};
Når en klient erklærer en Memory med
Memory diskBuffer;
vil oversætteren beklage sig, da der ikke findes en konstruktør med en tom
parameterspecifikation. Klienten må skrive
Memory diskBuffer (1000);
for at erklære en forekomst af Memory af 1000 enheder. Vi har garanti for, at en klient ikke
kan erklære forekomster af Memory, som han eller hun glemmer at kalde allokeringsfunktion
for, og eliminerer hermed en typisk kilde for programmeringsfejl.
Vær opmærksom på, at anonyme klasser ikke kan have konstruktører. Dette skyldes mere
syntaksen i C++ end reelle tekniske problemer: idet en konstruktør skal have samme navn
som klassen, vil en anonym klasse ikke kunne indeholde en konstruktør, fordi den netop intet
navn har!
3.4.2 Hvornår kaldes en konstruktør
Vi husker fra afsnit 2.9, at der er 3 primære måder at oprette en variabel på, nemlig ved
statisk, automatisk og dynamisk allokering. En konstruktør kaldes, når en forekomst oprettes,
og det gælder alle disse allokeringsformer:
Derfor:
• statiske objekter (også globale og eksterne) kalder konstruktøren når programmet
startes,
• automatiske objekter kalder konstruktøren hver gang, de erklæres, og
• dynamisk allokerede objekter kalder konstruktøren hver gang, operatoren new
efterfølges af den pågældende klasse.
3.4.1 Konstruktøren 145

class X { // et koncept "X"
X (); // konstruktør
// ...
};
X a; // a.X() kaldes ved programstart
void main () {
static X b; // b.X() kaldes ved programstart
X c; // c.X() kaldes her
X* d
d = new X; // d->X() kaldes her
// ...
}
Denne gruppering er lavet udfra hvordan objekterne er allokeret, og tjener til at vise, at det er
den samme funktion, der er tale om, uanset hvor objektet befinder sig. I syntaksmæssig
sammenhæng foretages kald til konstruktører i tre situationer:
...
1. En udtrykkelig oprettelse af et objekt, som i
X a; // X::X() kaldes for a
2. En overførsel af et objekt til en funktion som parameter, overført som værdi, som i:
void print (X a) { /* udskriv a */ }
X b;
print (b); // X::X() kaldes for a (ikke b)
3. En overførsel af et objekt fra en funktion til kalderen som returværdi, som i
X input () {
X a;
// ... indlæs en X i a
return a; // X::X() kaldes for et temporært objekt
}
X b = input (); // ... som kopieres til b her
Disse regler gælder kun for objekter, der overføres til eller fra funktioner som værdier. For
146 Initiering og nedbrydning af objekter 3.4

pointer-argumenter eller referencer bliver konstruktøren ikke kaldt, idet der ikke er tale om et
nyt objekt.
Konstruktørkald kan være en kilde til en pudsig programmeringsfejl, som er svær at opdage,
fordi den ikke umiddelbart ser forkert ud. Givet klassen X overfor, vil erklæringen
X x_obj();
ikke oprette et objekt af typen X som hedder x_obj og kalde konstruktøren X::X() for
dette objekt. Konstruktører kaldes implicit. Der er tale om en prototype på en funktion, som
hedder x_obj, som returnerer en forekomst af X og som har en tom parameterliste!
Konstruktører uden parametre skal altså ikke kaldes med tomme paranteser, men blot skrives
efter den samme syntaks som den, der bruges ved fundamentale typer, nemlig
X x_obj;
Den slags sælsomheder hører med til C++, og kan give anledning til timevis af grublen, fordi
fejlen ikke er åbenlys.
3.4.3 Konstruktører uden parametre
En klasse kan indeholde en konstruktør, som ikke har parametre, eller som har underforståede
værdier for alle parametre. Konstruktører, som ikke kræver parametre hedder underforståede
konstruktører på linie med den, som oversætteren genererer i tilfælde af manglende
konstruktører. Den underforståede konstruktør er brugbare i de tilfælde, hvor et objekt skal
initieres, men hvor denne initiering ikke nødvendigvis kræver indblanding fra klientens side.
Memory-klassen kan for eksempel indeholde en underforstået konstruktør, som allokerer
et fast antal lagerenheder. Konstruktøren skrives som:
Memory::Memory () {
mem_ptr = new char [size = BUFSIZ];
}
Når en klient erklærer en memory med
Memory buffer;
vil oversætteren indsætte et underforstået kald til buffer.Memory() og dermed allokere
BUFSIZ nye char ved brug af new-operatoren. C++ bruger iøvrigt den underforståede
konstruktør når vektorer af abstrakte datatyper erklæres. Hvis du for eksempel skriver
Memory buffer [8];
vil buffer.Memory() blive kaldt 8 gange, for buffer[0], buffer[1] ...
3.4.2 Hvornår kaldes en konstruktør 147

uffer[7]. Der findes ingen andre metoder til at kalde andre konstruktører under en
vektor-erklæring end den underforståede konstruktør.
3.4.4. Konstruktører med ét parameter
Når en konstruktør har et enkelt parameter (eller hvis alle andre parametre har underforståede
værdier), kan en alternativ syntaks bruges under erklæringen af objektet:
Memory buffer = 1000;
Dette er, hvis klassen Memory er defineret med en konstruktør med en enkelt parameter, for
eksempel en int, være identisk med
Memory buffer (1000);
Denne syntaks er mere i stil med den, vi kender fra de kombinerede erklærings/initieringssætninger
for de fundamentale typer.
3.4.5 Konstruktører med flere parametre
Hvis konstruktøren har mere end en parameter, skal disse med i erklæringen af en forekomst
af den pågældende klasse. I vores Complex-klasse vil en konstruktør med både en reel og
en imaginær initierings-værdi være praktisk. Konstruktøren får specifikationen
Complex::Complex (double r, double i);
og bliver kaldt på følgende måde under initieringen:
Complex a (3.4, 8.2);
3.4.6 Klasser med flere konstruktører
Hvis klassen overstyrer konstruktøren, får klienten større frihed i erklæringen af forekomster
af klassen. Klassen Complex, som har to assign()-funktioner, én for tildeling af to
double'r og én for tildeling af en anden Complex. Disse to funktioner kan direkte
omskrives til konstruktør-funktioner, så klienten kalder dem implicit under erklæringen:
class Complex {
double re, im;
148 Initiering og nedbrydning af objekter 3.4

public:
Complex (double r, double i = 0) { re = r, im = i; }
Complex () { re = im = 0; }
// ...
}
De to konstruktører giver klienten mulighed for at oprette Complex-forekomster på
følgende måder:
Complex a = 3; // a.Complex (3, 0) kaldes
Complex b; // b.Complex () kaldes
Complex c (4, 3.33); // c.Complex (4, 3.33) kaldes
Når en klasse har flere konstruktører giver det altså klienten flere indgange til oprettelse af
klassen. Det, vi tilstræber, er en syntaks i erklæringen af abstrakte datatyper, som ligner den
vi kender fra de fundamentale typer. Programmeringsfejl mindskes, fordi syntaksen er kendt.
De fire linier overfor kunne også skrives som:
Complex a = 3, b, c (4, 3.33);
Oversætteren vil binde kaldet fra erklæringen i klientprogrammet til den rette konstruktør på
oversættelsestidspunktet, afhængig af den kontekst, erklæringen har.
3.4.7 Konstruktører med underforståede parametre
Det er naturligvis også tilladt at bruge underforståede parametre i konstruktøren, ligesom for
normale funktioner. Den eneste regel er, at kun de sidste (mod højre) parametre kan være
underforståede. Overvej implementationen af konstruktøren i følgende klasser:
class Complex1 {
double re, im;
public:
Complex1 () { re = im = 0; }
Complex1 (double r) { re = r, im = 0; }
Complex1 (double r, double i) { re = r, im = i; }
// ...
};
class Complex2 {
double re, im;
public:
Complex2 (double r = 0, double i = 0) { re = r, im = i; }
3.4.6 Klasser med flere konstruktører 149

...
};
Disse to implementationer har samme funktionalitet. Det er muligt at erklære forekomster af
klasserne med nul, et eller to parametre, og alle ikke-specificerede parametre vil blive
nulstillet. Hvornår skal man bruge overstyrede konstruktører, og hvornår skal man bruge
underforståede parametre? Spørgsmålet er ikke let, fordi det kommer an på brugen af klassen
fra klientens side. Generelt giver overstyring et større lagerforbrug i kode, fordi der eksisterer
flere funktioner, mens underforståede parametre giver et større lagerforbrug i data, fordi de
underforståede parametre normalt står som skjulte konstanter i objektkoden. Overstyring af
konstruktøren vil være en smule hurtigere, fordi kun det antal parametre, der er brug for i
funktionen, vil blive overført fra klientens erklæring.
Balancegangen må være, at underforståede parametre er at foretrække, hvis to overstyrede
funktioner er identiske, og antallet af underforståede parametre ikke er for højt - for eksempel
ikke overstiger to. Hvis konstruktør-funktionerne har små forskelle, som kræver betingede
kontrolstrukturer, bør de overstyres. Husk på, at konstruktøren repræsenterer et skjult
funktionskald under erklæringer, hvilket kan blive til en hel del i et program, der bruger
mange forekomster. Derfor skal konstruktørens indhold af kontrolstrukturer minimeres.
3.4.8 Initieringslister
Der er et problem med C++'s regler for forskellene mellem tildeling og initiering. Fra afsnit
2.4.7 huskes det, at konstante typer og reference-typer skal initieres ved erklæringen, idet de
ikke er variable i normal forstand. Overvej nu følgende klasse-definition:
class Stof {
const double smeltePunkt, frysePunkt;
double Temperatur;
public:
Stof (double, double);
void setTemp (double t) { Temperatur = t; }
// ...
};
Stof::Stof (int f, int s) {
frysePunkt = f; // fejl: tildeling til konstant
smeltePunkt = s; // ligeså
}
De to medlemsvariable i klassen Stof er konstante, dvs. de kan ikke ændres hverken udefra
(da de i første omgang er private) eller indefra, da de er const. Konstruktøren, som
150 Initiering og nedbrydning af objekter 3.4

tænkes at bruges på følgende måde
Stof H2O (0, 100); // vand, udtrykt i Celcius
H2O.setTemp (16.8); // normaltemperatur i dansk badevand!
vil ikke kunne oversættes, da den tildeler værdier til konstante data. Samme problem opstår
med datamedlemmer, som er erklæret som referencer. Følgende klasse-definition beskriver et
vindue på en skærm, hvor skærmen er indeholdt som reference til en forekomst af en anden
klasse. Således kan flere vinduer dele samme skærm:
class Screen;
class Window {
Screen& display;
int top, left, bottom, right; // vinduets rammer
public:
Window (Screen&, int, int, int, int);
// ...
};
Window::Window (Screen& s, int a, int b, int c, int d) {
top = a, left = b, bottom = c, right = d; // ok
display = s; // fejl: tildeling til reference
}
Problemet er, at både referencer og konstante variable skal initieres på samme tid, som de
erklæres. I klasser er det imidlertid ikke muligt, fordi klassens definition og instantiering er to
forskellige ting. Derfor findes en initieringsliste i C++, som bruges til at initiere sådanne data.
Initieringslister kan kun forekomme i konstruktører, og har følgende syntaks:
klasse::klasse (type T) : /* initieringer her */ {
/* tildelinger her */
}
Konstruktørerne for Stof og Window kommer således til at se ud som følger:
Stof::Stof (int f, int s) :
frysepunkt (f), smeltepunkt (s) { // initieringer
{ } // tildelinger
Window::Window (Screen& s, int a, int b, int c, int d) :
display (s) // initieringer
{
top = a, left = b, // tildelinger
3.4.8 Initieringslister 151

ottom = c, right = d;
}
Initieringslisten udføres mens objektet oprettes, og initierer de medlemsvariable, der er
beskrevet i initieringslisten i den rækkefølge de er erklæret. Det gør det ikke blot muligt at
initiere konstante data og referencevariable, men har også betydnig for forekomster af andre
klasser, som er indkapslede i den aktuelle klasse samt for initiering af base-klasser, som vi
skal se i kapitel 4.
Der er også en effektivitetsmæssig fordel ved initieringslister. Idet de er en del af
konstruktørens erklæring, kan oversætteren generere bedre kode for oprettelsen af objekter -
en procedure, som ofte foretages - fordi der skal overføres færre parametre explicit til
konstruktøren. Initieringslisten bliver rent faktisk udført på kalderens side af oprettelsen af
forekomsten, hvilket sparer kopiering af initieringsdata til den dummy-funktion, som en
konstruktør egentlig er. Derfor er det også tilrådeligt at bruge initieringslister for ganske
normale medlemsdata.
Læg mærke til, at rækkefølgen af initieringerne ikke følger initieringslisten, men
erklæringen af medlemsdata i klassen. For eksempel,
class X {
int b, a;
public:
X (int x, int y) : a (x), b (a + y) { }
};
Konstruktøren i denne klasse vil resultere i, at a indeholder værdien af x, og at b er
udefineret, fordi b er erklæret før a i klassen. Når der er tale om initieringer af normale
medlemmer, som kræver aritmetiske behandlinger, er det tilrådeligt enten at lave dem om til
normale tildelinger i konstruktørens krop eller at være meget opmærksom på rækkefølgen af
kaldene. Det er en af de slags fejl, der er svære at finde, fordi det for programmøren ser rigtigt
nok ud, men alligevel ikke er det.
Læg også mærke til, at initieringslisten skal skrives der, hvor konstruktøren implementeres,
ikke hvor den defineres. Hvis den skrives udenfor klassens krop, skal initieringen også skrives
udenfor klassens krop, hvilket er det omvendte af reglerne for underforståede parametre, som
skal stå i definitionen af klassen:
class X {
int x;
public:
X (int y) : x (y); // fejl!
};
X::X (int y) { /* ... */ }
Grunden til dette er, at parameterlisterne skal være identiske i definitionen og i
152 Initiering og nedbrydning af objekter 3.4

implementationen af konstruktøren. Hvis initieringslisten forekommer i definitionen er der
som regel ikke brug for de parametre, som bruges i initieringen i selve konstruktørens krop -
men de skal stadig stå der til ingen verdens nytte. Derfor skal initieringslisten stå sammen
med konstruktørens implementation:
class X {
int x;
public:
X::X (int);
};
X::X (int y) : x (y) { /* ... */ }
3.4.9 Destruktøren
Hvor konstruktøren opretter objekter, er destruktøren ansvarlig for nedbrydningen.
Destruktøren varetager opgaver som deallokering af lager, frigivning af hardware, lukning af
filer - kort sagt alle de funktioner, klienten normalt kalder ved endt brug af en ressource eller
datastruktur. Når et objekts skop render ud (2.6.1) vil destruktøren blive kaldt helt automatisk.
Destruktøren er en medlemsfunktion med samme navn som klassen, men med en tilde (~)
før navnet. En klasse må kun have en enkelt destruktør, idet den kaldes implicit og derfor ikke
kan være afhængig af kaldeformen. Af samme grund kan den ikke have en returværdi.
Her er et eksempel på Memory-klassen med en destruktør:
class Memory {
char* mem_ptr;
int size;
public:
Memory (int i = BUFSIZ) { // konstruktør
mem_ptr = new char [size = n];
}
~Memory () { // destruktør
delete mem_ptr;
}
// ...
};
Oversætteren har en indbygget, underforstået destruktør, som kaldes i alle tilfælde. Den
underforståede destruktør frigiver alt lager, som optages af de variable, der er medlem af
klassen. Derfor frigiver Memory::~Memory() ikke selve pointervariablen mem_ptr og
heltallet size, men kun det lager, som konstruktøren har allokeret.
Den store fordel ved destruktøren er den samme som for konstruktøren: klienten behøver
ikke eksplicit at kalde oprydnings-funktioner, som "gør rent" i lageret eller lignende efter endt
3.4.8 Initieringslister 153

ug af et objekt. Når destruktøren automatisk kaldes, kan klasse-udbyderen være sikker på,
at alt sker, som det skal. Det er ikke mere klientens ansvar at kalde disse funktioner. Dette
koncept er en naturlig følge af indkapsling. Idet vi med klasserne skjuler
implementationsdetaljer fra klienten, så denne kan abstrahere fra de indre detaljer, skal
klienten heller ikke bære ansvaret for at kalde specielle funktioner på specielle tidspunkter.
Det skal gøres automatisk. Når vi bruger en float kalder vi ikke specielle
oprydningsfunktioner, og bør derfor heller ikke gøre det for abstrakte datatyper.
3.4.10 Hvornår kaldes en destruktør
Når en klasse har en destruktør, kaldes denne hver gang en forekomst af den klasse slutter sit
skop (afsnit 2.6.1). For automatiske variable er det slutningen af den blok, hvori den er
defineret, for statiske variable er det slutningen af programmet og for dynamisk allokerede
variable er det når de fjernes af brugeren med delete. For eksempel:
class X { // et koncept "X"
X (); // konstruktør
~X (); // destruktør
// ...
};
static X a; // a.X() kaldes ved programstart
void main () {
static X b; // b.X() kaldes ved programstart
X c; // c.X() kaldes her
X* e;
{
X d; // d.X() kaldes her
e = new X; // e->X() kaldes her
} // d.~X() kaldes her
X f; // f.X() kaldes her
delete e; // e->.~X() kaldes her
} // a.~X(), b.~X(), c.~X() og f.~X()
// kaldes her
Det er muligt at kalde en destruktør eksplicit med
X xobj;
xobj.~X(); // eksplicit destruktion
men det er næppe brugbart under normale omstændigheder - måske kun i situationer, hvor
programmet skal afbrydes og en særlig oprydning skal finde sted, som forbipasserer standard-
154 Initiering og nedbrydning af objekter 3.4

kaldende ved programmets slutning. Et kald til abort(), C-funktionen, der afbryder uden
tøven, er et eksempel på dette.
Hvis konstruktøren og destruktøren til klassen X overfor implementeres således
X::X () { cout

Complex ();
Complex (double, double = 0);
Complex add (Complex&);
Complex sub (Complex&);
Complex mul (Complex&);
void print ();
};
// complex.cpp
// eksempel 3-4b: en C++-implementation af et komplekst tal
#include
#include
// tom konstruktør: nulstiller alt
inline Complex::Complex () {
re = 0, im = 0;
}
// konstruktør med en eller to initierings-variable
inline Complex::Complex (double r, double i) {
re = r, im = i;
}
// addér to komplekse tal.
Complex Complex::add (Complex& c) {
Complex temp;
temp.re = re + c.re;
temp.im = re + c.im;
return temp;
}
// subtrahér to komplekst tal
Complex Complex::sub (Complex& c) {
Complex temp;
temp.re = re - c.re;
temp.im = re - c.im;
return temp;
}
// multiplicér to komplekse tal
Complex Complex::mul (Complex& c) {
Complex temp;
156 Initiering og nedbrydning af objekter 3.4

temp.re = re * c.re - im * c.im;
temp.im = re * c.im + im * c.re;
return temp;
}
// udskriv et komplekst tal
void Complex::print () {
cout

initierer en Complex fra andre typer, hvilket et af kravene til typen også var (afsnit 3.2). Vi
kan tildele en forekomst af Complex til en anden Complex med:
Complex a = 2; // initiér a med (2, 0)
Complex b = a; // initiér b med a, medlemsvist kopieret
Oversætteren kopierer ganske simpelt alle medlemmer af a (de to double'r re og im) én
for én til de tilsvarende pladser i b, og kalder de underforståede konstruktører under
oprettelsen af de nye medlemsdata. Dette er til forskel fra kopiering af objekter i C og i de
allertidligste versioner af C++, hvor det sker bitvist, uden kald til konstruktører af nogen art.
Der er dog klasser, som får problemer med denne simple kopiering. Memory-klassen
indeholder for eksempel en pointer til noget lager, som allokeres i konstruktøren. Hvis vi
foretager følgende tildelinger med Memory, som vi gjorde med Complex:
Memory a (1000); // initiér a med 1000
Memory b = a; // initiér b med a
ser vi, at a først oprettes med 1000 enheder (konstruktøren sætter bla. den private variabel
a.mem_ptr til starten af lageret) og at initieringen af b ikke eksplicit kalder nogen
konstruktør, da den initieres med en tildeling til en anden forekomst af Memory. Når vi så
tildeler b værdien af a, vil pointervariablen b.mem_ptr blive overskrevet med flere
problemer til følge:
• a og b bruger samme lagerplads. Selvom de respektive variable er allokeret separat,
er den ene en pointervariabel, som nu er blevet ændret. Det kan og vil give
problemer i brugen af a og b.
• Medlemsvariablen b.mem_ptr, som pegede på allokeret lager, har nu ændret
værdi som følge af kopieringen. Det allokerede lager er så at sige tabt, fordi vi ikke
ved, hvor det befinder sig. Det betyder også, at
• Når forekomsterne deallokeres senere i en destruktør, vil der opstå problemer, fordi
lageret frigives to gange. Der er kun allokeret lager én gang, men destruktøren kaldes
to gange.
Kernen i problemet er, at en af medlemsvariablene i Memory er en pointertype. Vi har brug
for at fortælle oversætteren, hvad den skal gøre når en bruger forsøger at initiere en forekomst
af Memory med en anden forekomst af samme klasse. Det er her vigtigt at forstå forskellen
mellem initiering og tildeling. Initiering forekommer i tre sammenhænge:
• erklæring med initieringer (som den, vi lige har beskrevet), hvor et objekt erklæres
og initieres i samme sætning,
158 Initiering og nedbrydning af objekter 3.4

• formelle parametre i et funktionskald, dvs. hvor et objekts værdi overførers fra en
funktion til en anden,
• returværdier fra en funktion, hvor et objekt overføres til den kaldende funktion.
Tildelinger forekommer kun i udtryk - stadig ikke i erklæringer - som bruger tildelingsoperatoren
=. Det er altså ikke det samme, når vi skriver
og
Complex a = b; // erklæring og initiering
Complex a; // erklæring
a = b; // tildeling
3.4.13 Kopi-konstruktøren
Det første problem er altså initiering. Når et objekt erklæres med samtidig initiering fra et
andet objekt, vil der normalt forekomme en simpel kopiering, hvilket, som vi har set, kan
skabe problemer. For at løse dette bruger vi en speciel konstruktør med et enkelt parameter,
som er en reference til en forekomst af samme type som klassen selv. En sådan konstruktør
kaldes en kopi-konstruktør, og kopierer ganske simpelt en forekomst. Kopi-konstruktøren
erstatter den indbyggede kopi-funktion i C++. En kopi-konstruktør for Memory-klassen kan
skrives på følgende måde:
Memory::Memory (Memory& m) {
mem_ptr = new char [size = m.size];
memcpy (mem_ptr, p.mem_ptr, m.size);
}
Denne konstruktør kaldes, og kaldes kun, når et objekt af typen Memory erklæres og
initieres med værdien af et andet Memory-objekt i samme sætning. Følgende sætninger
demonstrerer brugen:
Memory a (100); // Memory::Memory (int) kaldes for
// konstruktion af a
Memory b = a; // Memory::Memory (Memory&) kaldes
// for konstruktion af b fra a
Kopi-konstruktøren Memory::Memory (Memory&) allokerer plads til b's interne lager
ved en reference til a's size-variabel, og kopierer også size. Husk at C++ benytter
klasse-baseret indkapsling, hvilket er grunden til, at kopi-konstruktøren kan referere både a's
og b's private medlemsvariable. Dernæst kopierer kopi-konstruktøren lagerpladsen fra a til
b, så b bliver helt identisk med a. Vi kan se, at den opgave, der består i at initiere en
3.4.11 Anden løsning i C++ 159

forekomst af Memory med en anden er noget mere omfattende end blot en medlemsvis
kopiering.
Vi løber ind i et andet problem, når en forekomst af Memory tildeles en anden forekomst
af Memory. Her har vi en anden situation, nemlig en tildeling til et allerede initieret objekt.
Kopi-konstruktøren kan kun bruges, når objektet, der erklæres, endnu ikke er initieret, hvilket
er grunden til, at det hedder en kopi-konstruktør. Når vi blot tildeler et objekt til et andet, som
i
Memory a (100), b (50); // to erklæringer
a = b; // en tildeling
er objektet, som tildeles et andet objekt (her a), allerede initieret. Kopi-konstruktøren, som
allokerer nyt lager, vil derfor ikke kunne bruges.
Dette problem løses med en definition af en tildelings-operator-funktion, som reelt er en
overstyring af lighedstegnet for den aktuelle klasse. Næste afsnit (3.5) beskriver operatoroverstyring,
og kommer også ind på overstyring af tildelings-operatoren for at løse netop
dette problem.
3.4.14 Statiske objekter
Hvis et objekt erklæres med globalt skop (udenfor en funktion) eller erklæres som en statisk
variabel i en funktion (med static-nøgleordet), er objektets levetid defineret fra
programmet start til slut. For statisk erklærede forekomster af brugerdefinerede typer gælder,
at C++ kalder konstruktøren som det allerførste - altså før main() - og destruktøren efter
main(). Hvis vi for eksempel skriver
Complex a (-4, 4.2);
void main () {
static Complex b (3);
// ...
}
vil C++ foretage konstruktørkaldene Complex::Complex(-4, 4.2) for a og
Complex::Complex(3) for b før programmets egentlige start. Ligeledes vil
Complex::~Complex() blive kaldt for begge objekter umiddelbart før programmet
afsluttes.
Konstruktører og destruktører i statiske objekter eller objekter med eksternt skop kaldes
statiske konstruktører og statiske destruktører. Det kræver ingen særlig syntaks at definere
statiske konstruktører og destruktører, og definitionen bruges blot til at beskrive deres brug
samt at markere, at de kun kaldes én gang. Der skal ikke skrives speciel kode for at behandle
statiske forekomster, så enhver konstruktør bliver statisk for en given forekomst, når denne
erklæres statisk. Statiske objekter er brugbare i steder så som biblioteker, som skal initiere
specielle data, før de kan bruges.
160 Initiering og nedbrydning af objekter 3.4

3.4.15 Pointere og referencer til objekter
Reglerne for manipulation af data via pointere og referencer er nøjagtig de samme for
brugerdefinerede typer som for fundamentale typer. Det kan være svært at se, hvordan en
større, kompleks abstrakt datatype kan derefereres med * eller ->, specielt i forbindelse
med returværdier og tildelinger. Det kan derfor hjælpe at foregive, at objektet er fundamentalt
og tænke syntaksen igennem en gang til. Hvis en variabel V er en pointer til en type T vil
udtrykket *V kunne bruges i alle sammenhænge, som en normal forekomst af T kan bruges.
Idet pointere og referencer kun bærer adresse- og typeinformation i erklæringen, har de ikke
nogen forekomst at have med at gøre. Derfor kaldes ingen konstruktører eller destruktører for
pointere og referencer til abstrakte datatyper:
Complex a; // a.Complex() kaldes
Complex& b = a; // ingen konstruktør kaldes
Complex* c = &a; // heller ikke her
Indirekte reference til objekter med fortegns-operatorerne * og & følger igen samme regler
som for de indbyggede typer. Følgende kodefragment er derfor lovligt og ganske rimeligt:
class String { // generel tekst-streng
char* cp;
public:
String () { cp = 0; } // konstruér "tom" streng
String (char*); // konstruér fra C++-streng
String (String&); // konstruér fra String
~String ();
// ...
void f (); // medlemsfunktion
};
void f () {
String navn = "C.S.N.";
String* s = &navn; // String-pointer initiering
s->f(); // kald f i *s
String kopi = *s; // kalder kopi.String (String&
*s);
String& p = navn; // String-reference initiering
}
Det er oftest i forbindelse med funktionskald, at pointer-typer og reference-typer finder størst
anvendelighed:
3.4.14 Statiske objekter 161

*s
void f (String* s, int antal) {
while (antal--) s++ -> f (); // kald f() for alle
}
String& match (String* s, int antal) {
String temp; cin >> temp;
while (antal--)
if (*s++ == temp) return *--s; // returnér hvis ens
return String (); // returnér tom
streng
}
3.4.16 Dynamiske objekter
Abstrakte datatyper kan allokeres dynamisk i lageret med new og delete fuldstændig som
de fundamentale typer:
Complex* a = new Complex;
// ...
delete a;
C++ ser en allokering af en abstrakt datatype som starten på et skop af et nyt objekt, og kalder
en passende konstruktør når objektet allokeres med new samt destruktøren når det
deallokeres med delete. Det er tilladt at give information til konstruktøren under
allokeringen:
Complex* a = new Complex (5, 5);
Læg mærke til, at destruktøren i et dynamisk allokeret objekt, som ikke deallokeres med
delete, aldrig vil blive kaldt. Det er derfor endnu vigtigere at huske dette end for normale
forekomster af fundamentale typer.
Læg også mærke til, at dynamisk allokerede objekter kan arbejde sammen med referencer
og pointere på en meget subtil måde i forbindelse med funktioner. Givet
void pushComplex (Complex&);
som er en (prototype på en) funktion, der tager en reference til en Complex som parameter,
kan vi skrive
pushComplex (*new Complex);
Umiddelbart ser det ud som om, at vi allokerer en forekomst af Complex uden at tildele
162 Initiering og nedbrydning af objekter 3.4

adressen til en pointervariabel. Og hvordan skal vi så kunne delete dette lager igen? I
virkeligheden tildeles den nye forekomst til referencetypen i pushComplex(), som er det
faktiske objekt. Husk, at referencetyper skal initieres når de erklæres, og at dette også gælder
for parametre i funktioner. Parameteren i pushComplex() erklæres, når funktionskaldet
foretages, og initieres med det samme med indholdet af det nyallokerede objekt, på hvilket
tidspunkt konstruktøren kaldes. Initieringer til konstruktøren er selvfølgelig også tilladt:
pushComplex (*new Complex (4));
Grunden til, at der der er en dereference-operator før new i funktionskaldet er, at vi overfører
en faktisk forekomst - ikke en pointer. Men det betyder ikke, at hele objektet føres til
pushComplex(), fordi funktionen er erklæret med en referenceparameter. Så selvom den
nyallokerede forekomst derefereres, er det alligevel kun adresseinformation, som gives til
funktionen.
Det er eksempler som dette, som gør C++ fantastisk kraftfuldt. Men det er vigtigt at forstå,
præcis hvad der foregår. Programmører, som har brugt Pascal, Fortran eller Cobol vil finde
referencer og dereferencer i disse sammenhænge svære at greje. Det "rene" pointerkoncept i C
er i forvejen temmelig avanceret for selv kyndige programmører med erfaring i andre sprog,
og selv erfarne C-programmørers indlæringskurve stejler, når det kommer til referencer og
pointere, som blandes godt og grundigt sammen. Den bedste måde at forstå C++'s faciliteter
på dette punkt er at skrive et par små programmer med abstrakte typer, som indeholder
konstruktører og destruktører med små "pop-up" beskeder. Opgavesamlingen i slutningen af
kapitlet indeholder et par forslag.
Reglerne for destruktion af automatiske variable af vektor-typen (erklæret med lokalt skop i
en funktion eller blok) samt for statiske variable af vektor-typen (erklæret med globalt skop
udenfor funktions-kroppe) følger de normale regler og vil blive destrueret korrekt for alle
medlemmer. Dette sker, fordi oversætteren ved, hvor mange objekter, der er allokeret i
vektoren og kan derfor kalde det korrekte antal destruktører. Ligeledes for dynamisk
allokerede objekter, der er vektorer, foregår destruktionen af vektoren automatisk. Dette er til
forskel fra tidligere versioner (før 2.0) af C++, hvor det var påkrævet at angive vektorens
størrelse efter delete-udtrykket, som i følgende fragment:
int* heltal = new int [100];
// ...
delete [100] heltal;
Denne fremgangsmåde var nødvendig, fordi en pointer som heltal ikke er erklæret som en
vektor, hvorfor en delete uden længdeangivelse blot ville deallokere en enkelt forekomst,
nemlig den, som pointeren refererer. I nyere versioner af C++ er denne semanik indbygget i
pointerne, hvorfor konstruktionen er forældet (men accepteres og ignoreres stadig af de fleste
oversættere). I øvrigt er det en god ide at erklære pointere, der udelukkende bruges i
forbindelse med kald til new som konstante pointere, så de ikke uhensigtsmæssigt ændrer
værdi og går galt i byen i en delete-sætning.
3.4.16 Dynamiske objekter 163

3.4.17 Vektorer af objekter
Brugerdefinerede datatyper kan, som alle andre typer, afledes efter reglerne fra afsnit 2.4.
Klienten kan således oprette vektorer af objekter efter samme syntaksmæssige regler som for
fundamentale datatyper. En vektorerklæring af en brugerdefineret type vil allokere det antal
forekomster, der angives af klienten og initiere dem én for én ved konstruktørkald til de
enkelte elementer.
Klassen String fra afsnit 3.4.14 beskriver en generel streng, dvs. en sekvens af tegn.
Denne type findes som bekendt ikke i C++, og er en god kandidat til indkaplsling i en klasse.
En klient kan udover normale skalære instantieringer af String oprette vektorer efter de
normale regler:
String navne [30]; // 30 strenge
En sådan erklæring vil resultere i 30 allokeringer af String-objekter (30 char-pointere)
og 30 kald til hvert objekts underforståede String::String()-konstruktør:
navne [0].String ();
navne [1].String ();
navne [2].String ();
// ...
navne [29].String ();
Klienten refererer de individuelle objekter på vektoren med medlemsreference-operatoren:
navne [7].f (); // kald f () for 7. element i vektoren
Når vektor-objekter af klasser med destruktører går ud af skop, kaldes destruktøren for alle
objekterne på vektoren i omvendt rækkefølge:
navne [29].~String ();
navne [28].~String ();
navne [27].~String ();
// ...
navne [0].~String ();
Da vektor-erklæringer kalder mange konstruktører og destuktører, er det en god idé at lade
disse funktioner være meget små og eventuelt skrive dem inline for maksimal effektivitet.
De fleste oversættere vil være i stand til at kunne generere en løkke for initiering af alle
objekterne uden det store pladsmæssige forbrug. Dog er store vektor-erklæringer ikke noget,
der bør foregå for ofte i et program, og der henvises i øvrigt til inline-diskussionen i afsnit
2.6.12
Vektoren af String kan naturligvis også initieres på lige fod med normale erklæringer
164 Initiering og nedbrydning af objekter 3.4

med en initieringsliste i en blok:
String navne [3] = { "Jonas", "Laura", "Rikke" };
Her vil de underforståede kald til Strings konstruktør for de tre objekter på navnevektoren
blive gjort til String::String(char*), så de tre objekter bliver initieret med
de respektive C++-strenge i blokken:
navne [0].String ("Jonas");
navne [1].String ("Laura");
navne [2].String ("Rikke");
Hvis angivelsen af vektor-størrelsen er tom (String navne []), vil størrelsen af vektoren
afhænge af antallet af elementer i blokken. Hvis angivelsen af vektor-størrelsen er større end
antallet af elementer i blokken, vil den underforståede konstruktør blive kaldt for de sidste
objekter på vektoren, for hvilke der ikke er eksplicit initierings-data.
Initiering af vektorer af objekter, for hvilke der er konstruktører, som tager to eller flere
paramatre, er syntaksen en smule anderledes. Den numeriske type Complex kan for
eksempel instantieres med to initierings-parametre, og skal derfor oprettes på følgende måde i
skalære erklæringer:
Complex c (10,-1); // Complex c = 10,-1 går ikke
Vektor-erklæringer af typer med den slags konstruktører ser følgelig således ud:
Complex fft_data [4] = { // fire komplekse tal
Complex (3.14, -1), Complex (6.28, -1),
Complex (-3.14, 1), Complex (-6.28, 1)
};
Konstruktør-kaldet udtrykkes dermed eksplicit i stedet for implicit i initieringsblokken. Dette
skyldes simpelthen syntaksen for oprettelse af brugerdefinerede objekter, og hænger til dels
sammen med sprogets syntaksmæssige krav til kompatibilitet med C.
3.5 OVERSTYRING AF OPERATORER
Vi husker fra gennemgangen af C-løsningen på eksempel-problemet med det komplekse tal,
at syntaksen og semantikken i behandlingen af forekomsterne af Complex langtfra var,
hvad vi er vant til med de indbyggede typer. Vi skulle kalde specielle funktioner i bestemte
rækkefølger for at manipulere med objekterne. For at udføre d = a * b - c skulle vi
3.4.17 Vektorer af objekter 165

skrive
mul_Complex (a, b, temp); /* temp1 = a * b */
sub_Complex (temp, c, d); /* d = temp1 - c */
C++ tillader os at redefinere den semantiske mening af næsten alle operatorer for en given
klasse, så for eksempel aritmetiske behandlinger af Complex-forekomster kan foregå mere
naturligt fra en klients synspunkt:
d = a * b - c; // kræver vist ingen forklaring
Faktisk bruger de fleste programmører allerede operator-overstyring, selv om de ikke tænker
over det, fordi næsten alle sprog automatisk overstyrer operatorerne for de indbyggede typer.
I C kan vi for eksempel skrive
int i, j = 2, k = 3;
double f, g = 4.6, h = 8.7;
i = j + k;
f = g + h;
Vi finder det helt naturligt at udtrykket i = j + k adderer to int-typer og tildeler
resultatet en tredie, mens f = g + h gør det samme for tre float-typer. Men
operatorerne = og + har helt forskellige semantik. Den første sætning udfører en heltalsaddition
og heltals-tildeling, mens den anden udfører en kommatals-addition og kommatalstildeling.
Oversætteren behandler heltal og kommatal helt forskelligt som interne
fundamentale typer, og genererer derfor helt forskellig kode for de to sætninger. = og + er
derfor overstyrede operatorer; de har forskellige betydninger i henhold til den kontekst, de
bruges i.
Den store pointe her er, at klienten ikke behøver at bekymre sig om dette. Oversætteren kan,
på grundlag af type-informationen, generere den korrekte kode. Brugerdefineret overstyring
af operatorer for en given C++-klasse er simpelthen en udvidelse af dette koncept: det skal
være muligt at manipulere med forekomster af en hvilken som helst type ved brug af
standard-operatorerne. Dette er muligt, fordi en klasse er en type, som i grunden er ligeså reel
som de fundamentale typer i C++. Oversætteren har al type-information til rådighed, når en
abstrakt datatype udsættes for en operator i en sætning, og kan derfor diskriminere et udtryk
som d = a * b - c for int-typer, double-typer og Complex-typer. Alt, hvad vi
behøver gøre er at at fortælle oversætteren, hvad den skal gøre, når dette sker.
Vi befinder os nu på et grænseland mellem applikations-programmering og
oversætterdesign: at overstyre C++-operatorer er faktisk en udvidelse af oversætterens
semantik. Vi udvider sproget med nye betydninger af samme syntaks. Det kræver naturligvis,
at vi følger visse regler: lad for eksempel være med at overstyre + til at subtrahere. Klienten
skal kunne bruge operatorerne til at abstrahere fra eksplicitte funktionskald og benytte
standard C++-syntaks med samme fordele som de indbyggede operator-overstyringer i
sproget.
166 Overstyring af operatorer 3.5

3.5.1 Operator-funktioner
En operator @ kan overstyres med en funktion til behandling af et udtryk, i hvilken
operatoren @ kombineres med en eller flere operanter af en eller flere bestemte typer. En
funktion erklæres med operator-nøgleordet og operatorens symbol. Skriver vi for
eksempel
Complex a (5, 7), b (2, -3);
Complex c = a - b;
vil oversætteren forsøge at kalde en funktion operator- (operator minus), som tager to
Complex-typer som parametre og har en Complex som returværdi. En sådan funktion kan
implementeres således:
Complex operator- (Complex& a, Complex& b) {
Complex temp (a);
temp.sub (b);
return temp;
}
C++ vil erstatte udtrykket a - b med et funktionskald til operator-() med referencer
til a og b som parametre. operator-() udfører de nødvendige behandlinger af a og
b, og klarer selv brugen af midlertidige variable internt. temp er en midlertidig Complex,
som returneres som resultat af udregningen a - b, og som videre tildeles til c.
Det er altså den samme opgave, der bliver løst, men med en anden og for klienten bedre
syntaks.
3.5.1 Hvad kan overstyres?
Det er tilladt at overstyre følgende operatorer i C++:
[ ] ( ) (type) ++ --
& * + - ~
! / % >
< > = ==
!= ^ | && ||
= *= /= %= +=
-= = &= ^=
3.4.17 Vektorer af objekter 167

|= -> ->* new delete
sizeof
og ulovligt at overstyre
.* . :: ?:
Det er tillige ikke tilladt at definere operator-funktioner for andre symboler end de, som ligger
indbygget i sproget, hvilket gør det ulovligt at erklære en ny operator for for eksempel potensopløftning
(** bruges i flere andre sprog). Det er heller ikke muligt at ændre den indbyggede
præcedens operatorerne imellem. Med andre ord, * vil altid have højere prioritet end + og
-.
Alle binære operatorer, dvs. operatorer, der arbejder på to operanter (for eksempel *), kan
overstyres med operator-funktioner, som tager to parametre, som i ovenstående eksempel
Fortegns-operatorerne, dvs. de, der arbejder på en enkelt operant (for eksempel ! og ~), kan
overstyres med operator-funktioner, som tager et enkelt parameter. Dette gør det muligt at
diskriminere mellem et fortegnsminus og en subtraktion, eller mellem brugen af & som binær
AND og som addresse-på operator:
Complex operator- (Complex&, Complex&); // subtraktion
Complex operator- (Complex&) // fortegnsminus
Complex operator& (Complex&); // addresse-på
Complex operator& (Complex&, Complex&); // bitvis AND
Den eneste operator som tager tre operanter, den triadiske aritmetiske if/else (?:), kan
ikke overstyres.
3.5.3 Overblik
Det er interessant, at lageradministrations-operatorerne new og delete kan overstyres.
Ved at erstatte de indbyggede betydninger af disse operatorer kan en komplet bruger-defineret
lageradministration af en type opnås, især i forbindelse med overstyring af pointer- og
dereference-operatoren * samt reference- og adresse-på operatoren &. Udover new og
delete er indeks-operatoren [] og funktions-kald operatoren () ikke åbenlyse
kandidater, men kan være yderst brugbare.
Det er ikke muligt at overstyre betydninger af operatorer for de fundamentale typer. Med
andre ord, vi kan ikke redefinere meningen af for eksempel + for to int'er. Det er tilladt at
have fundamentale typer som parametre i operator-funktioner, men de må ikke bestå af
udelukkende fundamentale typer:
168 Overstyring af operatorer 3.5

int operator+ (int, int); // ulovlig!
Det er muligt at definere en klasse, som opfører sig akkurat som en indbygget type, og så
overstyre operatorerne for denne klasse. Fordelen ved dette skal ses i sammenhæng til
klassens relationer til andre klasser, et forhold, vi kommer ind på i næste kapitel. Men en
erstatning af de fundamentale typer med abstrakte typer giver en væsentlig reduktion i
performance.
Det er tilladt at skrive operator-funktioner som inline-funktioner, hvilket sætter
hastigheden på operationerne drastisk i vejret. Men som for alle inline-funktioner vil du
tabe i kodens størrelse hvad du vinder i dens hastighed. Større funktioner bør ikke inlines,
heller ikke operator-funktioner.
Der er ingen forskel på operatorernes associativitet og præcedens i forhold til hinanden,
men i tidligere versioner af C++ (før 2.1) var det ikke muligt for oversætteren at skelne
mellem en optælling (++) før og efter objektet. Med andre ord, givet en forekomst af en
abstrakt datatype obj, så ville
etObjekt++; // postfix-optælling
++etObjekt; // prefix-optælling
være det samme. I medlemsfunktionen operator++() var det ikke muligt at se, om det
var en prefix eller postfix anvendt operator. I nyere versioner af C++ findes en udvidet
syntaks for netop denne operator (samt naturligvis nedtællingsoperatoren --), som tillader
os at skelne mellem netop disse to anvendelser. Vi udnytter her, at udtrykket a++0 er
syntaktisk ækvivalent til a+0 og lader vores postfix-optællingsfunktion modtage et
parameter, som vi ikke benytter os af på følgende måde:
class X {
public:
operator++ (); // prefix-optælling (++x)
operator++ (int); // postfix-optælling (x++)
operator-- (); // prefix-nedtælling (--x)
operator-- (int); // postfix-nedtælling (x--)
};
void f (X* x) {
++x; // kalder X::operator++ ()
x++; // kalder X::operator++ (int)
--x; // kalder X::operator-- ()
x--; // kalder X::operator-- (int)
}
Heltallet, der overføres til postfix-operatoren er altid 0, medmindre funktionen kaldes
eksplicit (se nedenfor). Denne udvidelse i C++ betyder også, at vi skal være opmærksomme
3.5.3 Overblik 169

på, at de gamle op- og nedtællingsoperatorfunktioner automatisk bliver til prefix-optællinger
hvis de oversættes under nyere systemer. I øvrigt er det ikke tilfældigt, at det er postfixoperatoren,
der modtager et ekstra parameter: alle fortegnsoperatorer har kun ét parameter i
C++ og det har derfor været en nødvendighed at snyde med syntaksen i postfix-operatoren.
Alle operator-funktioner kan i øvrigt kaldes eksplicit. Den ovenstående funktion kan også
kaldes med udtykket
a = operator++ (b);
Eksplicitte funktionskald bruges så godt som aldrig fra klientens programmer, men kan i visse
tilfælde være eneste mulighed fra andre medlemsfunktioner, hvis operanten ikke eksisterer
som egentlig forekomst, eller hvis den er ukendt. Postfix-optællingen kan kaldes med
a = operator++ (b, 0);
eller et andet heltal.
3.5.4 Overstyring af fortegns-operatorer
Fortegns-operatorerne (de modadiske) arbejder alle på en enkelt operant, og omfatter:
& * ~ ! ++
-- (type) sizeof new delete
Disse operatorer kan alle overstyres med en operator-funktion, som tager et enkelt
parameter, og returnerer en forekomst af samme type som parameteren. Der er to undtagelser:
sizeof-operatoren skal returnere en værdi af typen size_t, som er defineret i headerfilen
stddef.h. (type)-operatoren bruges til brugerdefinerede typekonverteringer, og
skal returnere en værdi af samme type, som den, der står i parantesen. Det er meget sjældent,
og ofte farligt, at overstyre sizeof, fordi C++ i visse sammenhænge har skjulte
medlemmer i en klasse. Operator-funktionerne for brugerdefineret typekonvertering samt for
lageradministration (new og delete) beskrives senere i kapitlet.
3.5.5 Overstyring af binære operatorer
De binære (dyadiske) operatorer arbejder alle på to operanter, og omfatter:
%
& * + - /
> ^ | && ||
For binære operatorer gælder det, at operator-funktionen skal modtage to parametre. Disse
170 Overstyring af operatorer 3.5

ehøver ikke nødvendigvis at være af samme type, men er det oftest. Normalt kan operatorfunktioner
med parametre af andre type end returværdien undgås ved hjælp af brugerdefineret
typekonvertering.
Oversætteren har ingen prædefineret idé om, hvilke operationer de forskellige operatorer
gør. Det er en fordel, når vi ønsker en betydning af en operator, som ikke findes i forvejen.
Hvis vi for eksempel ønsker at uddrage "fællesmængden af to mængder", kan vi bruge &operatoren.
Oversætteren er ligeglad med, om & betyder bitvis-AND eller fællesmængde-af.
3.5.6 Overstyring af relationelle operatorer
Alle relationelle operatorer kan overstyres. De relationelle operatorer er:
< > = == !=
Overstyringen af de relationelle operatorer er næsten identisk med overstyringen af de binære.
Forskellen er, at operator-funktionen skal returnere en værdi, der kan testes for værende
"sand" eller "falsk". "Falsk" betyder, at værdien er nul, og "sand", at den er alt andet end nul.
Grunden til, at "sand" og "falsk" står i citationstegn er, at returværdien kan være
hvadsomhelst, blot den kan konverteres til en fundamental type.
Normalt returnerer en relationel operator-funktion en int:
int operator== (Complex& a, Complex& b) {
if (a.isEqual (b)) // sammenlignings-medlemsfunktion
return 1;
else
return 0;
}
Det kan være meget nyttigt at overstyre de relationelle operatoter flere gange - dvs. at
overstyre funktionsnavnene for de overstyrede operatorer - for derved at opnå muligheden for
at kunne sammenligne klasser på kryds og tværs. Dette diskuteres nærmere i afsnit 3.5.16.
3.5.7 Overstyring af tildelings-operatorer
Alle tildelings-operatorer kan overstyres. Disse omfatter:
= *= /= %= += -=
= &= ^= |= !=
Tildelings-operatorer implementeres som de singulære operatorer, dvs. operator-funktioner,
som har en enkelt parameter. Den eneste forskel er, at der ikke er nogen returværdi, samt at
operator-funktionen skal være medlem af en klasse (se afsnit 3.5.10).
3.5.5 Overstyring af binære operatorer 171

Det er normalt ikke nødvendigt at skrive en tildelings-operator, hvis alle medlemmer af
klassen er fundamentale typer. Hvis der imidlertid er medlemmer, som er afledte typer, eller
som er forekomster af andre klasser, er en speciel tildeling nødvendig. Hvis der ikke skrives
en tildelings-funktion, vil et udtryk som
a = b;
simpelthen kopiere indholdet af b til a. Dette skaber de samme problemer som de, vi
diskuterede i afsnit 3.4.11. Kopiering af objekter med tildelings-operatoren diskuteres i afsnit
3.5.12.
De andre tildelings-operatorer, som er hybrider af en aritmetisk eller logisk operator samt en
tildeling, kræver i alle tilfælde en specialskreven operator-funktion. Oversætteren kan ikke
addere to forekomster af brugerdefinerede typer uden hjælp, så der findes ingen
underforståede funktioner til disse tildelings-operatorer.
3.5.8 Overstyring af særlige operatorer
Overstyringer af tilgangsoperatoren til medlemsvariable i datastrukturer eller klasser, ->,
kan overstyres. Et udtryk som k->m fortolkes som (k.operator->())->m. Af den
grund skal en overstyring af denne operator returnere en pointer til et objekt med det
pågældende medlem, eller et for hvilket operatoren også er overstyret. Denne overstyring kan
for eksempel anvendes til at skabe et implicit kald til funktioner under referencer til
medlemmer. På denne måde kan visse medlemmer være public i klassen, og dog være
beskyttet af en overstyret tilgangsoperator. For eksempel,
struct Person {
char* navn;
unsigned alder;
}
class PP { // "abstrakt" pointer til en Person
Person* pers;
public:
PP (Person* p) : pers (p) { }
Person* operator->();
};
// udfør lidt triviel konsistenscheck på den aktuelle Person
Person* PP::operator-> () {
if (pers->navn == 0) {
172 Overstyring af operatorer 3.5

cerr navn
alder ()-
>alder
}
Operatorerne new og delete kan også overstyres, både globalt og for en given klasse
alene. Prototyperne er:
void* operator new (long);
void operator delete (void*);
Ved at overstyre disse to operatorer er det muligt at allokere lager på mere sofistikerede
måder end normalt. For eksempel kan et (objekt-baseret) virtuelt lager administreres af disse
overstyrede operatorfunktioner samt en overstyring af operator*() for forskellige
klasser, så allokeringsrutinen kan vælge en passende metode til udlæsning af objekter for at få
plads til de nye - last used eller least used, for eksempel. Når disse overstyringer blandes
sammen med overstyringer af op- og nedtælling, baner de vejen for semantisk fuldstændige
"kloge pointere".
3.5.9 Retningslinier for operator-overstyring
Selvom principperne bag operator-overstyring er simple, er det ikke en teknik, der bør bruges
uden omhyggelig planlægning og omtanke. Operator-overstyring er så kraftfuld en teknik, at
den kan misbruges på utallige måder, mest med ulæselige programmer til følge. Her er et par
retningslinier for, hvad man bør tilstræbe og hvad man bør undgå:
• Lad så vidt muligt de oprindelige semantiske betydninger af operatorerne stå. Mange
begyndere i C++ bliver så glade for operator-overstyring, at de fuldstændig
forvrænger sproget. C og C++ definerer næsten alle specialtegn i ASCII-sættet til at
have mindst én betydning. Prøv at bibeholde denne betydning - lad for eksempel
være med at redefinere ^ til at stå for potens-opløftning, da den normale betydning
er bitvis exclusive-or, med mindre det er helt nødvendigt.
3.5.8 Overstyring af særlige operatorer 173

• Skriv kun det antal operator-funktioner, som er nødvendige. Det er meget let at
"over-overstyre" en klasse med alle tænkelige operator-funktioner. Kun i klasser, der
definerer numeriske datatyper og andre lignende koncepter er det nødvendigt med et
stort antal operatorer. Normalt er det nok med blot et par stykker.
• Husk at dokumentere alle operatorer fyldigt. Grunden til, at dette er mere nødvendigt
end normalt er, at kaldet til en operator-funktion er underforstået. Hvis klienten ikke
er helt klar over, hvad der foregår, kan operator-overstyring gå hen og blive et
frustrationsmoment af dimensioner.
Dette betyder ikke, at man ikke kan være yderst kreativ i brugen af operator-funktioner, som
vi skal se i afsnittene om indekserings-operatoren og funktionskalds-operatoren.
3.5.10 Operator-funktioner som klassemedlemmer
Operator-funktioner kan, ligesom normale funktioner, være globale, statiske i den aktuelle fil,
eller være en medlemsfunktion af en klasse. Hvis en operator-funktion er medlem af en
klasse, kaldes funktionen med en underforstået første parameter, nemlig den forekomst, der
udgør venstre operant (i binære udtryk) eller den operant, der binder til operatoren (i
singulære udtryk). Fire af operatorerne skal være klassemedlemmer, nemlig tildeling (=),
indeksering ([]), funktionskald (()) samt medlemsreference (->).
Når en operator-funktion kaldes fra et udtryk, skaber oversætteren et underforstået kald med
operanterne som parametre. Hvis typen Complex skal overstyre additions-operatoren, kan
det ske på følgende måde:
Complex operator+ (Complex& a, Complex& b) {
Complex temp (a);
temp.add (b);
return temp;
}
Da operator+(Complex&,Complex&) er en funktion, som arbejder på forekomster af
Complex, men ikke er en medlemsfunktion af klassen Complex, kan den ikke referere de
indre variable, den egentlig har behov for.
Operator-funktionen kan sættes ind i en klasse som medlemsfunktion, hvorved operatorfunktionen
første parameter underforstået bliver den aktuelle forekomst:
class Complex {
double re, im;
public:
Complex operator+ (Complex&) // BINÆR addition!
// ...
174 Overstyring af operatorer 3.5

}
Operator-funktionen Complex::operator+() bliver kaldt i udtryk som:
Complex a, b, c;
a = b + c; // b.operator+ (c) kaldes
Fordelen ved at indsætte operatorer som medlemsfunktioner i en klasse er, at operatorfunktionen
får tilgang til de private data i klassen. operator+ kan nu implementeres
således:
// addér a til det aktuelle objekt
Complex Complex::operator+ (Complex& a) {
Complex temp (re + a.re, im + a.im);
return temp;
}
Husk igen, at C++ bruger klasse-baseret indkapsling, så en medlemsfunktion i Complex har
adgang til private data i alle forekomster af Complex. Derfor er det muligt at konstruere et
midlertidigt objekt med reference til det aktuelle objekts re og im til a's re og im
respektivt. Vi sparer altså at skulle kalde specielle medlemsfunktioner i klassen fra operatorfunktionen
for at komme til de forskellige private data.
3.5.11 friend-funktioner
Desværre er der et problem med indkapslede operator-funktioner, som først kommer til
udtryk, når operatoren bruges i særlige sammenhænge. En medlemsfunktion har et objekt af
sin klasses type som det første underforståede parameter. En operation, som kræver et objekt
af en anden type som venstre led eller første argument skal erklæres som normal funktion.
Overvej følgende klasse:
class X {
int i;
public:
X (int j = 0) { i = j; }
X operator+ (int j) { // for X = X + int
X temp (i + j);
return temp;
}
};
3.5.10 Operator-funktioner som klassemedlemmer 175

Hvis en klient skriver
X a, b (5);
int c = 5;
a = b + c; // a = b.operator+(c)
kaldes operator-funktionen X::operator(int) for b med c som parameter og
returnerer en X med X::i == 10. Hvis klienten ligeledes skiver
X a, b (5);
a = b + 5; // a = b.operator+(5)
vil samme operator-funktion blive kaldt. Problemet opstår, hvis klienten skriver
X a, b (5);
int c = 5;
a = 5 + b; // a = 5.operator+(b) ?
a = c + b; // a = int::operator+(b) ?
C++ kan som sagt ikke overstyre operatorer for de indbyggede typer. Udtrykket 5 + b vil
forsøge at kalde operator+() for en midlertidig int med en parameter af typen X. En
sådan funktion findes ikke. Problemet kan selvfølgelig løses ved at fjerne operator+()
fra klassen X, og gøre den global. Men så har funktionen ikke længere adgang til de private
data i X, som derfor må placeres i public-delen af klassen, som tillader funktionen tilgang
til disse data... men så har alle andre klient-funktioner også adgang til disse data, og vi har
overtrådt en af de fundamentale regler for indkapsling på "need-to-know" basis.
Man kunne overveje, hvorfor oversætteren, når den kommer forbi udtrykket
a = 5 + b;
ikke kan kalde funktionen b.operator+(5) - resultatet ville jo blive det samme.
Desværre er dette ikke muligt, idet faktorernes orden ikke er ligegyldig for alle operatorer.
Hvis vi havde med divisions-operatoren at gøre, ville a.operator/(b) og
b.operator/(a) ikke være det samme.
Der er altså brug for at tildele ikke-medlemsfunktioner adgang til de private dele af en
klasse. Dette gøres med friend-nøgleordet, som giver en ikke-medlemsfunktion samme
privilegier som en medlemsfunktion, selvom den ikke tilhører klassens skop.
En friend-funktion erklæres i klassens specifikation som følger:
class X {
int i;
public:
X (int j = 0) {
i = j;
176 Overstyring af operatorer 3.5

}
friend X operator+ (X&, int);
};
og kan nu implementeres med direkte adgang til de private variable:
X operator+ (X& o, int j)
X temp (o.i + j);
return temp;
}
friend-funktioner er mest brugbare i forbindelse med operator-overstyring. Men det kan
også være nødvendigt at erklære en funktion som friend, hvis den skal have adgang til to
eller flere forskellige klasser. Netop fordi en friend-funktion kan have adgang til flere
klasser har den ingen this-pointer, og har derfor ikke noget underforstået objekt at arbejde
på. Derfor modtager operator+() som ikke-medlems friend-funktion to parametre.
3.5.12 Mere om kopiering af objekter
Selvom erklæringen og brugen af tildelings-operatorer i overstyrede operator-funktioner
minder meget om de, der implementerer andre slags operatorer, er der en væsentlig forskel. I
afsnit 3.4.12 beskrev jeg problemet med at initiere et objekt fra et andet objekt, hvis
objekternes type indholdt pointere eller andre indirekte referencer. Vi husker, at kopikonstruktøren
bruges til at tildele et ikke-initieret objekt værdien af et andet:
Memory a = b; // Memory::Memory (Memory&) kaldes
Hvad nu hvis klienten skrev følgende kode:
Memory a;
a = b; // medlemsvis kopiering, i praksis det
// samme som bitvis kopiering
Hvis vi ikke har defineret en tildelings-operator for klassen Memory, vil b blive kopieret
medlem for medlem til a, med samme problemer til følge, som dem vi beskrev i afsnittet om
kopiering af objekter. Hvis tildelingen a = b skulle kalde kopi-konstruktøren render vi ind
i et andet problem. Kopi-konstruktøren i memory konstruerer jo netop forekomster af
Memory, og allokerer i dette tilfælde nyt lager med mere. Hvis vi kalder kopi-konstruktøren i
en tildeling (husk forskellen mellem initiering og tildeling), er objektet, her a, allerede
initieret, her i sætningen Memory a. Et yderligere kald til en konstruktør (hvadenten det er
kopi-konstruktøren eller en anden konstruktør) vil allokere lageret endnu engang og endda
"glemme" det først allokerede, idet det tidligst allokerede lager ikke deallokeres til systemet.
Tildelings-operatorer i klasser, som har indirekte referencer, skal derfor have en vis
3.5.11 friend-funktioner 177

struktur. For Memory-klassen drejer det sig om, at tildelinen skal rydde op i det aktuelle
objekt, før en reel tildeling kan finde sted. Her er en opdateret version af Memory:
class Memory {
char* mem_ptr;
unsigned int size;
public:
Memory () { // tom initiering
mem_ptr = NULL;
size = 0;
}
Memory (unsigned int i) { // konstruktør
mem_ptr = new char [size = n];
}
Memory (Memory& m) { // kopi-konstruktør
mem_ptr = new char [size = m.size];
memcpy (mem_ptr, m.mem_ptr, size);
}
~Memory () { // destruktør
delete mem_ptr;
}
void operator= (memory&); // tildeling
}
void Memory::operator= (Memory& m) {
if (size != m.size) {
delete mem_ptr;
mem_ptr = new char [size = m.size];
}
memcpy (mem_ptr, m.mem_ptr, size)
}
Alle funktionerne i klassen Memory kaldes underforstået, dvs. uden direkte reference til
funktionsnavnene. Derfor er et eksempel bedst til at beskrive, hvornår og hvordan de kaldes:
void main () {
Memory a (100); // Memory::Memory (unsigned int)
Memory b = a; // Memory::Memory (Memory&)
Memory c; // Memory::Memory ()
c = a; // Memory::operator= (Memory&)
} // 3 gange Memory::~Memory ()
Funktionen Memory::operator=() tester først om de to forekomster har allokeret lager
af samme fysiske størrelse. Hvis det ikke er tilfældet, deallokeres lageret i det aktuelle objekt,
178 Overstyring af operatorer 3.5

og nyt lager allokeres af samme størrelse som det tildelte objekts. Dernæst kopieres selve
lageret.
Forskellen mellem en kopi-konstruktør og en tildelings-operator er i de fleste tilfælde, at
tildelings-operatoren skal foretage en smule lageradministration, fordi objektet allerede er
initieret. Igen er det kun nødvendigt at skrive klasse-specifikke tildelings-operatorfunktioner,
hvis objektet indeholder pointere til forekomster. Hvis alle medlemsvariable er normale
erklæringer af fundamentale eller brugerdefinerede typer, er medlem-per-medlemkopieringen,
som standard-tildelingen udfører, tilstrækkelig.
3.5.13 Midlertidige objekter
I de foregående afsnit har vi set, hvordan et midlertidigt objekt er blevet brugt til for eksempel
at holde en mellemregning i en operator-funktion. Midlertidige objekter kan også oprettes i
sammensatte udtryk:
Complex a = Complex (2.2, 4.4) + Complex (3.3, 7.7);
Denne sætning resulterer i tre nye forekomster af Complex, nemlig objektet a og to
midlertidige, unavngivne objekter. Konstruktøren Complex::Complex(double,
double) bliver kaldt for de to midlertidige objekter som det første. Dernæst kaldes
operator-funktionen operator+(Complex&,Complex&) med de to midlertidige
forekomster, og til sidst kaldes konstruktøren Complex::Complex (Complex&) for a
med resultatet fra operator+. Hvis vi ser på indholdet af operator+(), finder vi, at
denne også opretter et midlertidigt objekt, temp, som bruges i mellemregningen til at holde
summen af de to komplekse tal i udtrykket. temp bliver fjernet, når operator+() slutter,
og de to midlertidige objekter i udtrykket fjernes på et ikke nærmere specificeret tidspunkt,
dog ofte så hurtigt som muligt. Det er imidlertid ikke et problem, som kommer programmøren
ved, fordi oversætteren genererer denne kode automatisk.
Midlertidige objekter kan bruges i næsten alle sammenhænge. Her er medlemsfunktionen
operator+() i en lidt anden udgave:
inline Complex operator+ (Complex& c1, Complex& c2) {
return Complex (c1.re + c2.re, c1.im + c2.im);
}
Her oprettes et lokalt, midlertidigt objekt, som konstrueres (ved et kald til
Complex::Complex(double,double)) med summen af henholdsvis den reelle og den
imaginære del som parametre til konstruktøren. Det er sandsynligvis en lille smule bedre end
at bruge et navngivent objekt, som i denne implementation:
inline Complex operator+ (Complex& c1, Complex& c2) {
Complex temp;
temp.re = c1.re + c2.re;
3.5.12 Mere om kopiering af objekter 179

temp.im = c1.im + c2.im;
return temp;
}
De to versioner udfører nemlig samme opgave. I den første version foretages først additioner
af de medlemsvariablene i de to objekter, og dernæst kaldes en konstruktør for et midlertidigt
objekt, som returneres med det samme. I anden version kaldes default-konstruktøren for det
midlertidige objekt, og dernæst tildeles de to medlemsvariable summen af de to additioner,
hvorpå det midlertidige objekt returneres. Brug derfor unavngivne midlertidige objekter, hvis
det er muligt, og specielt i inline-funktioner. En optimerende oversætter vil kunne
inferere mere om midlertidige objekter, som er udenfor programmørens kontrol, en de, som
behandles direkte af programmet.
Vi ser altså, at C++ kan konstruere og destruere midlertidige objekter, med underforståede
funktionskald til følge. Det er i denne sammenhæng vigtigt at identificere de mest frekvente
underforståede kald til medlemsfunktioner, for derpå at skrive disse kortest muligt og gøre
dem inline. Som sagt bliver objekt-orienterede sprog ofte kritiseret for ikke at være
effektive og at introducere fejl under kørslen. Kun ved at skrive de medlems-funktioner i
klasser på den rigtige måde kan vi sikre, at effektiviteten i objektkoden er så god eller bedre
end hvis vi skulle foretage alle de underforståede kald manuelt. Dette er især vigtigt, når vi i
næste kapitel begynder på nedarvnings-begrebet, hvor et enkelt kald (underforstået eller ej)
kan resultere i mange andre skjulte kald til andre klassers medlemsfunktioner.
3.5.14 Overstyring af indekserings-operatoren
Overstyring af de særlige operatorer som for eksempel indeksering ([]) giver
klassedesigneren mulighed for at styre tilgangen til klassen med størst frihed. Brugerdefineret
indeksering betyder, at en klients brug af operatoren medfører et kald til operator[]() i
den pågældende klasse. String-klassen fra forrige afsnit kan udbygges med en
indeksering, som udgør en rimelig syntaks for tilgang til de individuelle enheder i strengen:
class String {
char* cp;
public:
String () { cp = 0; }
String (char*);
String (String&);
~String ();
char operator[] (unsigned);
};
char String::operator[] (unsigned indeks) {
return *(cp + indeks);
}
180 Overstyring af operatorer 3.5

void f () {
String a = "Due";
char b = a [1]; // b == 'u'
}
Medlemsfunktionen, som overstyrer indeksering, kan returnere en hvilkensomhelst type, idet
semantikken bag referencen afhænger af klassens definition. I ovenstående klasse returneres
en forekomst af char, som kan tildeles til andre objekter. Her er en oplagt mulighed for
forbedring, samt at se reference-typens brugbarhed: hvad sker, hvis vi skriver
void f () {
String a = "Due", b = "Martin";
a [2] = b [3]; // char = char ?
}
operator[] kaldes for b med 3, og returnerer en midlertidig forekomst af en char. Det
samme sker for a, hvorved vi har en højreværdi på begge sider af lighedstegnet. Det, vi
forsøger, er at tildele et element i a med en char, hvilket kan realiseres med referencer:
class String {
char* cp;
public:
// ...
char& operator[] (unsigned);
};
char& operator[] (unsigned indeks) {
return *(cp + indeks);
}
void f () {
String a = "Due", b = "Martin";
a [2] = b [3]; // ok: char& = char&
} // a == "Dut"
Ved at returnere en reference, overføres kun type- og adresseinformation, men ingen
midlertidige objekter. Dermed kan udtrykket bruges som både venstre- og højreværdi i et
udtryk, og det bliver tilmed muligt at bruge samme funktion til både ind- og udlæsning via
indeksering. Udtrykket a [2] = b [3] evaluerer først b [3] til værdien 't' og
dernæst a [2] til værdien 'e'. Da begge udtryk er referencer, og da det er tilladt at tildele
en værdi til en reference-type, er semantikken i udtrykket faktisk noget ligenende
char& a = 't';
3.5.14 Overstyring af indekserings-operatoren 181

char& b = 'e';
a = b;
Det er altså reference-typen, som er magien bag at kunne bruge funktioner som disse på begge
sider af lighedstegnet. En indekseringsfunktion som den, der bruges i String vil typisk
indeholde et check på indeks-værdien, så den ikke hopper udenfor størrelsen på vektoren.
En interessant detalje ved overstyring af indekserings-operatoren er, at det ikke
nødvendigvis er et heltal, som skal bruges som indeks. Selvom det kræver en bedre
dokumentering af klassen, at en standard-funktion antager en anden syntaks, er der klare
fordele ved specialiseringer, specielt da operator-funktioner kan overstyres som normale
funktioner som beskrevet i afsnit 3.5.16. Man kan for eksempel overveje en klasse, som
beskriver en symboltabel, dvs. en liste af navne med tilhørende værdier. En indeksering i en
sådan klasse med indeks-operatoren for opslag i navnene for værdierne kunne se således ud:
class SymbolTabel {
// ...
public:
// ...
int operator[] (char*);
};
void f () {
SymbolTabel s;
// ...
a = s ["cur_x"]; // slå værdien af cur_x op
};
eller en klasse, som definerer en bølgeform, og som implementerer [] til indeksering i
bølgeformens y-værdier med kommatal, så en flydende indeksering er mulig ved interpolation
mellem værdierne i bølgeformen:
class Waveform {
double *d;
public:
Waveform (int);
double& operator[] (double&);
};
Waveform w (100); // 100 værdier
void f () {
182 Overstyring af operatorer 3.5

Waveform c (300); // 300 værdier
for (double a = 0; a < 100; a += 1/3)
c [a*3] = w [a]; // tredobbelt længde på bølgeformen
};
Denne frihed bliver bedst udnyttet, hvis klassens grænseflade designes bedst muligt, som vi
skal se nærmere på i kapitel 5. Der bør dog ikke herske tvivl om, at en grænseflade, som
designes til klassens natur på en rigtig måde, kan medvirke til en langt bedre brug af klassen
for klienten.
3.5.15 Overstyring af funktionskalds-operator
Overstyringen af funktionskalds-operatoren kan først se lidt overflødig ud, da man jo blot kan
erklære og definere en funktion med et hvilketsomhelst navn. Denne overstyring har også
mindre anvendelighed end de andre, og bruges i mindre grad. En populær anvendelse er
imidlertid en iterator, dvs. et specielt objekt som gennemløber andre objekter. Iterationer i
abstrakte datatyper kan klares med overstyringer af indeks-operatoren, men en alternativ
syntaks kan være at foretrække, jævnfør følgende normale C++-program:
void gets (char* p) { // get-string
char ch;
while ((ch = getchar()) != '\n') *p = ch, p++;
*p = '\0';
}
Her er p en iterator, fordi den gennemløber en tegnsekvens. Funktionen getchar() giver
for hvert kald det næste tegn i input-bufferen. En klasse kan med samme funktionalitet som
mål overstyre funktionskalds-operatoren på følgende måde:
class String {
char* cp;
unsigned len; // længde på strengen
unsigned indeks; // aktuelle indeks
public:
// ...
void start () { indeks = 0; }
char operator() (); // funktionskald
}
char String::operator() () {
if (indeks < len) return cp [indeks++];
3.5.14 Overstyring af indekserings-operatoren 183

eturn indeks = 0;
}
Funktionskalds-operatoren gennemløber strengen ved en underforstået interation og
indeksering med medlemsvariablen indeks. Klienten behøver dermed ikke arbejde med
indekseringer og holde rede på indeksværdier og slutbetingelser, da denne kompleksitet via
funktionskalds-operatoren kan indkapsles i klassen. Sagt på en anden måde ved klassen bedst
selv, hvordan den gennemløbes:
void putString (String& s) {
char ch;
s.start (); // start iteration på s
while ((ch = s ()) != 0)
cout

inline Complex operator+ (Complex& c, double& d) {
return Complex (c.re + d, c.im);
}
// addér en double og en Complex
inline Complex operator+ (double& d, Complex& c) {
return Complex (c.re + d, c.im);
}
Husk, at overstyringer af funktioner er mulige, fordi C++ kan diskriminere mellem de enkelte
funktioner på type-informationen fra parameterlisterne. Vi kan nu underforstået kalde de
forskellige operator+() funktioner i Complex:
Complex a (3, 5);
Complex b (3.2, 7);
double c = 2.5;
Complex d = a + b; // operator+ med to Complex
Complex e = a + c; // operator+ med Complex og double
Complex f = c + a; // operator+ med double og Complex
Complex g = c + c; // konstruktør med enkelt double
Overstyringer af operator-funktioner tillader os altså at kunne blande vores objekter med
objekter af andre typer (også fundamentale) i enkelte udtryk. Der er imidlertid en fare for, at
der skrives alt for mange operator-funktioner, for eksempel en for hver slags addition mellem
alle slags typer i et program og for alle klasser i programmet. Det kan blive til hundredevis af
operator-funktioner for selv et mindre program. Hvis vi ser på, hvad opgaven egentlig består
i, finder vi, at det drejer sig om at konvertere fra en type til en anden. C++ giver os, som vi
skal se i afsnit 3.6, mulighed for at specificere brugerdefinerede typekonverteringer til og fra
enhver klasse. Disse typekonverteringer er under programmørens kontrol, men kaldes
underforstået, og unødvendiggør dermed for mange medlemsfunktioner med samme indhold
for forskellige typer.
3.5.17 Overstyringer i standardbiblioteket
Vi kan nu se sammenhængen i, at standardbiblioteket kan bruge operatorerne > som
input- og output-operatorer. Standard-biblioteket definerer en række klasser, to af hvilke har
navnene istream og ostream for input-strøm og output-strøm. Disse to klasser bliver
instantieret fire gange i header-filen, nemlig som
istream cin; // input-strøm
ostream cout; // output-strøm
ostream cerr; // fejl-strøm
3.5.16 Overstyringer af operator-funktioner 185

ostream clog; // formateret fejl-strøm
I istream-klassen findes en overstyring af operatoren >>, og i ostream findes en
overstyring af operatoren > (istream&, int&);
istream& operator>> (istream&, float&);
//...
ostream& operator

cout. Den vil derfor kunne bruges i alle slags objekter, som er forekomster af ostream,
inklusive fil-objekter og fejl-objekter:
Complex a;
fstream f ("resultat.txt");
f

lægger to komplekse tal sammen med addér-og-tildel operatoren. Den normale semantik af
+= er, at den både foretager en aritmetisk behandling og en tildeling, men også at hele
sætningen er et udtryk, som er resultatet af sætningen, hvilket tillader os at skrive sætninger
som
a = b += c;
hvor a tildeles værdien af b efter den er blevet lagt sammen med c. Hvis vi vil overstyre
denne funktion med standard-semantik, må vi returnere en reference til b i den funktion, der
implementerer overstyringen. Denne reference er netop this. For Complex-klassen
kunne det se således ud:
Complex& Complex::operator+= (Complex& other) {
re += other.re, im += other.im;
return *this;
}
Dette sker i stor udstrækning i standardbibliotekets overstyringer af ind- og
udlæsningsoperatorerne >. Disse medlemsfunktioner returnerer referencer til den
aktuelle strøm, hvilket tillader os at skrive flere objekter efter hinanden, som i
cout

implementerer en hægtet liste.
class Haegte {
Haegte* next;
public:
void Indsaet (Haegte* sted) {
next = sted->next, sted->next = this;
}
// ...
};
Medlemsfunktionen Haegte::Indsaet() modtager en pointer til en anden Haegte og
kæder den aktuelle hægte ind lige efter denne. Til dette formål benyttes this på en elegant
måde.
3.5.19 Tredje løsning i C++
// Complex.h
// eksempel 3-5a: en C++-specifikation af et komplekst tal
class Complex {
double re, im;
public:
Complex ();
Complex (double, double = 0);
Complex (Complex&);
void operator= (Complex&);
friend Complex operator+ (Complex&, Complex&);
friend Complex operator- (Complex&, Complex&);
friend Complex operator* (Complex&, Complex&);
friend ostream& operator

e = 0, im = 0;
}
inline Complex::Complex (double r, double i) {
re = r, im = i;
}
inline Complex::Complex (Complex& c) {
re = c.re, im = c.im;
}
inline void Complex::operator= (Complex& c) {
re = c.re, im = c.im;
}
Complex Complex::operator+ (Complex &a, Complex& b) {
return Complex (a.re + b.re, a.im + b.im);
}
Complex Complex::operator- (Complex &a, Complex& b) {
return Complex (a.re - b.re, a.im - b.im);
}
Complex Complex::operator* (Complex &c) {
return Complex (a.re * b.re - a.im * b.im,
a.re * c.im + a.im * c.re);
}
ostream& operator

cout

Complex + double
Complex operator+ (Complex& c, double& d) {
return Complex (c.re + d, c.im);
}
// Complex + int
Complex operator+ (Complex& c, int i) {
return Complex (c.re + i, c.im);
}
// Complex + long
Complex operator+ (Complex& c, long l) {
return Complex (c.re + l, c.im);
}
// og så videre for de omvendte relationer
Kroppen af operator-funktionerne er alle næsten ens. Løsningen på problemet er derfor
enkelt: vi specificerer en gang for alle, hvordan en type relaterer til en anden type, og lader
denne specifikation hedde en brugerdefineret typekonvertering. Denne typekonvertering kan
og vil bruges i sammensatte udtryk af forskellige typer på samme måde som relationer
mellem de indbyggede typer, som vi kender:
int i = 5;
long l = i; // i konverteres til long(i)
Complex c (3, 7);
double d = c; // c konverteres til double (c)
Det er muligt både at specificere konverteringer fra en type T til andre typer og
konverteringer til en type T fra andre typer. I de næste afsnit skal vi se, hvordan vi skriver
funktioner til konvertering af brugerdefinerede typer, i hvilke sammenhænge de kaldes, og
hvordan de spiller sammen med andre funktioner.
3.6.1 Konverterings-funktioner
I C++ beskrives en konvertering fra type A til type B som en medlemsfunktion i B, som
overstyrer typenavnet A og returnerer en forekomst af A. Hvis vi, som i ovenstående
kodefragment, vil tildele en Complex til en double kan vi realisere dette med følgende:
class Complex {
double re, im;
public:
// ...
192 Brugerdefineret typekonvertering 3.6

operator double () { return re; }
};
Nu vil alle konverteringer fra Complex til double gå gennem funktionen
Complex::operator double():
Complex c (2, 4);
double d = c; // kalder c.operator double ()
Dette kan lade sig gøre, fordi C++ kører statisk type-check på alle forekomster, altså på
oversættertidspunktet. Det væsentlige er her, at C++ vil kalde konverteringsfunktionen
Complex::operator double () hver gang en forekomst af Complex befinder sig,
hvor en double er påkrævet, både i klientkode og i privat klasse-kode:
void f (double);
void g (int);
double h (double d) {
Complex c = -d; // c.Complex (double, double) kaldes
return c; // c konverteres til double før return
}
void main () {
Complex c;
f (c); // c konverteres til double før kaldet
g (c); // fejl, ingen Complex::operator int()
double i = 7;
double j = i + c; // c konv. til double før addition
double k = j * c; // c konv. til double før
multiplikation
i = h (j);
}
Læg mærke til, at en konverteringsfunktion ikke har nogen returtype, dog returnerer en
forekomst af samme type som navnet på funktionen:
Complex::operator double () {
return re;
}
Grunden til dette er, at funktionen kun kan returnere en bestemt type, og derfor tillades en
returtype ikke. Visse C++ oversættere tillader en erklæring af en konverterings-funktion med
returtype-information af samme type som funktionens navn og giver en advarsel om
3.6.1 Konverterings-funktioner 193

syntaksens overflødighed.
3.6.2 Eksplicit konvertering
Programmøren kan kontrollere typekonverteringen for brugerdefinerede typer på samme
måde som de fundamentale ved hjælp af eksplicitte konverteringer eller type-casts. Syntaksen
for dette gør kaldemetoden for de brugerdefinerede konverteringsfunktioner lettere at forstå:
Complex c;
double d = double (c); // eksplicit konvertering
Eksplicit typekonvertering af brugerdefinerede typer er normalt ikke nødvendig, men kan
være uundgåelige, hvis der fremkommer præcisions- eller tvetydighedsproblemer i et udtryk.
Dette behandles i slutningen af afsnittet.
3.6.3 Implicit konvertering
Implicit konvertering fra en type A til en type B forekommer hver gang, en forekomst af B
skal bruges, hvor en A findes. Medlemsfunktionen
A::operator B ();
eller konstruktøren
B::B (A);
foretager denne konvertering. C++ vil på oversættertidspunktet markere en underforstået
typekonvertering, som ikke kan findes som medlemsfunktion, som fejlagtig. Det giver
programmøren en sikkerhed for, at fejl af denne slags ikke bobler igennem til objektkoden,
som for eksempel i sprog som Smalltalk. Vi har set, hvordan implicit typekonvertering
fungerer i tildelinger af en Complex til en double.
3.6.4 Konstruktører og konvertering
Vi husker, at kontruktører kan overstyres som normale funktioner. En anden måde at se på
dette er, at et objekt kan konstrueres på flere måder - fra forskellige typer. En konstruktør kan
altså bruges i typekonverteringer, hvis en konvertering fra en vilkårlig type til den aktuelle
type er nødvendig, specielt i forbindelse med midlertidige forekomster. For klassen
Complex, som har en konstruktør Complex::Complex(double,double=0), er det
muligt at skrive:
194 Brugerdefineret typekonvertering 3.6

Complex a (3, 4);
Complex b = a + 5; // 5 konverteres til en Complex
I udtrykket b = a + 5 ser oversætteren, at udtrykket skal resultere i en Complex,
hvorved konverteringsreglerne (se afsnit 2.4.10) for Complex sættes i kraft. Der konstrueres
et midlertidigt Complex-objekt ved et kald til
Complex::Complex(double&,double&) som adderes med a ved et kald til
operator+(Complex&,Complex&), hvorefter resultatet tildeles b under initieringen i
dennes kopi-konstruktør Complex::Complex (Complex&).
Konstruktører kan altså bruges i konvertering, når en forekomst af en type skal bruges
midlertidigt. Det er med denne metode ikke muligt at konvertere til fundamentale typer, da
disse ikke er klasser, og da konverteringsreglerne for dem ligger fast. Her skal i stedet
anvendes konverteringsfunktioner som beskrevet i 3.6.1, fordi de i modsætning til
konstruktørerne er i stand til at konvertere fra en klasse til en fundamental type samt i øvrigt
at konvertere fra en klasse til en anden uden at ændre i modtagerklassen.
3.6.5 Konverteringer i flere led
Hvis resultatet af et udtryk semantisk skal give et resultat af typen T, men faktisk giver et
resultat af typen S, og hvis der findes en konverteringsmulighed fra S til T, vil
oversætteren indsætte den nødvendige konvertering. Dette gælder for de indbyggede typer,
hvor flere konverteringer underforstået kan forekomme i samme udtryk:
int i = 1;
long l = 2; // l konverteres til int, resultatet
double d = i + l; // til en double
For underforståede typekonverteringer i brugerdefinerede typer gælder det ligeledes, at hvis
en forekomst af type T skal bruges på venstre side af udtrykket, hvis kun en
konverteringsfunktion til type S forefindes, og hvis der findes en konverteringsmetode fra S
til T, vil udtrykket være korrekt. For eksempel:
class Complex {
double re, im;
public:
// ...
operator int () { return re; }
};
void main () {
Complex c;
long l = c;
3.6.4 Konstruktører og konvertering 195

}
Selvom der ikke findes nogen konverteringsfunktion fra en Complex til en long, vil det
stadig være muligt at kunne foretage en sådan tildeling, fordi der kan banes vej via en
konvertering til en int. Complex bliver til int, int bliver til long. Sådanne omveje
er udmærkede for konverteringer, som foretages sjældent i programmet, men hvis de ofte
sker, bør der skrives en specifik konverteringsfunktion, så et minimum af konverteringer sker
(de tager alle tid). Som for alle former for underforstået konvertering er fordelen, at selve
behandlingen overlades til oversætteren og derfor ikke skal skrives eksplicit i kildeteksten.
En anden form for flerledet konvertering viser sig i forbindelse med gentagne kald til
konstruktør-funktioner i klasser:
class A { public: A (int); };
class B { public: B (A); };
class C { public: C (B); };
void f (A); // funktion med en A som parameter
void g (B); // funktion med en B som parameter
void h (C); // funktion med en C som parameter
void main () {
int i = 0;
f (i); // konstruerer en A fra i, kalder f (A)
g (i); // konstruerer en A fra i, konstruerer en
// B fra A og kalder f (B)
h (i); // fejl: kan ikke konstruere en C fra
// en int
}
Vi ser, at når der findes en vej fra en type til en anden, vil der blive udført det antal
konverteringer, der er nødvendige for at opnå et resultat af den pågældende type, dog kun i
højest to led. I kaldet til g() i eksemplet ovenfor bliver der konstrueret et midlertidigt Aobjekt,
selv om hverken kaldet eller parameterlisten henviser til A.
Pas dog på med overstyrede funktioner, fordi det kan lede til tvetydigheder:
class A {
// ...
public:
A (int); // konstruér A fra en int
// ...
};
class B {
196 Brugerdefineret typekonvertering 3.6

...
public:
B (int); // konstruér B fra en int
// ...
};
void f (A); // funktion tager en A
void f (B); // funktion tager en B
void main () {
int i = 0;
f (i); // f(A(i)) eller f(B(i)) ?
}
Problemet med funktionskaldet til f() er, at oversætteren kan konvertere en int til både
en A og til en B. Funktionskaldet til den overstyrede funktion er dermed ikke mere entydigt,
og oversætteren vil ikke kunne binde kaldet korrekt. Derfor er dette kald ulovligt.
3.6.6 Objektets underforståede værdi
Det kan være brugbart at give en brugerdefineret datatype en underforstået værdi, som tillader
klienten at konvertere objektet til en fundamental type. Den underforståede værdi er for
eksempel brugbar når der skal testes for fejl:
ADT x; // x er en Abstrakt DataType
if (x) // er x ok?
Denne konvertering kan for eksempel være en overstyring af operator void*(), da en
pointer med nul-værdi traditionelt er en sikker angivelse af en værdi, der ikke kan bruges til
andet end fejlbehandling. På samme vis kan operator!() overstyres med den modsatte
betydning.
class ADT {
public:
operator void* () { /* ... */ }
// ...
};
I standardbiblioteket iostream (kapitel 6) overstyres mange klasser med operatorer for
underforståede værdier, så for eksempel en I/O-fejl nemt kan opdages i programmet.
3.6.5 Konverteringer i flere led 197

3.6.7 Fjerde løsning i C++
Med de nye metoder for brugerdefineret typekonvertering, vi har introduceret i dette afsnit,
kan vi konstruere en mere komplet Complex-klasse, som listes i eksempel 3-6.
// Complex.h
// eksempel 3-6a: en C++-specifikation af et komplekst tal
class Complex {
double re, im;
public:
Complex ();
Complex (double&, double& = 0);
Complex (Complex&);
void operator= (Complex&);
friend Complex operator+ (Complex&, Complex&);
friend Complex operator- (Complex&, Complex&);
friend Complex operator* (Complex&, Complex&);
friend ostream& operator

Complex operator+ (Complex &a, Complex& b) {
return Complex (a.re + b.re, a.im + b.im);
}
Complex operator- (Complex &a, Complex& b) {
return Complex (a.re - b.re, a.im - b.im);
}
Complex operator* (Complex &c) {
return Complex (a.re * b.re - a.im * b.im,
a.re * c.im + a.im * c.re);
}
inline Complex::operator long () {
return long (re);
}
inline Complex::operator double () {
return double (re);
}
ostream& operator

I main() i eksempel 3-6c findes flere typekonverteringer:
• i udtrykket a * b - 3 konverteres heltallet 3 først til en double, og dernæst til
en Complex via konstruktøren Complex::Complex (double&,
double&).
• i udtrykket e + c konverteres e fra en double til en long og c fra en
Complex til en long via konverterings-funktionen Complex::operator
long().
• i tildelingen i = d konverteres d først fra en Complex til en long, og dernæst
til en int.
Klassen Complex kan nu opfylde de fleste af de krav, vi opstillede i starten af kapitlet:
• vi kan allokere og initiere forekomster af Complex på en måde, som minimerer
fejlrisici og tvetydigheder,
• vi kan deallokere forekomster af Complex med sikkerhed for korrekt oprydning,
• vi kan kopiere forekomster af Complex med sikkerhed for korrekt opsætning,
• vi kan blande Complex med forekomster af andre typer i sammensatte udtryk,
• vi kan abstrahere fra implementationen af Complex, ved at bruge standardoperatorer
til manipulation,
• vi kan udskrive forekomster af Complex med samme syntaks som andre typer.
De problemer, vi opremsede i afsnit 3.2.2, kan vi nu gennemgå for eksempel 3-6:
• Syntaks. Manipulation af forekomster gøres gennem medlemsfunktioner, som har et
begrænset, "modulært" skop indenfor den klasse, de tilhører. Ved hjælp af
overstyringer af standard-operatorerne har vi opnået en blød grænseflade fra
klientens kode til klassens funktioner. Typekonverterings-funktionerne sparer os fra
at skrive utallige næsten ens funktioner med en anelse forskelligt indhold.
• Semantik. Selvom vi faktisk udvider sproget C++ til at indeholde en ny type, betyder
det ikke, at der gælder andre regler. Alle henvisninger til og med den ny type vil
blive checket for ækvivalens, og fejl vil blive rapporteret på oversættertidspunktet.
Operator-præcedens i udtryk med komplekse tal gælder som de plejer, og som en
vilkårlig klient ville forvente.
• Lageradministration. Ved hjælp af de specielle medlemsfunktioner, konstruktøren og
200 Brugerdefineret typekonvertering 3.6

destruktøren, kan vi beskrive, hvordan en forekomst af en given klasse skal forholde
sig under initieringen og oprydningen. Klienten skal ikke huske at kalde funktioner,
det gøres automatisk ved start og slut på objektets skop.
• Mellemregninger. Alle mellemregninger er flyttet fra klientens kode til
medlemsfunktionerne i klassen, hvor de ligger som midlertidige variable.
• Dokumentation. Idet klassen har en entydig specifikation af grænsefladen til klienten
(public-delen af klassen), har klienten en bedre direkte forståelse for, hvordan
forekomster af klassen skal manipuleres. Det er i det hele taget et mindre problem,
fordi de mange underforståede kald ikke kræver dokumentation. Derudover kan
selve klassens specifikation bruges i dokumentationsfasen, fordi klassen indkapsler
alle funktioner under samme domæne.
• Udvidelsesmuligheder. En udvidelse med for eksempel en divisionsmetode til
Complex-klassen er langt lettere i eksempel 3-6 end i eksempel 3-2, fordi det blot
indebærer en ny operator/()-funktion. Generelt skal koden stadig testes for fejl
på samme måde som før, men findes en fejl, er den lettere at lokalisere, fordi
grænsefladerne på grund af indkapsling er ridset klart op. Når vi vil blande abstrakte
datatyper med andre abstrakte datatyper samt fundamentale typer, giver
underforstået, brugerdefineret typekonvertering mulighed for "usynligt" at løse
opgaven uden indblanding fra klientens side. Overstyring af funktionsnavne gør det
også lettere at vedligeholde en klasse, fordi ingen nye funktioner med unikke navne
behøves introduceret. Vigtigst er det dog, at indkapslingen sikrer, at klienten ikke
skriver kode, som er afhængig af den indre implementation af en type. Dermed kan
typen ændres og udvides uden at det har betydning for klientens program, som end
ikke behøver genoversættelse.
• Sikkerhed. Indkapslingen af en klasse muliggør, at klassen kan skjule de
implementations-afhængige dele i private-delen af specifikationen. Klienten har,
støttet af sproget, slet ikke adgang til disse data og funktioner, og kan dermed ikke
gøre noget forkert i denne henseende.
3.7 KLASSER OG POINTERE
Pointere til medlemmer i datastrukturer eller klasser følger for indkapslede objekter eller
afledte indkapslede objekter den normale syntaks for pointererklæring og -anvendelse. En
pointer til et objekt af typen T i klassen S' skop har typen pointer til type T. Der er altså ingen
semantisk forskel, blot skal højre-udtrykket under tildelingen til pointeren omfatte objektets
navn:
class S { int i; };
3.6.7 Fjerde løsning i C++ 201

S s;
int* i = &s.i; // ganske normal pointer til int
int& j = s.i; // ganske normal reference til int
Det er helt normal pointermanipulation. Disse pointere peger ind i et objekt af en eller anden
type og er semantisk uden relevans til en klasse. I C++ kan vi imidlertid også arbejde med
pointere til klassemedlemmer, altså pointere, der både bærer information med sig om den
refererede type og også det leksikale skop, som typen befinder sig i.
3.7.1 Pointere til medlemsdata
Er der tale om pointere til datamedlemmer i klasser i stedet for i objekter eller pointere til
statiske variable indkapslet i klasser, skal klassenavnet anvendes i erklæringen i stedet for
objektnavnet:
class S { static int i; };
int* i = &S::i; // i er pointer til int
class T { int j; };
int T::*ptj = &T::j; // ptj er pointer til j i T
Det ses altså, at pointere til statiske klassemedlemmer er af samme type som pointere til
normale objekter. Derimod er pointere til ikke-statiske medlemmer af klasser (ikke objekter)
en beskrivelse af medlemmets position i klassen, et offset til den pågældende variabel. Denne
position kan bruges i forbindelse med objekter af denne, og kun denne, klasse:
T t; // et T-objekt
t.*ptj = 10; // tildel medlem i t værdien 10
Det, der sker i denne tildeling er, at ptj bliver bruges som en indgang i et T-objekt og er
fra klientens side generisk på linie med andre pointere. ptj kunne for så vidt referere
vilkårlige andre objekter i klassen (sålænge disse objekter er af typen int).
3.7.2 Pointere til medlemsfunktioner
Det er også muligt at arbejde med pointere til medlemsfunktioner i klasser. Det omfatter
imidlertid udvidede regler for både erklæring og anvendelse af pointerne. Operatorerne ->* og
.*, som kort blev remset op i afsnit 2.4.6 kan nu forklares i forbindelse med de datastrukturer
og klasser, hvis medlemmer de arbejder på. De er begge binære operatorer, og afviger kun i
en ekstra indirektion af den første operant. Operatoren .* binder to operanter sammen, som
skal være af henholdsvis typerne "forekomst af en klasse T" og "pointer til et medlem i T."
Lad os kort rekapitulere erklæringssyntaksen for en pointer til en normal ikke-
202 Klasser og pointere 3.7

medlemsfunktion:
int f (char*); // global funktion
int (*fptr) (char*) = f; // pointer til global funktion
Disse to objekter har henholdsvis typerne "funktion, der tager en char* som parameter og
returnerer en int" og "pointer til funktion, der tager en char* som parameter og returnerer en
int." Pointeren anvendes således:
int i = (*fptr) ("tekst"); // kald funktion peget på af fptr
Når der arbejdes med medlemsfunktioner, erklæres pointeren specifikt til at pege på et
medlem i en bestemt klasse. Grunden til, at der ikke kan anvendes generelle pointere i
forbindelse med medlemmer er, at der kan forekomme forhold mellem klassen og andre
klasser, der kræver, at oversætteren er bekendt med, hvad klassen hedder - forhold, som har
med arv og virtuelle funktioner at gøre og som beskrives i kapitel 4. En pointer til en
medlemsfunktion erklæres med
// erklær en type T med en medlemsfunktion
class T { int f (char*); };
// erklær et objekt af typen T
T t;
// erklær og initiér en pointer til medlemsfunktion i T
int (T::*ptf) (char*) = &T::f;
Læg mærke til, at adresse-af operatoren (&) skal med, når en pointer til en medlemsfunktion
skal findes, hvilket ikke er tilfældet for normale funktioner. Pointere til ikkemedlemsfunktioner
kan tildeles en funktion direkte, fordi der forekommer en underforstået
konvertering fra funktion til adresse. Grunden til denne forskel ligger begravet i, at adressen
på funktionen afhænger af det specifike objekt, der arbejes på.
3.8 PARAMETERISEREDE TYPER
Indtil nu har vi arbejdet med abstrakte datatyper i et design, som på en måde er meget statisk,
idet implementationerne bygger på et fastsat indhold og en formel grænseflade. Klienten, som
benytter de abstrakte typer, har ikke mulighed for at ændre på typernes opførsel men må
anvende dem, som de foreligger. Det kan siges at være en ulempe, fordi det ikke umiddelbart
tillader de abstrakte typer at arbejde sammen med de, som klienten ellers arbejder med eller
selv introducerer i typesystemet. Ulempen manifesterer sig i, at klienten enten er nødt til at
ændre på sine egne typer eller tilpasse dem den abstrakte type eller også selv skrive eller
omskrive den abstrakte type. Det betyder i direkte konsekvens, at de abstrakte datatyper ikke i
3.7.1 Pointere til medlemsdata 203

særlig stor grad fremmer det store mål at genbruge eksisterende kode.
Hvis vi ser på, hvilke egenskaber vi i grunden vil tillæge de statiske abstrakte typer, er det
muligheden for at de internt kan arbejde med objekter af klientfastsatte typer. Med andre ord,
en klasse, som indeholder eller refererer objekter af typen X er ikke meget værd i en
sammenhæng, hvor klienten arbejder med objekter af typen Y. Hvis klienten er i stand til,
uden at begynde at ændre i klassens implementation, at få klassen til at arbejde med Yobjekter
i stedet for, ville der være meget tid sparet. Det, vi leder efter, er en slags
parameterisering af klasser, som tillader os at fortælle en klasse at den skal ændre adfærd
efter behov. Den parameterisering er meget forskellig fra den, vi kender fra parameterlisterne
i normale funktioner, fordi der her er tale om faktiske typer og ikke om objekter.
Funktionerne modtager blot instanser af typer, ikke typerne selv. Parameterisering på
typeniveau er en opgave for oversætteren.
3.8.1 Eksempler på parameterisering
Der er i praksis flere måder at opnå ægte parameterisering af både klasser og funktioner på,
som har været anvendt i både C og C++. Den mest åbenlyse er at benytte præprocessorens
faciliteter for makroekspansioner. Ved at lade klassens indhold afhænge af en makro, som
klienten specificerer indholdet af, kan klassens opførsel kontrolleres eksternt. I praksis er det
mere populært at benytte typedefinitioner i stedet for makroer, fordi makroerne ikke
bliver typechecket. Som eksempel kan vises en simpel implementation af en stak, som
parameteriseres af en typedefinition:
typedef int TYPE; // definér typen - her en int
class Stack {
TYPE** rep; // selve stakken
int sp; // en stak-pointer
public:
Stack (int size) : sp (0) { rep = new TYPE* [size]; }
~Stack () { delete rep; }
void Push (TYPE* t) { rep [sp++] = t; }
TYPE* Pop () { return rep [--sp]; }
};
Stakken Stack manipulerer objekter af typen TYPE, som er typedefineret til en int i
dette tilfælde. Hvis vi blot ændrer i typedef-sætningen, vil stakken kunne arbejde med
objekter af andre typer. I realiteten er det dog kun pointere, der jongleres med - rep er en
pointer til en vektor af pointere - så pas på med at benytte denne stak til lagring af automatisk
allokerede objekter. Der er heller ikke sikkerhed for, at der Push'es over stakkens øvre eller
Pop'es under dens nedre grænse. Denne fremgangsmåde er imidlertid enkel og virker ganske
udmærket i mindre programmer. I en større sammenhæng er der to vanskeligheder, nemlig
dels at kildeteksten til den parameteriserede type (her Stack) skal genoversættes hver gang,
204 Parametiserede typer 3.7

den parameteriseres og dels, at den ikke kan parameteriseres for mere end én type ad gangen i
samme kildefil. Under normale omstændigheder betyder en genoversættelse - uanset, om der
er blevet rettet i kildeteksten eller ej - at der også skal gentestes. Og selv om en enkelt
anvendelse af parameteriseringen godt nok fremmer genbrug, er det ikke en fleksibel og
holdbar løsning.
Alternativt kan vi benytte os af den generiske pointer, der har været ANSI C's store styrke i
forhold til andre sprog, void-pointeren. Som beskrevet i afsnit 2.10.11 er en void-pointer
typeløs og kan konverteres til at pege på reelle typer, mens det omvendte, nemlig en
konvertering fra en void-pointer til en vilkårlig type kræver en tvungen konvertering † . En
implementation af Stack-klassen med void-pointere er ikke væsentlig anderledes end
ovenfor, blot er typedefinitionen fjernet og TYPE erstattet med void:
class Stack {
void** rep;
int sp;
public:
Stack (int size) : sp (0) { rep = new void* [size]; }
~Stack () { delete rep; }
void Push (void* t) { rep [sp++] = t; }
void* Pop () { return rep [--sp]; }
};
En sådan implementation er forholdsvis solid. Den virker med objekter af alle typer og
udnytter en facilitet, som næsten alle C-programmører (og en stor del C++-programmører)
anvender i praksis. Den kan oversættes én gang for alle og afhænger ikke af makroer eller
typedefinitioner. Objektmodulet er direkte lænkbart til klientens kode og kan placeres i et
bibliotek og genbruges om og om igen. Men er klassen i realiteten parameteriseret? Der er
ikke et umiddelbart parameter at se i klassen, og det viser sig da også, at parameteriseringen
sker i klientens kode i næsten alle kald til klassens medlemsfunktioner. Alle kald til Push()
skal indeholde en adresse på et objekt, som automatisk typekonverteres til en void*. For
kald til Pop(), som returnerer en void*, gælder, at returværdien skal typekonverteres
tilbage til at pege på den korrekte type, der blev brugt under kaldet til Push(). Denne
konvertering skal ske tvungent, fordi C++ ikke underforstået kan konvertere fra en void* til
en pointer til en anden type. Det betyder derfor, at klientens kode må indeholde et stort antal
eksplicitte typekonverteringer, som i praksis sætter C++'s typekontrol ud af kraft. Hvis
klienten laver en fejl, er der ingen, der gør opmærksom på det - typisk en konvertering til en
type, som ikke er identisk med den, som den originale pointer peger på. Og selv om
implementationen med void-pointere til gengæld er særdeles dynamisk og fleksibel, fordi
† Det er en af forskellene mellem ANSI C og C++. Under ANSI C er det tilladt at konvertere en void-pointer
implicit til en pointer til en anden vilkårlig type, sandsynligvis for at undgå de trivielle type-casts i
lagerallokeringskald og lignende. Denne praksis blotter imidlertid et gabende hul i typesystemet, fordi en ulovlig
typekonvertering kan foretages implicit. Oversætteren vil ikke kunne type-checke sådanne konverteringer. I C++ er
det ikke nødvendigt at gå på kompromis her, fordi en overstyring af operator new kan gøre det samme job,
endda bedre.
3.7.1 Eksempler på parametisering 205

den samme Stack kan bruges til at holde objekter af forskellige typer, har den et stort
handicap i og med, at den ikke selv kan se, hvad den arbejder med. En klasse bør i realiteten
skrives, så dens indbyggede algoritmer kan drage fordel af semantikken bag de typer, den
manipulerer. En klasse, der udelukkende bruger void-pointere, er derfor meget begrænset i
anvendelse. Overvej for eksempel en medlemsfunktion i Stack, der sorterer elementerne på
stakken. I typedef-versionen er det let nok for oversætteren at sammenligne objekterne på
stakken, fordi den kender til deres type (og kan beklage sig, hvis de ikke har semantik for
sammenligning i form af for eksempel operator-overstyringer), men i implementationen med
void-pointerne er det umuligt, fordi sorteringsfunktionen ikke vil have den fjerneste idé om,
hvordan den skal sortere når den ikke ved, hvad pointerne peger på.
Det, der er brug for, er en blanding af oversætterstøttet typekontrol og en enkel form for
makrolignende parameterisering. Eller med andre ord, en makrofacilitet for funktioner og
klasser, der ligger i oversætterens domæne og ikke i præprocessorens.
3.8.2 Skabeloner
I kapitel 4 skal vi se, hvordan disse problemer kan løses med objekt-orienterede teknikker,
som dog kræver meget benarbejde og forudsætter en del mere integritet i programmet end en
simpel abstrakt datatype, som vi her er interesseret i at skrive, gør og er desuden en smule
mindre effektive under kørslen. Der er imidlertid en facilitet i C++ (i implementationer med
officielt versionsnummer over 2.0), som gør det muligt at parameterisere en klasse eller en
funktion uden at gå på kompromis med hverken typesikkerheden eller effektiviteten. Det er en
slags blanding af det bedste fra forslagene i forrige afsnit og kaldes skabeloner (på engelsk
templates). En skabelon skrives for én eller flere generelle typer, hvor det forudsættes, at
typerne har den nødvendige semantik for at den eller de klasser og/eller funktioner, der
arbejder med typen i skabelonen, kan bruge dem. Når klienten instantierer en parameteriseret
klasse eller kalder en parameteriseret funktion, gør han det i forhold til en konkret type, som
angives i klientens kode. Denne angivelse er nok for oversætteren til at vide, hvad der skal
gøres på den anden side af kaldet. En skabelon er således en generel forskrift over måden,
hvorpå en klasse eller en funktion kan parameteriseres. Den definerer en familie af klasser
og/eller funktioner. Det er en metode, der kan sidestilles med en avanceret makroekspansion
med indbygget statisk typekontrol og den største anvendelse ligger indenfor udvikling af
generelle containerklasser (se afsnit 5.6).
Parameterisering er generelt muligt på grund af C++'s muligheder for overstyring. Overvej
følgende overstyrede funktionserklæringer:
int& max (int& x, int& y) { return x > y ? x : y; }
double& max (double& x, double& y) { return x > y ? x : y; }
float& max (float& x, float& y) { return x > y ? x : y; }
myType& max (myType& x, myType& y) { return x > y ? x : y; }
Hvad er forskellen på disse funktioner? Ikke andet end de typer, de arbejder på.
Parameterisering er en metode til at generalisere på typerne i en funktion eller en klasse. Til
206 Parametiserede typer 3.7

funktionen max() kan vi skrive en skabelon, der definerer det fælles i funktionen. Dette
"fælles" er abstraheret i den generiske klasse C (den kan i praksis hedde hvadsomhelst) i det
følgende:
template
C& max (C& x, C& y) { return x > y ? x : y; }
Denne erklæring vil ikke resultere i en instantiering af en funktion; der vil ikke blive
genereret kode. Til gengæld vil enhver brug af skabelonen for en ny type generere kode for
funktionen i relation til denne type. Dér er således igen en fordel over brugen af normale
makroer, som vil instantiere og generere kode for alle typer af funktioner, uanset om de rent
faktisk benyttes. Først når funktionen rent faktisk kaldes, opdager typesystemet, at en ny
forekomst af funktionen skal genereres. Hvis den allerede findes instantieret for den aktuelle
type, bruges naturligvis den eksisterende. For eksempel,
void f () {
int c = max (5, 7); // skaber int& max
(int&,int&)
float f = -5.1, g = 3.2;
float h = max (f, g); // skaber den samme for float
int i = max (c, 13); // bruger den eksisterende
// int& max (int&,int&)
// osv...
}
Idet indholdet af den parameteriserede funktion er konstant og anvendelsen af typer i
funktionen er variabel, er parameterisering en ideel løsning. Blot skal man være opmærksom
på, at enhver brug af funktionen med en ny type resulterer i en helt ny funktion, der optager
plads i lageret. Dog er denne teknik ment som en hjælp for klienten, og denne vil typisk bruge
få eller måske kun en parameterisering. Ideen er, at friheden til at bruge enhver type ligger
hos klienten.
En skabelon for Stack-klassen fra ovenfor kan skrives på følgende måde:
template
class Stack {
T** rep;
int sp;
public:
Stack (int size) : sp (0) { rep = new T* [size]; }
~Stack () { delete rep; }
void Push (T* t) { rep [sp++] = t; }
T* Pop () { return rep [--p]; }
};
3.7.2 Skabeloner 207

Igen resulterer denne erklæring ikke i hverken kode eller data, men er blot en forskrift, der
kan benyttes af klienten. Når klienten erklærer en forekomst af klassen Stack, skal typen
specificeres eksplicit i erklæringen, fordi den ikke kan fortolkes udfra normale parametre eller
andet. For eksempel,
Stack intStack (33); // liste af 33 ints
Denne erklæring vil resultere i en forekomst af Stack for typen int. Klassen Stack er
altså blevet parameteriseret for typen int. Ud over det lagerforbrug, der ligger i de
indkapslede data i Stack (her en int, en int** og 33 stk. int*), bliver alle
medlemsfunktioner i klassen, inklusive destruktører og konstruktører (men ikke friendfunktioner
eller nedarvede funktioner - se næste kapitel om arv) instantieret. For meget store
parameteriserede klasser er pladsforbruget for gentagne instantieringer med forskellige
parametre altså en dyr affære i lagerforbrug.
Den store fordel skal ses i lyset af, at enver type kan specificeres som parameter i
instantieringen. Hvis vi for eksempel har brug for stakke af pointere til funktioner, stakke af
typen Complex eller stakke af 3x3-kommatalsmatricer, kan vi erklære
Stack pcStackFrame (0x100);
Stack CalculatorStack (16);
Stack MatrixStack (9);
Forekommer der referencer til den parameteriserede klasse i klassens egne
medlemsfunktioner eller i ikke-medlemsfunktioner, skal parameteret opgives hver eneste
gang lige efter klassenavnet. Det er i virkeligheden slet ikke tilladt at referere til en
parameteriseret klasse uden at bruge et parameter! Overvej for eksempel en ændring af
Stack::Push(), hvor den returnerer en reference til den aktuelle klasse, så flerledede kald
i samme sætning kan udføres:
template
class Stack {
// ...
public:
// ...
Stack & Push (T*);
};
Hvis der skrives Stack uden parameter eller med et parameter, der ikke passer til T, vil
oversætteren brokke sig og nægte at oversætte. Det viser, at typesystemet er særdeles aktivt i
forbindelse med skabeloner. I dette tilfælde er typen på returværdien fra Stack::Push()
blevet parameteriseret af samme type som klassen selv. Når funktionerne skal implementeres
udenfor klassens krop, skal parameterinformationen også med. Her har jeg for øvrigt ændret
parameterets navn for at vise, at navnet er komplet irrelevant, sålænge det benyttes entydigt
indenfor en enkelt funktion eller klasse - ovenstående prototype, der er parameteriseret ved en
208 Parametiserede typer 3.7

type T og nedenstående, der parameteriseres ved X, er den samme funktion. Det tilrådes dog
så vidt muligt at benytte de samme navne i alle funktioner, der er medlem af den samme
klasse eller modul.
template
Stack & Stack ::Push (X* t) {
rep [sp++] = t;
return *this;
}
Denne implementation af Stack::Push() er, ligesom klassen, parameteriseret af den
type, der specificeres efter template-nøgleordet.
Til tider kan det være ønskværdigt eller nødvendigt at håndkode en enkelt implementation
af en funktion for en given type udtrykkeligt i stedet for at lade C++ parameterisere den
automatisk - for eksempel kan den skrives i assembler eller i et andet sprog. Dette kan gøres
af klienten for den type, der arbejdes på i en given sammenhæng, på følgende måde:
Stack & Stack ::Push (int* iptr) {
*(rep + sp) = iptr, sp++;
return *this;
}
Undertiden kan de parameteriserede funktioner og klasser blive syntaksmæssigt forvirrende at
arbejde med, hvis de skal gentages mange gange i et program. Af den grund er det en god ide
at give dem generelle navne ved hjælp af typedef, så de i højere grad ligner normale typer
i systemet. For eksempel,
typedef Stack funPtrStack;
typedef Stack complexStack;
typedef Stack matrixStack;
// ...
funPtrStack returnAdresses = 0x100;
complexStack fourierSeries = 16;
matrixStack inversionMatrices = 9;
Alle funktioner, der benytter parameterisering, skal efterstilles en templatespecifikation,
så oversætteren er i stand til at skabe de korrekte forbindelser til de anvendte
typer. Når en klasse omsluttes af en skabelon, bliver alle medlemsfunktioner automatisk
parameteriseret. Funktioner, der erklæres udenfor klassens krop, skal som nævnt eksplicit
parameteriseres, ligesom friend-funktioner, der jo er ikke medlemmer af klasser. Følgende
fragment viser en overstyring af + for Stack, implementeret i en friend-funktion, som
adderer to stakke:
3.7.2 Skabeloner 209

template
class Stack {
// ...
public:
// ...
friend Stack operator+ (Stack &, Stack &);
};
template
Stack operator+ (Stack & x, Stack & y) {
Stack result;
int c = x.sp < y.sp ? x.sp : y.sp;
while (c) {
result.Push (x.sp [c] + y.sp [c]);
c--;
}
return result;
}
Det ses, at en sådan funktion skal have parametre med alle steder, hvor der henvises til den
type, der er parameteriseret. Det er ikke muligt at overstyre et parameteriseret klassenavn
yderligere på manuel vis. I stedet må medlemsfunktionerne eksplicit skrives til den type, der
er brug for.
Statiske medlemmer i parameteriserede klasser har kun en enkelt forekomst for hver
parameterisering af klassen:
template
class X {
static C x_medlem;
};
X iX1, iX2; // skaber en int* x_medlem
X dX1, dX2; // skaber en double* x_medlem
Her får objekterne iX1 og iX2 en fælles statisk medlemsvariabel af typen int*, mens
objekterne dX1 og dX2 får en af typen double, altså to ialt. Det skal nævnes, at det ikke
er tilladt at parameterisere i flere led i selve erklæringerne, så følgende er ulovligt:
Stack stakAfIntStakke; // ulovlig
Skabeloner er klart den bedste facilitet for genbrug af kode i C++. I afsnit X.X.X skal vi se,
hvordan vi yderligere kan blande dem sammen med objekt-orienterede teknikker som arv
samt også, hvordan de farlige tvungne typekonverteringer i forbindelse med void-pointere
210 Parametiserede typer 3.7

kan indkapsles i klasser, så de er sikrere og mere robuste. Ved at blande skabelon-klasser
sammen med void-pointere kan vi nemlig spare på instantieringerne af funktionerne i
skabelon-klasserne. I afsnit 3.10.2 findes et eksempel på en associativ liste, der er
implementeret ved hjælp af skabeloner.
3.9 DESIGN AF ABSTRAKTE DATATYPER
Den abstrakte type Complex er af en art, som normalt klassificeres som en numerisk
datatype. Numeriske datatyper passer godt ind i det konventionelle
programmeringsparadigme, der oftest centraliserer databehandlingen omkring tal. Der er
imidlertid mange andre anvendelser for klasser i C++, fordi metoden er generel. Indkapsling
og kompleksitets-skjulning er faciliteter, som også gør programudviklingen lettere, når der
skal arbejdes modulært med generelle datastrukturer. I afsnit 3.10 gennemgås et antal
anderledes applikationer for abstrakte datatyper, som arbejder med klasse-begrebet udfra
andre synsvinkler. Inden da skal vi se på de egenskaber ved C++-klasser, som sammenblandet
med nogle af de generelle sprogstrukturer fra kapitel 2 giver anledning til designspørgsmål.
For mange er dette et punkt, hvor der sker to ting. Når anatomien bag klasser er forstået, og
de derefter bruges på måder, som ikke falder naturligt, er det svært at se, præcis hvad der sker.
Dernæst, når også dette er forstået, får man en mere gennemført opfattelse af klassen som
redskab. At programmere med klasser bliver helt naturligt, og mange finder det faktisk
umuligt at revertere til de tidligere principper for programopbygning. Målet er at kunne
visualisere et design opbygget efter princippet om indkapsling, uden først at skulle gennemgå
en analyse efter traditionelle principper og senere konvertere det til abstrakte datatyper.
3.9.1 Samspil mellem klasser
Selvom klassernes reelle anvendelighed ligger i, at de indkapsler og skjuler kompleksitet fra
klienten, kan kompleksiteten i selve klassen blive stor, faktisk så stor, at designeren af klassen
render ind i de samme problemer som dem, der blev beskrevet i starten af kapitlet. Derfor kan
man drage fordel af, at klasserne kan arbejde sammen og udover at skjule implementationsdetaljer
fra brugeren også gøre arbejdet med udviklingen af selve programmet, der
implementerer klasserne, lettere.
Lad os tage et eksempel fra dette kapitel og udbygge det. Eksemplet fra afsnit 3.4.15 med
dynamiske strenge af tegn kan udmærket gå hen og blive meget komplekst, når vi tager
samme design-krav i betragtning som for Complex-typen. Vi starter med et program, der
arbejder med strenge. Programmet består af en funktion, som søger i en streng efter en
substreng og erstatter denne, hvis den findes, med en anden substreng - en meget generel
funktion, der er brugbar i bla. tekstbehandlere. For ekempel er vi interesserede i følgende:
Original streng: "Danmarks Radio"
Søgestreng: "Radio"
Erstatningsstreng: "Akvarium"
Resultatsstreng: "Danmarks Akvarium"
3.7.2 Skabeloner 211

Funktionen, som skal foretage denne udskiftning, skal ikke være en del af String-klassen,
da den er alt for specifik. I stedet er det en normal funktion, som er klient af String:
// dstrtest.cpp
// eksempel 3-7a: test af dynamiske strenge
#include "dstring.h" // erklæring af String
#include // standard-I/O
String erstat (const String& orig, // original streng
const String& soeg, // søgestreng
const String& erst) { // erstatningsstreng
if (!soeg.len ()) return orig; // ingen søgestreng
String r; // resultatet
int i = 0, h = 0, k = soeg.len ();
while (k + i

}
Funktionen erstat() modtager en original streng (orig), en søgestreng (soeg) samt en
erstatningsstreng (erst), og erstatter alle forekomster af soeg i orig med erst. I
main() kaldes erstat() tre gange med forskellige data, og følgende udskrives:
Original: The Paths of Glory lead only to the Grave
Erstat: only
Med: but
Resultat: The Paths of Glory lead but to the Grave
Original: Holland er europamestre i fodbold
Erstat: Holland
Med: Danmark
Resultat: Danmark er europamestre i fodbold
Original: xyzxxyyzzxxxyyyzzz
Erstat: xx
Med: AA
Resultat: xyzAAyyzzAAxyyyzzz
Algoritmen for erstat() er simpel: variablen i holder den position i den originale
streng, der søges på for øjeblikket, og kører dermed fra 0 til længden af orig, mens h
husker den sidste position, hvor en funden forekomst af søgestrengen befandt sig i den
orig. while-løkken foretager en sammenligning mellem den aktuelle substreng i orig
og søgestrengen og erstatter derefter denne, hvis den fandtes. Resultatstrengen r opbygges
inkrementalt og ryddes til sidst op efter løkkens slutning.
Hvis vi går i detaljer med funktionen erstat() ser vi en hel del egenskaber ved
behandlingen af forekomster af String-klassen, som giver grund til forklaring. Funktionen
lægger for det første strenge sammen som om, de var numeriske datatyper. Her gælder, at
addition af forekomster af String betyder sammenlægning (på engelsk concatenation) af
strenge, dvs. at
"abc" + "def" == "abcdef"
Dernæst finder vi, at funktions-operatoren () er overstyret for String, idet der
forekommer udtryk som
orig (i, k);
flere steder i teksten. Denne overstyring returnerer substrengen i orig fra det i'ende
element, k elementer fremad. Der findes også overstyringer af tildel-og-adder og
sammenlignings-operatoren. Metoderne i den abstrakte datatype String arbejder således
med substrenge i flere af operationerne, hvilket giver anledning til at opdele String-
3.8.1 Samspil mellem klasser 213

klassen i to: en generel String og en Substring, som arbejder på dele af strenge for
derigennem at simplificere designet.
// dstring.h
// eksempel 3-7b: specifikation af en streng-klasse
#include // C's strengbibliotek
class String; // fremad-reference
// specifikation af substreng-klassen
class Substring {
friend String; // giv adgang til String
char* ssp; // substrengen selv
unsigned sslen; // længden på substrengen
Substring (const String&, unsigned, unsigned);
Substring (const Substring&);
public:
void operator= (const Substring&);
int operator== (const String&) const;
String operator+ (const String&) const;
};
// specifikation af streng-klassen
class String {
friend Substring;
char* sp; // strengen selv
unsigned slen; // længden på strengen
public:
String (); // underforstået konstruktør
String (const char*); // konstruér fra C++-streng
String (const String&); // kopi-konstruktør
String (const Substring&); // konstruér fra Substring
~String () { if (slen) delete sp; }
unsigned len () const { return slen; }
operator const char*() const { return sp; }
String operator+ (const String&) const;
String& operator+= (const String&);
void operator= (const String&);
int operator== (const String&) const;
Substring operator() (unsigned, unsigned);
Substring operator() (unsigned, unsigned) const;
214 Design af abstrakte datatyper 3.8

char& operator[] (unsigned i) { return sp [i]; }
char operator[] (unsigned i) const { return sp [i]; }
};
// dstring.cpp
#include "dstring.h"
// konstruér en Substring fra en del af en String
inline Substring::Substring (const String& s,
unsigned i, unsigned j) {
ssp = &((String&)s).sp [i], sslen = j;
}
// konstruér en Substring fra en anden Substring
inline Substring::Substring (const Substring& s) {
ssp = s.ssp, sslen = s.sslen;
}
// tildeling af en Substring fra en anden Substring
inline void Substring::operator= (const Substring& s) {
strncpy (ssp, s.ssp, s.sslen);
}
// sammenlign en Substring og en String
inline int Substring::operator== (const String& s) const {
return !strncmp (ssp, s.sp, sslen);
}
// sammenlæg en Substring med en String
String Substring::operator+ (String& s) const {
String r (*this);
return r + s;
}
// konstruér en "tom" String
inline String::String () : sp (NULL), slen (0) { }
// konstruér en String fra en C++-tegnstreng
String::String (const char* s) {
slen = strlen (s), sp = new char [slen + 1];
strcpy (sp, s);
}
3.8.1 Samspil mellem klasser 215

konstruér en String fra en anden String
String::String (const String& s) {
slen = s.slen, sp = new char [slen + 1];
strcpy (sp, s.sp);
}
// konstruér en String fra en Substring
String::String (const Substring& s) {
slen = s.sslen, sp = new char [slen + 1];
strncpy (sp, s.ssp, slen);
sp [slen] = '\0';
}
// sammenlægning og tildeling af to strenge
String& String::operator+= (const String& s) {
char* temp = new char [slen + s.slen + 1];
strncpy (temp, sp, slen);
temp [slen] = 0;
strncat (temp, s.sp, s.slen);
temp [slen + s.slen] = 0;
delete sp;
sp = temp;
slen += s.slen;
return *this;
}
// sammenlægning af to strenge
String String::operator+ (const String& s) const {
String temp (*this);
return temp += s;
}
// tildeling af en String fra en anden String
void String::operator= (const String& s) {
if (slen) delete sp;
slen = s.slen, sp = new char [slen + 1];
strcpy (sp, s.sp);
}
// sammenligning af en String med en anden String
inline int String::operator== (const String& s) const {
return !strcmp (sp, s.sp);
}
216 Design af abstrakte datatyper 3.8

udtræk en Substring fra en String
Substring String::operator() (unsigned p, unsigned l) {
return Substring (*this, p, l);
}
// udtræk en Substring fra en konstant String
const Substring String::operator() (unsigned p,
unsigned l) const {
return Substring (*this, p, l);
}
Hvad repræsenterer klasserne Substring og String? Rent faktisk er de to klasser
meget ens, hvilket kan ses, hvis man ser på deres datamedlemmer:
class String {
char* sp;
unsigned slen;
// ...
};
class Substring {
char* ssp;
unsigned sslen;
// ...
};
Den generelle forskel ligger i, at String er skabt med en pæn grænseflade til klienten,
mens Substring er en meget tynd klasse med kun få metoder. Og så er der to meget
væsentlige forskelle: mens String-objekter indeholder tegn, der i vanlig C++-stil slutter i
'\0', så de kan skrives ud og behandles som normale tegnsekvenser, indeholder
Substring tegnstrenge, som alene beskrives ved deres længde (sslen). Rent faktisk
allokerer Substring aldrig lager til sine indre variable, men peger altid ind i en String.
Den anden store forskel er, at Substring ikke kan instantieres af klienten! Idet
Substring's konstruktører er i den private del af klassen, kan de ikke ses af brugeren,
som vil få en fejl fra oversætteren. Også kopi-konstruktøren fra String til Substring er
privat, for at undgå, at klienten opretter en Substring med
String s = "Hello";
Substring ss (s, 2, 4); // fejl: konstruktør privat
Substring sss = s; // fejl: kopi-konstruktør privat
Når en klasse som Substring ikke kan bruges af klienten, kaldes den en privat klasse. I
både String og Substring erklæres den anden klasse som friend, hvilket gør alle
3.8.1 Samspil mellem klasser 217

medlemmer i klassen tilgængelige i metoder i den anden klasse. Forekomster af String kan
således arbejde på data i forekomster af Substring og vice versa. Substring's rolle er
således at abstrahere en del af kompleksiteten fra String, hvilket har resulteret i meget små
og letforståelige metoder i begge klasser.
Substring har tre public metoder, en for tildeling fra en String, en for
sammenligning med en String og en for addition af en Substring med en String.
Disse metoder er public, fordi klienten skal kunne bruge dem. Finessen er, at klienten
(dvs. eksempel 3-7a) ikke er klar over, at den til tider arbejder med midlertidige forekomster
af Substring og til tider med forekomster af String. Når klienten for eksempel skriver
String a = "en streng"
String b = a (3, 3); // giver "str"
sker der flere ting. Først kaldes operator() for a, hvilket returnerer en Substring,
som reelt er en pointer-reference og en længdeerklæring ind i a. String::operator()
opretter et midlertidigt Substring-objekt ved kald til klassens konstruktør (hvilket den har
lov til som friend-klasse) som den umiddelbart returnerer. Konstruktøren i Substring
foretager blot en tildeling af en pointer og en længdeerklæring. Når Substring-objektet
når tildelingen til b kaldes konstruktøren String::String(Substring&) for b, som
opretter og initierer b. Klienten opdager således aldrig, at der er Substrings inde i
billedet.
Substring-konstruktøren, som opretter et objekt fra en String, et indeks og en
længdeerklæring indeholder en interessant sprogkonstruktion:
ssp = &((String&)s).sp [i];
Konstruktøren modtager en const String reference, som det er nødvendigt at ændre til
en String-reference. Udtrykket &((String&)s) typekonverterer s tvungent fra en
konstant til en ikke-konstant. Dette er nødvendigt, da konstruktøren ellers tildeler en ikkekonstant
(ssp, en char*) med adressen på en konstant (&s.sp) i en sætning som
ssp = &s.sp [i]; // adressen af det i'ende element i s.sp
Denne typekonvertering er potentielt meget farlig, fordi vi standser oversætterens forsøg på at
forbyde ændringer i konstanter. Hvis det var muligt for en klient at lave forekomster af
Substring, kunne det lade sig gøre at ændre på en konstant Substring gennem et kald
til denne funktion. Men det er kun klassen String, som kan kalde denne funktion, og i
andet led er det kun de to operator()-overstyringer, som kalder denne konstruktør for at
finde en substreng i en streng. Den ene operator()-metode returnerer en konstant
Substring og kan derfor ikke lede til bekymringer, mens den anden arbejder på ikkekonstante
String-objekter, som gerne må ændres af klienten. Denne måde at styre
konstante og ikke-konstante kald til metoder i klassen er derfor meget brugbar i klasser som
String, hvilket også kan ses i de to lignende overstyringer af operator[]:
218 Design af abstrakte datatyper 3.8

String a = "en normal streng";
const String b = "en konstant streng";
a [0] = 'E'; // ok
b [0] = 'E'; // fejl
Tildelingen til a[0] kalder den ikke-konstante metode, som returnerer en reference til det
første tegn i strengen a, fordi a ikke er konstant. Den samme sætning for b giver derimod
en oversætterfejl, fordi der ikke findes en metode, som returnerer en reference til en char,
men blot værdien af denne. Denne værdi kan naturligvis ikke bruges på venstre side af
lighedstegnet (den er ikke en rvalue) hvilket fanges af oversætteren. Til gengæld er det muligt
at benytte den på venstre side (som lvalue) i sætninger som
a [1] = b [7];
da dette ændrer på b.
Overstyringen af den underforståede konvertering fra String til char* er til nytte for
brugeren, som tillades at blande forekomster af String med normale C++-strenge:
String a = "en streng";
char buf [256];
strcpy (buf, a); // a konverteres til const char*
cout

afbrydelse af programmet ikke rydder op i klientens data, som derfor ikke frigives til
systemet.
Fejlbehandling er et af de områder, hvor C++ kommer til kort. Der er ingen
sprogkonstruktioner, der kan hjælpe os med at fange fejl, der pludselig opstår på grund af
forkert brug fra klientens side eller indskydelser fra operativsystemet † . Vi er nødt til at
programmere os ud af problemet, og kan eventuelt bruge den konvention, der kendes fra for
eksempel C, hvor en bestemt værdi er defineret som en fejl. Når vi i C kalder en funktion for
at læse det næste tegn sekventielt i en fil, returnerer funktionen værdien -1 (et ulovligt tegn),
hvis der var fejl under læsningen. En global konstant bliver af læse-funktionen initieret med
en fejlkode, som kan læses af klienten, som kan arbejde videre derfra. For eksempel:
int i = 0;
int h = open ("filnavn", O_RDONLY);
if (h == 0) fejl ("Filen kunne ikke åbnes!");
while (i != EOF) {
if (i == -1) fejl ("Fejl under læsning");
i = getc (h);
}
Denne metode kan også bruges i C++, men vil lede til trivielle sammenligninger med
returværdier fra alle kald til metoder i klasserne. Bruger klassen overstyring af operatorer,
skal de ellers så naturlige udtryk bagefter checkes for fejl, hvilket gør kildeteksten ulæselig.
En anden mulighed er at fortælle klassen én gang for alle, hvad den skal gøre i tilfælde af
pludseligt opståede fejl. Ved at indkapsle en pointer til en fejlbehandlende funktion i klassen
kan klassen til enhver tid kalde klientens prædefinerede fejlrutine. For String kan en sådan
udbygning se således ud:
enum err { MEM_ALLOC, USER_ERROR, /* ... */ };
typedef void (*funptr) (err); // pointer til funktion
class String {
static funptr errorHandler;
// ...
public:
// ...
String operator+= (const String&);
};
// sammenlægning og tildeling af to strenge
† Dette gælder for AT&T C++ version 2.0. Efter version 2.1 forventes fejlbehandling at være en integreret del af
oversætteren, med mulighed for automatisk opfangning af fejl. Se eventuelt appendiks A eller [Stroustrup 87] for
detaljer. ANSI C++ ventes dog ikke at indeholde disse faciliteter.
220 Design af abstrakte datatyper 3.8

String& String::operator+= (const String& s) {
char* temp = new char [slen + s.slen + 1];
if (temp == NULL) (*errorHandler) (MEM_ALLOC);
strncpy (temp, sp, slen);
temp [slen] = 0;
strncat (temp, s.sp, s.slen);
temp [slen + s.slen] = 0;
delete sp;
sp = temp;
slen += s.slen;
return *this;
}
Typen funptr er en pointer til en funktion, som modtager en fejlkode. Den er erklæret
static i klassen, og forekommer således kun én gang. Klienten skriver en fejlbehandlende
rutine, som rydder op i egne data, specielt dynamisk allokerede data, og vælger en passende
aktion - afslutning, genstart eller hop til en hovedløkke i programmet:
void errhdl (err num) {
if (num == MEM_ALLOC) {
cout

Som beskrevet i afsnit 3.5.8 kan de særlige operatorer new og delete overstyres og
gives nye definitioner under programmørens kontrol. Konsekvensen af dette er, at vi kan
modellere specielle dynamiske lageradministrationer mens vi bibeholder syntaksen for normal
allokering og destruktion af objekter. Overstyringen foretages med en erklæring af
operatorerne efter de samme regler, som gør sig gældende under normal operator-overstyring:
void* operator new (size_t);
void operator delete (void*);
Disse to globale metoder skal sørge for henholdsvis at allokere det nødvendige lager og
returnere en pointer til det allokerede data samt at fjerne det allokerede lager igen. De kaldes,
når der foretages et eksplicit kald til new og delete. new-overstyringen modtager en
variabel af typen size_t (erklæret i header-filen ), som normalt er lig en
unsigned long, og skal returnere en void* til det lager, den allokerer. delete
modtager en pointer til det lager, som ønskes deallokeret, og skal ikke returnere en værdi.
Det er sjældent, at der er brug for at omdefinere den indbyggede lageradministration i C++,
men en eventuel applikation kan være en enkel opbygning af et virtuelt lager, organiseret på
en objekt-orienteret måde. Hvis de brugerdefinerede lageradministrationsfunktioner ikke kan
allokere interne lager ved en forespørgsel, kan de skrive dele af det aktuelle lager ud på et
sekundært lager (eksempelvis en disk) og erstatte dette med det nyallokerede lager. Med
overstyringer af både new og delete samt af pointer-operatoren kan funktionerne
kontrollere, hvilke af de allokerede objekter, der har ligget ubrugte hen. På den måde kan
programmet efter forskellige retningslinier (tidligst brugt, round-robin etc.) vælge hvilke det
objekt, der skal swappes til disk.
En simpel implementation af de to lageradministrationsfunktioner er blot en enkel
grænseflade til det eksisterende C-biblioteks funktioner malloc() og free(). Her
overlades administrationen af de blokke, der er allokeret til disse funktioner, som normalt
igen blot lader operativsystemet om det:
void* operator new (size_t size) {
return malloc (size); // "dum" allokering
}
void operator delete (void* pointer) {
free (pointer); // "dum" deallokering
}
Disse overstyringer af de globale lagerallokeringsoperatorer er især brugbare under systemer,
hvor der ikke findes et underliggende operativsystem (for eksempel embeddede systemer),
fordi det gør koden flytbar. Det er også overordentligt anvendeligt under systemer, som
allokerer lager i blokke af faste størrelser. For eksempel vil et kald til new under OS/2 2.0
altid medføre et minimumsforbrug på 4096 bytes. Operativsystemet indeholder specielle
funktioner til sub-allokering af dette lager, men det er en triviel og kedelig opgave. Med en
enkel overstyring kan sub-allokeringen foregå transparent i forhold til applikationen.
222 Design af abstrakte datatyper 3.8

Det er temmeligt vigtigt at overstyre begge fuktioner, da den underforståede anden funktion
ellers vil blive brugt med garanterede uønskede virkninger. Den indbyggede operator
new() vil normalt returnere 0, hvis det adspurgte lager ikke kunne allokeres. Dog vil
funktionen først forsøge at kalde en fejlbehandlingsfunktion, som normalt kaldes
new_handler(), hvis en sådan er defineret. En sådan funktion kan defineres af
programmøren og indsættes i systemet, således at en eventuel fejl opsamles og kan forsøges
reddet. Et kald til set_new_handler() modtager en pointer til en funktion, som
modtager en void* og returnerer void. Kaldet vil indsætte denne funktion som global
fejlbehandlingsfunktion og vil iøvrigt returnere adressen af den aktuelle funktion:
void MyErrorHandler (void* pointer) {
cout

void operator delete (void* pointer) {
count--;
delete pointer;
}
};
I forbindelse med klasse-specifikke overstyringer af disse operatorer er der to vigtige punkter
at tage notits af. Eventuelle afledte klasser (ved brug af arv, se afsnit 4.3) fra en klasse, der
indeholder overstyringer af new og delete vil overtage metoderne, og de skal derfor
skrives med dette i tankerne. Det er også vigtigt at være klar over, at oversætteren selv finder
ud af størrelsen på det objekt, der skal allokeres. Den værdi, der overføres til operator
new() er antallet af maskinord ( == sizeof (char) ) og skal ikke multipliceres med
størrelsen på det aktuelle objekt. Under arv er dette meget vigtigt at huske på - disse
funktioner nedarves nemlig, men kan ikke være virtuelle (afsnit 4.4.3), da de er statiske. De
fundamentale typers allokeringer kan ikke overstyres enkeltvis, de globale new- og
delete-operatorer gælder for dem alle.
Når en vektor af objekter af en klasse allokeres med new, kaldes den globale operator
new() og når vektoren fjernes igen, kaldes operator delete() i det globale
navnerum. Husk at antallet af kaldte konstruktører er proportionalt med størrelsen af vektoren
i erklæringen.
I det næste eksempel vises, hvordan en klasse kan anvende new og delete til at foretage
intern administration af de objekter, der allokeres. Klassen, som repræsenterer simplificeret
streng, kæder alle dynamisk allokerede objekter sammen i en hægtet liste. Ligegyldigt hvor i
programmet, en String allokeres med new vil den indgå i denne liste. Det tillader os at
allokere forekomster af String uden at tildele returværdien fra new-kaldet til en
pointervariabel samt at gennemgå listen og sikre konsistensen i alle objekterne. Det betyder
også, at alle String-objekter kan deallokeres én gang for alle eller måske udlæses på et
sekundærlager i forbindelse med oprydning efter en uventet hændelse som for eksempel en
allokeringsfejl.
class String {
char* rep;
String* next; // næste streng i listen
String* prev; // forrige streng i listen
static String* first; // første streng i listen
static String* last; // sidste streng i listen
public:
String () { }
String (const char* s) {
rep = new char [strlen (s) + 1];
strcpy (rep, s);
}
~String () { delete rep; }
void* operator new (size_t);
224 Design af abstrakte datatyper 3.8

void operator delete (void*);
static void Walk (ostream&);
static void delete_all ();
friend ostream& operatornext = s;
s->prev = last,
last = s, s->next = 0;
return s;
}
void String::operator delete (void* ptr) {
String* s = (String*) ptr;
if (s->prev) s->prev->next = s->next;
else first = s->next;
if (s->next) s->next->prev = s->prev;
else last = s->prev;
::delete s; // kald global delete
}
void String::Walk (ostream& os) {
for (String* s = first; s; s = s->next)
os

new String ("fjerde");
new String ("femte");
String::Walk (cout); // udskriv dem alle
String::delete_all (); // fjern dem alle
}
Læg mærke til, at disse operatorer følger de normale regler for tilgang i klasser. Det
betyder, at en privat operator new vil forbyde klienter at allokere forekomster af den
pågældende klasse dynamisk. Læg også mærke til, at disse eksempler viser forskellen på
instantiering og initiering. Instantieringen er den proces, der allokerer ressourcer for et objekt,
mens initieringen konfigurerer objektet. Det er operator new der instantierer og
konstruktøren, der initierer. Det betyder også, at et eksplicit kald til en destruktør i et
dynamisk allokeret objekt ikke vil kalde operator delete.
operator new og operator delete kan overstyres efter normale regler, så de
modtager ekstra information fra klienten i form af parametre. For eksempel,
class X {
public:
void* operator new (size_t size, int i) {
// ...
}
void operator delete (int j) {
// ...
}
};
X* xp = new (3) X;
// ...
delete xp (3);
Parametre til new og delete er sjældent anvendelige, men er tænkt som information til
allokatoren og deallokatoren, som skal være på plads før objektet konstrueres. Et forslag i et
distribueret system kunne for eksempel være den egentlige maskine, som objektet skal
allokeres på, men man kan også forestille sig, at klienten kan angive præallokeret lager i
kaldet til new, som ved overstyringen
void* operator new (size_t, void* ptr) { return ptr; }
blot accepterer denne placering af lageret. Nu kan klienten skrive
char mem [0x100]; // 256 bytes præallokeret
lager
String* s = new String (mem); // en String i dette område
226 Design af abstrakte datatyper 3.8

og ganske enkelt styre, hvor objekterne bliver allokeret. En interessant fordel ved at overtage
selve lageret er, at de dynamisk allokerede objekter (med virtuelle funktioner og alting - se
afsnit 4.4) kan inspiceres og udlæses af klienten selv. Pas imidlertid på ikke at delete
lager, der er allokeret på denne måde, fordi lageret rent faktisk ikke skal frigives. Det rejser et
problem, nemlig at vi ønsker at kalde objektets destruktør, men ikke at deallokere det. Så
derfor kalder vi blot destruktøren eksplicit:
s->String::~String (); // destruér, men ej deallokér
I versioner af C++ før 2.0 omfattede overtagelsen af lageradministrationen en vis akrobatik i
forbindelse med tildelinger til this-pointeren. Det er beskrevet i afsnit 3.5.18 og er nu en
forældet teknik, som de fleste oversættere ikke tillader. I afsnit 5.5.6 vises et eksempel på,
hvordan arv spiller sammen med brugerdefineret lageradministration.
3.9.4 Objekt-I/O
Programmer, der ikke er i stand til at ind- og udlæse data, er der ikke meget ved. Funktionsorienterede
programmer skrevet efter strukturerede metoder bruger specielle funktioner til
denne form for dataudveksling. Når der arbejdes med abstrakte datatyper, er det imidlertid
ofte mere hensigtsmæssigt at indkapsle I/O-funktioner i klasser, så de enkelte objekter selv er
i stand til at lagre og hente deres indhold. Ved objekt-I/O skal forstås det enkelte objekts -
ikke klasses - evne til at læse og skrive data. Anvendeligheden af dette skal ses i forbindelse
med mange applikationers nødvendighed for at kunne dele data mellem flere processer i et
system. I distribuerede systemer skal et objekt for eksempel være tilgængeligt flere steder på
samme tid. Visse objekt-orienterede systemer, især databasesystemer, indeholder begrebet
bestandige objekter, dvs. objekter, hvis eksistens ikke er bundet til eksekveringen af et
bestemt program. Objekterne "lever" altid et eller andet sted i systemet, uanset om et program
arbejder på dem til et givent tidspunkt.
I dette afsnit beskrives en simpel form for objekt-I/O, som arbejder på en enkelt abstrakt
type, og som giver typen en vis form for bestandighed. I det større perspektiv kræver objekt-
I/O, at der tages stilling til en mængde problemer med datarepræsentation i objekt-orienterede
systemer, da begreber som arv, polymorfi og statiske data gør objektindholdet meget
kompliceret. I kapitel 5 diskuteres teknikker for bestandige objekter i objekt-hierarkier.
Den enkleste måde at udvide en type på, så den er i stand til at ind- og udlæse objekter af
typen, er at anvende standardbibliotekets stream-klasser. Gennem disse kan vores typer
skrives til og læses fra en fil, kommunikeres til andre samkørende processer, over parallelle
eller serielle porte osv. Fremgangsmåden er den samme for alle ADT'er, og består af to
metoder til henholdsvis læsning og skrivning. For at udbygge klassen Complex med objekt-
I/O tilføjes en statisk metode readFrom(), som læser en Complex fra en navngiven
strøm og returnerer denne, mens den normale metode dumpOn() skriver objektet på en
strøm:
3.8.3 Brugerdefineret lageradministration 227

class Complex {
double re, im;
public:
// ...
static Complex& readFrom (istream& = cin);
void dumpOn (ostream& = cout);
};
Complex& Complex::readFrom (istream& input) {
Complex* temp = new Complex;
input >> temp->re >> temp->im;
return *temp;
}
void Complex::dumpOn (ostream& output) {
output

}
3.9.5 Samarbejde med andre sprog
I mange sprog er der ingen direkte faciliteter for lænkning af objektkode oversat af andre
oversættere. For eksempel er der et problem med samarbejdet mellem C og Pascal, fordi de
har hver deres metode at arrangere data på stakken under parameteroverførsler til funktioner
og fordi Pascal-overættere normalt udskriver navne i objektfilen med versaler mens C tillader
både store og små bogstaver. For at komme dette problem til livs, kan der mange oversættere
specificeres særlige nøgleord til parameteroverførselskontrol. I Borland C++ kan vi skrive
pascal int write (char*, int); // pascal kaldekonvention
cdecl int open (char*, int); // C kaldekonvention
for at kontrollere, om returadressen skal stakkes først eller sidst ved kaldet til funktionen.
Nøgleord som pascal er ikke en del af ANSI-standarden, og bliver det sandsynligvis ikke.
Når der skrives C++, er der et andet forhold, der problematiserer tingene yderligere. Navne
på funktioner, der er overstyret, skal i objektfilen have et unikt idenfificérbart navn for at
kunne lænke ordentligt. Disse navne bliver genereret af oversætteren, der normalt skaber et
navn, der har relevans til parametre eller klasser. For eksempel vil
int write (int);
int write (char);
int write (int, char*);
give navne af følgende art til funktionerne, når de skrives ud som objektfil fra oversætteren:
__write@si __write@sc __write@sicP
Oversætteren differentierer på den måde funktioner med samme navn ved at påføre ekstra
tegn afhængig af parametrenes typer. Der er et umiddelbart problem med denne teknik, der
går under betegnelsen name mangling, "navnemingelering". De fleste lænkere har nemlig en
maksimumlængde for navne, hvilket er cirka 32 tegn. Hvis navnemingeleringen
afstedkommer, at et navn bliver længere end 32 på grund af de ekstra påførte tegn, vil to
navne enten være ens (lænkerfejl) eller der må bruges en hashing-teknik for at ændre ét af
navnene. Helt sikkert bliver det dog aldrig, så det tilrådes ikke at benytte alt for lange navne i
overstyrede funktioner.
Men problemet bliver mere tydeligt, hvis koden skal lænkes med andre biblioteker. Hvis vi
for eksempel bruger en standard-funktion med prototypen
double sin (double);
3.8.4 Objekt-I/O 229

og andetsteds i programmet selv introducerer en overstyring af dette navn som
Complex sin (Complex);
vil oversætteren typisk mingelere de to navne med følgende resultat. Klitentens program, der
bliver oversat separat, vil producere et objektmodul, der indeholder de mingelerede navne
inklusive kaldet til den funktion, der findes i standard-biblioteket, som jo allerede er oversat
og findes i en anden objekt- eller biblioteksfil. Når de to objektmoduler lænkes, kan kaldet til
den ene funktion ikke lokaliseres, fordi oversætteren uden at blinke har ændret navnet i selve
koden: Hvor det oversatte bibliotek indeholder en funktion med et navn som _sin kalder
klientens kode noget i retning af _sin@dd, og lænkeren er ikke i stand til at producere et
køreklart program.
Løsningen er at benytte, hvad der i C++ hedder type-sikker lænkning, som er meddelelser til
oversætteren om, hvad der må og ikke må mingeleres. Hvis prototypen på den første sin()funktionen
får starten
extern "C" double sin (double);
vil oversætteren under alle omstændigheder lade dette navn være. Denne meddelelse fortæller
også, at der skal benyttes C-konventioner, for eksempel parameterrækkefølge. For mange på
hinanden følgende udtryk kan en blok benyttes:
extern "C" {
double sin (double);
double cos (double);
double tan (double);
}
Det skal bemærkes, at selve konventionen er maskinafhængig, og i visse tilfælde også
oversætterafhængig. Pointen er blot, at C++ skal kunne arbejde sammen med biblioteker
udviklet i andre sprog. Det er let at forestille sig type-sikker lænkning til biblioteker oversat
med andre sprog end C. Zortech C++ til MS-DOS og OS/2 tillader for eksempel Pascalkonventioner
med
extern "Pascal" ...
så det varer sikkert ikke længe for vi ser type-sikker lænkning muliggjort til Fortran- eller
COBOL-biblioteker.
For programmører, der skal bruge eksisterende C-biblioteker eller skriver understøttende
kode i assembler, kan det være en fordel at sætte C-konvention om hele den inkluderede
headerfil. Det tillader, at headeren kan bruges i både C++ og i C. Oversætteren vil behandle
alle erklæringer, definitioner og prototyper i traditionel C-stil uden at mingelere navne eller
lignende. For eksempel,
230 Design af abstrakte datatyper 3.8

extern "C" {
#include
}
En anden mulighed er at teste for den indbyggede makro __cplusplus, som er defineret,
hvis der er tale om en C++-oversættelse, og udefineret, hvis der er tale om en anden
oversættelse (normalt C). Denne makro kan testes for eksistens, og via betinget oversættelse
kan mingelering forbydes for C++-oversættelser:
#if defined (__cplusplus)
extern "C" {
#endif
// ... erklæringer og prototyper ...
#if defined (__cplusplus)
}
#endif
3.10 ANVENDELSER FOR ABSTRAKTE DATATYPER
I dette afsnit beskrives fire reelle anvendelser for abstrakte datatyper, som har forskellige
anvendelsesområder. Eksemplerne bliver benyttet og videreudviklet i senere kapitler, og
indgår også i klasebiblioteket i den sidste del af bogen. Der henvises i forbindelse med dette
afsnit især til [Horowitz 78] og [Sedgewick 88].
3.10.1 Klassen LinkedList
En meget ofte benyttet datastruktur er den hægtede liste. Hægtede lister (undertiden også
kaldet kædede lister) er ikke til at komme udenom, når data skal organiseres og relateres uden
forhåndkendskab til, hvor mange elementer der bliver brug for under kørslen. Hvis
programmøren på forhånd ved, hvor mange elementer der skal bruges, kan disse blot
allokeres i en vektor med new, men hvis antallet er afhængigt af kørslen af programmet, skal
der en anden teknik til.
Den hægtede liste arbejder med klumper af data, som peger på hinanden med
pointervariable. De enkelte klumper kaldes hægter eller nodes, og den hægtede liste består
blot af en pointer til den første hægte. Skal en ny hægte påføres listen er det blot et spørsmål
om dynamisk at allokere en ny hægte og lade den indgå i listen, så den kan findes frem igen.
En hægtet liste kan grafisk repræsenteres som i figur 3-2. Den hægtede liste har en pointer
til det første element, som igen peger på det andet og så videre indtil den sidste hægtes pointer
har værdien 0. At finde en hægte i listen bliver dermed et spørgsmål om at traversere listen,
dvs. iterativt gennemgå listen mens pointeren derefereres, indtil den ønskede hægte bliver
3.8.5 Samarbejde med andre sprog 231

aktuel. Den hægtede liste i dette afsnit har en meget simpel implementation, som kun
indeholder fremadrettede referencer (en singulært hægtet liste), og som blot har en pointer til
den første hægte. Andre implementationer kan indeholde bagudreferencer til de forrige
hægter (en dobbelthægtet liste), kan have både pointere til den første og sidste hægte i listen
og kan eventuelt have en præallokeret headnode, som sparer en smule databehandling i
indsættelsen af nye hægter.
Figur 3-2: Grafisk repræsentation af en hægtet liste.
I denne implementationen brugers en hægte, som har et prædefineret indhold, nemlig et
streng-objekt fra afsnit 3.9.1:
// eksempel 3-8
// en hægtet liste (klasserne Node og List)
typedef int bool;
// Node er en privat klasse
class Node {
friend LinkedList;
Node* next; // peger på den næste hægte
String* data; // peger på hægtens data
Node (String* s, Node* n) :
data (s), next (n) { }
};
// LinkedList definerer en singulært hægtet liste
class LinkedList {
Node* head; // peger på første hægte
public:
LinkedList () { head = 0; }
void Insert (String*); // indsæt en streng i listen
String* Retrieve (); // hent en streng fra listen
bool isEmpty () { return !head; } // er listen tom?
};
232 Anvendelser for abstrakte datatyper 3.10

metode til indsættelse af data i listen
void LinkedList::Insert (String* s) {
head = new Node (s, head);
}
// metode til udlæsning af data fra listen
String* LinkedList::Retrieve () {
String* s = head->data;
Node* n = head->next;
delete head; head = n;
return s;
}
Hægtede lister bruges oftere end de fleste tror, så selv om de er meget simple at implementere
er det ingen grund til ikke at indkapsle dem i klasser. Ovenstående eksempel bruger et statisk
typefelt - en String - hvilket egentlig burde give anledning til at kalde listen for en
StringLinkedList. I næste kapitel udvides klassen, hvor LinkedLister ved hjælp af
arv og polymorfi får generelle egenskaber og kan bruges i mange forskellige sammenhænge.
LinkedLists virkemåde demonstreres ved følgende eksempel:
Output:
void Print (LinkedList& list) {
while (!list.isEmpty ()) {
cout data);
delete s;
}
}
void main () {
LinkedList elever;
elever.Insert (new String ("Gurli"));
elever.Insert (new String ("Johanne"));
elever.Insert (new String ("Henriette"));
Print (elever);
}
Gurli
Johanne
Henriette
Bemærk, at listen udlæses i omvendt rækkefølge, fordi der altid arbejdes på den hægtede liste
fra head-pointeren, både under indsættelse af hægter (Insert()) og udlæsning af hægter
(Retrieve()). I denne implementation er klienten iøvrigt ansvarlig for allokering og
3.10.1 Klassen LinkedList 233

deallokering af hægternes indhold. De String-objekter, som klienten opretter, skal klienten
også selv fjerne, mens klassen LinkedList tager sig af lageradministrationen af Nodeobjekter.
Faktisk ser klienten aldrig noget til Node, hvorfor denne klasse er en såkaldt privat
klasse. Alle medlemmer er erklæret private, og klassen ikke har en underforstået
konstruktør, men derimod en eksplicit, som er privat, kan kun friend-klasser og -
funktioner instantiere objekter af Node. LinkedList er således friend til Node.
I næste kapitel udbygges denne hægtede liste til også at omfatte sortering, indeksering og
andre operationer, der er relevante for denne datastruktur.
3.10.2 Klassen AssocArray
Vektorer i C++ er så generelle, som de overhovedet kan blive. Mange sprog indeholder
faciliteter for sikring af lovlige referencer i vektorer, mens andre kan behandle elementerne
associativt (indholds-relateret) i modsætning til sekventielt. C++'s vektorer er simple, fordi
sprogets filosofi er simpel - hvis der er brug for specielle vektorer, kan programmøren selv
skrive dem i en abstrakt datatype. Der er ingen grund til at udvide selve sproget med en
facilitet, som kun i visse sammenhænge er nødvendig. Klassen i dette afsnit er en avanceret
skabelon-vektortype, som under kørslen vil checke for ulovlige opslag samt tillade associative
opslag. Den erklæres med det ny typenavn, og bruges med få undtagelser på samme måde
som normale vektorer, takket være overstyring af indeks-operatoren:
AssocArray a (10); // 10 elementer i en int-vektor
a [4] = 0; // tildeling til 4. element
a [20] = 0; // fejl: indeks er for stort
Såvidt den omfangssikrende del af klassen. Normale opslag i en vektor benyttes, når indekset
haves, og indholdet ønskes. Associative opslag er omvendte: indholdet af et element kendes,
og indekset ønskes. Hertil bruges funktionskalds-operatoren, og associtative opslag får
følgende syntaks:
AssocArray a (10);
a [5] = 33; // 5. element indeholder 33
int i = a (33); // i bliver 5
Ulovlige opslag ved for store indeks-værdier eller indhold, som ikke findes i vektoren
resulterer i en fejlmeddelelse og en "sikker" returværdi, som er en statisk medlemsvariabel i
klassen, og som blot skal sikre, at klienten ikke skriver til udefinerede data.
// eksempel 3-9
// en associativ liste (skabelonklassen AssocArray)
template
class AssocArray {
234 Anvendelser for abstrakte datatyper 3.10

TYPE* array; // den indkapslede vektor
unsigned size; // antal elementer i vektoren
public:
AssocArray (const int = 0);
AssocArray (const AssocArray&);
~AssocArray ();
AssocArray& operator= (const AssocArray&);
AssocArray operator+ (const AssocArray&) const;
TYPE& operator[] (const unsigned);
unsigned operator() (const TYPE&);
friend ostream& operator

array = new TYPE [size];
memmove (array, from.array, size * sizeof (TYPE));
}
return *this;
}
// addition af to AssocArray'er
template
AssocArray AssocArray::operator+
(const AssocArray& other) const {
AssocArray temp (size + other.size);
if (temp.size) {
memmove (temp.array, array, size * sizeof (TYPE));
memmove (&temp.array [size], other.aray,
other.size * sizeof (TYPE));
}
return temp;
}
// sekventielt opslag i en AssocArray
template
TYPE& AssocArray::operator[] (const unsigned idx) {
if (idx < size) return array [idx];
cerr

for (int i = 0; i < arr.size - 1; i++)
strm

Ved at ændre på erklæringen af vektoren i starten, så vektorens parameterisering er en anden
end en int, kan en AssocArray repræsentere vektorer af andre typer. For eksempel:
Output:
void main () {
AssocArray a (4), b (4);
for (int i = 0; i < 4; i++)
a [i] = i * 1.3, b [i] = -i * 1.3;
// ...
}
a = { 0, 1.3, 2.6, 3.9 }
b = { 0, -1.3, -2.6, -3.9 }
c = { 0, 1.3, 0.91, 2.21, -6.76, -8.06, -17.81, -19.11 }
AssocArray: index out of bounds
c [32] = 0
3.10.3 Klassen Random
Tilfældige tal er nødvendige i mange videnskabelige applikationer. I et normalt
funktionsbibliotek findes funktioner, som ved gentagne kald returnerer en serie af tilfældige †
tal efter en given forskrift, ofte initieret med en begyndelsesværdi. En tilfældighedsgenerator
kan indkapsles i en abstrakt datatype med fordele over et normalt funktionsbibliotek, fordi
klienten kan arbejde med en datatype "et tilfældigt tal".
Implementationen af klassen Random har ydermere en fordel over standard-funktionen i
C++ (og C), da den bruger sin egen algoritme [Kirkpatrick 81] til generering af serien af tal.
Hvis klienten således instantierer flere Random-objekter, vil de arbejde fuldstændigt
uafhængigt af hinanden, et faktum, der ikke holder for funktionsbiblioteket, som bruger den
samme globale funktion og dermed status. Hvis klienten bruger tilfældige tal i en
hændelsesdrevet applikation, vil brugen af uafhængige generatorer sikre, at de samme serier
kan genskabes ved brug af samme startværdier.
Random er også et eksempel på, hvordan funktionalitet fra standardbiblioteker kan
indkapsles i en abstrakt datatype, så en bedre grænseflade til klienten opnås. Objekter
instantieres med angivelse af en seed (en startværdi for serien) og et loft for de tilfældige tal,
så klienten kan anmode om tal i et bestemt interval. Klassens konstruktør initierer en liste af
† Eftersom en digital computer er deterministisk, vil den ikke kunne generere totalt tilfældige tal, hvilket er grunden
til, at de oftest benævnse pseudo-tilfældige.
238 Anvendelser for abstrakte datatyper 3.10

tal som udgør den grundlæggende del af algoritmen og en underforstået
konverteringsfunktion laver Random-objekter om til positive heltal. Det tillader klienten at
arbejde med tilfældige tal på følgende måde:
Random r; // r er et tilfældigt tal
unsigned serie [100]; // serie er en liste af heltal
for (i = 0; i < 100; i++)
serie [i] = r; // fyld listen op med tilfældige tal
Klassens implementation ser således ud:
static const rndbufsiz = 250;
class Random {
unsigned* buffer;
int index, ceiling;
public:
Random (int = rand (), int = 0);
~Random () { delete buffer; }
operator unsigned ();
};
// konstruktør: initiér buffer med tilfældige tal
Random::Random (int seed, int ceil) : ceiling (ceil) {
buffer = new unsigned [rndbufsiz];
srand (seed);
index = 0;
int msb = 0x8000, mask = 0xFFFF;
for (int i = 0; i < rndbufsiz; i++) buffer [i] = rand ();
for (i = 0; i < rndbufsiz; i++)
if (rand () > 0x4000) buffer [i] |= msb;
for (i = 0; i < 16; i++) {
int k = i * 11 + 3;
buffer [k] &= mask;
buffer [k] |= msb;
mask >>= 1, msb >>= 1;
}
}
// konverteringsmetode: returnerer 16-bit tilfældigt tal
Random::operator unsigned () {
int i = (index >= 147) ? index - 147 : index + 103;
unsigned next = buffer [index] ^ buffer [i];
buffer [index] = next;
3.10.3 Klassen Random 239

index = (index >= rndbufsiz - 1) ? 0 : index + 1;
return ceiling ? next % ceiling : next;
}
3.10.4 Klassen Set
En meget brugbar datatype, som ikke findes i hverken C eller C++, men derimod i Pascal og
Modula-2, er en mængde. Ved en mængde forstås en samling af værdier, som alle kun kan
være indeholdt i mængden én gang. Operationer på mængder omfatter fællesmængder mellem
to mængder, foreningsmængder og indsætning/udtagning af de enkelte værdier i mængden.
Klassen Set er en abstrakt datatype, som beskriver en mængde, hvor værdiernes maxima
fra starten er fastlagt. Set repræsenterer hvert tal i mængden med én bit, som beskriver om
et givet tal er til stede i mængden eller ej. Da et tal kun kan forekomme én gang i mængden,
er en enkelt bit nok til at repræsentere tallet - sålænge denne bit står på en bestemt plads.
Udregningen af denne plads i lageret er da også, hvad Sets metoder næsten alle handler om.
Set er et eksempel på en numerisk type, som internt arbejder med en datatype, som ikke
findes normalt i C++. En bit er ikke en type i C++, og derfor må Set skjule
implementationen fuldstændig af vejen. Det er ikke muligt for eksempel at returnere
referencer til elementer, sådan som AssocArray gør (afsnit 3.10.2).
typedef int bool;
class Set {
unsigned char* data;
unsigned long bits;
unsigned long bytes () const { return (bits + 7) >> 3; }
Set& largest (const Set& s) const {
return bits > s.bits ? *this : s;
}
public:
Set (const unsigned long);
Set (const Set&);
~Set () { delete data; }
Set& operator= (const Set&);
Set operator+ (const unsigned long) const;
Set operator- (const unsigned long) const;
Set& operator+= (const unsigned long);
Set& operator-= (const unsigned long);
bool operator[] (const unsigned long) const;
Set operator| (const Set&) const;
Set operator& (const Set&) const;
Set& operator|= (const Set&);
Set& operator&= (const Set&);
240 Anvendelser for abstrakte datatyper 3.10

ool operator== (const Set&) const;
bool operator!= (const Set& s) const {
return !(*this == s);
}
void off () { memset (data, 0x00, bytes ()); }
void on () { memset (data, 0xFF, bytes ()); }
friend ostream& operator

indsættelse af en værdi i den aktuelle mængde
Set& Set::operator+= (const unsigned long bit) {
if (bit < bits) data [bit >> 3] |= (1 > 3] &= ~(1 > 3] & (1

eturn *this;
}
// sammenligning af to mængder
bool Set::operator== (const Set& o) const {
for (unsigned long bit = 0; bit < largest (o).bits;
bit++)
if (operator[] (bit) != o [bit]) return 0;
return 1;
}
// udskrivning af mængde på standard-strøm
ostream& operator

eturnerer en reference til det aktuelle objekt, og er ikke konstante, da de har
indflydelse på det aktuelle objekts data. Klienten kan således skrive
a = b += c;
så a tildeles b efter c er blevet adderet til b. Returværdien fra operator+=()
kan være en reference, da der ikke er grund til at oprette en midlertidig forekomst for
at returnere det aktuelle objekt.
• Klassens metoder benytter hinanden med stor fordel, hvorved det demonstreres, at en
implementation med små, isolerede metoder har gavn af disses begrænsede
funktionalitet. Sammenlignings-operatoren er et godt eksempel. I forbindelse med
sammenligning af to mængder skal det også bemærkes, at størrelsen på de to
mængder ikke behøver være den samme. Selv om den ene mængde har flere antal
mulige værdier end den anden, kan de to mængder stadig indeholde samme aktuelle
værdier, hvorved de bliver ens.
Ud over selve klassens interessante interne detaljer viser Set også eksempler på, hvordan
visse operator-overstyringer kan give mindre problemer i brug. Overvej følgende eksempel på
brugen af Set:
Output:
void main () {
Set s1 (10), s2 (10);
for (int i = 0; i < 5; i++)
s1 += i * 2, s2 += i * 2 + 1;
cout

s3 = { 0 2 4 8 }
{ 0 2 4 8 } == { 0 2 4 8 }
I main() fyldes to mængder på med henholdsvis ulige og lige tal i intervallet fra 0 til 9, og
klasserne samt deres forenings- og fællesmængder udskrives. I cout-sætningen
demonstreres, hvordan sprogets indbyggede præcedens i evalueringen af subudtrykkene
bliver et problem for forekomster af Set. Hvis klienten skriver
cout

4. Hvad er forskellen på type-baseret indkapsling og objekt-baseret indkapsling, og
hvilken metode bruges i C++? Diskutér anvendeligheden af den anden metode.
5. Du har skrevet et bibliotek til behandling af strenge, som indeholder følgende
funktioner:
void strcpy (char*, const char*);
void strcmp (const char*, const char*);
unsigned strlen (const char*);
Hvilke metoder kan tages i brug for at forbedre dette bibliotek?
6. Design en klasse til manipulation af matricer. Matricer er todimensionale vektorer af
kommatal. Hvordan bør de private data arrangeres? Hvilke konstruktører bør bruges?
Hvilke operatorer bør overstyres? Hvilke typekonverteringer har klassen brug for?
Hvilke medlemsfunktioner skal bruges?
7. Udvid standardbiblioteket til at omfatte ind- og udlæsning af matricer (opgave 3.6).
8. I C++ er der en udtrykkelig forskel på initiering og tildeling. Hvad består denne
forskel i? Hvorfor er det interessant?
9. Hvad er forskellen på indkapslede og ikke-indkapslede operator-funktioner? Hvornår
bruges hvilken type?
10. Hvad er en friend-funktion? Giv et eksempel på, hvornår det er nødvendigt at
bruge friend-funktioner.
11. Hvad er forskellen på en fundamental og en abstrakt datatype? Hvad er forskellen fra
en klients synspunkt?
12. C++ er et objekt-orienteret sprog med en funktions-orienteret syntaks. Det giver
anledning til tvedtydigheder i mange sammenhænge. Giv nogle eksempler.
13. Modificér eksempel 3-6 i afsnit 3.6.7, så ingen medlemsfunktioner er inline. Mål
forskellen i eksekveringstider for forskellige anvendelser af klassen, for eksempel
operator-kald, vektor-erklæringer og dynamiske allokeringer.
14. Givet klassen i eksempel 3-5, hvilke medlemsfunktioner kaldes underforstået i
følgende sætning:
Complex a = Complex (5,6) + Complex (3,3) + 2;
246 Opgaver til kapitel 3 3.11

15. Forklar begrebet brugerdefineret typekonvertering. Hvorfor og hvornår bør dette
bruges?
16. Givet klassen i eksempel 3-6, hvilke medlemsfunktioner kaldes underforstået i
følgende sætning:
double d = (Complex (3, 7) * 4) + Complex (2);
17. Givet følgende prototype:
void f (G&);
hvilken information overføres til funktionen f() ved dette kald:
f (*new G);
Hvad indebærer denne form for allokering, når objektet, der allokeres med new
senere skal destueres? Hvem bør holde rede på objektet: den kaldende eller den
kaldte metode?
18. Hvad er forskellen på statiske medlemsvariable og normale medlemsvariable? Giv et
eksempel på brugen af statiske medlemsvariable.
19. Hvad er forskellen på statiske medlsmsfunktioner og normale (ikke-statiske)
medlemsfunktioner? Giv et eksempel på brugen af statiske medlemsfunktioner.
20. Hvad er en privat klasse? Diskutér anvendeligheden af private klasser, og i hvilke
sammenhænge, de kan bruges.
21. Nogle objekt-orienterede sprog indeholder ikke faciliteter til at forbyde klienter
adgang til objekters data. Diskutér ulemperne ved dette forhold fra et udviklingsmæssigt
synspunkt.
22. Skriv en skabelon til en generel sorteringsfunktion. Funktionen skal kunne sortere
objekter af alle typer i lineære lister af vilkårlige typer hvor det forudsættes, at
typerne har en operator>()-overstyring. Du må selv vælge sorteringsalgoritme.
3.12 REFERENCER OG UDVALGT LITTERATUR
[Stroustrup 87a] og [Stroustrup 87b] fortæller noget om udviklingen af C++ fra det
procedurale C til et sprog med abstrakte typer og modularitet. Om sprogets sammenhæng med
tidligere forskning og i forbindelse med andre sprog henvises til [Lippmann 88]. I [Coplien
3.11 Opgaver til kapitel 3 247

92] findes en oversigt over de mange idiomer, som en C++-programmør skal være bekendt
med.
248 Introduktion 4.1

Objekt-Orienteret Programmering
Forrige kapitel handler om klasser. I terminologien bruges begreberne klasser
og abstrakte datatyper i flæng, hvilket desværre er en smule hæmmende for en
bred forståelse af sprogets muligheder, for dataabstraktion er kun én af
ingredienserne i et objekt-orienteret program. I dette kapitel skal vi se på,
hvordan vi kan udnytte C++'s muligheder for at understøtte udvikling af
objekt-orienterede programmer til fulde. Men først skal nogle principper for
traditionel programdesign "aflæres"; en frokost er aldrig gratis.
4.1 INTRODUKTION
Overgangen fra et proceduralt orienteret sprog som C til et objekt-orienteret sprog som C++ er
lettest i den fase, der handler om abstrakte datatyper. Indkapsling og dataskjul, som er beskrevet i
de forrige kapitler, er let at lære for en programmør, som har brugt de gængse metoder, fordi
metoden bygger på allerede kendte principper, der i vid udstrækning også bruges under for
eksempel C.
Det er muligt at bruge et sprog som C++ udelukkende med henblik på manipulation af abstrakte
datatyper. Et program, som før bestod af funktionsbiblioteker og globale datastrukturer, kan
omskrives til at indeholde isolerede klasser med indbyggede metoder til manipulation af
tilhørende data. Problemerne, som løses med dataabstraktion, er af programmeringsteknisk
karakter. De objekt-orienterede principper adresserer løsning af design- og
konstruktionsproblemer i softwareudvikling.
Når vi anvender et bestemt sprog og en bestemt udviklingsmetode til løsning af et
programmeringsproblem, bruger vi et sæt af regler for at strukturere programmets opbygning. Et
ofte brugt begreb for et sådant sæt regler, som tilsammen udgør udviklingsmetoden og sprogets
støtte til denne, er et paradigme. Det proceduralt orienterede paradigme handler om at nedbryde
det overordnede problem i delproblemer, og implementere disse som miniature-programmer. Det
er altså et spørgsmål om funktionelt at isolere opgaverne fra toppen nedefter, og abstrahere de
enkelte opgaver i mindre blokke - for eksempel funktioner eller filer.
Som beskrevet i kapitel 1 er det sjældent, at et sprog direkte understøtter en given
programmeringsmetode. Nogle sprog giver mulighed for programmering efter mange forskellige
paradigmer, mens andre kun tillader ét bestemt, og andre igen direkte understøtter programmøren
3.11 Opgaver til kapitel 3 249
4

i en bestemt metode. I C er det for eksempel muligt at skrive både objekt-orienterede
programmer, proceduralt orienterede programmer og selv udøve logikprogrammering, i Modula-
2 [Wirth 82] er dataabstraktion og modulærprogrammering næsten uundgåelig, mens Smalltalk
[Goldberg 83a] helt påtvinger programmøren det objekt-orienterede paradigme. At bruge en
bestemt programmeringsmetode i et sprog, som ikke direkte understøtter et givent paradigme
bliver derfor et spørgsmål om disciplin fra programmørens side. Desværre er programmører et
sært folkefærd, som alle arbejder forskelligt, og som alle har deres egne kæpheste.
C++ er en slags hybrid i denne sammenhæng. Sproget tvinger ikke programmøren til at bruge
et bestemt paradigme, men understøtter i videst muligt omfang det paradigme, der vælges. Da
C++ er kildetekst-kompatibelt med C, er dette næsten en forudsætning. De overbygninger, der
findes over C i C++ er, når det kommer til stykket, meget få og simple. Men når de bruges
korrekt, har de kolossal effekt.
4.1.1 Det objekt-orienterede paradigme
De fleste programmører er bekendt med struktureret programmering og design, som handler om
at konkretisere data, relationer mellem data og behandling af data, set udfra et programeksekveringsmæssigt
synspunkt. Man tegner data-flow diagrammer, hvor data forbindes med
logisk separerede dele af programmet, og man tegner flow-charts, hvor programmet arbejder på
de tildelte data. Derefter skriver man subprogrammerne efter flow-chartet.
Objekt-orienteret programmering bygger videre på klasse-begrebet, og beskriver relationer
mellem klasser. Idet klasser består af både data og af metoder til bearbejdning af disse, er
relationerne mellem klasserne hvad vi mangler for at kunne konstruere mere komplekse
programmer. I afsnit 3.9.1 så vi, hvordan klasser kan arbejde sammen i et eksempel med
afgrænsede typer. I det eksempel var det nødvendigt udtrykkeligt at beskrive forskellene mellem
de to klasser ved underforståede brugerdefinerede typekonverteringer, som skulle skrives
eksplicit i begge klasser. Objekt-orienteret programmering giver en bedre og renere metode til
beskrivelse af klasse-relationer.
Der er tre nøglepunkter, der kendetegner et objekt-orienteret sprog:
• Indkapsling, som beskriver grænsefladen mellem en klasse og en klient af denne,
• Arv, som bruges til at beskrive sammenhænge, relationer og afhængigheder klasser
imellem, samt til at lette udviklingen af generisk kode,
• Dynamisk binding, som skjuler forskellene mellem klasserne fra klienten (udtrykt ved
arv).
Indkapsling, som er beskrevet i kapitel 3, tvinger klienten til at bruge et defineret sæt af regler
og operationer for manipulation af en forekomst af en klasse (klassens specifikation), og sikrer
konsistens i dens data. Klienten isoleres bogstaveligt talt fra forekomstens data og fra de
algoritmer, der bruges til at arbejde på dem (klassens implementation). Dermed kan en klasse
ændres med garanti for, at et klientprogram ikke fejler, og fejlfinding gøres ligeledes lettere, idet
kode, som arbejder på bestemte data i en klasse, er isoleret indenfor samme klasse.
250 Introduktion 4.1

Arv er en teknik, som tillader en klasse at overtage data og metoder fra en eksisterende klasse,
og som dermed simplificerer udviklingen af nye klasser. Ideen er, at vi kan nøjes med at beskrive
forskellene mellem de to klasser i stedet for at omskrive en hel klasse. Pointen er, at hjulet
allerede er opfundet. Hvis du opfinder et nyt hjul, og det er bedre end det, der findes i forvejen, så
har du opnået noget. Ellers har du spildt din tid. Arv gør det mere favorabelt at skrive generiske
programmer, altså programmer, som udfører generelle opgaver, og isolere disse i klasser. Andre,
mere specifikke opgaver, kan nedarve fra de generelle klasser og bygge de mere specifikke dele
ovenpå. Genbrug af kode er et af de vigtigste emner i fremtidens softwarekonstruktion. De
kæmpe-opgaver, der skal løses, tillader ikke enhver at genopfinde hjulet efter behov, med alle de
fejl og abnormaliteter samt ikke mindst tidsforbrug dette måtte medføre. For programmører, der
hidtil har arbejdet med proceduralt orienterede sprog, kan beskrivelsen af nedarvninger være
svære at se pointen i. Men husk altid, at de ikke har det fjerneste med data-flow eller control-flow
diagrammer at gøre. De beskriver ikke algorimer eller datamodeller, men udgør snarere en
nedbrydning af et program i reelle koncepter - på samme abstraktionsniveau, som man kan
bevæge sig på under hele udviklingsfasen. Det giver en stor frihed at kunne tale om
afgrænsninger i et program som isolerede koncepter helt fra designfasen og ned i kildeteksten.
Når der ikke foretages kontekst-skift, får man en bredere og mere homogen forståelse for
programmets logik.
Dynamisk binding, eller sen binding, gør klientprogrammerne mere generiske ved at skjule
forskellene mellem relaterede klasser. Via dynamisk binding kan forskellige klasser have
forskellige implementationer af den samme funktion. Herefter kan en klient kalde denne funktion
uden at kende præcis hvilken klasse, der arbejdes på. Hvad er fordelen i det? For eksempel kan et
klientprogram, som udskriver formularer, være den samme uanset typen af formular.
Klientprogrammet kalder blot en metode i klassen, og dynamisk binding sikrer, at det er den
rigtige metode for den specifikke klasse af en forekomst, der kaldes. Men hvordan kan klienten
kalde en funktion i en klasse uden at kende karakteren af denne klasse? Det er blot en af
fordelene ved arv. Som vi skal se, tillader arv os at behandle forskellige klasser med mindre indre
afvigelser på samme måde for derved at opnå en generalisering af den kode, der behandler alle
klasse-forekomster af samme karakter. Dynamisk binding virker ved at forsinke
bindingstidspunktet til programmet rent faktisk kører, og beskrives nærmere i afsnit 4.4.2.
4.1.2 Terminologi
Med objekt-orienteret programmering medfølger en del nye begreber, som kræver en forklaring,
før vi for alvor kan tage fat:
Indkapsling skjuler implementationsdetaljer ved at samle data og kode i klasser, som beskrevet
i kapitel 3. Når en klasse arver fra en anden, kaldes den nedarvede klasse for baseklassen eller
den overordnede klasse og den nedarvende for den afledte eller underordnede klasse. Visse bøger
kalder bruger også termerne nedarvede og nedarvende klasser, men de leder efter min mening til
begrebsforvirringer (hvad er hvad?) og er alt for ens (kun ét bogstav til forskel). I denne bog
holder jeg mig til de førstnævnte baseklasser og afledte klasser.
4.1.1 Det objekt-orienterede paradigme 251

Figur 4-1: Lineær arv (a), multipel arv (b) og hierarki af klasser (c).
Det er muligt igen at nedarve fra en afledt klasse, ligesom baseklassen selv kan være en afledt
klasse. For at få hold på dette bruges base og afledt relativt fra den aktuelle klasse, der tales om.
Der kan nedarves flere gange fra samme baseklasse til forskellige afledte klasser og en afledt
klasse kan nedarve fra flere forskellige baseklasser, hvilket bærer betegnelsen flersidet eller
multipel arv. Et system af baseklasser og afledte klasser kaldes et klasse-hierarki. Der findes
mange systemer til at afbilde klasse-hierarkier, men de mest simple viser blot de enkelte klasser
som kasser og nedarvningerne som streger imellem dem, hvor afledningen foregår vertikalt
nedefter og hvor pilene går i retning af baseklasserne. Her er det så muligt at specificere de
enkelte klassers data og metoder inde i kasserne, så det klart fremgår, hvad der nedarves (figur 4-
1). Der findes mange forskellige udvidelser til denne repræsentation, for eksempel har [Booch
91] en hel række af ikoniserede pile til at symbolisere blandt andet arv, instantiering, indkapsling
som medlem og andre typeforhold samt tilsvarende symboler for klasseforhold så som leksikalt
skop, parametre, felter og synkrone/asynkrone kald. En anden model til beskrivelse af klassehierarkier
er en linie-baseret liste af klassenavne, indrykket efter afhængigheder af baseklasser, så
klassenavnene mod venstre er baseklasser og navnene mod højre er de afledte klasser:
class_a
class_b
class_c
class_d // d arver fra c, b og a
class_e
class_f
class_g
252 Introduktion 4.1

class_h // h arver fra g og a
class_i
Denne model er simplere og fylder meget mindre, men skaber problemer, når den skal beskrive
komplekse klassehierarkier (med multipel arv, for eksempel, som beskrives i afsnit 4.5). Den
bruges imidlertid i opremsningerne af eksempelklasserne i kapitel 7.
De egenskaber, sproget får fra dynamisk binding af metoder i klasser, kaldes polymorfe. Dette
begreb, som er græsk og betyder mangeformet egenskab, dækker over det princip, at en given
metode eller datastruktur kan bruges på mange forskellige måder, uden konkret at skulle
specificere måden for den enkelte metode eller datastruktur. Det er ikke helt let at begribe dette
koncept, men det er meget centralt i objekt-orienteret programmering, så lad os tage et eksempel:
du skriver en funktion, som i en løkke tegner et antal grafiske objekter på skærmen. Disse
objekter er alle forekomster af forskellige klasser som beskriver forskellige geometriske former.
Under normale omstændigheder skal du i løkken for hver iteration kalde en specifik metode i
hver klasse afhængig af, hvilken geometrisk form den har (da det jo er forskellige metoder, der
tegner forskellige former). Dette klares for eksempel med en switch-kontrolstruktur i løkken.
Pointen er nu, at de polymorfe metoder tillader dig at være ligeglad med, hvilken klasse det
aktuelle objekt tilhører, sålænge alle klasserne har den samme indkapslede tegne-metode. Den
sene binding vil så at sige foretage valget helt underforstået. Funktionen bliver dermed meget
simpel og letlæselig, og det bliver endvidere, som vi skal se, meget let at udvide funktionens
virkemåde uden at ændre en linie eller sågar at genoversætte den! Det er således polymorfiens
funktion både at organisere programmerne bedre og at gøre dem mere generiske.
Polymorfi realiseres delvist gennem en programkonstruktion i C++, som hedder virtuelle
funktioner eller metoder. Virtuelle metoder har polymorfe egenskaber i den forstand, at de
repræsenterer de "usynlige" forskelle mellem klasserne. De manifesterer dermed den flertydighed,
som et typehierarki kan have. Grunden til, at de er virtuelle er, at de har egenskaberne
af metoder, men ikke nødvendigvis implementerer disse rent fysisk. De kan med andre ord
erstattes af andre funktioner uden videre. Virtualitet kendes på mange måder i datalogien, for
eksempel indenfor lageradministration og maskinarkitekturer.
Når en baseklasse konstrueres med virtuelle metoder, er det normalt ikke meningen, at den skal
instantieres, dvs. at en klient opretter et objekt af klassen, fordi den kun definerer en fællesnævner
for afledte klasser. Baseklasser med denne kvalitet kaldes ofte for abstrakte klasser, fordi det ikke
er muligt at skabe et objekt af klassen. Det abstrakte ligger i, at klassen ikke kan bruges af
klienten, men kun som baseklasse for andre klasser.
4.2 ET EKSEMPEL-PROBLEM
Som i sidste kapitel starter vi med en problemstilling, som vi løser per absurdum, dvs. med en
metode, vi ved er "forkert", for derefter bedre at kunne se fordelen i at bruge en mere "rigtig"
metode - i henhold til objekt-orienterede pricipper. Programmet, der skal skrives, er et grafisk
system, der kan bruges til opstilling af forskellige geometriske former på skærmen. Først løses
problemet i C++ med abstrakte datatyper og derefter forbedres det trinvist, som flere objektorienterede
faciliteter kommer for dagen.
4.1.2 Terminologi 253

Kravet til programmet, som skal kunne fungere som bibliotek for klienter, der skal bruge
forskellige figurer på skærmen, er, at figurtyperne punkt, linie og rektangel skal kunne behandles
og det skal være muligt dynamisk at ændre på figurerne. De skal ydermere kunne tegnes på en
skærm af vilkårlige dimensioner, som defineres af klienten. En sådan skærm kaldes en logisk
eller virtuel skærm, fordi den har alle egenskaber en rigtig skærm har, men er rent faktisk kun en
software-repræsentation af en skærm. Programmet skal derfor kunne oversætte brugerens
koordinatsystem til de dimensioner, som den aktuelle hardware har. En sådan oversættelse kaldes
en transformation, og involverer en skalering af koordinater fra logiske (virtuelle) koordinater til
fysiske (reelle) kordinater. Grunden til, at en transformation af koordinater er interessant er, at det
gør de geometriske klasser uafhængige af en bestemt opløsning på skærmen eller den enhed, man
nu ønsker at vise sit billede på. Ved at ændre transformationen kan det samme geometiske
program tegne figurer på et andet koordinatsystem uden at skulle omskrives. Den umiddelbare
fordel er, at grafikprogrammet kan flyttes til anden hardware, dvs. en anden skærmtype - for
eksempel med større opløsning eller flere farver. Men også indenfor samme skærm er det muligt
at forestille sig vinduer, dvs. indrammede, logiske subskærme indenfor den fysiske skærm. Igen
er det selve de geometriske objekter uvedkommende; de er blot interesserede i at repræsentere og
behandle sig selv, og ikke i absolutte, fysiske skærm-orienterede konstanter.
4.2.1 En løsning med abstrakte datatyper
Vi angriber problemet med de metoder, vi gennemgik i kapitel 3. Programmet skrives ud fra et
design, som indkapsler alle gensidigt uafhængige data og funktioner i klasser, som kan
instantieres og bruges af klienten. Vi er interesserede i at arbejde med forskellige geometriske
former, samt at udskrive disse på en output-enhed. Programmet skal derfor kunne arbejde med
datatyper som Firkant og Linie. Først erklærer vi to andre klasser, som arbejder sammen
med de geometriske klasser og som går igen mange gange i geometriske programmer. De to
klasser hedder Koordinat og Transformation, og behandler henholdsvis koordinater på
en todimensionel flade samt transformationer fra logiske til fysiske koordinatsystemer.
4.2.2 Klassen Koordinat
Koordinater bruges i næsten alle manipulationer af grafiske figurer, deriblandt beskrivelser af
punkter i et koordinatsystem, selve koordinatsystemets dimensioner samt transformationer
mellem koordinatsystemer og er derfor en oplagt kandidat til indkapsling i en brugerdefineret
datatype. Klassen Koordinat's definition ser sådan ud:
// eksempel 4-1a: en koordinat-ADT
enum bool { nej, ja };
class Koordinat {
double x, y; // det faktiske koordinat
public:
254 Et eksempel-problem 4.2

Koordinat () : x (0), y (0) { };
Koordinat (double& xi, double& yi) : x (xi), y (yi) { }
Koordinat (const Koordinat& k) : x (k.x), y (k.y) { }
Koordinat operator+ (const Koordinat&) const;
Koordinat operator- (const Koordinat&) const;
Koordinat operator* (const Koordinat&) const;
Koordinat operator/ (const Koordinat&) const;
Koordinat& operator+= (const Koordinat&);
Koordinat& operator-= (const Koordinat&);
Koordinat& operator*= (const Koordinat&);
Koordinat& operator/= (const Koordinat&);
friend ostream& operator

}
De to andre aritmetiske overstyringer, operator+= og operator-=, tildeler begge et
Koordinat summen af to Koordinater, hvoraf den ene er det aktuelle objekt. Derudover
returnerer de også resultatet (som reference-type), så sætninger som
a += b += c; // c adderes til b, dernæst b til a
kan oversættes:
Koordinat& Koordinat::operator+= (const Koordinat& k) {
x += k.x, y += k.y;
return *this;
}
Koordinat& Koordinat::operator-= (const Koordinat& k) {
x -= k.x, y -= k.y;
return *this;
}
De fire medlemsfunktioner operator*(), operator*=(), operator/() og
operator/=() multiplicerer og dividerer objekter af Koordinat. At multiplicere og
dividere koordinater er brugbart i transformationer af figurers placeringer på skærmen, dvs. når
der skal oversættes fra virtuelle til fysiske koordinater.
Koordinat Koordinat::operator* (const Koordinat& k) const {
return Koordinat (x * k.x, y * k.y);
}
Koordinat& Koordinat::operator*= (const Koordinat& k) {
x *= k.x, y *= k.y;
return *this;
}
Koordinat Koordinat::operator/ (const Koordinat& k) const {
return Koordinat (x / k.x, y / k.y);
}
Koordinat& Koordinat::operator/= (const Koordinat& k) {
x /= k.x, y /= k.y;
return *this;
}
256 Et eksempel-problem 4.2

Overstyringen af standard-output-operatoren

Figur 4-2: Grafisk transformation.
Klienten kan til enhver tid bestemme sig for at ændre på de fysiske koordinater ved at fortælle
transformations-klassen om de nye koordinater. Derved vil efterfølgende brug af de geometriske
klasser automatisk omstille sig til det aktuelle koordinatsystem. I dette eksempel benytter vi ikke
en faktisk fysisk skærm af to årsager: for det første er det ikke interessant for eksemplet, hvordan
man rent algoritmisk tegner linier og streger på en bestemt enhed, og for det andet er det svært at
vise sekventielt grafisk output i en bog. Derfor nøjes vi med bot at skrive operationen som en
grafikkommando. I en reel situation ville vi have to transformationer, først en fra brugerens
selvvalgte koordinatsystem til normaliserede koordinater, dvs. et altid ensartet logisk
koordinatsystem (for eksempel afgrænset mellem 0 og 1), og dernæst fra de normaliserede
koordinater til fysiske koordinater. I vores eksempel er vi ikke interesserede i at gøre os
hardware-afhængige på nogen måde, og springer derfor dette led over.
Transformation-klassen indeholder derfor blot den transformation, som oversætter fra
logiske til fysiske koordinater:
258 Et eksempel-problem 4.2

eksempel 4-1b: en todimensionel transformationsklasse
class Transformation {
Koordinat transfunkt;
public:
Transformation () : transfunkt (1, 1) { };
void setFysisk (const Koordinat& fysisk) {
transfunkt *= fysisk;
}
void setLogisk (const Koordinat& logisk) {
transfunkt /= logisk;
}
Koordinat operator () (const Koordinat& k) const {
return transfunkt * k;
}
};
Klassen Transformation indeholder et Koordinat-medlem, som hedder
transfunkt og som beskriver selve transformationen. Når en Transformation
instantieres, sættes transfunkt til (1,1), dvs. et forhold mellem de logiske og de fysiske
koordinater på 1:1 for både x- og y-koordinater. To medlemsfunktioner styrer henholdsvis det
logiske og det fysiske koordinatsystem og har reciprokke virkninger for transfunkts
indhold.
setFysisk(), som tillader brugeren at ændre på den fysiske skærm, modtager
dimensionerne på det fysiske koordinatsystem i et Koordinat, som ganges med transformationsfunktionen.
Jo større, det fysiske koordinatsystem bliver, des mindre bliver tælleren i
forholdet mellem det logiske og det fysiske koordinatsystem. Hvis setFysisk() kaldes med
en Koordinat(1280,1024), bliver tranformationsfunktionen 1280:1 for x-aksen og 1024:1
for y-aksen, dvs. at hvis et koordinat skal oversættes skal det ganges med 1280 for x og 1024 for
y. setLogisk() arbejder lige omvendt, idet den dividerer transformationsfunktionen med
angivelsen af det logiske koordinatsystem. Hvis klienten angiver det fysiske koordinatsystem til
(1280,1024) og det logiske til (640,256), vil forholdet blive 2:1 for x og 4:1 for y, dvs. den
logiske skærm er ca. otte gange mindre end den fysiske. Det omvendte forhold, dvs. et kald til
setLogisk() med for eksempel (10000,10000), vil resultere i et forhold på ca. 1:8 for x og
1:10 for y.
De geometriske klasser bruger kald til forekomster af Transformation via den
overstyrede operator(), som returnerer det fysiske koordinatsæt for et givet logisk
koordinatsæt. Transformation ganger blot de logiske koordinater, som kommer fra den
geometriske klasse, med den aktuelle transformations-funktion og returnerer dette som et
Koordinat. Hvis det fysiske koordinatsystem er sat op til (1280,1024) og det logiske til
(640,512), vil transfunkt have værdien (2,2). Et kald til operator() med et vilkårligt
koordinatsæt vil returnere den korrekte oversættelse:
Transformation t;
4.2.3 Klassen Transformation 259

Output:
t.setFysisk (1280,1024);
t.setLogisk (640,512);
cout

const Koordinat IBM_8514 (1280,1024); // fysisk skærm
const Koordinat IBM_CGA (320,200); // logisk skærm
void main () {
trans.setFysisk (IBM_8514);
trans.setLogisk (IBM_CGA);
Koordinat punkt (100,100);
cout

Da Figur er en privat klasse, kan den ikke instantieres af klienter udenfor medlemsfunktioner i
de klasser, som er erklæret friend til Figur. Læg mærke til, at det ikke er nødvendigt at
prototype de tre friend-erklæringer. Figur beskriver blot et generelt grafisk objekt med et
startpunkt, en farve og et kan-ses-flag.
4.2.5 Klasserne Punkt, Linie og Firkant
Nu er det tid til at definere de faktiske geometriske klasser, som er friend til Figur:
Punkt, Linie og Firkant. Punkt er et enkelt billedelement på skærmen (en pixel), mens
en Linie og et Firkant har et startpunkt og et endepunkt. Alle tre klasser har en forekomst
af en Figur som privat medlemsvariabel.
// eksempel 4-1d: en konkret figur-klasse
class Punkt {
Figur fig;
public:
Punkt () : fig () { }
Punkt (const Koordinat& k) : fig (k) { }
void Tegn ();
void Slet ();
void Flyt (const Koordinat&);
};
void Punkt::Tegn () {
fig.vises = ja;
cout

Punkt har to konstruktører: en underforstået konstruktør, som blot opretter et en forekomst af et
Punkt og nulstiller alle variable samt en konstruktør, som initierer et Punkt med et
koordinatsæt. Der er ingen destruktør, da et Punkt kun indeholder medlemsvariable som
forekomster og ikke som indirekte pointere til forekomster. Den underforståede destruktør er
derfor nok til at destruere Punkter (man kunne dog selvfølgelig forestille sig, at destruktøren
slettede punktet fra skærmen eller noget lignende - det behøver ikke altid være de udtrykkelige
regler, der bestemmer, hvad en destruktør skal bruges til). Ligeledes er de underforståede kopikonstruktører
og tildelings-operatorer tilstrækkelige.
Udover konstruktørerne indeholder klassen tre public metoder til behandling af punkter:
• Tegn() tegner et Punkt på skærmen,
• Slet() sletter Punktet på skærmen,
• Flyt() flytter et Punkt til et nyt koordinat, relativt fra den aktuelle position.
Tegn() skriver således blot koordinaterne ud på skærmen, mens Slet() fortæller, at punktet
på koordinaterne nu er slettede. Flyt() ser først, om punktet er aktuelt (vises på skærmen),
hvorefter det i bekræftende fald fjernes. De nye koordinater gøres aktuelle og punktet vises igen,
hvis det tidligere var vist på skærmen.
Når et Punkt instantieres med et Koordinat, videregives dette til Figur-forekomsten.
Der er ingen andre datamedlemmer, da indholdet af Figur er nok til at beskrive et Punkt. De
tre normale metoder i Punkt benytter forekomsten af den globale transformationsklasse
trans til beregning af fysiske koordinater. Punkter kan nu bruges som følger:
void main () {
Koordinat Normal (1,1);
trans.setLogisk (Normal); // 1:1-oversættelse
trans.setFysisk (Normal); // logisk == fyisk
Punkt a (Koordinat (10,10)), c;
c = a;
a.Flyt (Koordinat (12,6));
a.Tegn (); c.Tegn ();
c.Flyt (Koordinat (3,-3));
a.Slet ();
}
Dette program udskriver:
Punkt tegnet på (22,16)
Punkt tegnet på (10,10)
Punkt slettet på (10,10)
Punkt tegnet på (13,7)
Punkt slettet på (22,16)
4.2.5 Klasserne Punkt, Linie og Firkant 263

Vi skal også have linier og rektangler:
// eksempel 4-1e: flere konkrete figur-klasser
class Linie {
Figur fig;
Koordinat endePunkt;
public:
Linie () : fig (), endepunkt () { }
Linie (const Koordinat& k, const Koordinat& e) :
fig (k), endePunkt (e) { }
void Tegn ();
void Slet ();
void Flyt (const Koordinat&);
};
void Linie::Tegn () {
fig.vises = ja;
cout

void Flyt (const Koordinat&);
};
void Firkant::Tegn () {
fig.vises = ja;
cout

Flyt() og Slet() fordi de er underlagt hvert deres skop - de respektive klasser.
4.2.6 Gennemgang af ADT-løsningen
Vi har implementeret de tre klasser Punkt, Linie og Firkant som abstrakte datatyper,
fordi de repræsenterer tre isolerede koncepter i en grafisk applikation. Dataabstraktion handler
netop om at isolere konceptuelt forskellige dele af programmet i indkapslede moduler, som kan
skjule implementationen og kompleksiteten fra brugeren.
Men koncepter er aldrig helt isolerede. Selvom en linie ikke ligner et rektangel, er de dog begge
geometriske former, og selvom et punkt er noget helt andet end en linie, deler det dog mange
egenskaber med linien. Det kan vi endda se helt klart: selvom de tre klasser er helt isolerede, er
en stor del af koden helt identisk fra klasse til klasse.
Problemet her består altså ikke kun af programmeringstekniske overvejelser om grænseflader til
klienten og skjulning af implementationer. Komplekse programmer (og de er flest) indeholder
mange relaterede og dog divergerende koncepter, der skrives som specialiserede dele af det.
Hvordan kan disse afvigelser beskrives med et minimum af dublet-kode? I anden omgang ser vi,
at brugen af relaterede klasser bliver svær fra klientens side. Når flere klasser deler en del af deres
anvendelighed, men er forskellige typer, får klienten svært ved at arbejde på dem samlet.
4.2.7 En forbedret ADT?
Måske er abstrakte datatyper slet ikke gode til at repræsentere mere komplicerede og
sammenhængende koncepter. En løsning, der ligger tættere på de funktionsorienterede sprog,
ville måske være bedre til opgaver som denne. For eksempel kan vi omskrive den generelle
klasse Figur, til at repræsentere både punkter, rektangler og linier, og som deler
medlemsfunktionerne for alle figurer. Prisen for at kunne dele disse funktioner er, at vi selv skal
overtage typekontrollen på de forskellige geometriske former.
// eksempel 4-2: en kombineret figur-klasse
enum figurType { Punkt, Linie, Firkant; }
class Figur {
figurType slags;
bool vises;
Farve f;
union { // anonym union
Koordinat p; // for punkter
struct { Koordinat ls, le; } // for linier
struct { Koordinat rx, re; } // for firkanter
};
public:
266 Et eksempel-problem 4.2

Figur (figurType t, Koordinat& k) :
p (k) { // konstruktion af punkt
f = hvid, slags = t, vises = nej;
}
Figur (figurType t, Koordinat& k1, Koordinat& k2) :
ls (k1), le (k2) { // konstruktion af linie
f = hvid, slags = t, vises = nej; // eller firkant
}
void Tegn ();
void Slet ();
void Flyt ();
};
void Figur::Tegn () {
switch (slags) {
case Punkt:
cout

vises = nej;
}
void Figur::Flyt (Koordinat& k) {
bool vistes = vises;
if (vises) Slet ();
switch (slags) {
case Punkt:
p += k; break;
case Linie:
ls += k, le += k; break;
case Firkant:
rs += k, re += k; break;
}
if (vistes) Tegn ();
}
Nu har vi indkapslet alle figurtyperne i en enkelt klasse, men det synes ikke at have mindsket
kompleksiteten. Der er tvetydigheder i konstruktørerne, som må benytte sig af forskellige
parameterlister og strukturen i unions for at initiere objekterne korrekt til den rette figurtype.
De tre specielle klient-metoder Tegn(), Slet() og Flyt() er faktisk slet ikke så delt
mellem figurtyperne, som de ser ud til. Selvom de tre metoder er fælles for alle figurer, skal de
foretage et valg af kode for den aktuelle figur for hvert kald. Det er selvfølgelig nydeligere at
indkapsle dette valg i stedet for at lade det være op til klienten, men koden skal alligevel udføres
for hver operation.
Eksempel 4-2 introducerer en ny opremsning, en figurType, som indeholder navnene på de
forskellige figurer, der kan indeholdes i klassen Figur. En indkapslet, anonym union i
Figur består af de tre forskellige datastrukturer, som de tre figurtyper behøver (henholdsvis et
koordinat, to koordinater samt to koordinater). Medlemsfunktionerne tester variablen slags,
som beskriver figur-typen (Punkt, Linie eller Firkant), og vælger en bestemt rute
afhængig af denne; de forskellige figurer skal jo i sidste ende tegnes forskelligt.
Og det er netop dette, der er kernen i problemet. De fleste programmer indeholder et større antal
datastrukturer, som er næsten ens. De behandles alle på samme måde, men da de ikke er helt ens,
må der skrives behandlende kode (metoder) til hver enkelt af dem. Det giver en masse kode, som
næsten ser redundant ud, men som simpelthen behandler en specialiseret klasse eller datastruktur.
Struktureret design, for eksempel, resulterer ofte i programmoduler, som indholder næsten
identiske funktioner - ofte blot med typenavne eller variabelnavne erstattet. Det er normalt
umuligt at skrive generiske funktioner til fælles behandling af disse næsten ens strukturer, fordi
de netop ikke er helt ens.
Dette kan illustreres med et forslag til et klientprogram, der benytter klasserne i eksempel 4-1
og 4-2. Det ville for eksempel være nyttigt at kunne holde et antal figurer i en liste (vektor, hægtet
liste, stak eller andet) og skrive dem ud eller flytte dem rundt med reference til elementerne i
268 Et eksempel-problem 4.2

listen. Men da figurerne er forskellige, må der skrives forskellige funktioner til at behandle de
forskellige typer - det er ikke muligt at generalisere: Selvom de har meget til fælles, kan sproget
ikke se lighederne. En cirkel-tegnefunktion er fra oversætterens synspunkt noget helt andet end
en linie-tegnefunktion. Med eksempel 4-1 som bibliotek må et klientprogram eksplicit foretage
dette type-check i koden og kalde den ønskede metode i det ønskede objekt. Hvis eksempel 4-2
ligger til grund, skal selve klassen skrives om, hvis en ændring ønskes.
Det, der er brug for, er en mere formel metode til udtrykkeligt at beskrive forskellene mellem
klasser, som har noget til fælles. Denne metode hedder arv, og er hjørnestenen i det objektorienterede
paradigme og dets faciliteter for genericitet og genbrug af kode.
4.3 ARV
Vi husker fra kapitel 3, at klasser og typer har samme betydning i objekt-orienteret terminologi.
Når et program består af flere forskellige klasser med mindre afvigelser, er det en fordel, hvis
sprogets typesystem hjælper programmøren med at undgå så mange eksplicitte (programkontrollerede)
type-checks som muligt. Jo bedre type-ækvivalens sproget selv kan beskrive, des
mindre triviel kode skal skrives dertil.
Typesystemet i C++ udvider, som beskrevet i kapitel 3, begrebet fra de indbyggede, skalære
typer til brugerdefinerede, abstrakte typer. Den store gevinst er i første omgang, at de
brugerdefinerede typer kan blandes i sproget uden tab af abstraktion og i anden omgang, når de
objekt-orienterede faciliteter tages i brug, at typerne kan relateres til hinanden og smelte sammen.
Typesystemet udvides altså ikke blot til at omfatte indkapslinger og pæne grænseflader, men også
til at beskrive forhold typerne imellem.
For at forstå begrebet "et forhold mellem typer" må vi se på programudvikling og -design på en
ny måde. For mange betyder dette, at de velkendte metoder og paradigmer skal lægges på hylden,
for objekt-orienterede programmer er fundamentalt anderledes end andre programmer. Dog er
paradigmet heldigvis naturligt forekommende.
4.3.1 Type-ækvivalens
Vi har det med at klassificere verden. Vi ordner virkeligheden efter klasser og opstiller systemer
for afhængigheder og relationer. Grundprincippet i det objekt-orienterede paradigme er præcis
det samme. Programmer bør designes og opbygges med de "logiske byggesten", verden er lavet
af.
For eksempel klassificerer vi verdens fauna meget stringent. Vi taler om forskellige dyrearter,
som igen opdeles i racer og racerne manifesterer sig undertiden som faktiske dyr med
individuelle karakterer og egenskaber. Dumbo er en elefant † , som har et pattedyrs egenskaber.
Insekter er et andet godt eksempel, hvor indviklede systemer kategoriserer de forskellige dyr.
Ligeledes for planteverdenen. Litteratur og musik. Astronomi og mytologi. Vi inddeler vores
hverdag i et hierarki af klasser for at holde rede på, hvad tingene repræsenterer, hedder og kan
bruges til.
† Dumbo er faktisk en forekomst af en elefant (vistnok indisk).
4.2.7 En forbedret ADT? 269

Det interessante er nu, at kategoriseringen indebærer en naturlig nedarvning nedefter i
hierarkiet: det, som gælder for et pattedyr, gælder for både hunde, katte, marsvin og spidsmus.
Det, som gælder for hunde gælder både for Pluto og Nuser. Det er ikke en tilfældighed, at vi
inddeler verden på denne måde. Hvis det hele var en stor pærevælling af isolerede samlinger af
egenskaber og adfærd ville vi simpelthen ikke kunne overskue noget. Sådan har det til gengæld
været med software i lang tid.
Tilbage til C++. Når vi taler om nedarvning mellem klasser, betyder det, at én klasse kan
"overtage" kode og data fra andre klasser efter bestemte regler og udbygge eller modificere dem
efter behov. Således kan en overordnet baseklasse beskrive alt, hvad der vedrører pattedyr (for
eksempel gennemsnitlig levetid, kropstemperatur og drægtighedstid), hvorefter en underordnet
afledt klasse kan overtage alt, hvad baseklassen indeholder og udbygge med flere data og
metoder for at specialisere klassen, for eksempel for hunde med pelstype og opdrætningsforhold.
En anden klasse kan nedarve for aber og udvide med sprogkundskaber og klatrefærdighed.
Ligesom i det konceptuelle hierarki bliver det faktisk implementerede hierarki i C++ en samling
af klasser, hvor de overordnede er generelle og de underordnede er mere specifikke.
Figur 4-3: Et associativt opbygget hierarki.
270 Arv 4.3

Der er flere fortrin ved en sådan konceptuel opdeling. Ikke nok med, at klasserne bliver lette at
overskue og at eksisterende kode bliver let at genbruge på grund af den direkte nedarvning fra
andre klasser, så kan et baseobjekt også bruges som basis-reference til mange forskellige afledte
objekter. Hvis en type har arvinger er det logisk ækvivalent til dem alle, og kan derfor bruges til
at samordne mange forskellige afledte objekter i en enkelt databehandling. Eller med andre ord:
en baseklasse har type-ækvivalens til afledte klasser. Dette giver en utrolig frihed i
programmeringen, fordi man ikke behøver kende den faktiske afledte klasse, men kan arbejde på
baseklassen alene. For eksempel kan en hundekennel holde sine internerede hunde i en liste af
hunde, som indeholder referencer til en baseklasse. Hver reference peger egentlig på en bestemt
forekomst af en klasse, som er nedarvet fra hunde-klassen, for eksempel puddel, gravhund
og collie. Sålænge en klasse nedarver fra hunde (eller fra en anden klasse, som nedarver
fra hunde osv.) kan den bruges som "generel hund". Hvis en metode i klassen, som er fælles
for alle hunde (for eksempel logre()), skal kaldes for alle hunde, behøver vi ikke kende den
faktiske afledte klasse for at kalde funktionen. Det er nok at kende til baseklassen.
Denne overlagte ligegyldighed gennemføres ved at forsinke bindingstidspunktet mellem kalder
og modtager fra oversættertidspunktet til kørselstidspunktet, det, der kaldes sen binding eller
dynamisk binding. Når en baseklasse har disse mange forskellige skjulte egenskaber, kaldes den
en polymorf klasse. Polymorfe klasser og magien bag dynamisk binding behandles i afsnit 4.4.
4.3.2 Lineær arv
Lad os gå tilbage til problemstillingen i eksemplerne 4-1 og 4-2. Hvad er det mest rigtige design
af geometri-klasserne? Eksempel 4-1 har en indkapslet funktionalitet, som skjuler
implementationsdetaljerne fra klienten, men som kræver en hel del dublet-kode i alle klasserne,
fordi de er meget ens. Eksempel 4-2 udnytter derimod den samme kode lidt bedre, men kræver, at
klassen skrives om for hver ændring. Hvis vi er interesserede i at tegne en trekant, skal næsten
alle metoder i Figur-klassen skrives om - man skal med andre ord ind og pille ved kode, som
er meget sensitiv, og som man eventuelt ved virker. Derefter skal metoderne testes igen for alle
varianter, selv dem, der allerede virkede og var kendte. Lineær arv udtrykker en
typesammenhæng, som indgår i C++'s typesystem som en forskel mellem to typer. Løsningen er
en mellemting mellem eksempel 4-1 og 4-2, idet der er brug for at dele visse funktioner klasserne
imellem og separere andre funktioner fra hinanden. Vi erklærer derfor en generel Figur-klasse,
som er meget lig samme klasse fra eksempel 4-1:
class Figur {
public:
Farve f;
Koordinat p;
bool vises;
Figur () : p () { f = hvid, vises = nej; }
Figur (Koordinat& k) : p (k) { f = hvid, vises = nej; }
};
4.3.1 Type-ækvivalens 271

Figur er en generalisering af de tre geometriske klasser. Alle klasserne har en x/y-koordinat og
et flag, der fortæller, om figuren vises eller ej. Nu ændrer vi erklæringen af de tre klasser fra
eksempel 4-1:
class Punkt : public Figur { // et punkt er en figur
public:
void Tegn (); // kun punkter ved, hvordan de
void Slet (); // selv skal tegnes & slettes
};
class Linie : public Figur { // en linie er også en figur
Koordinat endepunkt; // men udbygger med et punkt
public:
Linie (); // og har derfor en konstruktør
void Tegn (); // kun linier ved, hvordan de
void Slet (); // selv skal tegnes.
};
class Firkant : public Figur {
Koordinat endepunkt; // firkanter er også figurer
public:
Firkant (); // og har derfor en konstruktør
void Tegn (); // metoder til tegn og slet
void Slet ();
};
I erklæringsdelen af klassen, efter class navn, skrives et kolon og et andet klassenavn.
Betydningen af dette er, at klassen skal arve data og metoder fra klassen efter kolonet. Sætningen
class A : public B { // ...
kan læses som "klasse A er en slags B...". public betyder her, at A får privat adgang til B's
offentlige data og metoder, og beskrives nærmere i afsnit 4.3.5. Vi har altså abstraheret de fælles
egenskaber i de tre geometriske klasser ind i en ny, overordnet klasse, som de tre klasser nedarver
fra. Punkt, Linie og Firkant er afledt fra Figur, de er subtyper af denne type. Ikke
blot i vores begrebsverden, men rent semantisk i C++ er de tre klasser Figurer.
Læg mærke til forskellene på de tre klasse-erklæringer. Punkt har ingen data, koordinatet p
samt vises-flaget og farven er nok til at beskrive et punkt. Linie udbygger med et nyt
koordinat, et endepunkt, som fortæller, hvor linien ender. Firkant udvider ligeledes med et
andet Koordinat, som her beskriver det andet hjørne.
272 Arv 4.3

Figur 4-4: Nedarvning fra Figur.
Denne abstraktion beskriver forskellen mellem de tre klasser på en meget elegant måde. Idet både
Punkt, Linie og Firkant er Figurer, kan de bruges som sådanne. Det er nu muligt for
eksempel at skrive en hægte af Figurer, som kan indeholde en hvilken som helst klasse,
sålænge den er nedarvet fra figur:
class FigurHaegte {
Figur& fig;
FigurHaegte* naeste;
public:
FigurHaegte (Figur& f) : fig (f) { }
void HaegtPaa (FigurHaegte& fh) { naeste = &fh; }
};
Konstruktøren i hægten initierer nye forekomster af FigurHaegte med en Figur eller en
arving af Figur. Her ses, hvordan tre forskellige klasser kan lægges i samme liste:
4.3.2 Lineær arv 273

void f () {
Punkt a;
Linie b;
Cirkel c;
FigurHaegte h1 (a), h2 (b), h3 (c);
h1.HaegtPaa (h2);
h2.HaegtPaa (h3);
h3.HaegtPaa (0);
}
Type-ækvivalensen kan også forstås i form af konverteringer fra forekomster af afledte klasser til
forekomster af baseklasser. Et objekt, der er en forekomst af en baseklasse kan tildeles et andet
objekt, der er en forekomst af en afledt klasse af baseklassen, fordi det afledte objekt indeholder
samtlige data og metoder, som findes i baseklassen. Det omvendte er ikke tilfældet, et afledt
objekt kan ikke tildeles et baseobjekt. Følgende kode-fragment viser en sådan tildeling:
class base_klasse {
// ...
};
class afledt_klasse : base_klasse {
// ...
};
void f () {
base_klasse b;
afledt_klasse a;
b = a;
}
Nedarvningen foregår, som navnet siger, nedefter. Baseklassen har derfor ikke adgang til data og
metoder i afledte klasser, fordi nedarvningen foregår rettet: baseklassen kan ikke "vide", hvem
der nedarver. Det ville iøvrigt ødelægge ideen med generalitet.
unions kan ikke bruges i nedarvning, hverken som baseklasser eller som afledte klasser,
dels fordi de ikke kan indeholde tilgangs-specifikationer og dels, fordi der er tvetydigheder i
unions. Derfor skal en union indeholdes i andre klasser som medlemmer.
4.3.3 Tilgangs-specifikationer
En afledt klasse har tilgang til data og metoder i baseklassen efter særlige regler. Overvej
følgende arvefølge:
274 Arv 4.3

class A {
public:
int i;
void set_i (int j) { i = j; }
};
class B : A {
public:
int k;
void set_k (int);
};
void B::set_k (int l) {
k = l;
};
B nedarver datamedlemmet i og metoden set_i() fra A og udvider endvidere med
variablen k og metoden set_k(). i og set_i() er derfor reelt også medlemmer af B, og
kan derfor bruges af B. Et objekt af typen B har også data-medlemmet i og metoden
set_i(). Derfor kan en metode i B "se" de to medlemmer i A og bruge dem som om, de var
erklæret direkte i B:
eller
void B::set_k (int l) {
k = l;
i = l; // refererer A::i
}
void B::set_k (int l) {
set_i (k = l); // kalder A::set_i ()
}
Det er ikke nødvendigt, medmindre der er tvetydigheder, at foretage en eksplicit reference til
baseklassens data og metoder. Det underforståede objekt (3.3.2) udvider sit skop til baseklassen,
og this bliver den underforståede medlemsreference for både den afledte klasse og for
baseklassen.
Tvetydigheder kan opstå, og kun opstå, hvis baseklassen og den afledte klasse indeholder data
eller metoder af samme navn. I så tilfælde skal der gives en eksplicit reference med skoptilgangs-operatoren
:: til den klasse, man ønsker at arbejde på:
class A {
4.3.3 Tilgangs-specifikationer 275

public:
int i;
void set_i (int);
};
void A::set_i (int j) {
i = j; // A::i tildeles
}
class B : A {
public:
int i;
void set_i (int);
};
void B::set_i (int j) {
i = j; // B::i tildeles
}
Når metoden set_i() kaldes for objekter af klassen B, er det B::set_i(), der er aktuel,
og når set_i() kaldes for objekter af A, er det A::set_i(). Reglerne følger helt de
eksisterende for medlemsfunktioner, der refererer data eller metoder, som er tvetydige:
eller
int i;
void B::set_i (int j) {
i = j; // B::i tildeles
A::i = j; // A::i tildeles
::i = j; // global i tildeles
}
void set_i (int); // global funktion
void B::set_i (int j) {
A::set_i (i = j); // kalder baseklassens set_i()
::set_i (j); // kalder global set_i()
}
Dette ligger meget tæt på den syntaks, der bruges til kald af metoder i objekter, som er
medlemmer af klassen i stedet for at være baseklasser. Her bruges blot medlemsreferenceoperatoren
i stedet, da objektet netop er medlem af klassen:
276 Arv 4.3

class X {
public:
void f ();
// ...
};
class Y {
X x;
void f () { x.f (); }
// ...
};
Den afledte klasse arver altså både data og metoder fra baseklassen, og må eksplicit tilkendegive
baseklassens navn, hvis data eller metoder erstattes med andre af samme navn. En baseklasse kan
for eksempel indeholde en Udskriv()-funktion, som udskriver detaljer om denne. Den afledte
klasse kan også indeholde en Udskriv(), som først udskriver indholdet af sig selv, og dernæst
kalder baseklassens Udskriv() for at få dette med. Dermed kan alle baseklassens metoder
relateres til data i denne, og behøver ikke skrives om (endsige genoversættes) for eventuelle
afledte klasser. Hvis den afledte klasse ikke redefinerer data eller metoder, vil en reference til
disse (hvis de er public), resultere i nærmeste baseklasse med definitionerne.
4.3.4 Tilgang fra klient-kode
En klasse kan have private medlemmer (3.3.8), for at skjule disse fra klienten af klassen. Når
en klasse B nedarver fra en klasse A, vil B ikke have adgang til de private dele i A:
class A {
int i;
public:
void set_i (int l) { i = l; }
};
class B : A {
int j;
public:
void set_j (int);
};
void B::set_j (int k) {
j = k; // ok, B har tilgang til egen j
i = k; // fejl, B har ingen tilgang til A's i
set_i (k); // ok, B har tilgang til A's set_i()
};
4.3.3 Tilgangs-specifikationer 277

Man kan spørge, hvad ideen er i dette. Hvorfor kan en klasse ikke nedarve en eksakt kopi af
tilgangs-mønstret i baseklassen? Svaret ligger i, at de private dele af en klasse søges skjult fra en
klient på to grundlag: dels, at klienten skal kunne abstrahere fra disse data og dels, at den kode,
som arbejder på de private data, skal kunne isoleres for at få hold på konsistensen. Hvis metoder i
en afledt klasse har tilgang til private date i en baseklasse, er det blot et spørgsmål om at nedarve
fra en given klasse for at få adgang til de private dele. Dermed er grundlaget for indkapslingen
fjernet, da alle dele af programmet ved en mindre manøvre vil kunne få tilgang, og kilden til en
fejl vil være svær at finde.
Arv kan derfor foregå på to måder: private og public, hvor private er underforstået.
I de ovenstående eksempler nedarves data og metoder derfor private. Det betyder, at klienter
udefra ikke har tilgang til baseklassens data eller metoder i den afledte klasse. Det kan være en
smule kompliceret at se, hvem der har adgang til hvad i disse tilfælde, så vi tager et eksempel til,
hvor vi nedarver to gange fra A:
class A {
int i; // i er private datamedlem i A
public:
void set_i (int); // set_i() er public metode i A
};
class B : private A { // B nedarver private fra A
int j; // j er private datamedlem i B
public:
void set_j (int); // set_j() er public metode i B
};
class C : public A { // C nedarver public fra A
public:
int k; // k er public datamedlem i C
void set_k (int); // set_k() er public metode i C
};
void A::set_i (int l) {
i = l; // ok, A har tilgang til A::i
}
void B::set_j (int l) {
j = l; // ok, B har tilgang til B::j
i = l; // fejl, B har ej tilgang til A::i
set_i (l); // ok, B har tilgang til A::set_i()
}
void C::set_k (int l) {
278 Arv 4.3

k = l; // ok, C har tilgang til C::k
i = l; // fejl, C har ej tilgang til A::i
set_i (l); // ok, C har tilgang til A::set_i()
}
Det ses, at der ikke er forskel i tilgangs-rettighederne for klasserne B og C i A's data og
metoder. Tilgangs-specifikationen i erklæringen af klasserne har kun betydning for klienter, som
bruger B og C:
void f () {
A a;
a.i = 0; // fejl, A::i er private
a.set_i (0); // ok, A::i er public
B b;
b.i = 0; // fejl, A::i er private
b.j = 0; // fejl, B::j er private
b.set_i (0); // fejl, B::set_i() er private
b.set_j (0); // ok, B::set_j() er public
C c;
c.i = 0; // fejl, C::i er private
c.k = 0; // ok, C::k er public
c.set_i (0); // ok, C::set_i() er public
c.set_k (0); // ok, C::set_k() er public
}
Klienter, som bruger objekter af B har ingen tilgang til hverken private eller public
medlemmer af A som nedarves af B, fordi B nedarver med private tilgangs-specifikation
fra A. For C, som nedarver med public tilgangs-specifikation fra A, har klienten tilgang til
public medlemmer af A, som nedarves i C, og spejler altså A direkte. Nedarves public er
tilgangen til medlemmer i baseklassen for en klient de samme som tilgangen for et objekt af
baseklassen.
Et ord om nedarvning af klasser i en struct: Når en struct nedarver fra en anden
struct eller class, foregår nedarvningen underforstået public, og ikke private. Dette
er en af de specielle forskelle mellem struct og class:
struct B : A { // ...
er identisk med
class B : public A { public: // ...
Der er visse muligheder for at ændre på disse regler om tilgang. Hvis en klasse B nedarver
4.3.4 Tilgang fra klient-kode 279

private fra en klasse A, vil alle medlemmer (data og metoder) i A være skjult fra klienten.
Det er dog muligt for B udtrykkeligt at beskrive, at public medlemmer i A også skal være
public i B:
class A {
// ...
public:
int i; // public medlem i A
};
class B : A { // private arv, i bliver private for
// ... // klienter af B, men tilgængelig i B
public:
A::i; // men her ændres det eksplicit, så i
}; // bliver public fra B's synsfelt
Dette gør A::i til et public datamedlem i B, og klienter af B har tilgang til denne variabel.
A::i i B er ikke en erklæring i normal forstand, og afsætter ikke plads til en ny variabel. Det er
blot en tilkendegivelse af, at adgangsbetingelserne for denne variabel skal ændres. Det samme
gælder den anden vej:
class B : public A {
A::i; // i bliver private fra B's synsfelt
// ...
};
Dette vil ændre A::i's tilgangs fra public til private for klienter af B. Det skal dog
nævnes, at denne eksplicitte ændring af tilgangsrettigheder på en medlem-for-medlemsbasis kun
kan bruges til at genskabe den rettighed, som medlemmet har i baseklassen. Et public medlem
i baseklassen kan ikke gøres private i den afledte klasse, ejheller kan et private
baseklassemedlem ændres til et public medlem i afledningen. Derfor opstår fejl i følgende
kodefragment:
class A {
int i;
public:
int j;
};
class B : public A {
A::j; // fejl: kan ikke ændre tilgang til
private
public:
A::i; // fejl: kan ikke ændre tilgang til public
280 Arv 4.3

};
Det er også værd at nævne, at metoder opfører sig som data fra klientens side hvad angår
tilgang. Derfor vil et kald til en metode i et afledt objekt, hvor metoden faktisk er defineret i
baseobjektet rent faktisk kalde denne funktion i baseobjektet:
class A {
int a;
public:
void print ();
};
class B : public A {
int b;
public:
};
void f () {
B b;
b.print (); // kalder A::print ()
}
Dette følger ideen om, at metoder, som arbejder på baseklassens data, ikke skal skrives om i den
afledte klasse. Fra klientens side eksisterer metoden som om den var skrevet i den afledte klasse.
Igen er den afledte klasse blot en overbygning på baseklassen, så når en nedarvning specificeres
med : overtages altså alle data og metoder, dog kan ikke alle ses fra klientens kode.
Det er muligt eksplicit at referere baseklassen i en reference til public nedarvede data eller
metoder i den afledte klasse. Dette gøres med en specifikation af baseklassens navn umiddelbart
før medlemmets navn:
struct A { int i; void f (); };
struct B : A { };
void g () {
B b;
b.i = 0; // implicit reference til baseklassen
b.A::i = 0; // eksplicit reference til baseklassen
b.f (); // implicit reference til baseklassen
b.A::f (); // eksplicit reference til baseklassen
}
Under lineær arv er eksplicitte referencer til baseklassen unødvendige, fordi oversætteren selv
4.3.4 Tilgang fra klient-kode 281

kan finde det rigtige navn. I afsnit 4.5 skal vi imidlertid se eksempler på, at referencer til
baseklassen kan være nødvendig i forbindelse med tvetydigheder i særlige situationer.
4.3.5 protected tilgang
Klasser har to grænseflader: en mod klienten og en mod andre klasser, som nedarver
egenskaberne. Den ene side er bruger-orienteret og kræver en god definition af klassens
virkemåde og koncept. Den anden har med udvidelser at gøre, og kræver, at klassen er så generel
som mulig.
Der er imidlertid et problem. Hvis en klasse A har et private medlem, som ønskes skjult
for klienten, kan dette ikke ses af den afledte klasse, som måske kan have fordel af at kunne se
dette medlem:
class A {
int i; // private medlem i A
public:
// ...
};
class B : public A {
void f () {
i = 0; // fejl, i er ikke tilgængelig
}
// ...
};
void f () {
A a;
a.i = 0; // fejl, A::i er ikke public
B b;
b.i = 0; // fejl, B::i er ikke public
}
Der er to umiddelbare løsninger på dette. Enten kan i placeres i public-delen af A, hvorved
B nedarver den som private medlem i B, og dermed har tilgang. Eller også kan der skrives
en speciel tilgangs-funktion i A, som læser og skriver i. Den første metode er uinteressant, fordi
i, udover at være tilgængelig fra B, også vil kunne manipuleres af en klient af A. Den anden
metode ligger nærmere OOP-filosofien, idet data bør læses og skrives af kode i klassen, så
klienten gør sig implementations-uafhængig. Men B er strengt taget ikke en klient. Metoder i
klasser bør være så effektive som muligt, fordi de vil blive kaldt ofte. En afledt klasse bør derfor
282 Arv 4.3

ikke kalde metoder i baseklassen til manipulation af data, som den afledte klasse selv kunne
udføre, medmindre baseklassens metode er god nok.
Af denne grund findes en tredje tilgangs-metode i klasser udover public og private,
nemlig protected (beskyttet). protected tilgang betyder, at klienter ser medlemmerne
som private og dermed ikke har tilgang samt at afledte klasser ser dem som public og
dermed har tilgang.
Arvemetode i
den afledte
klasse
private arv
public arv
Original tilgangsspecifikation i baseklassen
public protected private
private
public
ingen
private
Tabel 4-1: Den afledte klasses tilgang ved arv med forskellige tilgange.
class A {
// ... // private medlemmer
protected: // protected medlemmer
int i; // i er private for klienter
public: // public medlemmer
// ...
};
ingen
ingen
Med andre ord: medlemmer af en klasses private del kan kun og altid kun læses og skrives
fra metoder i klassen. Hverken klienter eller afledte klasser har mulighed for at manipulere disse
data direkte. protected medlemmer af klassen kan ikke manipuleres fra klienter, men kan ses
fra afledte klasser, som nedarver offentligt (class B : public A { ...). public
medlemmer i klassen kan ses af både afledte klasser, men kun af klienter, hvis der arves
private. Klienten har med andre ord kun adgang til baseklassens medlemmer, hvis de er
erklæret public i baseklassen og hvis den afledte klasse arver public.
Kun ét spørgsmål mangler besvarelse, nemlig klientens tilgang til data i en afledt klasse, hvor
data oprindelig er defineret i baseklassen. Hvis data er erklæret public i baseklassen, og hvis
de nedarves public i den afledte klasse (class B : public A { ...), kan de ses af
klienten. I alle andre tilfælde er de skjult, dvs. hvis data er enten protected eller private i
baseklassen, eller hvis den afledte klasse nedarver private (class B : private A {
...).
Her følger eksemplet overfor igen med protected tilgang for i:
class B : public A {
void f () {
i = 0; // ok, B har tilgang til i
4.3.5 protected tilgang 283

};
// ...
};
void f () {
A a;
a.i = 0; // fejl, i er ikke public
B b;
b.i = 0; // fejl, i er ikke public
}
Nu har B::f() retteligt adgang til A::i, hvorimod f() ikke kan oversættes. Læg mærke til,
at tilgangen til protected medlemmer følger samme regler, når der er tale om friendklasser.
protected tilgang har også betydning for abstrakte klasser, idet en protected
konstruktør umuliggør instantiering af klassen, fordi den ikke befinder sig i klientens skop.
4.3.6 Tvetydigheder ved lineær arv
Der kan opstå navnekonflikter i forbindelse med arv, hvis den afledte klasse definerer et navn,
som baseklassen allerede indeholder. For både data og funktioner gælder, at objekterne i den
afledte klasse har prioritet i forhold til baseklassens. Overvej:
struct A {
int i;
};
struct B : A {
int i;
void f () {
i = 0; // B::i
}
};
void f (B b) {
b.i = 0; // B::i
}
Hvis der er brug for manipulation af eller tilgang til baseklassens data eller funktioner af samme
navn som den afledtes, må der gives eksplicit reference til baseklassens typenavn. Det tilrådes
ikke at underbygge et design på dette, fordi klienten helst skulle være ligeglad med eventuelle
baseklasser, når der arbejdes på afledte klasser alene. Syntaksen er:
284 Arv 4.3

struct B : A {
int i;
void f () {
i = 0; // denne klasses i-medlem
A::i = 0; // baseklassens i-medlem
}
};
void f (B b) {
b.i = 0; // B-klassens i-medlem
b.A::i = 0; // A-klassens i-medlem
}
De sædvanlige regler for tilgang gælder naturligvis også her, så private og protected
medlemmer i baseklassen kan ikke ses fra klienten, mens private medlemmer i baseklassen
ikke kan ses af den afledte klasse.
4.3.7 Konstruktion af afledte objekter
Når et objekt af en afledt klasse oprettes, vil eventuelt definerede konstruktører kaldes opefter i
hierarkiet. Hvis A er baseklasse til B, og hvis begge har konstruktører, vil en instantiering af B
resultere i et kald til A::A() og dernæst til B::B(). Heraf følger, at konstruktører ikke
nedarves, men kaldes automatisk for alle klasser i arvefølgen. Normale metodekald resulterer i et
og kun et kald, mens konstruktørkald til afledte klasser vil kalde alle konstruktører
(underforståede eller eksplicitte) opefter.
Hvis baseklassen har en konstruktør, som kræver parametre (dvs. hvis der ikke findes en
underforstået konstruktør), skal der defineres en konstruktør for den afledte klasse, som initierer
baseklassen. Eller mere specifikt: Hvis en baseklasse har en konstruktør, skal den afledte klasse
også have en. For klasser med underforståede konstruktører kaldes først baseklassens
konstruktør, dernæst den afledte klasses konstruktør. For eksempel,
class A {
public:
A () { cout

B () { cout

Figur (const Koordinat& k) : p (k) {
vises = 0;
}
// ...
};
Konstruktøren Figur::Figur() initierer startpunktets Koordinater. Når nu vi nedarver
fra Figur, må vi eksplicit fortælle, hvordan information skal flyde fra konstruktør til
konstruktør opefter i klasse-hierarkiet:
class Linie : public Figur {
Koordinat endepunkt;
public:
Linie (Koordinat& st, Koordinat& en) :
Figur (st), endepunkt (endepunkt) { }
// ...
};
Klassen Linie udbygger Figur med et endepunkt. Linies konstruktør indeholder derfor et
ekstra Koordinat, som initierer dette private datamedlem. Men Linie skal også videregive
informationen om startpunktet til baseklassen Figur. Dette gøres i initieringslisten med samme
syntaks som for medlemsdata, blot med navnet på baseklassens typenavn, hvilket er det samme
som at kalde baseklassens konstruktør eksplicit. Dette skyldes, at Linie ikke har en konkret
Figur at arbejde med, idet den kun nedarver fra klassen.
Her kommer initieringslisterne igen til berettigelse. Hvis den afledte klasses konstruktør
eksplicit skulle kalde baseklassens konstruktør, måtte det afledte objekt nødvendigvis oprettes før
baseobjektet. Men det nytter ikke noget, fordi baseklassen skal oprettes før den afledte klasse for
at opsætte hierarkiet ordentligt. Initieringslisten kommer før konstruktørens krop, og udføres
dermed før denne. Det er også et spørgsmål om effektivitet. Når oversætteren ser et kald til en
baseklasses konstruktør i en initieringsliste i en afledt klasse, vil dette helt forbigå den afledte
klasses konstruktør i målkoden. Kaldet til baseklassen "bobler op" til dennes konstruktør, og
bliver faktisk til et direkte kald fra instantieringen i klientkoden til baseklassen. Den afledte
klasse indeholder ikke reel kode til behandling af disse informations-overførsler. Hvis der var tale
om et eksplicit funktionskald, ville der blive genereret triviel kode til konstruktion af
baseobjekter, og det ville være op til oversætteren at optimere sig ud af dette bagefter, en svær og
langsommelig opgave.
Nu er det klart, at hvis en baseklasse A har en underforstået konstruktør, så vil en vilkårlig
konstruktør i en afledt klasse B, som skrives
B::B (/* ... */) { // ...
være identisk med
B::B (/* ... */) : A () { // ...
4.3.7 Konstruktion af afledte objekter 287

fordi der ikke skal overføres information. Men konstruktøren kaldes under alle omstændigheder,
fordi den kan udføre opgaver, som er uafhængige af udefrakommende data.
Det er vigtigt at være opmærksom på den rækkefølge, C++ intitierer baseklasser på. For en
given klasse som instantieres, foregår initieringen efter følgende regler:
1. Baseobjektet initieres, hvis det findes.
2. Eventuelle datamedlemmer i klassen initieres i den rækkefølge, de er erklæret. Hvis en
klasse indeholder brugerdefinerede typer, bliver deres konstruktører (og eventuelle
baseklassers konstruktører) kaldt.
3. Det aktuelle objekt initieres ved eksekvering af konstruktørens krop.
C++ anvender disse regler rekursivt, hvilket vil sige, at hvis en klasse har en baseklasse, som selv
er afledt, vil dennes baseklasse blive initieret først eller hvis der forekommer baseklasser eller
brugerdefinerede typer i de datamedlemmer, som klassen måtte indeholde. Overvej følgende
eksempel:
class A { // A er en isoleret klasse
public:
A () { cout

Ovenstående program vil udskrive
A::A()
B::B()
A::A()
C::C()
A::A()
B::B()
D::D()
Kig eksemplet igennem og sammenlign med reglerne for initiering på forrige side.
4.3.8 Destruktion af afledte objekter
Destruktører, der som bekendt ikke har parameterlister, og derfor ikke behøver information fra
klienter, skal ikke behandles specielt fra afledte klasser. Destruktører nedarves ikke, men kaldes
automatisk i baseklassen. De kaldes i omvendt rækkefølge end konstruktørerne, så afledte
objekter først destrueres, dernæst baseobjekter:
Output:
class A {
public:
A() { cout

A::A()
A::A()
B::B()
A::A()
B::B()
C::C()
C::~C()
B::~B()
A::~A()
B::~B()
A::~A()
A::~A()
Igen giver det mening, at den afledte klasses destruktør kaldes først, idet denne typisk vil rydde
op i data, som relateres til baseobjektet. Derfor er det ufikst, hvis baseobjektet ikke eksisterer.
Destruktører nedarves ikke. Der genereres imidlertid en underforstået destruktør, hvis ingen
erklæres, og den kalder baseobjektets (objekternes) destruktører automatisk efter det aktuelle
objekt er blevet destrueret. Automatisk genererede destruktører er altid public.
4.3.9 Typekonvertering under arv
Visse regler gælder for konvertering mellem objekter af klasser, som har et base/afledt-forhold:
• Det er kun muligt at konvertere til og fra objekter, som er nedarvet public fra
baseklassen.
• Et forekomst af en afledt klasse kan konverteres til en forekomst af en public
baseklasse, som i
class base { // ...
class afledt : public base { // ...
afledt a;
base b = a; // a konverteres til base
• En pointer eller reference til en forekomst af en afledt klasse kan konverteres til en
pointer eller reference til en forekomst af en baseklasse, som i
afledt* a;
base* b = a; // a konverteres til base*
afledt& c = *a; // ingen konvertering
base& d = c; // c konverteres til base&
• En pointer eller reference til et medlem af en baseklasse kan konverteres til en pointer
290 Arv 4.3

eller reference til et medlem af en afledt klasse (behandles i detaljer i afsnit 3.7), som i
class base { public: int i; // ...
class afledt : public base { public: // ...
int base::*bp = &base::i; // bp peger på base::i
int afledt::*ap = bp; // ap peger på afledt::i
Disse konverteringer skal ses i sammenhæng med, hvordan strukturen af afledte objekter ser ud.
Nedarvningen overtager jvf. afsnit 4.3.2 data og metoder i baseklassen (alt overtages, blot kan
dele af baseklassen eventuelt ikke ses fra den afledte klasse), så den afledte klasse repræsenterer
summen af baseklassen og sig selv. Diagrammet i figur 4-4 kan derfor opdeles på en mere reel
måde med henblik på indholdet af de afledte klasser.
Figur 4-5: Det afledte objekts reelle indhold.
I figur 4-5 fremstår det klart, hvordan en forekomst af Linie kan konverteres til en forekomst
af Figur, og derefter behandles som en sådan, fordi alle medlemmer i baseklassen også tilhører
den afledte klasse. Konvertering af forekomster vil derfor tabe den information, som findes i den
afledte klasse udover det nedarvede materiale. Men baseklassens information bibeholdes, hvilket
gør, at en pointer til en baseklasse, som tildeles adressen på en afledt klasse kan arbejde på, og
kun på, de nedarvede elementer. Derfor kan en pointer til et medlem i en baseklasse konverteres
til en pointer til et medlem i en afledt klasse, hvilket muliggør funktioner, som arbejder på de
generelle dele af de afledte klasser uden at have viden om de medlemmer, som de afledte klasser
bygger til.
4.3.10 En løsning med nedarvning
Nu omskriver vi eksempel 4-1 med klasserne Punkt, Linie og Firkant som nedarvede
klasser.
Først erklærer vi baseklassen Figur, som indeholder et Koordinat og et flag, vises,
som fortæller om figuren er synlig eller ej. Disse data er fælles for alle Figurer: et startpunkt
og et synligt-eller-ej flag. Vi giver også figuren et navn, så vi kan se, hvad den forestiller.
Baseklassen har fire medlemsfunktioner, som også er fælles for alle Figurer. En konstruktør
opretter Figurer med et startpunkt og et navn mens en destruktør fjerner Figurer. De
normale metoder giver navnet på figuren og flytter den til et nyt punkt. Vi opdeler nu klassen i en
4.3.9 Typekonvertering under arv 291

privat del, en offentlig del og en beskyttet del og placerer datamedlemmer og medlemsfunktioner
i de tre afdelinger afhængig af klient- og arvingbehov.
// eksempel 4-3: en generel figur
class Figur {
char* navn;
protected:
Farve f;
bool vises;
Koordinat p;
public:
Figur (Koordinat&, char*); // konstruktør
Figur (Figur&); // kopi-konstruktør
~Figur (); // destruktør
void operator= (Figur&); // tildelings-operator
const char* figurNavn ();
void Flyt (Koordinat&);
};
Konstruktøren Figur::Figur() initierer Koordinatet p med startpunktet i
initieringslisten og allokerer plads til navnet på det frie lager. Standard-funktionen strlen
returnerer længden af strengen (antallet af tegn op til det afsluttende '\0', men uden dette) og
lader navn pege på dette lager. Derefter kopieres navnet i s til det nyallokerede lager. Vi kan
ikke blot tildele navn til s, da s kan være en midlertidig variabel.
Figur::Figur (Koordinat& k, char* s)
: p (x, y), f (hvid), vises (ja) {
navn = new char [strlen (s) + 1];
strcpy (navn, s);
cout

Figur::~Figur () {
delete navn;
}
Af samme grund som kopi-konstruktørens tilstedeværelse må vi også have en tildelings-funktion,
så forekomster af Figurer kan tildeles hinanden:
void Figur::operator= (Figur& f) {
p = f.p, f = f.f, vises = f.vises;
if (navn != NULL && strlen (navn) != strlen (f.navn)) {
delete navn;
navn = new char [strlen (f.navn) + 1];
}
strcpy (navn, f.navn);
}
figurNavn() returnerer blot navnet som en char-pointer, så klienten kan bruge denne til
udskrivning eller andet. Det er en const char*, som returneres, for klienten skal ikke kunne
ændre i navnet uden tilladelse - hvis han gjorde noget forkert, ville den indre orden i Figur
være ødelagt af kode udenfor Figur, et af de nøglepunkter, dataabstraktion hjælper med at
undgå. En tvungen konvertering (type-cast) er nødvendig hvis oversætteren ikke skal advare om
en ikke-const-til-const underforstået konvertering.
const char* Figur::figurNavn () {
return navn;
}
Medlemmet Flyt() adderer blot et nyt koordinatsæt til startpunktet p. Flyt() arbejder
altså relativt fra det aktuelle startpunkt. En midlertidig forekomst af et Koordinat oprettes,
fordi grænsefladen til Koordinat-klassen kun tillader operator-kald med andre
Koordinater.
void Figur::Flyt (Koordinat& k) {
p += k;
cout

public:
Punkt (const Koordinat& k, char* n) : Figur (k, n) { }
void Tegn ();
void Slet ();
};
Punkt udbygger ikke med datamedlemmer, men indeholder derimod to nye metoder til at tegne
Punkter og slette punkter (Tegn() og Slet()). Strengt taget er det ikke nødvendigt med
en konstruktør, når der ikke er data, der skal initieres, men Figur har ingen underforstået
konstruktør og bliver derfor eksplicit kaldt fra Punkt::Punkt(). Der er ingen destruktør;
Figur::~Figur() kaldes således blot fra den underforståede destruktør.
Når et Punkt skal flyttes, er det blot et spørgsmål om at ændre det Koordinat, som
beskriver punktet. Da Punkter ikke udbygger Figurer med data, som har betydning for deres
placeringer i koordinatsystemet, kan Flyt()-metoden i Figur-klassen nedarves direkte, og
dermed genbruges helt. Metoderne til at tegne og slette Punkter kan ikke nedarves fra Figur,
da Figurer naturligvis ikke kan vide noget om Punkter:
void Punkt::Tegn () {
cout

Linie::Linie (const Koordinat& s, const Koordinat& e,
char* n) : Figur (s, n), endePunkt (e) { }
Parameteren s er startpunktet mens e er slutpunktet for linien. Igen har klassen ingen indirekte
data, og behøver ingen destruktør. At flytte en Linie indebærer en modifikation til både
baseklassen Figurs Koordinat og til Linies Koordinat. Da alle figurer flyttes
relativt, opfattes parametrene til Flyt() som en delta-værdi, positiv eller negativ, som adderes
til de to Koordinater:
void Linie::Flyt (Koordinat& k) {
Figur::Flyt (k); // flyt startpunkt
endePunkt += k; // flyt slutpunkt
}
Læg mærke til, hvordan baseklassens Flyt()-metode genbruges i den afledte klasses
Flyt(). Her er der tale om, at Linier og Figurer ikke flyttes på samme måde, men at der
dog er et forhold, som kan beskrives med en smule ekstra kode, som - og det er det vigtigste -
ikke kræver, at den originale Flyt()-metode i baseklassen skal ændres.
At tegne og slette Linier er trivielt, og er derfor blot skitseret:
void Linie::Tegn () {
cout

void Slet ();
};
Firkant::Firkant (const Koordinat& s, const Koordinat& e,
char* n) : Figur (s, n), endePunkt (e) {
}
void Firkant::Tegn () {
cout

void Firkant::Slet () {
cout

Der er altså fra klientens side i princippet ingen forskel på brugen af klasser, som er helt
isolerede og klasser, som er nedarvet fra den samme baseklasse. Forskellen ligger kun i designet,
og kommer bedst til udtryk, når klasser skal modificeres eller nye klasser skal indlægges. Klassen
Firkant er et bevis på, at generaliserings-princippet holder. Jo højere vi kommer op i
hierarkiet, jo mere generelle er vores klasser, og jo længere ned, vi kommer, jo mere specifikke er
de. Deraf følger, at hvis to klasser har mere til fælles, end de sammenlagt har til fælles med
baseklassen, er det mere naturligt at lade dem nedarve fra hinanden eller fra en ny klasse, som
skubbes ind i midten af baseklassen og de to relaterede klasser.
Figur 4-6: Ny acyklisk orienteret
graf (dag), hvor Firkant nedarver
fra Linie.
4.3.11 Problemer med lineær arv
Princippet i nedarvning mellem klasser er subtilt. Når vi indfører begrebet klasser og relationerne
mellem dem udtrykt ved arv, kan vi ikke undgå at skabe nye problemer. Det værste ved disse nye
problemer er, at de er udtryk for det objekt-orienterede paradigmes begrænsninger, samtidig med,
at de er af en anden karakter, end vi normalt har med at gøre. figur-hierarkiet i forrige afsnit
løser en hel del problemer i form af implementeringsmæssige regler for generisk kode. Men hvis
vi går i detaljer med klasserne ser vi, at der er blevet skåret hjørner af for at præsentere klasserne
så pæne som muligt.
Det viser sig, at baseklassens statiske egenskaber, som kommer til udtryk ved, at de ikke kan
kalde metoder i de afledte klasser er et væsentligt problem. Overvej for eksempel de forskellige
implementationer af Flyt() for klasser, som udbygger med egne medlemsvariable. Et fælles
træk for alle metoder, som flytter geometriske figurer er, at der skal ske tre ting i rækkefølge:
1. Først skal figuren slettes, hvis den er synlig, dvs. der skal foretages et kald til den
specifikke klasses Slet()-funktion hvis vises == ja.
2. Dernæst skal figuren flyttes, dvs. der skal foretages to ting, et kald til baseklassens
298 Arv 4.3

Flyt()-funktion og en eventuel ændring i den afledte klasses medlemsdata.
3. Sidst skal figuren tegnes igen på de nye koordinater, altså et kald til den specifikke
klasses Tegn()-funktion, hvis det originale vises-flag var ja.
De fælles træk for alle Flyt()-metoder er altså et kald til Slet(), en opdatering af data, og
et kald til Tegn(). Siden kaldene til Slet() og Tegn() skal foretages i et bestemt objekt,
kan Flyt() ikke nedarves af klasserne, men skal skrives for hver enkelt klasse. Her er for
eksempel implementationen af to Flyt()-metoder for to vilkårlige klasser, Cirkelbue og
Trekant:
void Cirkelbue::Flyt (int x, int y) {
bool husk = vises; // husk om figuren vises
if (vises) slet (); // slet hvis vist
figur::Flyt (x, y); // flyt startpunkt
e += koordinat (x, y); // flyt endepunkt (e)
if (husk) Tegn (); // hvis vist, tegn igen
}
void Trekant::Flyt (int x, int y) {
bool husk = vises; // husk om figuren vises
if (vises) slet (); // slet hvis vist
figur::Flyt (x, y); // flyt startpunkt
e1 += koordinat (x, y); // flyt endepunkt 1 (e1)
e2 += koordinat (x, y); // flyt endepunkt 2 (e2)
if (husk) Tegn (); // hvis vist, tegn igen
}
Selvom det er et meget banalt eksempel, viser det klart, at visse metoder i et klasse-hierarki
nødvendigvis må indeholde mange linier (eller tit skærmfulde) af identisk kode, fordi en enkelt
linie i midten af metoden afviger.
Et andet problem er, at selvom de afledte klasser er logisk ækvivalente til baseklasserne, dvs. at
baseklasserne kan tildeles de afledte klasser som i nedenstående kode-fragment, så kan de ikke
umidelbart erstatte hinanden i programmet. Idet afledte klasser overtager alle data og alle
public metoder fra baseklassen til fri afbenyttelse i klientens kode, kan vi skrive kode som:
class base { public: funktion (); // ...
class afledt : base { // ...
void f () {
base b;
afledt a;
b = a; // baseobjekt tildeles afledt objekt
b.funktion (); // kalder funktion i baseobjektet
4.3.11 Problemer med lineær arv 299

ase* bp; // pointer til baseobjekt
bp = &a; // tildeles afledt objekt
bp->funktion (); // kalder funktion i baseobjektet
}
Dette lader sig gøre, fordi funktioner i baseklassen også er funktioner i den afledte klasse. Når
basefunktionen kaldes gennem en forekomst, som er typekonverteret fra en afledt klasse til en
baseklasse, er det kun baseklassens data, der kan arbejdes på, og den information, der er gået tabt
i konverteringen har ingen betydning i den henseende.
Men det faktum, at information går tabt, sammenholdt med, at baseklasser ikke direkte kan
kalde funktioner i afledte objekter (med mindre de indeholder eksplicitte referencer til disse) gør,
at der er mange operationer, der ikke kan udføres gennem baseklassen. Dette kan illustreres ved
et eksempel på en vektor af Figurer. Lad os antage, at vi vil holde en tegning af et antal
forskellige objekter, alle nedarvet fra Figur. I princippet gør lineær arv, som den er beskrevet
her i afsnittet, intet for at hjælpe programmøren med at abstrahere fra forskellene mellem de
enkelte afledte klasser.
// eksempel 4-9: vektor af pointere til baseklasse
void f () {
Koordinat k1 (100,100), k2 (200,200);
const antal = 3;
figur* tegning [antal]; // vektor af figur-pointere
tegning [0] = new Punkt (k1, "A");
tegning [1] = new Linie (k1, k2, "B");
tegning [2] = new Firkant (k2, k2 + k1, "C");
for (int i = 0; i < antal; i++)
tegning [i]->Flyt (30,20); // kalder Figur::Flyt()
delete tegning [0]; // fatal !
delete tegning [1]; // fatal !
delete tegning [2]; // fatal !
}
Det viser sig, at C++ ikke med lineær arv er i stand til at blande afledte klasser med hinanden.
Problemets kerne er, at selvom der er type-ækvivalens mellem en baseklasse og en afledt klasse,
er det, at information går tabt i konverteringen, uhensigtsmæssigt. Hvis vi antager, at alle
klasserne i Figur-hierarkiet har destruktører, vil de tre delete-sætninger i eksemplet overfor
alle kalde Figur::~Figur og ikke de respektive destruktører for Punkt, Linie og
Firkant. Derfor må vi udtrykkeligt typekonvertere hvert medlem af tegning til de rigtige
klasser før deallokering.
En anden måde at udtrykke dette på er, at en liste af objekter af forskellige afledte klasser vil
under disse omstændigheder alle opføre sig som baseklassen, idet informationen om den afledte
300 Arv 4.3

klasse gik tabt i konverteringen. Det er altså ikke muligt, uden eksplicit at konvertere det enkelte
objekt tilbage igen, at kalde en metode i den afledte klasse. De tre kald til Flyt() vil ikke blive
ledt til de tre afledte klasser, men gå direkte til baseklassen, med mindre vi skriver
((Punkt*)tegning [0])->Flyt (30,20);
((Linie*)tegning [1])->Flyt (30,20);
((Firkant*)tegning [2])->Flyt (30,20);
Det blev nævnt i indledningen til dette kapitel, at objekt-orienteret programmering er et
spørgsmål om design rettere end teknik. Derfor viser de første problemer sig først fra klientkodens
side, som det ses af ovenstående eksemplers syntaks. Det er nu de tvungne
typekonverteringer, som klienten bliver nødt til at bruge, som er problemet. Tvungne typekonverteringer
skal så vidt muligt begrænses til et minimum, fordi de er farlige i den forstand, at
en lille fejl kan forsage stor skade og være svær at lokalisere. Oversætteren beklager sig nemlig
ikke. Når der bruges tvungne konverteringer er ansvaret programmørens. Alt håb er imidlertid
ikke ude.
4.4 POLYMORFE KLASSER
Jo dybere man graver sig ned i et nyt programmeringsparadigme, jo mere spidsfindige bliver de
problemer, man støder på. De metoder, der er beskrevet i kapitel 3 og i de første afsnit i dette
kapitel er for de fleste, som har erfaring med andre programmeringssprog og metoder for design,
overkommelige at forstå umiddelbart. Dette afsnit indeholder nogle af de faciliteter i objektorienteret
programmering, hvor mange synes, det ændrer sig radikalt. Derfor starter vi varsomt.
4.4.1 En isotrop opfattelse af klasser
Hvis vi for et øjeblik forlader programmeringens verden og tænker på en "klasse" som et generelt
begreb, finder vi, at vi ofte generaliserer mere på klassernes faktiske egenskaber end på deres
indhold. Faktisk er det klassernes "opførsel" vi i det hele taget kan relatere os selv til. Måden, vi
grupperer klasser på, er derfor i høj grad afhængig af, hvordan klasserne opfører sig. Selvom en
flaske vin og en sodavand har meget få ting til fælles, er de begge en del af samme kategori, som
har at gøre med drikkevarer. Egentlig grupperer vi på den måde for at kunne bruge de forskellige
klasser. På den måde har klassernes repræsentation større betydning i vores begrebsverden end
deres indre opbygning. Vores viden om, hvordan man drikker vin og hvordan man drikker
sodavand er (stort set) den samme - vores indbyggede metode til at udføre denne opgave følger
samme mønster.
Det interessante ved denne iagttagelse er, at vi i mange henseender har samme metode, i hvert
fald i teorien, til at klare forskellige opgaver, selvom de indebærer forskellige resultater. De fleste
af os ved for eksempel hvordan man kører bil, knallert og cykel. Det er bestemte metoder, der
bruges til at starte en bil, vende den rundt og til at accellerere og bremse. Men det spiller ingen
rolle i selve handlingen om det er en Opel eller en Citroën, vi kører i. Vi er faktisk komplet
4.3.11 Problemer med lineær arv 301

ligeglade; fabrikanten af bilen har sørget for, at der er en ensartet grænseflade til bilen, så vi
behøver normalt ikke at bruge et nyt sæt regler, når vi skifter bil. På samme måde med knallerter
og cykler i trafikken. De er forskellige transportmidler, men reglerne for, hvordan de skal styres
gennem gaderne er de samme - vi har lært dem en gang for alle, og bruger de samme
"kommandoer" for begge.
Denne ensartethed i anvendelse af klasser i den virkelige verden er også, hvad objekt-orienteret
programmering gør for klasser. Sagen er, at hvis vi arbejder med flere forskellige klasser, som har
en ensartet grænseflade, kan vi i bestemte situationer være ligeglade med den faktiske klasse, når
vi blot ved, hvordan den opfører sig. Det kan umiddelbart være svært at se, at man kan bruge et
objekt uden at kende navnet på den klasse, som den er en forekomst af, men prøv at tænke på den
naturlige definition ovenfor, når vi nu tager et konkret eksempel fra C++-verdenen.
Vi tænker os, at vi skal skrive et system til administration af udlån i et bibliotek. Biblioteket
indeholder publikationer af mange forskellige typer, som alle er relaterede, og dog har mindre
afvigelser. Alle publikationer har en titel, et primært forfatternavn, et forlagsnummer samt
antallet af bøger på hylden og udlånte eksemplarer. I første omgang er der to forskellige typer af
publikationer, nemlig bøger og tidsskrifter. Alle bøger har et ISBN-nummer, mens tidsskrifter har
et ISSN-nummer og en liste af artikler inde i bladet. Bøger kan igen opdeles i skøn- og
faglitteratur, med hver deres genre-kode.
Når vi låner en publikation ud, er vi interesserede i at udføre en metode, som er ens for alle
publikationer, nemlig at nedtælle antallet af indeholdte eksemplarer, optælle antallet af udlånte
eksemplarer og registrere låneren. På det tidspunkt, altså når vi kalder metoden udlaan(), kan
vi tillade os at abstrahere fra, hvorvidt publikationen er en skønlitterær bog eller et
sejlsportsmagasin. Vi vil bare låne den ud. Ligeledes når der skal gøres status over
publikationerne for at udlæse antallet af udlånte bøger. Her er vi interesserede i at gennemløbe
alle forekomster af alle typer af publikationer og summere udlåns-indikationen. Men det er helt
uinteressant hvad publikationen hedder eller hvilken specifik klasse den tilhører. Vi vil blot kalde
en metode, som fortæller os antallet af udlånte eksemplarer. Principperne for lineær arv tillader os
at skrive en metode i en baseklasse, som arbejder på de fælles data for alle publikationer, her
udlånsinformation.
Men vi har også brug for en metode til udlæsning af publikationens art, navn, forfatter, indhold
og andre data, der er specifikke for de enkelte slags publikationer. En sådan metode skal skrives i
den afledte klasse, idet baseklassen ikke har den nødvendige information til at foretage en
udlæsning af disse data. Nu står vi så med det interessante problem, at vi stadig ønsker at være
uafhængige af, hvorvidt publikationen er af type A eller B (vi vil blot skrive indholdet ud), men
kan samtidig ikke kalde en metode i baseklassen. Det er tydeligt, at disse operationer er
klientorienterede. Fra klientens side er den eneste umiddelbare løsning at foretage en tvungen
type-konvertering eller en reference til det aktuelle klassenavn, i kaldet til det objekt, der skal
arbejdes på. Men, som beskrevet i afsnit 4.3.9, giver det en bunke af nye problemer, som er
endnu mere uløselige. Det er altså grænsefladen til klasserne, som skal være mere gennemsigtig.
Indtil nu har grænsefladen til klienten været begrænset til den enkelte klasse, men objektorienteret
programmering giver os også mulighed for at beskrive en mere flydende grænseflade
klasserne imellem.
302 Polymorfe klasser 4.4

4.4.2 Bindingstidspunkter
Når en metode i en klasse kaldes (eller for den sags skyld en normal funktion), foretages en
indentifikation af metodens endelige adresse, dvs. dens placering i lageret, hvorefter programmet
hopper til denne adresse. Denne identifikation sker normalt under oversættelsen † , hvor metodens
adresse er unik og kendt, og skrives direkte i klientens kode. Dette kan ikke ændres, med mindre
klienten foretager tvungne type-konverteringer af de objekter, som indeholder metoderne. Af
denne grund kaldes denne proces for statisk binding eller tidlig binding med henvisning til, at
bindingen mellem klient og metode sker før programmet startes.
C++ har et alternativ. Ved at forsinke bindingstidspunktet til programmet rent faktisk kører, er
det muligt for programmet selv at determinere det faktiske objekt og foretage bindingen
umiddelbart før kaldet. Denne bindingsform kaldes for dynamisk binding eller sen binding, fordi
det først sker, efter programmet er sat i gang. For denne type kald er det klart, at oversætteren
ikke kender metodens endelige adresse. Programmet indeholder selv det nødvendige "klister" til
at udføre denne opgave, og derfor er der et mindre overhead i kald til metoder, som kræver
dynamisk binding. Dette forhold diskuteres nærmere i afsnit 4.4.5.
C++ kan, som et af de eneste objekt-orienterede sprog, foretage både statisk og dynamisk
binding ud fra den filosofi, at programmerne skal være effektive. Statisk binding er hurtigere, og
skal derfor bruges, hvis det kan.
4.4.3 Virtuelle funktioner
Hvis en baseklasse kun tilbød medlemsfunktioner af den slags, der er beskrevet i afsnit 4.3, ville
nedarvning som sådan ikke være særlig interessant, fordi en baseklasse ikke ville kunne tilbyde
særlig mange interessante metoder. Da baseklasser er meget generelle, er normale metoder i dem
også meget generelle. Normale metoder skal implementeres i de klasser, som erklærer dem, og
skal følgelig kaldes fra klienten med reference til samme klasser. Som tidligere beskrevet har
baseklasser ifølge klasse-hierarkiets natur ikke adgang til afledte klassers data og metoder, så det
er ikke muligt at konstruere generelle metoder i baseklassen, som kalder de mere specifikke
metoder i de afledte klasser. Dermed bliver den mest indlysende fordel ved lineær arv en
behændig metode til genbrug af kode. Vi skal imidlertid senere (i afsnit 5.9) se eksempler på, at
arv ikke bør anvendes som generel genbrugsmekanisme, men som generel
abstraktionsmekanisme. Fra klientens synspunkt kan det nemlig være ligegyldigt, om en klasse
nedarver fra en anden klasse eller om den er isoleret, sålænge der arbejdes med lineær arv. Men
behandlingen af typer kræver, at forskellige klasser skal kunne behandles ens og med samme
syntaks, ligesom vi kender den indbyggede polymorfi fra de gængse sprogs fundamentale typer.
For at skabe en blød grænseflade for alle klasser i et hierarki tages et nøgleredskab i objektorienteret
programmering i brug. Den egalitet mellem medlemsfunktioner i afledte klasser, som
er eksemplificeret i afsnit 4.4.1, implementeres i C++ ved hjælp af virtuelle funktioner. En virtuel
funktion i en baseklasse har den egenskab, at den kan erstattes på kaldetidspunktet med en
metode i en afledt klasse. På den måde repræsenterer en virtuel funktion en "rød tråd" gennem et
†
Normalt sker selve samlingen af lænker-værktøjet (compile-time binding), men kan også foregå ved indlæsningen
af programmet (load-time binding) eller ved brug af specielle biblioteker, som kaldes dynamic link libraries. Fælles
for dem alle er dog, at metodernes positioner i lageret skrives statisk ind i klientkoden.
4.4.2 Bindingstidspunkter 303

klassehierarki, og udgør en vertikal ensartet grænseflade til klienten. Klienten kan således arbejde
på en række af afledte klasser uden at bekymre sig om deres type.
En virtuel funktion erklæres med nøgleordet virtual før funktionserklæringen. Dermed
fortælles oversætteren, at den givne funktion kan erstattes af en funktion i en afledt klasse. Men
hvordan og hvorfor sker denne erstatning? Hvordan ved oversætteren, at det skal være en afledt
klasse, som skal modtage kaldet? Svarene på disse spørgsmål ligger gemt i pointermanipulation
med objekter. Når der ikke arbejdes med pointere, vil et metodekald i en klasse altid henvise til
en metode i den aktuelle forekomst. Med pointere til objekter kan det ifølge reglerne for
typekonvertering gennem nedarvede klasser være muligt at have en pointer til et baseobjekt, som
egentlig peger på et afledt objekt, som beskrevet i afsnit 4.3.8. Når en virtuel metode kaldes via
en pointer til et objekt, vil kaldet dynamisk binde til en funktion i det objekt, som egentlig
refereres af pointeren, hvis metoden er erklæret i den klasse, som objektet er en forekomst af.
Ifølge afsnit 4.3.1 vil en pointer til et baseobjekt, som tildeles adressen på et afledt objekt ikke
miste typeinformationen fra det afledte objekt. Det er grunden til, at oversætteren kan identificere
den virtuelle funktion og kalde den korrekte version for det objekt, pointeren refererer.
For eksempel,
class X { public: virtual int f(); };
class Y : public X { public: virtual int f(); };
X a; // a er en forekomst af X
Y b; // b er en forekomst af Y
a.f(); // X::f() kaldes for objektet a
b.f(); // Y::f() kaldes for objektet b
X* xp1 = &a; // xp1 er en pointer til en X
X* xp2 = &b; // b er afledt af X, adressen kan derfor
// tildeles en X*
xp1->f(); // kalder X::f() for objektet a
xp2->f(); // kalder Y::f() for objektet b !
Her ses, hvordan den virtuelle metode f() kaldes med forskellige forudsætninger. Først kaldes
den for forekomster af henholdsvis X og Y, hvorved den opfører sig som normal metode.
Dernæst tildeles adressen på de to forekomster til to pointer-variable. De efterfølgende kald til
f() med reference til disse to pointere ser helt ens ud, men resulterer i kald til X::f() og
Y::f() for henholdsvis xp1 og xp2, fordi pointerne bærer typeinformation med sig. Kaldet
til xp2->f(), binder dynamisk til et Y-objekt selvom xp2 er en pointer til en X.
Da pointerens store anvendelse ligger i dens generalitet, kan virtuelle funktioner og pointere på
ovenstående måde bruges til at skrive funktioner, som abstraherer fuldstændig fra de datatyper,
de arbejder på. Hvis en funktion f() tager en pointer eller reference til en type T som
parameter, og hvis T indeholder en public virtuel metode v(), vil et kald til
parameterobjektets v() binde til den type, som f() kaldes med. Dermed er f() helt
generisk, da det er muligt at nedarve en ny type fra T og kalde f() med en reference til denne.
De problemer, der opstod i løsningen af Figur-problemet med lineær arv, var alle relateret til
kode, som var ikke-generisk og som derfor skulle modificeres, hvis programmet skulle udvides.
304 Polymorfe klasser 4.4

Overvej følgende ændringer i klasserne (forkortet for læsbarhedens skyld):
// eksempel 4-10: figurklasser med virtuelle funktioner
class Figur {
// ...
public:
virtual void Tegn ();
virtual void Slet ();
void Flyt (Koordinat&);
// ...
};
class Linie : public Figur {
// ...
public:
virtual void Tegn (); // sådan tegnes en linie
virtual void Slet (); // sådan slettes en linie
// ...
};
class Punkt : public Figur {
// ...
public:
virtual void Tegn (); // sådan tegnes et punkt
virtual void Slet (); // sådan slettes et punkt
// ...
};
Den eneste principielle forskel på eksempel 4-3 og 4-10 er, at de metoder, som er specifikke i
funktion for den givne klasse, men som er fælles i abstraktion for alle klasserne, er lavet om til
virtuelle funktioner. En global funktion Tegn() kan nu skrives uden forhåndskendskab til
Linie og Punkt, men blot arbejde på Figurer:
void Tegn (Figur& f) {
f.Tegn ();
}
På samme måde kan funktionen Flyt(), som nedarves fra Figur i de to afledte klasser,
kalde virtuelle metoder for sit eget underforståede objekt. Dermed kan kompleksiteten for mindre
dele af funktioner, som har næsten samme funktion (afsnit 4.3.10), abstraheres og lægges i en
virtuel funktion. Funktionen Figur::Flyt() kan have følgende implementation:
void Figur::flyt (Koordinat& k) {
4.4.3 Virtuelle metoder 305

ool husk = vises;
if (vises) Slet (); // virtuelt metodekald
p += k; // flyt startpunktet
if (husk) Tegn (); // virtuelt metodekald
}
Ved et kald til Figur::Flyt(), som direkte nedarves fra Figur, bliver de efterfølgende
kald til Tegn() og Slet() foretaget for det underforståede objekt, og afhænger dermed af
typen, som Flyt() blev kaldt for. Med virtuelle funktioner kan metoder i afledte klasser altså
kaldes fra metoder i baseklasser.
4.4.4 Dynamisk Binding som indkapsling
I 1968 skrev Edsgar Dijkstra en artikel med titlen GO TO Statement Considered Harmful - GO
TO anses for skadelig [Dijkstra 68]. Hans argument var, at den blinde hoppen rundt i progammet
efter regler, som i abstraktion lå meget lavt, gør koden ulæselig og umulig at genbruge på længere
sigt. Artiklen var startskuddet til et gennemgribende paradigmeskift, som resulterede i
principperne for struktureret programmering.
Et af hovedelementerne i struktureret programmering er symbolik. I en situation, hvor der kan
være tale om flere grenvalg, er det i dag skik at anvende en switch-struktur (2.7.5) fordi den
gør koden læsbar, en trods alt vigtig faktor. I de to følgende eksempler foretages sådanne
grenvalg på en abstrakt datatype, som indeholder egen subtype-information, taget fra afsnit 4.2.7
(eksempel 4-2):
// forstør en figur med en given faktor
void Forstoer (Figur& fig, double factor) {
switch (fig.slags) {
case Punkt:
// et punkt kan ikke forstørres!
break;
case Linie:
// ... kode til at forstørre en linie ...
break;
case Firkant:
// ... kode til at forstørre et rektangel ...
break;
}
}
// rotér en figur om en given koordinat med en given grad
void Roter (Figur& f, Koordinat& cent, double ang) {
switch (fig.slags) {
case Punkt:
306 Polymorfe klasser 4.4

}
// et punkt kan ikke roteres!
break;
case Linie:
// ... kode til at rotere en linie ...
break;
case Firkant:
// ... kode til at rotere et rektangel ...
break;
}
De to funktioner Forstoer() og Roter() er skrevet efter strukturerede principper og
udviser en høj grad af funktionel abstraktion. Der er dog to problemer, som det strukturerede
paradigme ikke løser:
• den del af kildeteksten, som behandler en given Figur-type, er spredt rundt i
programmet. Det er ikke muligt at isolere kode, der relaterer sig til en bestemt type i
samme modul eller oversættelsesenhed. Hvis der opstår en fejl i behandlingen af for
eksempel et rektangel, kan den være svært at lokalisere.
• hvis der skal foretages udvidelser i programmet, for eksempel en ny Figur-type
Cirkel, skal der ændres i alle dele af programmet, som behandler Figurer. De dele
viser sig oven i købet at være de mest kritiske, nemlig selve definitionen på typen samt
funktionerne til behandling af alle former for typer. Netop fordi koden for de enkelte
subtyper ikke er isoleret, skal det meste af programmet genoversættes og gentestes for
eventuelle fejl. For hvem kan garantere, at en programmør ikke pludselig finder
grundlag for en mindre forbedring i koden for at forstørre en Firkant mens han
udvider med en Cirkel?
Programmer, der skrives på denne måde er alstå ikke bare implementations-afhængige, fordi
programmøren varetager type-kontrollen over en given polymorf datastruktur, men er også
rodede, fordi kildeteksten ikke kan organiseres på en - efter subtyperne - naturlig måde.
Pointen her er, at typesystemet i C++ skal overtage så megen kontrol som muligt. De enkelte
switch-strukturer i funktionerne skal erstattes med nedarvede typer, som indeholder virtuelle
metoder. De afledte klasser repræsenterer hver type-variant, en virtuel metode erstatter hver
switch-sætning og hver case-sætning bliver til en metode i den afledte klasse, som bindes
dynamisk. Hermed lokaliseres den kode, som arbejder på en enkelt subtype af Figur til en
enkelt kildefil, og opståede fejl med denne type vil kun kunne findes der. Af samme grund
oversættes koden for hver subtype separat, og det er derfor ikke nødvendigt at genteste koden for
andre subtyper i systemet, hver gang en rettelse eller udvidelse foretages.
Under det objekt-orienterede paradigme kan vi ændre Dijkstras frase til switch Statement
Considered Harmful, fordi programkonstruktioner, som bygger grenvalg op på denne måde
organiserer kildeteksten i akkurat samme "spaghetti", som den fordums GO TO gjorde, blot efter
4.4.4 Dynamisk Binding som indkapsling 307

et andet paradigme †
. Et program med switch-sætninger er stort og uoverskueligt, fordi
semantikken simpelthen går tabt i de enkelte grenvalg. Dynamisk binding giver os imidlertid
mulighed for en elegant opdeling af programmerne, som lokaliserer relateret kode i isolerede
stumper ved hjælp af et sikkert type-check på kørselstidspunktet. Her er forrige eksempel
omskrevet efter det objekt-orienterede paradigme:
// eksempel 4-11: typeuafhængighed for Roter() og Forstoer()
class Figur {
Koordinat p;
public:
virtual void Forstoer (double);
virtual void Roter (Koordinat&, double);
};
class Punkt : public Figur {
public:
virtual void Forstoer (double);
virtual void Roter (Koordinat&, double);
};
class Linie : public Figur {
Koordinat e;
public:
virtual void Forstoer (double);
virtual void Roter (Koordinat&, double);
};
void Forstoer (Figur& fig, double factor) {
fig.Forstoer (factor); // polymorf!
}
void Roter (Figur& fig, Koordinat& cent, double ang) {
fig.Roter (cent, ang); // polymorf!
}
De globale funktioner Forstoer() og Roter() er nu fuldstændig uafhængige af
subtyperne af Figur, og vi kan uden videre aflede en ny klasse fra denne uden at røre ved en
eneste linie eksisterende kode. Det eneste, funktionerne skal vide er, at der findes virtuelle
funktioner i arvefølgen under Figur - den dynamiske binding sørger for selve identifikationen
af typen. Klasser med virtuelle funktioner kaldes polymorfe klasser.
4.4.5 Virtuelle metoder i detaljer
†
Windows eller OS/2 PM programmører kender de op mod 1000 liniers typiske switch-sætninger.
308 Polymorfe klasser 4.4

Man kan stille det relevante spørgsmål om, hvordan C++ identificerer et afledt objekt, når kaldet
i sig selv ikke på oversættelsestidspunktet er entydigt. Svaret ligger i, at et objekt med virtuelle
metoder indeholder ekstra skjulte datamedlemmer, som peger på de specifikke virtuelle metoder.
Det betyder, at de tre klasser Firkant, Punkt og Linie fra sidste afsnit alle har to
usynlige datamedlemmer, nemlig pointere til de to funktioner Forstoer() og Roter().
Oversætteren bruger den skjulte pointer, når der skal foretages et kald til en virtuel funktion. Da
en virtuel funktion skal være erklæret i baseklasssen, kan oversætteren generere et indeks til
pointeren til den virtuelle funktion, som er ens for alle klasser, som nedarver fra denne
baseklassen. Dermed er kompleksiteten i dynamisk binding ikke større end en ganske normal
indirektion, hvor den effektive adresse er resultatet af en dereference af en pointer. De skjulte
medlemmer i de polymorfe klasser er blot pointere til funktioner. Den ekstra databehandling, som
ligger i denne indirektion, bliver selvfølgelig påført programmets effektivitet i forhold til statisk
bundne kald. Dog er der ikke tale om et større nedslag, da en indirektion ofte kan foretages i en
eller to enkle instruktioner på assembler-niveau, og er på visse processorer endda implementeret
direkte i instruktionssættet.
I Figur 4-7 ses, hvordan de forskellige objekters skjulte virtuelle tabeller refererer de faktiske
funktioner. Den virtuelle tabel, som indeholder pointerne til de virtuelle metoder, forekommer
dog kun en gang for hver polymorf klasse, ikke for hver forekomst af klassen. Forekomsten
indeholder en pointer til den virtuelle tabel, så en polymorf klasse vil højest indeholde et skjult
overhead svarende til en pointerforekomst (multipelt afledte klasser indeholder dog flere pointere,
mere om det i afsnit 4.5).
4.4.5 Virtuelle metoder i detaljer 309

Figur 4-7: Skjulte datamedlemmer i polymorfe klasser (konceptuel model).
310 Polymorfe klasser 4.4

Figur 4-8: Et kald til en virtuel funktion. Her ses den reelle tabel til de virtuelle funktioner.
Figur 4-8 viser, hvordan to forskellige forekomster af klassen Punkt gennem en pointer til
den virtuelle tabel gennemfører et virtuelt funktionskald, der svarer til, at to uafhængige pointere
til Figurer, som reelt peger på Punkt-objekter, kalder Forstoer()-funktionen for disse
pointere.
4.4.6 Polymorfe metoder
Virtuelle metoder er faktisk en form for overstyring, da der er tale om, at en identisk syntaks
medfører forskellige resultater. Forskellen fra generelt overstyrede funktionsnavne og operatorer
er, at de virtuelle metoder bindes dynamisk. C++ opstiller visse krav til virtuelle metoder, som
skal følges for at få magien til at virke:
• Først og fremmest skal en virtuel metode erklæres i baseklassen, dvs. den klasse, hvis
type bruges i reference til de virtuelle kald. Metodernes prototyper skal være helt
identiske i baseklassen og i de afledte klasser, fordi syntaksen er ens i kaldet uanset
hvilken type, der er tale om. Udover funktionsnavnet skal både parameterlisten og
returværdien i den afledte klasse være mage til baseklassens. Oversætteren kan sikre
dette, og vil normalt fejle, hvis det ikke overholdes. Virtuelle metoder må godt
overstyres efter de normale regler, hvorved klassen blot får to eller flere virtuelle
metoder at arbejde med.
• Da virtuelle funktioner arbejder i et klassehierarki med reference til den klasse, som de
er erklæret i, har de altid et underforstået objekt, for hvilket den specifikke polymorfe
metode kaldes. Det forbyder virtuelle friend-funktioner, fordi en sådan ikke har et
underforstået objekt, da den kan være friend til mere end én klasse. Det tillader
imidlertid en virtuel funktion i én klasse at være erklæret som friend i en anden
klasse, da funktionen i så fald har et underforstået objekt (den første klasse).
• Det er ikke nødvendigt at specificere virtual-nøgleordet i erklæringen af virtuelle
metoder i de afledte klasser. Det er nok at fortælle baseklassen, at metoden er virtuel,
hvorefter alle afledte klasser også opfatter den som sådan. Det er dog tilrådeligt at skrive
virtual før en virtuel metode, fordi det gør det helt klart, hvilken type metode, der er
tale om. virtual-nøgleordet skal kun skrives i klassens krop, ikke i en eventuel
ekstern implementation af metoden.
• Det er ikke påkrævet, at en afledt klasse redefinerer en virtuel metode, sålænge den har
en erklæring i baseklassen. Hvis en virtuel metode ikke findes i den afledte klasse, arves
den fra den nærmeste baseklasse, som implementerer den (med mindre den er ren, se
afsnit 4.4.10).
En metode bør erklæres virtuel, hvis designeren af baseklassen mener, at den eventuelt får en
4.4.5 Virtuelle metoder i detaljer 311

anden betydning i en afledt klasse. Forskellen på at erklære metoden virtuel og lade den stå som
normal funktion er fra dette synspunkt, at baseklassen kan bruges som fællesnævner for de
afledte klasser i klientens programmer. Det gør klientens kode langt mere generisk og
genbrugelig.
Læg mærke til, at en virtuel metode kun er polymorf, sålænge der er tale om kald gennem
pointere eller referencer til den klasse (eller baseklasse), som metoden er medlem af. Selv om en
metode er virtuel, vil den binde statisk til kalderen, hvis den kaldes med henvisning til en
forekomst af klassen:
void f (Figur& fig, Punkt pkt) {
fig.Forstoer (1.30); // dynamisk binding
pkt.Forstoer (1.30); // statisk binding
}
Det sidste kald til Forstoer() binder statisk, fordi oversætteren identificerer kaldet til et
Punkt på oversættertidspunktet. Der er nemlig ikke noget at være i tvivl om, når der arbejdes
med forekomster af klasser.
Hvis den virtuelle metode i den afledte klasse afviger fra den originale prototype i baseklassen,
får den ikke den tilsigtede funktion. Det er vigtigt at sikre ækvivalensen, for oversætteren vil ikke
advare om fejl:
class Firkant : public Linie {
// ...
public:
void Forstoer (float);
virtual Forstoer (double);
// ...
};
Den virtuelle metode i Firkant kan ikke arbejde sammen med den nedarvede metode
Forstoer() fra Linie, fordi den afviger i specifikation. Den første metode i den afledte
klasse er blot en normal metode, mens den anden bliver en virtuel metode nedefter i hierarkiet,
men ikke opefter, da den returnerer en int. Klassen Firkant indeholder derfor hele tre
funktioner Forstoer(), da den også nedarver den virtuelle funktion fra baseklassen:
void Firkant::Forstoer (float); // normal metode
int Firkant::Forstoer (double); // virtuel metode
void Firkant::Forstoer (double); // virtuel metode (arvet)
Selvom en afledt klasse ikke redefinerer en virtuel metode, og dermed arver baseklassens, kan en
ny afledning redefinere metoden:
312 Polymorfe klasser 4.4

class Base {
public:
virtual void f ();
};
class Afledt : public Base {
public:
};
class Afledt2 : public Afledt {
public:
virtual void f ();
};
Selv om klassen Afledt ikke redefinerer den virtuelle metode f(), og dermed overtager den
fra Base, så får metoden en anden betydning i Afledt2, som erklærer en ny af samme navn
og dermed ikke arver den oprindelige.
Der er en mulighed for tvetydighed her. Hvis en baseklasse erklærer en virtuel metode i
public-delen af klassen, og en nedarvet klasse reerklærer metoden i en private eller
protected sektion, hvad sker så? Det er ikke ulovligt at foretage en sådan ændring i adgang til
en given virtuel funktion, fordi grænsefladen til den afledte klasse kan kræve det. Overvej
class Base { public: virtual void f (); };
class Afledt : public Base { protected: virtual void f (); };
void foo (Base& b) {
b.f();
}
Den virtuelle funktion f(), som kaldes fra foo() er public, og giver derfor funktionen
adgang. Hvad sker, hvis funktionen kaldes med
void main () {
Afledt p;
foo (p); // kalder indirekte den protected'e
} // virtuelle metode Afledt::f() !
hvorved foo() vil kalde en metode, der reelt er protected og for hvilken den er forment
adgang? Svaret er, at en virtuel funktion altid har samme visibilitet som den klasse, den kaldes
med reference til. Funktionen foo() kalder en virtuel metode, som er erklæret public i den
klasse, som metoden kaldes for. Dermed vil alle fra Base afledte klasser have samme
adgangsbetingelser, nemlig public. Hvis funktionen i stedet arbejder på en reference til en
Afledt, vil alle kald til den virtuelle funktion være protected, fordi den fra Afledts
synspunkt og nedefter har dette adgangskriterium. Følgende vil derfor ikke kunne oversættes:
4.4.6 Polymorfe metoder 313

void foo (Afledt& a) {
a.f(); // fejl: f() er protected i Afledt
}
Eller helt konkret:
Afledt a; Base& bp = a;
Afledt& ap = a;
bp.f(); // ok, kalder Afledt::f()
ap.f(); // fejl, ingen adgang til f()
Der skal også lægges vægt på, at de virtuelle funktioner har præcis de samme prototyper i både
baseklasser og afledte klasser. Hvis den afledte klasses reerklærede virtuelle funktion afviger i for
eksempel et parameter, introducerer den en ny virtuel funktion! Husk derfor altid at
dobbeltchecke konstante funktioner, parametre og returværdier samt parametertyper.
4.4.7 Polymorfe datastrukturer
Hvis en klasse K indeholder referencer eller pointere til andre polymorfe klasser, er disses
indhold afhængig af de faktiske klasser, som K peger på. Dermed er K en polymorf klasse i en
anden forstand, nemlig set fra datasiden, og kaldes derfor en polymorf datastruktur. Dette
koncept kan eksemplificeres med en ny klasse Billede, som indeholder et antal Figurer:
// eksempel 4-12a: en klasse, der både er klient og arving
class Billede : public Figur {
Figur** liste;
int antal;
public:
Billede (int = 100);
~Billede ();
Billede& Indsaet (Figur*);
virtual void Tegn ();
virtual void Slet ();
virtual void Forstoer (double);
virtual void Roter (Koordinat&, double);
};
Billede::Billede (int kapacitet) {
liste = new Figur* [kapacitet];
antal = 0;
}
314 Polymorfe klasser 4.4

Billede::~Billede () {
for (int i = 0; i < antal; i++;) delete liste [i];
delete liste;
}
Billede& Billede::Indsaet (Figur* fig) {
liste [antal++] = fig;
return *this;
}
void Billede::Tegn () {
for (int i = 0; i < antal; i++) liste [i]->Tegn ();
}
void Billede::Slet () {
for (int i = 0; i < antal; i++) liste [i]->Slet ();
}
void Billede::Forstoer (double factor) {
for (int i=0; i < antal; i++) liste [i]->Forstoer
(factor);
}
void Billede::Roter (Koordinat& k, double ang) {
for (int i = 0; i < antal; i++) liste [i]->Roter (k, ang);
}
Klassen Billede indeholder en liste af pointere til Figurer, som reelt kan pege på ethvert
objekt, som er en forekomst af en af Figur afledt klasse. Dermed kan Billede bruges til at
beskrive en tegning af mange forskellige slags Figurer, og med et indhold, som kan ændre sig
dynamisk. Den egenskab, at en klasse indeholder forekomster af eller pointere til andre klasser
gør den til en såkaldt container-klasse, hvilket beskrives nærmere i kapitel 5. Generelt er
Billede en kollektion af Figurer, som kan bruges på følgende måde:
// eksempel 4-12b: polymorfe datastrukturerer i anvendelse
void main () {
Billede& stjerner = *new Billede (3);
Billede& kometer = *new Billede (2);
stjerner // definér stjernerne
.Indsaet (new Punkt (Koordinat (100,100)))
.Indsaet (new Punkt (Koordinat (300,50)))
.Indsaet (new Punkt (Koordinat (200,300)));
4.4.7 Polymorfe datastrukturer 315

kometer // definér kometerne
.Indsaet (new Linie (Koordinat(20,20),Koordinat(30,400)))
.Indsaet (new Linie (Koordinat(80,200),Koordinat(300,30));
Billede nathimmel (2);
nathimmel.Indsaet (&stjerner).Indsaet (&kometer);
nathimmel.Tegn ();
delete *stjerner;
delete *kometer;
}
Dette eksempel illustrerer, hvordan polymorfe datastrukturer kan acceptere alle former for afledte
klasser som medlemsdata. I eksemplet erklæres to Billeder, stjerner og kometer, som
fyldes med henholdsvis Punkter og Linier. Så erklæres et nyt Billede, nathimmel,
som får indsat stjernerne og kometerne, og dernæst skrives ud:
Punkt på (100,100)
Punkt på (300,50)
Punkt på (200,300)
Linie fra (20,20) til (30,400)
Linie fra (80,200) til (300,30)
Det spændende ved dette eksempel er, at Billede både arver fra Figur og har Figur
som medlemsvariabel. Det tillader, at vi indsætter Billeder i Billeder, og dermed kan
anskue stjerner og kometer som subbilleder uden at skulle erklære dem som sådanne.
Klassen Billede udvider dermed sin polymorfi til at omfatte sig selv og viser, hvor stor
polymorfiens styrke er.
4.4.8 Initiering af polymorfe klasser
Konstruktører nedarves ikke, og kan følgelig ikke være virtuelle. En konstruktør har til opgave at
initiere en forekomst af en given klasse, og har intet at gøre i de afledte klasser. Der skal derfor
ikke tages specielle hensyn i forhold til baseklasserne, når der skrives konstruktører i en afledt
klasse.
Det omvendte er derimod tilfældet. Initieringsrækkefølgen i et afledt objekt under konstruktion
siger, at baseklassen initieres før den afledte klasse (afsnit 4.3.7). Når baseklassens konstruktør
bliver kaldt, er objektet derfor stadig under konstruktion, hvilket har betydning for de virtuelle
funktioner:
// eksempel 4-13: virtuelt kald fra konstruktør
class X {
public:
virtual void f () { cout

};
class Y : public X { // Y arver fra X
public:
Y () { f (); } // kons. kalder virtuel funktion
};
class Z : public Y { // Z arver fra Y
public:
Z () { f (); } // kons. kalder virtuel funktion
virtual void f () { cout

~X();
}
class Y : public X {
public:
Y();
~Y();
}
void f () {
X* a = new Y; // kalder konstruktøren Y::Y()
delete a; // kalder destruktøren X::~X()
}
Problemet er, at det underforståede kald til destruktøren i sætningen delete a binder statisk
til X::~X(), selvom a rent faktisk er en forekomst af Y. For at undgå dette erklæres
destruktøren virtuel, hvorved kaldet binder dynamisk til den rigtige destruktør og bobler opad i
hierarkiet på den sædvanlige måde. Destruktører er ikke virtuelle som standard, fordi der er
mange anvendelser af nedarvede klasser, hvor polymorfi ikke er nødvendig, og hvor det blot ville
skabe et unødvendigt overhead i både kode- og datastørrelse.
En god regel er, at hvis en klasse er afledt, og skal bruges polymorft (med indirekte reference til
baseklassen), og især, hvis den indeholder virtuelle metoder, så skal destruktøren også være
virtuel. Da destruktører ikke nedarves, overtages en eventuel virtuel destruktør ikke fra
baseklassen, og en manglende definition resulterer i et ikke-virtuelt, underforstået destruktørkald.
4.4.10 Abstrakte klasser
Undertiden arbejder vi med koncepter, som ikke har en fysisk form eller anvendelighed, men må
klassificeres som abstrakte uden en egentlig manifestation i virkeligheden. I eksemplet i afsnit
4.3.1 (figur 4-3) arbejdes med forskellige dyrearter, som nedad i hierarkiet bliver mere og mere
specifikke. En vilkårlig klasse Elefant har for eksempel en klar betydning og manifestation,
da det er muligt at forestille sig en forekomst af dette dyr, ligesom det er muligt at skabe
Svaner, Rokker og Myg. Alle disse klasser er konkrete; det er muligt at forestille sig en
forekomst af dem.
Det gælder ikke for Elefants nærmeste baseklasse, Pattedyr. Selv om vi kan arbejde
med Pattedyr på et generaliserende og abstrakt niveau, kan vi ikke forestille os en forekomst
af et pattedyr. Vist er en elefant et pattedyr, men det er mere end det. Der findes ikke en skabning,
som blot er et pattedyr, hvilket gør ordet til et begreb uden fysisk repræsentation i virkeligheden.
Vi har en stor abstrakt begrebsverden, tænk blot på ordene - eller klasserne - køretøj, bog, pige,
væske og computerspil. Umiddelbart tænker vi, at vi da har en bil, som er en 2CV, en bog som
hedder Princpia Mathematica, en pige, som hedder Charlotte osv., men de er mere end blot en
bil, en bog og en pige. Grunden til, at vi overhovedet har disse abstrakte begreber er, at vi skal
318 Polymorfe klasser 4.4

uge dem, når vi ikke kender den konkrete klasse, men blot én af de mere generelle nærmeste
klasser, som den tilhører. Uden at kende til indholdet i eller titlen på en bog ved vi godt, hvordan
den skal tages ud af bogreolen, bladres i, læses osv.
Principperne for nedarvning i C++ tilstræber en generalitet opefter og en specialisering
nedefter. De øverste klasser i et hierarki bliver derfor de mest generelle, for hvilke der ikke er
berettigelse for egentlige instantierede objekter. Overvej
Figur f;
Hvad menes med denne erklæring? Den siger, at f er en forekomst af Figur, men hvad er en
Figur, når det kommer til stykket? Det er kun de afledte klasser, som har en egentlig betydning,
og det er slet ikke meningen, at baseklassen Figur skal instantieres som her. Det giver
anledning til et par væsentlige spørgsmål:
• hvordan skal de virtuelle funktioner implementeres i en klasse, hvis koncept ikke egner
sig til instantiering? Hvordan skal en Figurs Tegn()-metode for eksempel se ud?
• hvad sker der, hvis programmøren glemmer at erklære og definere en virtuel funktion i
en afledt klasse, så den dermed nedarves fra baseklassen med en uønsket virkning?
Da der ingen idé er i at instantiere Figur-klassen, fordi den repræsenterer et abstrakt begreb,
har de virtuelle metoder i den ingen reel funktion. De kunne eksempelvis se ud som følger:
void Figur::Tegn () {
cerr

...
public:
virtual void Tegn () = 0; // ren virtuel metode
virtual void Slet () = 0; // ren virtuel metode
// ...
};
De to metoder i Figur er en slags spøgelsesmetoder, som blot erklærer de virtuelle metoder
uden at definere dem. Dette har to konsekvenser:
• den klasse, som indeholder rene virtuelle metoder, kan ikke instantieres, da klassen er
funktionel inkomplet. En erklæring som
Figur f;
vil generere en oversætterfejl, fordi et kald til f.Tegn() ikke kan binde til en egentlig
funktion. Dermed repræsenterer en klasse med rene virtuelle funktioner det abstrakte
begreb ovenfor, og kaldes derfor for en abstrakt klasse. Abstrakte klasser bruges kun
som baseklasser for andre klasser, og det er umuligt at skabe reelle objekter fra dem.
• den klasse, der er nedarvet fra en klasse emd en eller flere rene virtuelle metoder vil
automatisk overtage disse metoder. De skal enten erklæres og implementeres i den
afledte klasse for at gøre klassen ikke-abstrakt, ellers vil de rene virtuelle metoder arves
direkte i den afledte klasse og gøre denne abstrakt. I tidligere versioner af C++ (før 3.0)
arvedes de rene virtuelle metoder ikke, hvorved programmøren var tvunget til enten at
generklære dem som rene eller rent faktisk at implementere dem. Det har imidlertid vist
sig, at de fleste afledte klasser af abstrakte baseklasser selv var abstrakte klasser, hvorfor
funktioner af denne art nu arves direkte. Følgende kode var ikke tilladt i C++ 2.1:
class X { public: virtual f (); };
class Y : public X { };
fordi Y ikke enten redefinerede f() som ren eller implementerede funktionen. I ANSI
C++ og AT&T C++ 3.0 er disse erklæringer lovlige; klassen Y vil være abstrakt og
indeholde den rene virtuelle funktion f().
En abstrakt klasse repræsenterer dermed virkelighedens abstrakte begreber, altså koncepter, der
ikke har en fysisk form. Det betyder ikke, at vi ikke kan arbejde med pointere til abstrakte
datatyper, ganske som i den rigtige verden. Selvom en klasse er abstrakt, kan vi sagtens erklære
en pointer til en forekomst af denne klasse. Når pointeren skal tildeles adressen på et objekt, skal
det blot være en forekomst af en konkret klasse, nedarvet fra den abstrakte klasse.
Hvis en afledt klasse ikke implementerer den rene virtuelle metode, den arver, bliver metoden
en ren virtuel metode i den afledte klasse. Derved kan mange klasser nedefter i hierarkiet være
abstrakte, hvilket finder mange paralleller i virkeligheden: Fugl nedarver fra Dyr,
320 Polymorfe klasser 4.4

Sangfugl nedarver fra Fugl, men de er alle abstrakte klasser. Først, for eksempel, når
Solsort arver fra Sangfugl har vi en konkret klasse.
4.4.11 En løsning med virtuelle metoder
Klasserne i Figur-hierarkiet kan nu omskrives med en abstrakt baseklasse, som indeholder
virtuelle metoder, og som derved løser problemerne fra afsnit 4.3.10.
// eksempel 4-14: en abstrakt figur-klasse
class Figur {
char* navn;
protected:
Farve f;
bool vises;
Koordinat k;
public:
Figur (const Koordinat&, const char*);
Figur (const Figur&);
virtual ~Figur () { delete navn; }
void operator= (const Figur&);
const char* figurNavn () { return navn; }
const Koordinat& startPunkt () { return k; }
virtual void Flyt (const Koordinat&);
virtual void Tegn () = 0;
virtual void Slet () = 0;
};
class Punkt : public Figur {
public:
Punkt (const Koordinat& k, const char* s)
: Figur (k, s) { }
virtual void Tegn ();
virtual void Slet ();
};
class Linie : public Figur {
Koordinat endepunkt;
public:
Linie (const Koordinat& a, const Koordinat& b,
const char* s) : Figur (a, s) { endepunkt = b; }
virtual void Flyt (const Koordinat&);
virtual void Tegn ();
4.4.10 Abstrakte klasser 321

virtual void Slet ();
};
Implementationen af metoderne i Figur er ækvivalente til de fra eksempel 4-3. De to afledte
klasser erklærer de rene virtuelle funktioner Tegn() og Slet(), men indeholder ikke
tildelings- eller kopi-konstruktør, da den underforståede kan bruges for den afledte klasse: der er
ingen indirekte data. Flyt()-metoden nedarves fra Figur til Punkt, mens den omskrives i
Linie, der også skal flytte sit endePunkt. Metoderne i Punkt og Linie er mage til
eksempel 4-4 og 4-5. Lad os igen udvide med et Billede:
// eksempel 4-15: virtualiseret version af eksempel 4-12
class Billede : public Figur {
Figur** liste;
int antal; // antal Figurer i Billedet
int kapacitet; // maksimum-kapacitet
public:
Billede (int a = 100) : Figur (Koordinat(0,0), "Billede")
{ liste = 0, antal = 0, kapacitet = a; }
Billede (const Koordinat& k, const char* s, int a = 100)
: Figur (k, s) { liste = 0, antal = 0, kapacitet = a; }
Billede (Billede&);
virtual ~Billede ();
virtual void Flyt (const Koordinat&);
virtual void Slet ();
virtual void Tegn ();
Billede& Indsaet (Figur*);
};
Billede::~Billede () {
for (int i = 0; i < antal; i++) delete liste [i];
delete liste;
}
void Billede::Flyt (const Koordinat& k) {
Figur::Flyt (k);
for (int i = 0; i < antal; i++) liste [i]->Flyt (k);
}
void Billede::Tegn () {
for (int i = 0; i < antal; i++) liste [i]->Tegn ();
}
322 Polymorfe klasser 4.4

void Billede::Slet () {
for (int i = 0; i < antal; i++) liste [i]->Slet ();
}
void Billede::Indsaet (Figur* fig) {
if (antal < kapacitet) liste [antal++] = fig;
return *this;
}
Metoderne i Billede er ligefremme: de kalder iterativt alle indeholdte objekter med samme
metodenavn. Et Billede med 10 Punkter, som modtager et kald til Tegn(), vil kalde
Tegn()-metoden i alle 10 punkter. Den virtuelle destruktør sikrer, at alle de indeholdte objekter
destrueres, hvis Billedet går ud af skop †
. Den eneste metode, der ikke er defineret ovenfor er
kopi-konstruktøren. Her er nemlig et problem, overvej følgende implementation:
Billede::Billede (Billede& b) : Figur (b) {
antal = b.antal;
liste = new Figur* [kapacitet = b.kapacitet];
for (int i = 0; i < antal; i++) liste [i] = b.liste [i];
}
Denne metode vil kopiere alle Figur-pointerne fra det ene Billede til det andet. Da der blot
er tale om kopier af pointere, vil de to Billeders destruktører referere til de samme Figurer,
når de deallokeres. Dermed deletes samme objekter to gange, hvilket er en alvorlig fejl. En
anden fremgangsmåde, som er mere naturlig, når vi antager, at Billeder "ejer" de indeholdte
objekter, er at kopiere dem. Men hvordan kopieres et polymorft objekt? Vi kan ikke skrive
Billede::Billede (Billede& b) : Figur (b) {
antal = b.antal;
liste = new Figur* [kapacitet = b.kapacitet];
for (int i = 0; i < antal; i++)
liste [i] = new Figur (*b.liste [i]); // fejl:
abstrakt
}
fordi allokeringen af en Figur er ulovlig, da den er abstrakt. Hvis vi på den anden side skriver
alt andet end new Figur, vil tildelingen ikke være korrekt. En rimelig løsning er at skrive en
polymorf metode i alle Figur-klasser, som skaber en kopi af det underforståede objekt:
// eksempel 4-16: eksplicitte kopi-rutiner
† Det er i dette eksempel Billede-klassens ansvar at deallokere sine "egne" objekter. Problemet med ejerforhold
i container-klasser beskrives nærmere i afsnit 5.6.1.
4.4.11 En løsning med virtuelle metoder 323

class Figur {
// ...
public:
//
virtual Figur* Kopier () const = 0;
};
Figur* Punkt::Kopier () const { return new Punkt (*this); }
Figur* Linie::Kopier () const { return new Linie (*this); }
Figur* Billede::Kopier() const { return new Billede(*this); }
og derefter implementere Billedes kopi-konstruktør som følger:
Billede::Billede (Billede& b) : Figur (b) {
antal = b.antal;
liste = new Figur* [kapacitet = b.kapacitet];
for (int i = 0; i < antal; i++)
liste [i] = b.liste [i]->Kopier ();
}
De afledte klasser kan blandes i en langt højere grad end ved lineær arv. Først og fremmest kan
vi skabe polymorfe datastrukturer uden bekymringer, som i
Output:
void main () {
const antal = 2;
Figur* tegning [antal];
tegning [0] = new Punkt (Koordinat (100,100), "Prik");
tegning [1] = new Linie (Koordinat (0,0),
Koordinat (50,50), "Streg");
for (int i = 0; i < antal; i++)
cout

afledt fra:
// skab en kopi af figuren og flyt den lidt væk fra
originalen
Figur* skyggeEffekt (const Figur& fig) {
Figur* f = fig->Kopier ();
f->Flyt (Koordinat (-2,-2));
return f;
}
// undersøg, om to figurer overlapper
bool Overlap (const Figur& fig1, const Figur& fig2) {
return fig1->startPunkt() == fig2->startPunkt ();
}
Sådanne datastrukturer og metoder er uafhængige af den egentlige type, på hvilken den arbejder,
og kan følgelig behandle typer, som endnu ikke er skrevet. Det tillader, at et generisk bibliotek
kan skrives sideløbende med et klassehierarki, hvilket især i større projekter giver hver
programmør en meget stor frihed og sikkerhed.
Polymorfi er givetvis det sværeste koncept at forstå for programmører, der arbejder med
strukturerede metoder eller med proceduralt orienteret design. Og det er ikke nok blot at forstå.
Selve programudviklingen skal anskues på en helt anden måde, fordi design af klasser og
klassehierarkier ligger meget langt fra design af funktioner og datastrukturer under de gængse
paradigmer. I kapitel 5 gennemgår jeg nogle retninglinier for, hvordan klasser bør designes og
hvordan polymorfi skal - og ikke skal - anvendes. Der ligger en utrolig styrke i polymorfi, men
metoden kan også bruges på forkerte måder. Et dårligt skrevet objekt-orienteret program kan
være meget værre end et dårligt skrevet proceduralt orienteret program, fordi der er flere
underforståede afhængigheder. Der er nogle vigtige regler for anvendelsen af især polymorfi, som
gennemgås i afsnit 5.9.
4.5 MULTIPEL ARV
Indtil nu har vi kun arbejdet med klasser, som nedarver fra en enkelt baseklasse. C++ tillader som
et af de få objekt-orienterede sprog at en klasse nedarver fra et vilkårligt antal baseklasser, en
teknik, som kaldes flersidet eller multipel arv (engelsk multiple inheritance). Multipel arv er en
fremgangsmåde, som lader en klasse overtage data og metoder fra mere end én baseklasse,
hvorved karakteristika fra alle disse klasser bliver en del af den multipelt afledte klasse.
Teknikken er i mange henseender en determinant for, om et system er ægte objekt-orienteret.
Med multipel arv kan et klassehierarki opbygges mere modulært, fordi modulariteten i de enkelte
klasser kan deles på flere niveauer. Egenskaberne i baseklasserne smelter sammen i den afledte
klasse, som på den måde bliver langt simplere at skrive.
Lad os fortsætte med fauna-eksemplet fra afsnit 4.3.1. I dette hierarki arver alle klasser fra en
baseklasse, og den generelle træstruktur repræsenterer klasser af faldende generalitet nedefter. Vil
4.4.11 En løsning med virtuelle metoder 325

vi udvide med en ny klasse finder vi blot en klasse i hierarkiet, som kommer vores nye begreb
nærmest og arver fra denne. Den nye klasse specialiserer sig indenfor sit eget område i
programmet og indgår i hierarkiet på linie med alle de andre.
Hvor kommer multipel arv så ind i billedet? Man skulle tro, at arv fra en enkelt baseklasse er en
tilstrækkelig teknik til opbygning af klassehierarkier. Brugbarheden af multipel arv skal
imidlertid ses i sammenhæng med, at begreber normalt ikke er isolerede. Mange egenskaber ved
klasser kan abstraheres i uafhængige sidespor, som rent funktionelt ikke er relaterede. Hvis vi
således ønsker at udvide hierarkiet med egenskaber som truede dyrearter, kød- og planteædende
dyr eller intelligensgrad finder vi, at de på ingen måde strukturelt kan sættes ind i det eksisterende
hierarki. De går med andre ord på tværs af træet, som er opdelt efter familier og racer. De nye
egenskaber har intet med familier og racer at gøre, og kan dermed ikke integreres uden at
introducere redundans i programmet, hvilket nærmest er en synd i objekt-orienteret
programmering.
Figur 4-9: Multipel arv.
Med multipel arv kan vi introducere en helt ny klasse, som beskriver for eksempel en truet
dyreart, og nedarve både fra denne og fra en eksisterende klasse i hierarkiet. Datastrukturen, som
beskriver træet ændres dermed, og kan beskrives som en acyklisk orienteret graf (dag), hvis
opadgående afhængigheder kan gå på kryds og tværs af træet. For eksempel kan vi skrive to
klasser, Koedaedende og Planteaedende, og lade de klasser, som beskriver kødædende
dyr nedarve fra den første, de, som beskriver planteædende dyr fra den anden og sidst de, som
både æder dyr og planter fra begge klasser - se figur 4-10.
Denne opdeling tillader os ikke blot at abstrahere funktionalitet ud af sidebenene på
eksisterende klassehierarkier, men giver os mulighed for at indkapsle denne funktionalitet et
enkelt sted, med de dertil hørende fordele hvad angår fejlbehandling, vedligeholdelse osv.
Derudover kan vi, som vi skal se, med polymorfe klasser under multipel arv arbejde med den
baseklasse, som vi har brug for i en given situation og ignorere den anden sålænge det er
nødvendigt. Vi kan således forestille os lister af planteædende dyr og lister af fugle, hvilket
ingenlunde er det samme. Syntaksen for multipel arv er en simpel udvidelse af den eksisterende
teknik. De baseklasser, som ønskes for en ny klasse skrives som en kommasepareret liste i
erklæringen af klassen:
class Afledt : Base1, Base2 { ...
326 Multipel arv 4.5

Alle regler for public og private arv gælder også under multipel arv, så syntaksen kan
også være
class Afledt : public Base1, public Base2 { ...
Klassen Afledt arver således fra både Base1 og fra Base2.
Figur 4-10: Multipel arv i fauna-hierarkiet.
4.5.1 Multipel arv med uafhængige baseklasser
Det simpleste eksempel på multipel arv er en arvefølge, hvor den afledte klasse har to uafhængige
klasser som baseklasser. Med uafhængige klasser menes, at der ikke eksisterer et typeforhold
mellem de to klasser. Lad os udvide Figur-hierarkiet fra afsnit 4.4.11 med nogle nye
egenskaber, som beskriver mere end blot figurer.
Grafiske objekter forestiller et eller andet. Denne dimension af deres indhold kan vi beskrive i
et par nye klasser, som beskriver de attributter i figurerne, som ikke åbenlyst fremgår af Figurklasserne.
Denne løsning på en parallel udvidelse bevarer klassernes generalitet, så de grafiske
objekter ikke får et specifikt, applikations-afhængigt indhold. Vi antager at ville skrive et
program, som simulerer en stjernehimmel, og skal derfor bruge begreber som Stjerne og
Planet, som skal være konceptuelt uafhængige af grafiske primitiver:
// eksempel 4-17: et generelt himmellegeme
class Himmellegeme {
protected:
4.5 Multipel arv 327

char* navn; // himmellegemets navn
int dist; // distance fra solen
double magnitude; // lysstyrke
public:
Himmellegeme (char*, int, double&);
~Himmellegeme () { delete navn; }
const char* operator char* () { return navn; }
};
// konstruktør for himmellegemer
Himmellegeme::Himmellegeme (char* n, int d, double& m) :
dist (d), magnitude (m) {
navn = new char [strlen (n) + 1];
strcpy (navn, n);
}
// en stjerne-klasse
class Stjerne : public Himmellegeme {
double parallax; // relativt fra solplanet
public:
Stjerne (char* n, int d, double& m, double& p) :
Himmellegeme (n, d, m), parallax (p) { }
~Stjerne ();
long Temparatur (); // udregnet i Kelvin
// ... andre stjerne-relaterede metoder ...
};
// en planet-klasse
class Planet : public Himmellegeme {
double sideral; // omløbstid i forhold til Jorden
double density; // i gram/kubikcentimeter
public:
Planet (char*n, int d, double& m, double& r, double& y) :
Himmellegeme (n, d, m), sideral (r), density (y) { }
double EscapeVelocity (); // udregnet i km/s
// ... andre planet-relaterede metoder ...
};
Himmellegeme-hierarkiet består af en ikke-abstrakt baseklasse, som indeholder data om
legemets navn, distance fra Solen (km × 10 4
) samt dets lysstyrke. Afledt fra Himmellegeme
udbygger de to klasser Stjerne og Planet med egne data, nemlig henholdsvis stjernens
trigonometriske parallakse i forhold til solplanet og planetens omløbstid om solen i dage samt
dens tæthed i gram pr. kubikcentimeter.
328 Multipel arv 4.5

Figur 4-11: Himmellegeme-delhierarki
Klasserne kan instantieres i objekter efter de normale regler:
Planet IV ("Mars", 227.94, -2.0, 686.98, 3.94);
Planet II ("Venus", 108.21, -4.4, 224.701, 5.25);
Stjerne CenA ("Alpha Centauri", 4.3, 4.4, 0.751);
Stjerne Ori ("Betelgeuse", 650, -6.0, 0.005);
Med to isolerede klassehierarkier som Figur og Himmellegeme, der hver beskriver helt
urelaterede koncepter, kan vi ved hjælp af multipel arv skabe nye afledte klasser, som blander
kvaliteterne fra de to eksisterende. Figur, som er den grafiske repræsentation af et objekt på
computerskærmen, og Himmellegeme, som er den matematiske repræsentation af et objekt på
nattehimmelen, skal ikke modificeres for at foretage denne udvidelse:
class GrafiskStjerne : public Punkt, public Stjerne {
// ... ingen ny data ...
public:
GrafiskStjerne (char* n, int d, double& m, double& p)
: Stjerne (n, d, m, p),
Punkt (Koordinat (sin (p) * d, cos (p) * d)) { }
};
class GrafiskPlanet : public Punkt, public Planet {
// .. ingen ny data ...
public:
GrafiskPlanet (char* n, int d, double& m, double& r,
double& y) : Planet (n, d, m, r, y),
Punkt (Koordinat (sin (p) * d, cos (p) * d)) { }
};
4.5.1 Multipel arv med uafhængige baseklasser 329

De to ny klasser GrafiskStjerne og GrafiskPlanet beskriver begge et astronomisk
objekt, som - omend i teorien - har en grafisk repræsentation på computerskærmen. Det er
bemærkelsesværdigt, hvor lidt klasserne indeholder i forhold til, hvor stor funktionaliteten er. Når
en GrafiskStjerne instantieres, udregnes - stadig i teorien - stjernens position på skærmen,
som skal svare til positionen på nattehimmelen. Således kan eksisterende klasser som Punkt
udbygges med sideløbende og uafhængige klasser, uden at de behøver den mindste smule
modifikation.
Der er en vigtig læresætning her: vær ikke bange for at introducere nye klasser. Begrebet
dataabstraktion kan desværre have den utilsigtede virkning på nytilkommere til det objektorienterede
paradigme, at en klasse skal være ren og hel - næsten holistisk. Abstrakte datatyper
giver et lidt ensidigt indtryk, fordi de minder så meget om de fundamentale typer vi kender og
under alle omstændigheder ikke vil - eller kan - lave om på. Arv, og specielt multipel arv, viser,
at en ny klasse blot er en udvidelse af programmet på en eller anden måde, og at denne udvidelse
skal ses som en helt naturlig del af udviklingen. I store objekt-orienterede projekter kan findes op
mod 500 klasser, hvoraf mange blot varetager en minimal funktion i forhold til hele programmet
og på den måde klistrer dele af det sammen, så det er overskueligt og genbrugeligt. Se derfor ikke
religiøst på en klasse som en isoleret og ubrydelig del af programmet, men som en byggesten, der
kan raffineres. Når du bruger klasser i arv, skal du tænke mere på programmets opbygning og
design end på brugeren.
Figur 4-12: Multipel arv i Figur-hierarkiet.
Et andet forhold ved arv, som specielt gør sig gældende under multipel arv, er nødvendigheden af
330 Multipel arv 4.5

dummy-konstruktører, dvs. konstruktører, som blot videregiver parametre til baseklasserne uden
selv gøre brug af disse. Det er nødvendigt at skrive disse kopier af baseklassernes konstruktører
af den simple grund, at konstruktører ikke arves i C++. Under multipel arv kan der derudover
være to konstruktører, som begge entydigt skal initieres. Dette kan kun foregå via en konstruktør
i den multipelt afledte klasse.
Den store fordel ved multipel arv af den art, vi har behandlet i dette afsnit er, at de afledte
klasser får en flertydig funktionalitet. Både metoderne fra Figur-arvingerne og fra
Himmellegeme-arvingerne bliver et umiddelbart indhold i GrafiskStjerne og
GrafiskPlanet. Objekter af disse klasser kan således både slettes sig selv fra skærmen og
udregne sine forskellige matematiske variable:
GrafiskStjerne CenA ("Alpha Centauri", 4.3, 4.4, 0.751);
CenA.slet (); // kalder Punkt::slet ()
long t = CenA.Temperatur(); // kalder Stjerne::Temperatur()
cout

...
};
void g () {
C c;
c.j = 1; // ok, c.A::j tildeles
c.k = 1.0; // ok, c.B::j tildeles
c.i = 0; // tvetydig, c.A::i eller c.B::i ?
c.f(); // tvetydig, c.A::f() eller c.B::F() ?
}
Det er med andre ord ikke ulovligt at arve en tvetydighed, det er blot forbudt at gøre brug af den.
Funktionen g() ovenfor kunne reddes med henvisning til baseklasserne ved reference til de
tvetydige data:
void g() {
c.A::i = 0; // A::i i c-objektet tildeles
c.B::i = 0; // B::i i c-objektet tildeles
c.A::f (); // A::f() kaldes
c.B::f (); // B::f() kaldes
}
Denne løsning er dog ikke særlig pæn, idet den forudsætter klientens kendskab til baseklassen.
Den rigtige løsning er at undgå tvetydigheder i designet. Læg iøvrigt mærke til, at en erklæring
som
class Afledt : public Base, public Base { // ...
er ulovlig. Det er umuligt at redde den åbenlyse tvetydighed i den dobbelte arv fra samme
baseklasse med eksplicit reference til denne. En klasse må derfor kun arve fra en given baseklasse
én gang.
Jeg har nævnt, at den rigtige løsning på tvetydighederne er at undgå dem. Der er imidlertid
situationer, hvor kildeteksten til implementationen af de klasser, der arves fra, ikke er tilgængelig.
I de tilfælde er tvetydigheden ikke mulig at rette i den multipelt afledte klasse, men kan klares
med introduktionen af to nye klasser, som blot redefinerer navnet på den eller de funktioner, der
er tvetydige. Et rimeligt eksempel er to baseklasser, en grafisk med metoden Tegn() og en
forsikringsklasse, der også indeholder en Tegn()-metode til tegning af forsikringer:
class GrafiskKlasse {
// ...
public:
// ...
void Tegn ();
};
332 Multipel arv 4.5

class ForsikringsKlasse {
// ...
public:
// ...
void Tegn ();
};
Det er selvsagt ikke muligt for en ny klasse at aflede fra både GrafiskKlasse og fra
ForsikringsKlasse uden at introducere en tvetydighed for metoden Tegn() i den nye
klasse. Derfor skriver vi to andre nye klasser, som ligger mellem disse to og den nye multipelt
afledte klasse:
class GrafiskSubKlasse : public GrafiskKlasse {
public:
virtual void GrafiskTegn () = 0;
void Tegn () { GrafiskTegn (); }
};
class ForsikringsSubKlasse : public ForsikringsSubKlasse {
public:
virtual void ForsikringsTegn () = 0;
void Tegn () { ForsikringsTegn (); }
};
For en klasse, som arver fra både GrafiskSubKlasse og ForsikringsSubKlasse,
skal metoderne GrafiskTegn() og ForsikringsTegn() implementeres, da de er rene
virtuelle metoder. Da metoderne Tegn() redefineres i begge klasser, så de kalder de respektive
virtuelle tegnemetoder, er tvetydigheden opløst. Den multipelt afledte klasse får nye navne for de
to metoder. Teknikken kaldes omdøbning, og ophæver tvetydigheder og navnekonflikter ved at
introducere nye klasser for hver tvetydig baseklasse, som indeholder en virtuel metode med det
nye navn samt en omskrivning af den tvetydige metode. Den multipelt afledte klasse får således
ingen problemer:
class GrafiskForsikring : public GrafiskSubKlasse,
public ForsikringsSubKlasse {
public:
virtual void GrafiskTegn (); // implementation af
disse
virtual void ForsikringsTegn (); // metoder
};
De mellemliggende klassers funktion er blot at undgå tvetydigheder, og klistrer således en
baseklasse sammen med en afledt klasse, mens tvetydigheden ophæves med en omdøbning.
4.5.2 Tvetydigheder ved multipel arv med uafhængige baseklasser 333

4.5.3 Multipel arv med relaterede baseklasser
Hidtil har vi kun beskæftiget os med multipel arv i situationer, hvor baseklasserne ikke har haft
noget med hinanden at gøre. Der er imidlertid mange anvendelser, specielt i dele af
klassehierarkier, som implementerer meget ens klasser, hvor baseklasserne selv igen kan være
afledt fra den eller de samme klasser. I en sådan situation kan den grafiske repræsentation af
klassens arvefølge for eksempel se ud som i figur 4-13. Til spørgsmålet om, i hvilke situationer
en sådan opbygning kan være nødvendig må svares, at en multipelt afledt klasse kan have
baseklasser, som selv deler funktionalitet. Et eksempel på dette er en udvidelse af Figurhierarkiet
med en ny klasse, som repræsenterer to uafhængige figurer, en linie og et punkt:
// eksempel 4-18: multipel arv med urelaterede baseklasser
class LiniePunkt : public Linie, public Punkt {
public:
LiniePunkt (Koordinat& s, Koordinat& e, Koordinat& x) :
Linie (s, e), Punkt (x) { }
void tegn () { Linie::tegn (); Punkt::tegn (); }
void slet () { Linie::slet (); Punkt::slet (); }
void flyt () { Linie::flyt (); Punkt::flyt (); }
};
Figur 4-13: Multipel arv med relateret baseklasse.
Når der arves fra flere baseklasser, som
igen har en fælles baseklasse, er der ofte en sikker kandidat for tvetydigheder, især for metoder
eller data, som er erklæret i den fjerneste baseklasse. Derfor er multipelt afledte klasser fra
sådanne baseklasser, som LiniePunkt, ofte behængt med dummy-metoder, som blot kalder
videre bagud. I dette tilfælde er det klart, at LiniePunkt bliver nødt til at fortælle både
Streg og Punkt hvad de skal gøre.
334 Multipel arv 4.5

Arvetræet for LiniePunkt ser således ud:
Figur 4-14: Multipel arv med urelaterede baseklasser.
Klassen LiniePunkt arver
altså to gange fra Figur, hvilket dermed godt kan lade sig gøre i andet eller højere led af arv. I
dette tilfælde er det også ønskværdigt, da stregen og punktet i LiniePunkt skal være
positions-uafhængige - de skal have hver deres Figur-objekt. Eksempler på brug af
LiniePunkt:
Output:
void main () {
Koordinat a (100,100), b (200,200);
LiniePunkt skew (a, b, b - Koordinat (0, 100));
skew.Flyt (-a);
}
Linie tegnet fra (100,100) til (200,200)
Punkt tegnet på (200,100);
Linie slettet fra (100,100) til (200,200)
Punkt slettet på (200,100);
Linie tegnet fra (0,0) til (100,100)
Punkt tegnet på (100,0)
4.5.4 Virtuelle baseklasser
Ved multipel arv fra baseklasser, som har indbyrdes relationer via egne baseklasser, kan den
gentagne instantiering af den øverste baseklasse gå hen og blive et problem. Et eksempel på dette
er en udvidelse af LinkedList-klassen fra afsnit 3.10.1. Først foretager vi en mindre
4.5.3 Multipel arv med relaterede baseklasser 335

modifikation i Node-klassen, så den tillader to hægter at blive sammenlignet med hinanden
relationelt:
struct Node {
Node* next; // næste hægte
virtual bool operator> (Node&) = 0; // sammenlign hægter
virtual ~Node () { };
virtual void printOn (ostream& = cout) = 0;
};
Klassen Node er nu en abstrakt klasse (to rene metoder) og har ydermere den egenskab, at den
ikke har et dataelement! Ideen er, at vi arver fra Node, og udbygger med de data, vi har brug for.
Node er ikke længere en privat klasse, da vi i dette eksempel ønsker, at klassen skal være visibel
for klienten. LinkedList skal derfor også modificeres en smule, så den modtager og afsender
Node-pointere:
// eksempel 4-19: hægtet liste med polymorfe hægter
class LinkedList {
protected:
Node* head;
public:
LinkedList () { head = 0; }
~LinkedList ();
void Insert (Node*);
Node* Retrieve ();
bool isEmpty () { return !head; }
void printOn (ostream&) const;
};
// dealloker alle hægter hvis listen udgår af skop
LinkedList::~LinkedList () {
Node* cursor = head, *temp;
while (cursor) {
temp = cursor, cursor = cursor->next;
delete temp;
}
}
// indsæt en hægte i listen
void LinkedList::Insert (Node* n) {
n->next = head, head = n;
}
336 Multipel arv 4.5

hent en hægte fra listen
Node* LinkedList::Retrieve () {
Node* n = head;
head = head->next;
return n;
}
// udskriv en liste
void LinkedList::printOn (ostream& os) const {
for (Node* n = head; n; n = n->next) n->printOn (os);
}
Der er i ovenstående eksempel tale om en meget enkel implementation af en hægtet liste, som
vi nu vil udbygge med arv for at øge funktionaliteten. To egenskaber, som hægtede lister ofte har,
er indeksering af de individuelle hægter og sortering af alle hægterne. Vi nedarver således to nye
klasser fra LinkedList: en sorteret hægtet liste, SortedList og en indekseret hægtet liste,
IndexedList. De er begge ganske normale hægtede lister med en smule ændret karakter,
nemlig for den førstes vedkommende en ordning i hægter i stigende orden (hvilket er grunden til
ændringen i Node ovenfor) og for den andens vedkommende en mulighed for indeksering i
listen med indeks-operatoren ([]).
// eksempel 4-20a: en sorteret liste med polymorfe hægter
class SortedList : public LinkedList {
public:
void Insert (Node*);
};
// Indsæt den ny hægte på sin rette plads
void SortedList::Insert (Node* newnode) {
Node* cursor = head;
Node* track = 0;
while (cursor && *cursor > *newnode) // find pladsen
track = cursor, cursor = cursor->next;
if (track) // indsæt hægten
newnode->next = track->next, track->next = newnode;
else newnode->next = head, head = newnode;
}
// eksempel 4-20b: en indekseret liste med polymorfe hægter
class IndexedList : public LinkedList {
4.5.4 Virtuelle baseklasser 337

public:
Node& operator[] (int);
};
// find den rette hægte
Node& IndexedList::operator[] (int index) {
Node* cursor = head;
while (index && cursor) cursor = cursor->next, index--;
return cursor;
}
Med disse to ny klasser har vi et normalt træ, hvor en klasse er baseklasse til to afledte klasser.
Sorterede hægtede lister er brugbare i sammenhænge, hvor rækkefølgen for eksempel skal være
afhængig af hægtens værdi, mens indekserede hægtede lister er lettere at have med at gøre fra
klientens side. En blanding af disse to klasser vil give det bedste fra begge i en enkelt klasse. Vi
arver en sorteret, indekseret hægtet liste:
// eksempel 4-21: en sorteret, indekseret polymorf liste
class SortedIndexedList : public SortedList, // sorteret og
public IndexedList { // indekseret
public:
void Insert (Node* n) { SortedList::Insert (n); }
};
Tvetydigheden ved arven af Insert()-metoden fra både LinkedList (via
IndexedList) og SortedList reddes ved et videreført kald til SortedList i en
omskreven funktion. Klassehierarkiet ser ud som i figur 4-15.
Denne struktur demonstrerer imidlertid et stort problem ved multipel arv. Når en forekomst af
SortedIndexedList instantieres, får SortedIndexedList to LinkedList-baser,
og dermed to pointere til den første hægte i listen. Det giver en utilsigtet tvetydighed, fordi de to
head-pointere ikke refererer den samme Node. Når objekter indsættes i en
SortedIndexedList, foretages et videreført kald til SortedList::Insert(), som
sætter hægten ind det rette sted. Hvis en hægte senere hentes med []-operatoren, vil kaldet
foregå til den entydige metode operator[], som er nedarvet fra IndexedList.
338 Multipel arv 4.5

Figur 4-15: Et tvetydigt baseobjekt i en hægtet liste.
Da SortedList og IndexedList har hver deres LinkedList-baseklasser, og
dermed hver deres head-pointere, vil indekseringen returnere en NULL-pointer. Problemet
bliver endda tydeligere, hvis klienten forsøger at skrive
SortedIndexedList sil;
// ... Indsæt data i listen ...
Node* np = sil.Retrieve (); // tvetydig
fordi kaldet til SortedIndexedList::Retrieve() ikke kan identificeres som en entydig
metode. Metoden er nedarvet fra både SortedList og IndexedList, som begge igen har
arvet metoden fra LinkedList. Klienten bliver således nødt til at specificere hvilken
Retrieve(), der menes ved for eksempel at skrive
Node* np = sil.SortedList::Retrieve (); // entydig
Det samme gælder for kald til isEmpty(). Problemet i en nøddeskal er, at der ikke må
forekomme to LinkedList-subobjekter i en SortedIndexedList. Den ønskede
orienterede acykliske graf for arvefølgen skal se ud som i figur 4-16. Hvis vi studerer figuren ser
vi, at problemet ikke ligger i LinkedLists erklæring, men er et problem, der opstår i de
afledte klasser. Løsningen skal altså findes ved at ændre i specifikationen af baseklasserne i de
afledte klasser. I C++ er det muligt fra den afledte klasses synspunkt at erklære en baseklasse
virtuel, hvilket betyder, at en eventuel dobbelt forekomst af den virtuelt erklærede klasse vil blive
smeltet sammen i én forekomst. Med syntaksen
class A { /* ... */ };
class B : public virtual A { /* ... /* };
fortæller vi oversætteren, at såfremt en klasse nedarver multipelt fra B og fra en anden klasse,
4.5.4 Virtuelle baseklasser 339

som også er afledt direkte eller indirekte fra A, skal de to A-subobjekter være ét og samme
objekt, hvis placering er fysisk identisk. Virtuelle baseklasser er sandsynligvis et af de sværeste
koncepter umiddelbart at forstå, fordi en virtual-erklæring hverken har betydning for den aktuelle
klasse eller for baseklassen, men kun for afledte klasser. I eksemplet ovenfor er det for både A og
B ligegyldigt, om A erklæres som virtuel baseklasse i B eller ej. Kun eventuelle fra B afledte
klasser bliver påvirket af erklæringen. Den primære grund til dette er, at det er A, problemet
ligger i, og en klasse, der er afledt fra B skal ikke nødvendigvis vide noget om A.
Figur 4-16: Et entydigt baseobjekt i en hægtet liste.
For SortedIndexedList betyder dette således ikke, at vi skal erklære de to baseklasser
SortedList og IndexedList som virtuelle baseklasser, men derimod erklære
LinkedList som virtuel baseklasse i både SortedList og IndexedList. Dette har
ingen betydning for forekomster af hverken LinkedList, SortedList eller
IndexedList, som alle opfører sig som før, men for SortedIndexedList betyder det, at
forekomster af denne klasse kun indeholder én LinkedList:
class LinkedList { // ...
class SortedList : public virtual LinkedList { // ...
class IndexedList : public virtual LinkedList { // ...
class SortedIndexedList : public SortedList,
public IndexedList { // ...
Af disse erklæringer kan det tydeligt ses, at den virtuelle egenskab af LinkedList som
baseklasse er en funktion af arven og ikke af LinkedList selv. Det er nødvendigt at erklære
baseklassen virtuel i alle afledte klasser, da C++ kun smelter objekter sammen, som er erklæret
virtuelle alle steder. Hvis vi således kun erklærer LinkedList virtuel i SortedList, vil
det ikke have nogen effekt.
Det er muligt, og til tider ønskværdigt, at en afledt klasse både indeholder virtuelle og ikkevirtuelle
forekomster af en baseklasse. Givet følgende erklæringer
340 Multipel arv 4.5

class A { /* ... */ };
class B : public virtual A { /* ... */ };
class C : public virtual A { /* ... */ };
class D : public A { /* ... */ };
class E : public B, public C, public D { /* ... */ };
vil et E-objekt indeholde to A-subobjekter, et virtuelt nedarvet gennem B og C og et ikkevirtuelt
nedarvet gennem D. En forekomst af E vil resultere i en struktur, som kan visualiseres i
følgende skema †
:
B-objekt
---------------
B's og C's
A-objekt
C-objekt
D-objekt
---------------
D's A-objekt
E-objekt
Virtuelle baseklasser er en avanceret metode til differentiering af klasser, som har forhold, der
ikke kan beskrives med multipel arv alene. For SortedIndexedLists vedkommende
betyder virtualiseringen af LinkedList automatisk, at metoderne Retrieve() og
isEmpty() bliver entydige, fordi de arbejder på det samme objekt. Når klienten kalder
metoden Retrieve(), vil der kun være én head-pointer i konteksten, og den rigtige Node
vil blive returneret.
Før vi kan bruge SortedIndexedList skal vi imidlertid erklære en ikke-abstrakt afledt
klasse fra Node, som definerer data og implementerer de rene virtuelle metoder printOn()
og operator>(). En god kandidat til hægteindhold er et struktur, der består af to relaterede
værdier, for eksempel et navn og dets tilhørende værdi. Vi nedarver Symbol fra Node:
// eksempel 4-22: konkretisering af hægte-klassen
class Symbol : public Node {
int value;
String name; // klassen fra eksempel 3-7
public:
† C++ giver ingen garanti for, i hvilken rækkefølge de forskellige subobjekter af et multipelt afledt objekt ligger.
Ligesom under simpel arv kan de forskellige nedarvede objekter ligge i vilkårlig rækkefølge, så programmer, som
gør sig afhængige af en bestemt rækkefølge vil ikke være flytbare.
4.5.4 Virtuelle baseklasser 341

Symbol (const char* s, int v) : name (s), value (v) { }
virtual bool operator> (Node& n) { // sortér Symboler
return ((Symbol&)n).value > value; // efter deres værdi
}
virtual void printOn (ostream& = cout) const;
};
void Symbol::printOn (ostream& strm) const {
strm

hensyn til både multiple og virtuelle baseklasser. Initieringsrækkefølgen for et multipelt afledt
objekt er således:
1. Eventuelle virtuelle baseklasser, i den rækkefølge de findes ved en dybdeprioriteret,
venstre-mod-højre-traversering af arvetræet. Initieringen af de virtuelle baseklasser
starter med de klasser, der ligger nærmest den aktuelle klasse i træet.
2. Ikke-virtuelle baseklasser i den rækkefølge, de er erklæret i den multipelt afledte klasses
definition. Initieringsrækkefølgen har dermed intet at gøre med den rækkefølge,
baseklasserne har i den afledte klasses konstruktørs initieringsliste.
3. Eventuelle medlemsvariable i den multipelt afledte klasse, i den rækkefølge de er
erklæret, som igen ikke har relation til konstruktørens initieringsliste.
4. Det aktuelle objekts konstruktør eksekveres.
Hvis konstruktøren ikke eksplicit indeholder baseklassernes og medlemsvariablenes navne i
initieringslisten, vil disse blive initieret med et kald til den underforståede konstruktør. Som for
lineær arv gælder reglerne også her rekursivt, hvilket gør, at de fire ovenstående punkter bliver
prøvet for ethvert objekt, der initieres som del af et multipelt afledt objekt. Overvej følgende
komplekse objekt E:
class A {
public:
A () { cout

};
class E : public C, public D {
D ed;
public:
E () { cout

A::A()
B::B()
C::C()
D::D()
E::E()
Når klienten skriver
E e;
bliver resultatet dermed ikke færre end 20 underforståede konstruktør-kald. Det er i denne
sammenhæng vigtigt at påpege, at objekter af klasser som E ikke er egnede til vektorerklæringer.
Skriver klienten for eksempel
E e_vektor [5000];
kaldes 100000 (hundrede tusinde) kontstruktør-metoder. Det er ikke så meget tidsforbruget, der
gør sig gældende, da initieringen kun sker én gang, men langt mere, at designet er for komplekst
til denne type instantiering. Det er en god idé at gennemgå ovenstående initieringsrækkefølge
grundigt, da den har betydning for alle multipelt afledte objekter. I den forbindelse kan listen
eventuelt læses bagfra, hvilket også omvender prioriteterne for initieringsrækkefølgen. Med
kommentarer og indrykninger bliver det en del mere overskueligt at se, hvad der initieres:
(20) E::E() // E-objektet
(19) D::D() // E's D-medlemsvariabel
(18) C::C() // D's C-medlemsvariabel
(17) B::B() // C's B-medlemsvariabel
(16) A::A() // B's A-medlemsvariabel
(15) A::A() // C's A-baseobjekt
(14) B::B() // D's B-baseobjekt
(13) A::A() // B's A-medlemsvariabel
(12) A::A() // D's A-baseobjekt
(11) D::D() // E's D-baseobjekt
(10) C::C() // D's C-medlemsvariabel
(9) B::B() // C's B-medlemsvariabel
(8) A::A() // B's A-medlemsvariabel
(7) A::A() // C's A-baseobjekt
(6) B::B() // D's B-baseobjekt
(5) A::A() // B's A-medlemsvariabel
(4) C::C() // E's C-baseobjekt
(3) B::B() // C's B-medlemsvariabel
(2) A::A() // B's A-medlemsvariabel
(1) A::A() // C's og D's A-baseobjekt (virtuel)
4.5.5 Initiering og nedbrydning af multipelt afledte objekter 345

Subobjekterne 19-12 udgør E's medlemsvariabel D, 11-5 er E's ene baseklasse D og 4-1 er E's
anden baseklasse C. Læg mærke til forskellen mellem de to initieringer af D-subobjekterne,
hvor den første (medlemsvariablen) instantierer et A-objekt (nr. 12), mens den anden ikke har
den tilsvarende initiering, da der er tale om en virtuel klasse, som først initieres som nr. 1 under
C-baseobjektet. Husk, at ovenstående initieringsrækkefølge er den omvendte virkelighed, da
baseobjekter altid skal initieres før afledte objekter.
Nedbrydning af multipelt afledte objekter foregår i den omvendte rækkefølge af
konstruktionen, analogt med lineær arv. Det er en nødvendighed for korrekt oprydning i
komplekse objekter, at destruktionen er en direkte spejling af konstruktionen.
4.5.6 Typekonvertering under multipel arv
Type-systemet har næsten samme funktion under multipel arv som under lineær arv. En pointer
eller reference til en multipelt afledt klasse kan konverteres underforstået til en pointer eller
reference til en af baseklasserne, mens det omvendte ikke er tilladt. Dermed kan kode, der
arbejder på én bestemt klasse, stadig kaldes for multipelt afledte objekter af denne klasse:
// ombyt to elementer i en indekseret liste
void swap (IndexedList& list, int first, int second) {
Node& temp = list [first];
list [first] = list [second];
list [second] = temp;
}
Ikke-medlemsfunktionen swap() arbejder på en reference til en IndexedList, men kan
efter de normale regler kaldes med reference til alle klasser, som ligger i arvefølge under
IndexedList, både enkelt og multipelt. Hvis funktionen kaldes med en forekomst af
SortedIndexedList, bliver objektet underforstået konverteret til den IndexedList, som
udgør et subobjekt i dette objekt:
void f () {
SortedIndexedList SymbolTable;
SymbolTable.Insert (new Symbol ("første", 1));
SymbolTable.Insert (new Symbol ("andet", 2));
SymbolTable.Insert (new Symbol ("tredie", 3));
swap (SymbolTable, 0, 2);
}
I dette fragment bliver objektet SymbolTable automatisk konverteret fra en
SortedIndexedList til en IndexedList, fordi den første klasse er afledt fra den anden.
Følgende skema viser, hvordan konverteringen fra SymbolTable-objektet til list-objektet
sker i selve kaldet til swap():
SymbolTable-objekt
346 Multipel arv 4.5

┌─────────────────────────┐
&SymbolTable ─────│ SortedIndexedList-delen │
├─────────────────────────┤
│ SortedList-delen │
class Base {
public:
virtual operator== (Base& bp);
};
├─────────────────────────┤
&list ────────────│ IndexedList-delen │
├─────────────────────────┤
│ LinkedList-delen │
└─────────────────────────┘
Efter konverteringenses kun den del af objektet, der ligger i IndexedLists skop.Desværre er
det omvendte, dvs. underforstået konvertering fra baseklasse til afledt klasse, ikke tilladt, hvilket
ville være yderst brugbart i en situation som denne:
class Afledt : public Base {
int x;
public:
virtual operator== (Afledt& ap); // fejl, afvigende
};
Med en sådan specifikation på en virtuel funktion, som modtager en parameter som øjensynligt
bliver konverteret efter objektets type, vil det kunne lade sig gøre at skrive kode som
Base& bp1 = *new Afledt;
Base& bp2 = *new Afledt;
if (bp1 == bp2) // ...
hvilket ville løse en del af de problemer, man kommer ud for, når objekter af forskellige typer
skal blandes sammen. I metoden Base::operator==() ville parameteren have den korrekte
type, og skulle ikke behøve en tvungen konvertering. Hvis det var tilladt, ville det gøre livet
lettere i situationer, hvor virtuelle funktioner er klassebestemte og kræver parametre af den type,
som den aktuelle metode befinder sig i. Desværre er det ikke tilladt, da større og værre problemer
bliver det uafvigelige resultat:
Base& bp1 = *new Afledt;
Base& bp2 = *new Base1;
if (bp1 == bp2) // ...
Her kaldes metoden Afledt::operator==() med et baseobjekt, som, hvis koden var
4.5.6 Typekonvertering under multipel arv 347

legal, vil blive konverteret til et afledt objekt. Problemet er selvfølgelig, at der ikke er et afledt
objekt at arbejde på i denne situation - parameteren er en forekomst af Base, og baseobjekter
kan som bekendt ikke typekonverteres til afledte objekter - så den konverterede pointer vil ikke
pege på definerede data:
┌─────────┐
bp2 ───────────────│ Base1 │
└─────────┘
ap ──────────────── ?
I tilfælde, hvor man med sikkerhed ved, at et bestemt objekt er af en bestemt type, kan problemet
løses med tvungen konvertering. Er vi for eksempel sikre på, at Afledt::operator==()
kun kan kaldes med forekomster af Afledt, kan vi implementere denne metode som
int Afledt::operator== (Base& b) { // en virtuel funktion
return ((Afledt&)b).x == x; // tvungen konvertering
}
Det er vigtigt at behandle multipelt afledte objekter med forsigtighed, når der opereres med
tvungne konverteringer, fordi C++ ikke vil advare om konverteringer, der resulterer i en reference
til et ikke-eksisterende objekt eller subobjekt. Den ovenstående funktion vil derfor, hvis den
kaldes med en Base-forekomst komme i alvorlige vanskeligheder. I afsnit 5.8 beskrives,
hvordan større klassehierarkier kan indeholde en vis form for eksplicit, programmørkontrolleret
type-check, for at give klienten større frihed i blandingen af typerne.
4.5.7 Multipel arv og polymorfi
Virtelle funktioner spiller en mere kompleks rolle i forbindelse med multipelt afledte objekter,
fordi referencen til det polymorfe objekt ikke altid er den samme. Under multipel arv kan et
virtuelt kald resultere i et faktisk metodekald, som ligger udenfor den naturlige arvefølge i
klassehierarkiet, og som derfor skal designes mere forsigtigt. Eksemplet med Stjerne og
Punkt fra afsnit 4.5.1 kan for eksempel udbygges med metoder til statisk udlæsning af de
enkelte objekters interne data for fejlfinding, lagring eller andet. En sådan metode bør være
virtuel, da klienten selv bør bestemme hvilken baseklasse, der skal arbejdes med under egne
forudsætninger. Vi erklærer således metoden
virtual void Udskriv () const;
i public-delen af klasserne Punkt, Stjerne, Planet, GrafiskStjerne og
GrafiskPlanet, og implementerer dem som følger:
// eksempel 4-23: multipel arv med virtuelle funktioner
void Punkt::Udskriv () {
348 Multipel arv 4.5

cout

Tæthed: 5.25 gcm3]
Punkt [(-6,6)]
Stjerne ["Betelgeuse"
Distance: 650 lysår
Magnitude: -6
Parallax: 0.08333]
De to kald til Udskriv() foretages med reference til to forskellige polymorfe objekter. Det
interessante er, at der i kaldet til Planet::Udskriv() forekommer et underforstået kald til
Punkt::Udskriv(), og at der i kaldet til Punkt::Udskriv() forekommer et
underforstået kald til Stjerne::Udskriv(). Som det fremgår af koden er de to klasser
Planet og Punkt uden direkte relation, ligesom Punkt og Stjerne heller ikke har noget
med hinanden at gøre.
Multipel arv blandet med virtuelle metoder tillader altså en afledt klasse at binde et metodekald
på tværs af arvetræet. En vigtig konsekvens at dette er, at multipel arv kan udnyttes på en måde,
som binder eksisterende klasser sammen ikke blot i indhold, men også i funktion. Et glimrende
eksempel på dette er definitionen på en adjacency matrix (incidensmatrice), som bruges til
implementering af orienterede grafer. En incidensmatrice er en "liste af lister", og er visualiseret i
figur 4-19.
Figur 4-18: Virtuelle funktioner som "klister" mellem baseklasser.
En graf består af et antal knuder, som er forbundet med kanter. En implementation af en graf
med generelle hægtede lister (som vi har behandlet i de forrige afsnit) indeholder knuderne som
en liste, der igen hver især indeholder en liste af referencer til de andre knuder. De primære
knuder (gråtonede felter i figur 4-19) repræsenterer knuder (en knude kaldes en edge på engelsk)
mens sublisterne (de hvide felter) repræsenterer kanterne (en kant kaldes en vertex på engelsk)
mellem grafernes knuder. Normalt indeholder en kant i en computerrepræsentation af en graf en
numerisk identifikation af en headnode, men af to væsentlige årsager bruger den følgende
implementation pointere til headnodes i stedet: For det første er det mere effektivt og for det
andet strider indeksreferencer mod enkle hægtede listers natur, da de jo netop bygger på
pointerbegrebet.
Vi begynder med at arve en ny abstrakt klasse fra Node, som blot beskriver en headnode eller
350 Multipel arv 4.5

en knude i grafen. Berettigelsen for denne klasse, som ikke indeholder væsentlige udbyggelser
over Node, bliver klar senere. Foreløbig er klassens funktion at relatere knuder med hægter.
// eksempel 4-24a: en abstrakt "incidenshægte"
class AdjacencyNode : public Node {
public:
AdjacencyNode (Node* n = 0) : Node (n) { }
virtual void printOn (ostream& = cout) = 0;
};
Figur 4-19: En incidensmatrix implementeret med hægtede lister.
4.5.7 Multipel arv og polymorfi 351

Den næste klasse definerer en headnode. I figur 4-19 kan det ses, at en headnode (de gråtonede
felter i figur 4-19) både indeholder en pointer til en første hægte i en ny liste samt til en næste
hægte i en eksisterende liste. De er dermed både hægter og hægtede lister, og skal derfor afledes
multipelt fra AdjacencyNode og LinkedList:
// eksempel 4-24b: en headnode, en egentlig knude i grafen
class HeadNode : public AdjacencyNode, public LinkedList {
friend Edge;
// her indsættes grafens egentlige data, nu blot et navn
const char* name;
public:
HeadNode (const char* n) : name (n) { }
virtual void printOn (ostream& = cout);
};
// udskriv en headnode, både hægte og liste
void HeadNode::printOn (ostream& strm) {
strm

void Edge::printOn (ostream& strm) {
strm

kan for eksempel repræsentere arvefølgen for fire klasser, hvor B og C er afledt fra A, og hvor
D er multipelt afledt fra A, B og C eller fire punkter i det centrale København forbundet med
ensrettede gader. Grafens incidensmatrix har en fysisk repræsentation som i figur 4-22 - den er
mindre kompliceret end den ser ud til.
Figur 4-22: En graf repræsenteret ved hægtede lister.
Med vores nye klasser kan vi oprette en tilstødende liste med en LinkedList af
HeadNoder, der igen indeholder hægter af typen Edge og udskrive dem:
ostream& operator

Output:
HeadNode* A = new HeadNode ("A");
HeadNode* B = new HeadNode ("B");
HeadNode* C = new HeadNode ("C");
HeadNode* D = new HeadNode ("D");
B->Insert (new Edge (A)); // B "peger på" A
C->Insert (new Edge (A)); // C "peger på" A
D->Insert (new Edge (A)); // D "peger på" A
D->Insert (new Edge (B)); // - og B
D->Insert (new Edge (C)); // - og C
AdjacencyList.Insert (D); // opret selve grafen
AdjacencyList.Insert (C);
AdjacencyList.Insert (B);
AdjacencyList.Insert (A);
cout

virtual char* id () { return "B"; }
};
class C : public virtual A { };
class D : public B, public C { };
Hierarkiet ligner grafisk det fra figur 4-16. Nu forestiller vi os en implementation af forskellige
behandlinger på forekomster af én af klasserne, C:
void printID (C& c) {
cout

ubelejligt.
Hvis en klasse for eksempel implementerer en virtuel funktion, som udlæser objektets indhold
på en strøm, er det en naturlig ting for funktionen som det første at kalde baseklassens
udlæsningsmetoder. Er der mere end en baseklasse, skal de naturligvis alle kaldes, så hele
objektet kan blive udlæst. Men hvis der forekommer en virtuel klasse et sted i de gentagne kald til
baseklasserne, kan det ikke undgås, at den kaldes flere gange. For eksempel,
class A {
public:
virtual void readOut () {
cout

B
A
C
D
altså to gange A. Selv om klassen er virtuel, og således kun forekommer én gang i objektet, er
det altså ingen garanti for, at det ikke kan optræde flere gange i en logisk sekvens af
funktionskald eller lignende.
Der er flere måder at løse dette problem på, men de er som sådan ikke støttet af C++. Enten
kan en virtuel funktion, erklæret i den virtuelle baseklasse, bruges til kun at udlæse indholdet af
den aktuelle klasse i det komplekse objekt, mens en anden virtuel funktion også udlæser
baseklassens data. På denne statiske måde kan en multipelt afledt klasse kontrollere kaldene til de
virtuelle klasser. En anden mulighed er at lade den virtuelle klasse huske, om den er blevet kaldt
før, eventuelt med et katalog over this-pointere, der allerede er blevet behandlet. Den virtuelle
funktion deles op i to, en "hovedindgang", som først sletter kataloget og så kalder den anden
(eventuelt protected), der indsætter data i kataloget.
4.6 OPGAVER TIL KAPITEL 4
1. Udbyg eksempelet med himmellegemer fra afsnit 4.5.1, så planeternes måner også står i
Planet-objekterne, og tillad, at nyopdagede måner kan tillægges objekterne med tiden
(godt råd: brug LinkedList-klassen fra afsnit 3.10.1).
2. Skriv tegne og slettemetoderne i Figur-hierarkiet, så de rent faktisk tegner de
forskellige figurer grafisk på dit system.
3. Skriv en polymorf kø-klasse og stak-klasse, som tillader indsættelse af objekter af
forskellige typer (kig på LinkedList)
4. Hvad skal der til for at lade en polymorf kø indeholde stakke af objekter? Eller
omvendt?
5. Beskriv alle tvetydigheder ved arv.
7. Beskriv dynamisk binding. Prøv så at oversætte et kald til en virtuel funktion til C-kode
(eller hvad du nu har lyst til), som eksplicit foretager den dynamiske binding.
8. Udbyg Figur-hierarkiet med nye abstrakte klasser og multipel arv, således at der kan
skrives funktioner, der arbejder på figurer af forskellige arter.
9. Udbyg Figur-hierarkiet, så figurer kan ind- og udlæses på en strøm i
standardbiblioteket.
358 Multipel arv 4.5

4.7 REFERENCER OG UDVALGT LITTERATUR
Rationalet for udvidelse af C++ med multipel arv er beskrevet i [Stroustrup 87]. Dynamisk
binding i C++ beskrives af [Koenig 88]. [Lippmann 89] forklarer i detaljer om this, og
hvordan den har forskellige betydninger i nogle versioner af sproget. Generelt om arv henvises
også til litteraturen om Smalltalk og Ada.
4.5.9 Problemer med virtuelle klasser 359

Programkonstruktion
De mange facetter i et nyt paradigme og programmeringssprog er tit
uoverskuelige og forvirrende. De nye teknikker til implementation af abstrakte
datatyper, afledte klasser, polymorfi osv. giver anledning til en stor række
spørgsmål om programkonstruktion, som ikke kan besvares med syntaktiske
eksempler alene. Dette kapitel går i dybden med objekt-orienteret
programmering og fokuserer på konstruktion af rigtige programmer under det
ny paradigme.
5.1 INTRODUKTION
Programkonstruktion er en anden og mere bramfri betegnelse for programdesign. Denne bog
behandler ikke design i den traditionelle og formelle forstand, men beskriver de
problemstillinger, som programmering indebærer. En kort indføring i objekt-orienteret
programdesign vil dog ikke være af vejen.
Først kunne man stille det mere fundamentale spørgsmål, om hvad design i det hele taget er.
Softwaredesign går videre end blot det programmeringstekniske (uden dog at udelukke dette) og
fokuserer på problemer som programudvikling og -test, support og konfiguration, vedligeholdelse
og dokumentation, administration samt mange menneskelige aspekter. Et program er ikke blot
binære tal i computerens lager, det er også:
• en platform for videre udvikling, en slags videnbase for den person eller virkomhed,
som ejer det.
• et produkt, som skal kunne forbedres, konfigureres og understøttes under hele dets
levetid.
• en intellektuel udfordring, som skal løses på den bedst mulige måde, med de færrest
mulige ressourcer og på den kortest mulige tid.
• et arbejdsredskab, som skal kunne forstås og anvendes af brugerne.
360 Opgaver til kapitel 4 4.6
5

Kort og godt overlever et design ofte både hardware- og softwarespecifikationerne på et problem.
Seriøse applikationer bør designes før de programmers for at sikre, at budgetter overholdes og at
de bliver færdige til tiden. Selv om et færdigt program løser den nødvendige opgave, er det ikke
sikkert at programdesignet tillader mindre ændringer i koden uden at det bryder sammen. Det
forhold, at definitionen på programmet og dets anvendelse kan ændre sig under
udviklingsforløbet siger noget om, at man bør tænke fremad og arbejde dynamisk, så
programmeringen og teknikken ikke bliver bindende for resultatet.
Traditionel struktureret design lægger sig tæt op af det proceduralt orienterede paradigme, idet
programmet anskues i del-problemer, som igen kan brydes op i mindre komponenter. Man
arbejder top-down og fokuserer på programmets funktion fra start til slut. De mindste dele af
nedbrydelsen bliver direkte til globale eller modulært indkapslede funktioner. Der anvendes
desuden en teknik, der hedder data-flow analyse, som beskriver, hvordan data udveksles mellem
de enkelte dele af programmet for at sikre konsistensen og berretigelsen af disse. Top-down
filosofien er en direkte dekomposition af det enkelte program, og arbejder på den måde efter en
model, som anskuer ethvert nyt program som en ny opgave, uden at indeholde muligheder for
hverken teknisk eller konceptuelt at drage fordel af erfaringer fra tidligere projekter. I det hele
taget er struktureret design en abstraktion fra det rent tekniske, idet der tages mest hensyn til
udviklingsproblemer, konsistens og problemanalyse.
Som sådan er strukturerede metoder ganske gode og bruges i vid udstrækning. De opgaver, der
stilles under en struktureret udviklingsproces er, i grove træk, følgende:
1. Analyse: Analysér programmets funktion og beskriv dets virkemåde fra start til slut i et
tekstuelt design.
2. Funktionel nedbrydning: Identificér programmets funktionelle bestanddele, og gentag
denne proces indtil de atomiske (ikke-delelige) programstumper er fundet.
3. Data-flow analyse: Identificér dataudvekslingen mellem de enkelte dele og skriv
datastrukturer til at indeholde disse data.
4. Implementering: Skriv funktioner til de enkelte dele, som behandler datastrukturerne
samt modtager og afsender dem til hinanden som parametre og returværdier.
Der er imidlertid nogle - omend ikke fatale - mangler ved en denne model, specielt når den
sammenlignes med objekt-orienterede principper. For det første tages der meget lidt hensyn til
genbrug af eksisterende kode og data, hvilket er den største udfordring i fremtidens udvikling.
Problemerne, som skal løses, bliver næsten eksponentielt større, og med en ensartet, top-down
fremgangsmåde bliver forbruget af ressourcer uacceptabelt. Som konsekvens af dette bliver
metoden meget statisk i sin grundvold. Hvis programmets design behøver modifikation midt i et
projekt, er det svært at konfigurere designet uden store kvaler.
Grunden hertil er, at struktureret design resulterer i meget specialiserede kodestumper, som er
svære at genbruge i nye programmer. De generelle dele af strukturelt designede programmer er
sjældent meget mere end "klister-funktioner", som indeholder et antal kald til mere specielle
funktioner, men som ikke selv indeholder egentlig funktionalitet. Ved at ændre på disse
5.1 Introduktion 361

funktioner opnår man blot en ombytning af sekvensen i programmet. Nu ville det være
vidunderligt, hvis jeg kunne udnævne objekt-orienteret design til at være redningen. Desværre er
formel objekt-orienteret design på et meget tidligt stadie, og er genstand for megen diskussion og
forskning. Min fortolkning af dette er, at der i dag ikke findes reelle metoder til objekt-orienteret
design. Selv om litteraturlisten indeholder glimrende forslag, er ingen af dem bredt accepterede
endnu. Der findes for eksempel ingen standarder for klassebiblioteker eller design af
klassebiblioteker. Derfor vil jeg fokusere på programkonstruktion på en programmeringsteknisk
baggrund, og prøve at løse nogle af design-problemerne med eksempler på, hvordan det objektorienterede
paradigme giver os nogle guldkorn at arbejde med.
Under objekt-orienteret programkonstruktion bør man gå frem efter følgende retningslinier:
1. Dekomposition: Analysér programmets nøglekoncepter, uden hensyntagen til
eksekveringssekvens eller data-flow. Koncepterne er programmets byggestene og er
analoge til dets klasser.
2. Specialisering: Identificér klassernes attributter, dvs. indhold af data, samt deres
opførsel, dvs. deres grænseflader til omverdenen.
3. Differentiering: Identificér klassernes indbyrdes relationer og beskriv disse ved arv eller
instantiering.
4. Rekomposition: Identificér eksisterende klasser, som kan genbruges som baseklasser
eller instanser.
Denne model (som bliver uddybet i afsnit 5.9) er fundamentalt anderledes fra den strukturerede
på to punkter: den følger ikke en vertikal, funktionelt nedbrydende sekvens og den indeholder
store muligheder for genbrug af eksisterende kode. Uanset hvor langt objekt-orienteret design er
kommet i dag, er det et faktum, at der ikke er tale om top-down dekomposition. Det kan heller
ikke siges at være en bottom-up model, da der arbejdes med både abstraktion, konception og
baseklasser. En god definition findes faktisk ikke, men jeg er tilbøjelig til at kalde udviklingen for
here-and-there, fordi modellen afspejler en ikke-sekventiel udvikling. Objekt-orienterede
programmer udvikles ved en inkremental, iterativ proces, hvor de enkelte bestanddele vokser,
som de har brug for. De fire ovennævnte punkter skal altså ikke ses som en opskrift, men som fire
uafhængige retningslinier, som optræder igen og igen under designet. De to væsentligste
betydninger af en sådan udviklingsproces er, at
1. jo mere eksisterende kode, der kan genbruges, des mere tid kan der bruges på
arbejdsområder som design, udvikling og programmering. Objekt-orienterede
programmer er tillige lettere at vedligeholde på grund af deres opbygning med
dataskjulning, implementationsuafhængighed og klare grænseflader. Tiden kan bruges
på mere spændende og produktive opgaver.
2. inkrementaliteten muliggør en flydende transition fra prototype til færdig applikation.
Det er til alle tider muligt at ekstrahere programmets byggestene og skabe et kørende
362 Introduktion 5.1

program, der kan testes. De ofte benyttede "milepæls-versioner" af programmer mister
deres betydning som del af designet.
I projekter med mange programmører giver objekt-orienteret programmering meget store
fordele i form af privatisering af data. Anskues hver programmør som en klient for alle de andre,
og skjuler hver programmør sine egne implementationsdetaljer fra klienterne, er de alle så at sige
teknisk uafhængige af hinanden, så længe der findes en veldokumenteret protokol til
kommunikation mellem programmets klassebestanddele. I sprog som C++ er denne teknik en
integreret del af sproget som sikrer helt ned i koden, at ingen kan få våde fødder i andres
domæner.
Objekt-orienteret programmering er en teknik, som kan gøre gode programmører brilliante,
men dårlige programmører elendige. Det bunder i, om hele paradigmet er forstået, og ikke blot
den syntaks, der udgør et bestemt sprog. Problemet med softwaredesign er, at et design alt for
ofte bliver forældet, fordi det ikke opdateres gennem og efter projektets udførelse. Programmører
er mere interesserede i at programmere, og administratorer er mere interesserede i at få et færdigt
produkt. Som værktøj giver objekt-orienterede systemer en usynlig gevinst i denne sammenhæng,
fordi dataskjulning og indkapsling af kompleksitet kan tillade, at der skrives program før design
uden at det har en fatal effekt på projektets succes.
5.2 HVORNÅR SKAL MAN BRUGE OBJEKTER?
Det ses ofte, at et paradigmeskift leder til et uhensigtsmæssigt programdesign, fordi de nye
begreber ikke kan ses i sammenhæng med gængse metoder. Der er således tidspunkter, hvor
objekter er meget brugbare og tidspunkter, hvor de ikke har så megen relevans. Når man tager et
nyt begreb som OOP op, er det nødvendigt at kunne skelne mellem de fordele, som de nye
muligheder giver og de gamle metoders effektivitet. Objekter har deres store fordel i
modularisering af data på en konsistent, sprog-understøttet facon, og er ikke en universalløsning
for alle problemer.
5.2.1 Overvejelser om klasser
Hvordan skal man stille sig overfor et problem, når man har klasser som redskab? Den enkleste
måde er at følge de fire retningslinier fra introduktionen i dette kapitel, men der findes også nogle
"læresætninger", som letter forståelsen af, hvornår programmering med klasser gavner designet.
Brug klasser til repræsentation af virkeligheden.
Klasser er perfekte til en direkte implementation af de begreber, som programmets byggestene
repræsenterer. Ved at modellere programmet med klasser, som kan anskues analogt til den
abstrakte, eksterne forståelse af dem, bliver programmets opbygning let at forstå, og designet
5.1 Introduktion 363

eflekteres direkte i koden. Som beskrevet i afsnit 3.3 gør klassernes egenskaber i form af
indkapsling af både data og metoder, at de kan have samme mening både logisk og fysisk som
den virkelighed, de repræsenterer. Klassens data er virkelighedens fysiske attributter, mens dens
metoder er virkelighedens opførsel.
Brug klasser til at skjule kompleksitet.
Klasser indkapsler rent teknisk data og metoder, men i en større sammenhæng skjuler en klasse
med mange data og mange metoder en del af programmets kompleksitet, og skaber en navngiven
fællesnævner for denne. En opdeling af programmet efter dets enkelte bestanddele isolerer de
dele af koden, som har - og i yderste konsekvens kun har - noget at gøre med én bestemt
bestanddel. Resten af programmet kan overlade de nærmere detaljer til klassen, som altid er i
stand til at udføre en opgave, der har relation til klassen selv. Den egenskab at kunne skjule data
fra klienten, og dermed gøre ekstern kode uafhængig af klassens implementation giver klienten
langt større frihed og langt mindre ansvar. Det er til enhver tid muligt at ændre på den enkelte
klasses data, uden at dette har den mindste betydning for, om klientkoden kan oversættes. Dette
betyder, at programmet behøver færre globale modifikationer, og at en fejl lettere kan isoleres til
en bestemt klasse.
Brug klasser til at skabe bedre grænseflader.
En klasse er en udvidelse af reglerne for skop. Hver klasse kan have samme syntaks for
relaterede metoder, som gør forståelsen for klassen i en større sammenhæng meget bedre. Uanset
hvilken klasse der arbejdes med, kan metoder af samme navn altid være en fællesnævner for den
samme operation på alle klasser. Således kan metoder for ind- og udlæsning have samme navne i
alle klasser, hvilket gør det lettere at arbejde med dem. Den implementation af klasser, som C++
indeholder, giver mulighed for en meget bred beskrivelse af klassernes grænseflader udadtil. De
fleste datatyper kan med gavn gøre brug af brugerdefinerede overstyringer af standardoperatorerne,
så klienten kan arbejde med naturlige udtryk i forbindelse med forekomster af
klassen.
Brug klasser til sikkerhed for initiering og oprydning.
Et fundamentalt, programmeringsteknisk problem som datakonsistens er det nødvendigt at løse
på en sikker måde, hvis programmet skal fungere korrekt. I objekt-orienterede systemer arbejdes
ofte med såkaldte forudsætninger for og følgevirkninger af objekters instantiering, hvilket vil sige
de usynlige operationer, der skal udføres før objektet kan tages i brug samt ved endt brug. I
traditionelle, proceduralt orienterede programmer er sikkerheden for korrekt initierede og
opryddede data dårlig, fordi det er klientens ansvar at kalde specielle funktioner til at udføre
opgaverne. Ved brug af konstruktører og destruktører lægges dette ansvar over på klassens
udbyder, som dermed kan være sikker på klassens datakonsistens.
364 Hvornår skal man bruge objekter? 5.2

Brug klasser til et bedre udviklingsmiljø.
En konsekvens af indkapsling, dataskjulning og udvidet kontrol med modulære data er, at
udviklingsmiljøet bliver lettere at arbejde med. Projekter med mange involverede programmører
drager mange fordele af et bedre udviklingsmiljø, fordi hver programmør kun har ansvar for sine
egne klasser, dens indre data og metoder samt dens grænseflade til resten af programmet.
Udviklingsmiljøet giver alle større produktivitet i og med, at de ikke er teknisk afhængige af
hinanden. Det viser sig også, at programmering med klasser resulterer i langt mindre stumper af
kode, som er lettere at overskue og arbejde med. Forståelsen for det enkelte programmodul,
klassen, er meget højt. Kildeteksten bliver på den måde mere organiseret, både på grund af en
mindre kompleksitet og også fordi polymorfi tillader isolering af kode, som arbejder på en
bestemt klasse i samme modul eller fil. Alt dette har betydning for udviklingsmiljøet, som bliver
mere overskueligt og gavner administrationen af et projekt.
Brug klasser til genbrug af kode.
Som nævnt i introduktionen er software-genbrug †
den største udfordring i morgendagens
programmering. Det nytter ikke længere, at hvert projekt opfattes som en ny opgave, som skal
løses fra bunden. Hvis vi skal kunne gøre os forhåbninger om nogensinde at blive færdige med de
kæmpesystemer, vi står overfor at udvikle, må vi i stedet anskue et projekt som en udvidelse eller
modifikation af et tidligere projekt. Programmering med klasser og arv mellem klasser er en
hjørnesten i OOP til at løse genbrugsproblemet på en generel måde. Findes en klasse, der udviser
en funktionalitet, som minder om den ønskede, kan en ny klasse konstrueres og afledes fra denne,
hvorefter forskellen kan udtrykkes ved omskrivning af de metoder, der afviger fra baseklassen til
den ny afledte klasse. Denne teknik kaldes ofte for differentialprogrammering, fordi opgaven
består i at differentiere én klasse fra en anden. Denne teknik åbner desuden nødvendigheden af
generelle klasser, som har en funktionalitet, der er fællesnævner for et stort antal klasser i et
program, men som ikke nødvendigvis selv skal bruges til noget konkret. Generelle klasser
fungerer som byggesten i programmeringen, og gør udviklingen af en ny klasse lettere, fordi
mange metoder allerede findes til den ønskede opgave. Skabeloner (afsnit 3.8) er en endnu mere
tilgængelig mekanisme for direkte genbrug, fordi den parametiserer typer og ikke objekter.
Brug klasser til udvikling af generisk kode.
Som udvidelse af genbrugs-princippet ligger generisk kode som den funktionelle efterfølger.
Generisk kode er funktioner, som ved udviklingen er skrevet med fremtiden i tankerne. En
† Genbrug af kode skal forstås på den måde, at tidligere skrevne programmer og udarbejdede designs kan anvendes
igen uden (væsentlige) problemer. Der sigtes ikke mod genbrug af kode, der er smidt væk - den engelske term er reuse
og ikke re-cycling - kode, der er kastet bort, vil sjældent kunne genbruges, men rettere mod kode, der kan
anvendes igen og igen i forskellige sammenhænge.
5.2.1 Overvejelser om klasser 365

generisk funktion arbejder således med objekter, hvis egentlige typer ikke er kendt på det
tidspunkt, funktionen oversættes. Det tillader os at udvide programmet med nye klasser, som kan
indgå og bruges af de generiske funktioner uden at disse behøver modifikation. På den måde kan
en stor del af et projekt skrives, så det ikke er afhængigt af bestemte typer, men overlader dette til
oversætteren og miljøet. Generiske metoder er mulige via polymorfe metodekald, som i C++
implementeres som virtuelle funktioner i klassers arvefølger. Her er det vigtigt at forstå, at
polymorfi ikke er et redskab i selve klasserne, men en egenskab, de har overfor klientkoden.
Polymorfi skal altid ses udefra, og når der skrives virtuelle funktioner er det vigtigt at tænke på
klassens indhold, funktionalitet og grænseflade i forhold til både klienten og til de klasser, som
skal nedarve fra den. Generisk kode repræsenterer således også genbrug, omend på et andet plan
end arv.
Brug klasser til modulærprogrammering.
Modulærprogrammering er programmering med indkapslede data og funktioner i moduler, en
teknik som sædvanligvis er baseret på filen som et modul. Det er dog de færreste sprog, som i sig
selv understøtter moduler med en udvidet syntaks for skop-kontrol og adgang, der er nødvendig
for, at alle holder sig til reglerne. Klasser er oplagte til en modulær opbygning af programmer,
fordi klassens typenavn kan bruges direkte i koden som reference til det ønskede modul. Den
umiddelbare fordel ved modulærprogrammering er, at globale data elimineres fra programmet.
Globale data har den ulempe, at alle dele af programmet har adgang til dem, og at en fejl i disse
data dermed er svær at lokalisere arnestedet for. Modulærprogrammering i C++ foretages oftest
som udvikling af datastrukturer, der indeholder statiske data, og som derved sætter navn på de
data, der i en given situation er tale om.
Brug klasser til indkapsling af funktionsbiblioteker.
Teknikken for modulærprogrammering kan bruges i forbindelse med paradigmeskift, så
eksisterende funktionsbiblioteker kan integreres i det nye miljø. Et bibliotek som C's
kan med fordel indkapsles i et antal moduler, som relaterer de forskellige metoder
med et overordnet navn og et par eventuelle ekstra metoder og overstyringer af operatorer. På den
måde får det eksisterende bibliotek mulighed for at overleve skiftet til OOP, og kan stadig bruges
fornuftigt.
Brug klasser til sikring af flytbarhed.
Ved at indkapsle hardware-afhængigheder i modulære klasser, så klasserne selv har ansvar for
maskinspecifikke operationer, sikrer de klientkodens flytbarhed fra en platform til en anden.
Sålænge klienten støtter sig til klassen, når de sensitive funktioner skal kaldes, vil en ændring af
366 Hvornår skal man bruge objekter? 5.2

operativsystem, skærmtype, printer, disk, processor osv. kunne beskrives i klassen uden fare for,
at klientens kode bryder sammen. Dette er et meget illustrativt og konkret eksempel på
nødvendigheden af implementationsuafhængighed.
Brug klasser, når der er brug for mere end én forekomst.
Den enkleste definition af, hvornår en ny klasse skal introduceres er, når et program viser
symptomer på redundante datastrukturer eller lignende funktioner. Har et program for eksempel
mere end én definition på en hægtet liste, mange behandlinger af streng-variable, sortering af data
på forskellige måder eller blot et forhold mellem to dele af programmet, kan de næsten altid
indkapsles i klasser. Før i tiden var klasser noget, der blev opfattet som meget store byggestene i
programmerne, og der skulle meget til, før en del af programmet blev isoleret i en klasse. Faktisk
blev langt de fleste C++-programmer essentielt skrevet som C-programmer med kun de største og
vigtigste datastrukturer indkapslet med bredt definerede metoder. Mindre grupper af klasser giver
imidlertid et objekt-orienteret system den egentlige funktionalitet, så vig absolut ikke tilbage for
at introducere nye klasser selv for en minimal del af programmet.
Vær kreativ, men ikke over-kreativ, med klasser.
Programmering med klasser appellerer til programmørens kreativitet i langt højere grad end
programmering med isolerede funktioner og datastrukturer. Idet grænsefladen mellem klassen og
klienten kan beskrives i meget udførlige detaljer, er det klassedesignerens opgave at skrive denne
så fyldestgørende som muligt. En sideeffekt ved dette er, at klasser ofte har alt for mange
behandlende funktioner, specielt overstyrede operatorer, i forhold til, hvor meget de bruges
udefra. Til gengæld giver de klienten frihed, fordi de under alle omstændigheder findes. En god
retningslinie er, at kun de operationer, der er brug for, når klassen skrives, bør medtages i den.
Resten kan tilføjes senere, hvis der er brug for dem.
5.2.2 Fremgangsmåder
Nu er spørgsmålet hvordan man udfra en idé kommer frem til et klassedesign. Klassens design er
ikke blot afhængigt af, hvordan den opfører sig og hvilket indhold den har, men også hvad den
egentlig repræsenterer. Der er visse kendetegn at se efter, men først skal der ridses to
hovedområder op, som har betydning for opbygningen af klassen:
• hvad er klassens attributter, eller med andre ord, hvad repræsenterer klassen? I mange
situationer er dette spørgsmål ligegyldigt, fordi klassens data altid er startpunktet, men
ofte kan en ekstern brug af klassen tilskynde en anden datarepræsentation. Klassen
Koordinat fra afsnit 4.2.2 er et eksempel på dette, idet denne klasse ville kunne
fungere fint med en intern repræsentation med heltal, men hvor en senere brug i
5.2.1 Overvejelser om klasser 367

transformationer nødvendiggør kommatal.
• hvad er klassens opførsel, eller med andre ord, hvordan skal klassen bruges set fra
klientens side. Igen har det relation til klassens egentlige idé, da de metoder, som
klassen udbyder, skal være nært forbundne med klassens repræsentation. Når man
skriver medlemsfunktioner er det en god idé altid at have klientens program i
baghovedet, og eventuelt skrive et lille test-program, som benytter klassen. Opførsler
som returværdityper, parametertyper, underforståede parametre, konstante og statiske
metoder samt overstyringer af operatorer er alle bestemmende for, hvor god klassen er i
brug.
Man kan sige, at klasser altid sætter funktion over form, fordi implementationen skjules fra
klienten, som må gå gennem grænsefladen i stedet. Derfor er klassens attributter relateret til
implementationen af klassens metoder, mens klassens grænseflade er relateret til klientens kode.
Nu følger nogle retningslinier for, hvilke spørgsmål der gør sig gældende under konstruktionen af
en klasse:
• Repræsenterer klassen et fysisk eller et konceptuelt begreb? Konceptuelle begreber egner
sig bedst som abstrakte klasser med rene virtuelle metoder og til polymorf ekstern brug.
• Er klassen kendetegnet som aktiv eller passiv, dvs. er klassen en del af kernen i
programmet, eller udfører den en simpel, generel funktion? Aktive klasser er som regel
større og har tendens til at være fritstående - for eksempel en klasse, der behandler en
seriel port - mens passive klasser er små og ofte indgår i et klassehierarki.
• Hvad repræsenterer klassens indhold i forhold til programmet, der bruger klassen?
Relevansen er, at en forekomst af en klasse kan have forskellige levetider, afhængig af,
hvad den repræsenterer. Der findes tre fundamentale levetider for objekter: midlertidige,
permanente og bestandige. Et midlertidigt objekt allokeres og fjernes dynamisk under
kørslen, og tilskynder en lille, operationel klasse med hurtige konstruktører og
destruktører. Permanente objekter er statisk allokeret, dvs. har sit skop fra programmets
starter til det slutter, og der findes sædvanligvis kun ét objekt - eller en vektor af
objekter - af en bestemt klasse. Permanante objekter giver dermed anledning til klasser,
som kan have store konstruktører og destruktører, flere statiske medlemmer, og som har
en eller få forekomster i applikationen. Bestandige objekter har en ubegrænset levetid,
kun afbrudt af en bestemt operation i programmet. De eksisterer altså på et ydre lager,
når applikationen ikke kører. Sådanne objekter har normalt en meget stor
repræsentation, og indeholder metoder for ind- og udlæsning af data, som eventuelt er
implementeret i konstruktøren og destruktøren. Bestandighed (eller persistens) har stor
anvendelse i databasesystemer, og behandles i afsnit 5.6.
• Repræsenterer klassen et helt eller et delt begreb? En hel (også kaldet afsluttet) klasse
har for det meste en gennemført grænseflade, har ingen rene virtuelle funktioner og en
public-erklæret konstruktør. En delt klasse har det meste af sin funktionalitet fra en
368 Hvornår skal man bruge objekter? 5.2

aseklasse, og har indtil flere "søskende-klasser", som også er afledt fra denne base. Den
delte klasse deler funktionalitet og/eller data med hinanden gennem baseklassen. I afsnit
5.3.1 gennemgås nogle retningslinier for, hvordan man afgør om en klasse er delt eller
ej.
• Repræsenterer klassen et generelt eller et specifikt emne? En generel klasse bør
indeholde (eventuelt rene) virtuelle funktioner, og ofte ikke mange datamedlemmer. En
specifik klasse kan ofte arves fra en generel klasse, og udbygge/omskrive/implementere
funktionerne i denne.
• Hvem er klassens klient? Hvis klassen kun har én klient, for eksempel en anden klasse,
bør den skrives som privat klasse. Klienten erklæres som friend i klassen, og der
skrives ydermere en konstruktør, som ved at være privat eller beskyttet sikrer, at ingen
andre end den ønskede klient kan instantiere objekter af klassen. Klassen Node fra
afsnit 3.10.1 er et eksempel på en sådan klasse. Både klasser og specifikke funktioner i
klasser kan erklæres som friend. På den måde kan en klasse skrives til en helt
specifik opgave, som kun vedrører en bestemt funktion eller klasse, uden at skabe
forvirring andetsteds. Klassen Node kan for eksempel ikke ses af LinkedLists
klient, som slet ikke mærker Nodes eksistens.
Med disse overvejelser kan vi opfylde de første generelle retningslinier for objekt-orienteret
konstruktion, nemlig identifikation af klassens koncepter, dens repræsentation og grænseflade.
5.2.3 Organisering af kildetekst
Som beskrevet i afsnit 2.2 er udviklingsmiljøets faciliteter bestemmende for, hvor let udviklingen
kan forløbe. Dog er den fysiske organisering af kildeteksten det første, der skal være i orden.
Kildeteksten bør opdeles i flere moduler eller oversættelses-enheder, som normalt er det samme
som filer på systemet. Et enkelt modul er logisk opdelt i to filer:
• en specifikation, som indeholder klasseerklæringen, konstanter, typedefinitioner og
eventuelle makroer og inline-metoder. Specifikations-filen, eller header-filen, som den
også kaldes, medoversættes i alle andre moduler af programmet, som bruger netop dette
modul.
• en implementation, som indeholder koden for klassens metoder, initiering af statiske
medlemsvariable og eventuelle lokale variable i modulet.
Denne opdeling sikrer, at alle moduler, som benytter sig af et bestemt eksternt modul, alle vil
følge samme specifikation. Dette gælder også for det eksterne moduls implementation selv. Et
enkelt modul bør kun indeholde én klasse eller få meget tæt relaterede klasser. Tæt relaterede
klasser er friend-klasser (som for eksempel String og Substring fra afsnit 3.7.1) eller
private klasser, men ikke arvede klasser. Et modul, som benytter klasser, som findes i andre
moduler, må ved hjælp af præprocessorens #include-direktiv indlæse specifikationen på disse
5.2.2 Fremgangsmåder 369

klasser. Figur 5-1 viser, hvordan de fire klasser fra afsnit 4.5.3 opdeles i specifikationer (.h-filer)
og implementationer (.cpp-filer). Stregerne mellem kasserne beskriver et #include-forhold
opefter.
De enkelte moduler i LinkedList-hierarkiet indeholder følgende direktiver og erklæringer
(klassernes kroppe samt metodernes implementationer vises ikke):
// linkedlist.h
class Node { /* ... */ };
class LinkedList { /* ... */ };
// linkedlist.cpp
#include "linkedlist.h"
// indexedlist.h
#include "linkedlist.h"
class IndexedList : virtual public LinkedList { /* ... */ };
// indexedlist.cpp
#include "indexedlist.h"
// sortedlist.h
#include "linkedlist.h"
class SortedList : virtual public LinkedList { /* ... */ };
// sortedlist.cpp
#include "sortedlist.h"
// sortedindexedlist.h
#include "indexedlist.h"
#include "sortedlist.h"
class SortedIndexedList :
public IndexedList, public SortedList { /* ... */ };
// sortedindexedlist.cpp
#include "sortedindexedlist.h"
370 Hvornår skal man bruge objekter? 5.2

Figur 5-1: Afhængigheder mellem moduler i LinkedList-hierarkiet.
Erklæringerne i specifikationsfilerne indeholder alle klassernes metoder som prototyper samt
eventuelle offentlige datamedlemmer. Klassens erklæring i specifikationsfilen bliver dermed
udgangspunktet for den eksterne definition af dens brug for klienten. Ved at undersøge klassens
specifikationsfil kan klitenten se, hvordan grænsefladen er bygget op, og kan dermed danne sig et
indtryk af, hvordan klassen bruges. Dokumentationen af en klasse bør derfor være grundlag i
klassens specifikation, og beskrive de enkelte dele i denne udførligt, hvilket behandles i nærmere
detaljer i afsnit 5.10.
En klasses specifikation bør derfor følge et ensartet mønster. De forskellige dele af klassens
5.2.3 Organisering af kildetekst 371

erklæring bør opdeles i klart afgrænsede dele i kildeteksten, så det er muligt for en klient at se
hvad, der er hvad. Det forhold, at klassens implementation skinner igennem i specifikationen ved
private datamedlemmer og metoder gør, at der er en smule unødvendig information, som skal
være let at filtrere fra. En opdeling kan tage udgangspunkt i de forskellige grænseflader, en klasse
har:
// klasse.h
// --------- afhængigheder -----------------
#include-direktiver
// --------- ekstern specifikation --------class
klasse {
friend-funktioner
friend-klasser
public:
konstruktør(er)
destruktør
konverteringsmetoder
offentlige metoder
// --------- reserveret specifikation -----protected:
konstruktør(er)
beskyttede metoder
datamedlemmer
// --------- intern specifikation ---------private:
konstruktør(er)
private metoder
datamedlemmer
};
inline metodeimplementation(er)
// klasse.cpp
metodeimplementation(er)
Ved at opdele klassen på ovenstående måde i selve kildeteksten kan en bruger af klassen finde de
relevante oplysninger fra specifikationsfilen i en fart. De fire dele af specifikationen udgør
henholdsvis:
• Modulets eksterne afhængigheder, dvs. de specifikationsfiler, som det aktuelle modul
enten arver fra eller benytter som forekomster, indirekte referencer, friend-
372 Hvornår skal man bruge objekter? 5.2

funktioner eller direkte funktionskald. Den eksterne afhængighed fortæller noget om,
hvad specifikationen bruger udover erklæringerne i den aktuelle klasse.
• Klassens eksterne specifikation, dvs. den grænseflade, som den har mod klientens kode.
Når klienten skal bruge en bestemt klasse, skal denne sektion altså refereres, og intet
andet.
• Klassens reserverede specifikation, dvs. den grænseflade, som den har mod afledte
klasser. En klasseudbyder, som vil bruge den aktuelle klasse som baseklasse skal altså
referere til denne sektion i specifikationen.
• Klassens interne specifikation, dvs. klassens implementation af datamedlemmer og
private metoder. Den interne specifikation og implementation har kun relevans for
klassens udbyder, og er både en del af specifikationsfilen og implementationsfilen.
I mange henseender kan der være flere klasser i samme modul, hvilket vil være tilfældet for
klasserne String og Substring samt for Node og LinkedList. I andre sprog, som
støtter modularisering i højere grad end C++, er det muligt fuldstændigt at skjule
implementationen og den interne specifikation fra klienten, så denne slet ikke kan se de elementer
af modulerne, som ikke er vedkommende. I C++ er en mulig løsning via operativsystemet at
tillade skrive-adgang til et modul alene for den bruger, som er udbyder af klassen eller klasserne i
modulet. Det er givet, at en stor udfordring indenfor CASE-teknologien er udvikling af redskaber
til behandling af klassespecifikationer, så de kan lagres i en central database og indgå i
udviklingsmiljøet.
5.3 ORGANISERING AF KLASSER
Isolerede klasser, og metoderne for udvikling af isolerede klasser, har størst anvendelse som
abstrakte datatyper i enten numerisk form eller som parallel til de fundamentale typer, hvor de
udnytter den første objekt-orienterede hovedingrediens, indkapsling, og drager fordel af
implementationsuafhængigheder. I den større sammenhæng må klasserne imidlertid organiseres,
så de udnytter de to andre basiselementer, arv og polymorfi, og realiserer genbrugelighed og
udvikling af generisk kode. Men organisering af klasser handler ikke blot om arv og polymorfi.
Klasser kan relateres til hinanden på mange forskellige måder, afhængigt af det forhold, som gør
sig gældende mellem dem. En forståelse for klassernes afhængigheder af hinanden er en vigtig
faktor i organiseringen af klasserne.
5.3.1 Overvejelser om arv
Ét er altså hvornår, der skal bruges klasser, et andet, hvornår der skal bruges arv. I de fleste
tilfælde vil arv være et redskab i en større sammenhæng, hvor flere klasser indgår i samme modul
eller sekvens af moduler, eventuelt fordelt på flere programmører. Andre gange vil arv ikke være
5.2.3 Organisering af kildetekst 373

en direkte og åbenlys del af designet, hvorfor der er nogle regler at følge:
• Når en ny klasse introduceres, bør det eksisterende klassebibliotek gennemgås og
efterses for eventuelle fælles træk. Hvis der allerede findes en klasse, som kan siges at
være et subset, dvs. en del af, den klasse der skal skrives, bør der nedarves fra denne
klasse. Den eksisterende klasse behøver ikke være et helt rent subset af den ny klasse, da
forskellene kan udtrykkes ved omdefinitioner af metoder.
• Når to klasser i programmet udviser fælles træk, bør en tredje klasse introduceres og
benyttes som baseklasse for disse to klasser. Der er to fundamentale årsager til denne
regel: for det første kan de to klasser deles om både data og metoder i baseklassen, som
derfor ekstraherer kompleksitet fra de to afledte klasser, og for det andet betyder det
faktum, at der er to kongruente klasser i programmet, at der med stor sandsynlighed på
et tidspunkt kommer flere klasser, som også viser sammenfald med disse. Derfor gælder
denne regel også for grupper af klasser. En baseklasse vil derfor være en udmærket
sikkerhed for en reduktion af redundans.
Når der arves, er der flere hensyn at tage for at sikre, at det er en korrekt klasse, der bruges som
base. Opdelingen af kildetekstens specifikationsfil er faktisk ikke fyldestgørende, fordi der er
andre elementer end blot klassens interne specifikation, som har betydning for den afledte klasse.
Således kan offentligt arvede metoder være uønskede i den ny klasse ligesom privat arvede data
måske ikke har relevans. En definition af, hvad "fælles træk" er, vil derfor være på sin plads:
• Hvis to klasser har samme data, bør disse data og de metoder, der udelukkende arbejder
på dem skrives om i en baseklasse. Det betyder ikke, at alle data skal være ens, men blot
at en del af klassernes implementationer er de samme. Hvis den ene klasse bliver "tom"
af en sådan omfordeling, bør denne klasse blot være baseklasse for den anden.
• Hvis to klasser bruger den samme globale funktion, eller har ens implementerede
medlemsfunktioner, bør disse funktioner skrives om i en baseklasse. Baseklassen får
karakter af en proces-klasse, som blot indeholder funktionalitet og ikke data.
• Hvis to klasser afspejler den samme brug, dvs. hvis de fra klientens side har meget ens
grænseflader, bør denne grænseflade beskrives i en baseklasse. Hvis de to klasser er for
forskellige til, at baseklassen kan implementere metoderne, bør de erklæres virtuelle i
baseklassen og forblive uændrede i de afledte klasser. Dermed tillades klienten at
benytte de to klasser polymorft, hvilket der er gode chancer for, når de demonstrerer det
samme mønster i grænsefladen.
• Hvis programmets logiske sekvens ser ud til at ville bestå af mange betingelser med
konstante test-værdier (if-sætninger og specielt switch/case-strukturer), bør disse
sekvenser erstattes af virtuelle kald og værdierne med afledte klasser. Et fælles træk er
altså ikke altid åbenlyst - der kan forekomme fælles træk i dele af et program, som slet
ikke indeholder klasser. En vigtig detalje at se grundigt efter er, om der foretages
374 Organisering af klasser 5.3

eksplicit type-kontrol i programmet, dvs. om en betingelse undersøger ét af mange
specielle forhold ved en datastruktur eller andet. Sådanne betingelser har det med at
være centrale, og vil være genstand for regelmæssige modifikationer. Ved erstatning
med polymorfe metoder (se afsnit 4.4.6) bliver ansvaret for typekontrollen lagt over på
oversætteren, og alle de behandlende led decentraliseres.
• Hvis to klasser udviser type-ækvivalens. Dette er nok det vigtigste, fordi det tillader
klienter af klasserne at blande dem sammen i deres kode. Type-ækvivalente klasser kan
kun identificeres ved betydningen af deres indhold. I afsnit 4.3.1 beskrives de forhold
ved type-ækvivalens, der gør arv til en præcis abstraktionsmekanisme for at udtrykke
forhold mellem klasser. Det handler om at identificere generelle og specifikke klasser og
opdele disse i hierarkier udfra klasernes semantisk. Vi kan faktisk sige, at hvis der findes
en kongruens mellem to klasser er det en helt klar indikation af nødvendigheden for arv.
Det sikrer nemlig, at klienten både kan opfatte og også i selve sproget behandle dem
som kongruente.
Programkonstruktion med arv har den bekvemmelighed, at programstumperne organiseres ved
analogi. Analogier er lette at forstå for mennesker, og slægtsskaber mellem klasser er både
overskuelige og elegante. Et lille minus er, at en baseklasse kan have mere eller mindre skjulte
egenskaber, som det ikke er hensigtsmæssigt at arve. Hvordan ser en dårlig baseklasse-kandidat
så ud? Igen er der flere kendetegn:
• Hvis baseklassen indeholder medlemsvariable, som ikke er nødvendige i den afledte
klasse, bør der ikke arves. Alle forekomster af den afledte klasse vil indeholde de
ligegyldige data, hvilket kan blive til en hel del. En mulig anden løsning er at skabe en
ny baseklasse, som beskriver forskellen mellem baseklassen og den afledte klasse, og
lade dem begge arve fra denne. Arv af unødvendige data er den største synd i objektorienteret
programmering.
• Hvis baseklassen indeholder metoder, som ikke er relevante i den afledte klasse, bør der
i reglen ikke arves. Udviser baseklassen denne forskel, er der som regel tale om en
klasse af en helt anden natur, hvis type-forhold til den aktuelle klasse er meget
afvigende. Hvis baseklassen på den anden side indeholder udelukkende relevante data i
forhold til den aktuelle klasse kan de unødvendige metoder fjernes fra klientens domæne
ved enten at arve privat (hvis det ikke skjuler andre nødvendige metoder fra klassen
selv), ved at omskrive dem til at udføre en anden funktion eller ved at reerklære deres
tilgang i den private del af klassen. Det sidste er normalt det bedste, og gøres på
følgende måde:
class Base {
// ...
public:
// ...
void Irrelevant ();
5.3.1 Overvejelser om arv 375

};
class Afledt : public Base {
// ...
void Base::Irrelevant (); // skjul metoden
public:
// ...
};
Hvis forholdet mellem de to klasser udviser disse symptomer bør en anden teknik tages i brug,
hvilket normalt betyder, at baseklassen må indgå i den afledte klasses implementation som
forekomst eller pointer-variabel. I næste afsnit beskrives de forskellige egenskaber ved og
forskelle mellem repræsentationer af objekter i en klasse og arv. Under arv bør man også stille
spørgsmålet, om hvornår baseklassen skal arves offentligt eller privat i den afledte klasse.
Generelt er svaret, at klasser designes med den tanke, at afledte klasser arver offentligt fra den, så
alle offentlige medlemmer i baseklassen også er offentlige i den afledte klasse. Privat arv bruges
således i to situationer: hvis den afledte klasse ikke har behov for tilgang til private eller
beskyttede medlemmer i baseklassen eller hvis den afledte klasses eventuelle efterfølgere ikke
skal tillades adgang til disse.
Det bringer os frem til spørgsmålet om, hvordan den aktuelle klasses medlemmer opdeles i
forskellige tilgangs-områder. Nøgleordet her er, at man bør være visionær, dvs. at tænke på
klassens mulige anvendelser i fremtiden:
• Skriv ikke metoder i klassen, som går ud over klassens egentlige anvendelsesområde.
Metoder, som gør klassen mere specifik, end den giver sig ud for at være, kan med
større fordel skrives i en afledt klasse. Begynd altid med generaliteten og lad
funktionaliteten vente til senere. Det er lettere at se, om programmet bevæger sig i den
rigtige retning, når de generelle komponenter er på plads. De detaljerede metoder kan
sagtens vente til senere, hvilket også mindsker sandsynligheden for, at de skal ændres
eller måske smides væk.
• Erklær altid klassens data i den private (eller beskyttede, se nedenfor) del af
specifikationen. Private data er ikke tilgængelige for klienten af klassen, og sikrer
dermed til en rimelig grænse konsistensen af objekter af klassen. Det betyder også, at
klassen til alle tider kan ændre implementation, fordi klienten går gennem metoder i
klassen for at få tilgang til de private data. Det er altså ikke blot et spørgsmål om formel
sikkerhed, men mere om frihed til at ændre på en del af et program i midten af et
projekt. Det kan betale sig at skrive bittesmå inline tilgangs-metoder til private data
i stedet for at lade klienten referere dem direkte.
• Tænk både på klienten og på eventuelle afledte klasser. Der er to formelle grænseflader
at tage hensyn til, nemlig den offentlige del til klienten og den beskyttede del til den
afledte klasse. Sørg for at erklære metoder og specielt data, som eventuelt vil have
fordel af at være tilgængelig fra en afledt klasse, beskyttet. Men pas på, at der ikke er
376 Organisering af klasser 5.3

tale om meget sensitive data, da en erklæring i den beskyttede del af klassen i princippet
ikke er mere "sikker" end i den offentlige: en klient kan blot arve fra klassen og
modificere de private data.
• Brug så få friend-funktioner som muligt. Den primære anvendelse af sådanne
funktioner er i sammenhæng med operator-overstyring, hvor en brug af den aktuelle
klasse som anden-operant og en fundamental type som første-operant tvinger
overstyringen til at være en global funktion (se afsnit 3.5.11). Hvis friend-funktioner
bruges i andre sammenhænge er det muligvis en svaghed i designet: for det første har
friend-funktioner ikke et underforstået objekt, hvorved de ikke kan bruges polymorft,
og for det andet distribuerer de klassens implementation til vilkårlige steder i
programmet. friend-klasser er derimod ofte brugbare i forbindelse med private
klasser, som ikke skal kunne ses af andre end netop de af klassen udvalgte. Men husk
på, at en friend-klasse ikke nedarves. En afledt klasse har ikke nogen form for
adgang til baseklassens friend-klasser.
En overvejende del af de forslag til objekt-orienteret design som er publiceret til dato, ser
objektet som det centrale element. Det kan imidlertid være gavnligt at se et enkelt element som
en organiseret klynge af klasser, som spreder kompleksiteten fra selve elementet ud i de enkelte
klasser. Den normale læresætning, når objekterne i et system skal identificeres, er at klasserne
allerede har en definition i den konceptuelle beskrivelse af systemet. Klasserne er med andre ord
til at plukke fra det tekstuelle designs indhold. Denne metode tager, selvom den fungerer fint i
praksis, ikke hensyn til klassernes brug set fra klientens side. Det er en alt for ofte begået fejl, at
klassebiblioteket opbygges udfra klassernes interne funktion, uden egentlig hensyntagen til deres
reelle brug udefra. Når man som klassedesigner arbejder med et design er klassens anvendelighed
det vigtigste. Ellers bliver resultatet en stor mængde klasser med alsidig, dog isoleret,
funktionalitet. Det er nødvendigt, at der tages hensyn til klassernes samspil under
programkonstruktionen, hvis det endelige resultat ikke skal løbe ud i sandet.
Således er arv en teknik, som kan bruges i sammenhænge, hvor fordelen egentlig ikke er særlig
stor. Hvis klassehierarkiet består af en mængde container-klasser (klasser, som indeholder andre
objekter), hvis indhold nedefter i hierarkiet blot udbygger den overordnede klasse med et par
objekter og et par tilgangs-metoder til disse objekter, er det objekt-orienterede aspekt gået fløjten.
Indkapsling bliver ligegyldig, fordi klientens billede af den enkelte klasse er defineret af klassens
indhold og ikke af dens funktionalitet. Polymorfi bliver heller ikke brugt, fordi klienten altid
arbejder på enkelte forekomster af klasserne. I situationer, hvor container-klasser blot indeholder
objekter og tilgangsmetoder til disse objekter gør objekt-orienteret programmering intet positivt
og er bedst udeladt.
Lad os tage et eksempel. Vi tænker os et par klasser til definition af rapport-generering til et
administrativt system, som skal kunne behandle videnskabelige, administrative og interne
rapporter. En typisk arvefølge på en sådan definition er:
class Report {
String text;
public:
5.3.1 Overvejelser om arv 377

void Create (); // indtast en rapport
void Analyze (); // analysér en rapport
void Print (); // udskriv en rapport
};
class FinancialReport : public Report {
public:
void Create (); // indtast en administrativ rapport
void Analyze (); // analysér en administrativ rapport
void Print (); // udskriv en administrativ rapport
};
class ScientificReport : public Report {
public:
void Create (); // indtast en videnskabelig rapport
void Analyze (); // analysér en videnskabelig rapport
void Print (); // udskriv en videnskabelig rapport
};
Vi ender med et antal klasser, som alle har Report som baseklasse, men som alle dog har
helt specifik funktionalitet. At klasserne arver fra samme baseklasse giver kun den fordel, at de er
type-ækvivalente, og kan bruges polymorft, hvis medlemsfunktionerne erklæres virtuelle. Men
polymorfien er egentlig ikke interessant, fordi alle klasserne implementerer deres egne metoder
for indlæsning, analyse og udskrivning af deres egen type rapport, og således ofte vil blive brugt
af klienten som en forekomst af netop denne klasse. Med andre ord er klasserne ret forskellige,
både i attributter og i opførsel, selvom deres betydninger for klienten forsøges ligestillet.
Sådanne hierarkier er det fristende at oprette. Problemet er, at det eneste klasserne arver er en
smule data og ingen eller kun få metoder. Metoderne drejer sig i reglen blot om udskrivning og
indlæsning af klassens data. Problemet med denne organisering er, at den er alt for statisk.
Nedarvningsprincippet bruges kun til at definere et forhold, men tager ikke hensyn til de
relationer, der egentlig skaber de afledte klasser. Hvis vi ser nærmere på klasserne viser det sig, at
det egentlig ikke er de forskellige rapporters indhold, som er væsentlig. De data, som definerer en
videnskabelig rapport er meget forskellige fra de, som definerer en administrativ rapport. Det er
faktisk metoderne til indlæsning, udskrivning og anslyse af rapporter, som gør en rapport-klasse
til en rapport. Det er disse metoder, som klienten bør forstå en rapport ud fra. Problemet kan også
forstås ud fra mulighederne for at arve fra en af de eksisterende klasser. Arver vi for eksempel en
medarbejderrapport-klasse fra Report skal klassen stort set skrives helt fra bunden. Hvis den
videnskabelige klasses Analyze() og den administrative klasses Print() eventuelt var
brugbare i denne nye klasse er den eneste udvej at arve multipelt fra disse to klasser. Men en
medarbejderrapport er hverken videnskabelig eller administrativ, hvorved der opstår en forkert
forståelse for klassens position i forhold til de andre klasser.
Der skal en anden fremgangsmåde til, som kan kaldes for kompositorisk klassedesign, og som
går ud på, at der skal nedarves mellem klasser, som har direkte og entydig type-relevans. I
ovenstående eksempel er type-relevansen ikke åbenbar mellem de forskellige rapporter, men
378 Organisering af klasser 5.3

mellem de metoder, rapporten indeholder. Det, vi har forsøgt, er at anvende abstraktionen arv
som genbrugsmekanisme. Som vi skal se gennem de næste afsnit er det absolut ikke
hensigtsmæssigt.
5.3.2 Alternativer til arv
For at komme problemet med Report-eksemplet til livs, må vi ekstrahere størstedelen af
funktionaliteten i baseklassen, nemlig de tre medlemsfunktioner:
class RCreator {
// ...
public:
// ...
virtual void doIt() ();
};
class RAnalyzer {
// ...
public:
// ...
virtual void doIt ();
};
class RPrinter {
// ...
public:
// ...
virtual void doIt ();
};
Fra disse klasser kan vi nedarve specifikke versioner af rapportgenerering, analysering og
udskrivning, som kan udvælges efter behov, når en egentlig rapport skal bruges. Således
indeholder Report blot referencer til elementerne af den egentlige funktionalitet i en rapport,
som kan bestemmes af klienten. Klienten får dermed yderligere den frihed, at en bestemt del af
rapporten kan udskiftes uden at skulle nedarve og omskrive komplekse metoder fra selve rapportklassen.
De tre klasser RCreator, RAnalyzer og RPrinter er helt isolerede og er derfor
lettere at forstå (forståelsen kan yderligere øges ved at implementere disse klasser som
funktionoider, se afsnit 5.5). Da Report indeholder referencer til de tre klasser, vil kaldet til
deres doIt()-metoder binde dynamisk for nedarvede klasser, hvilket gør Report til en
meget dynamisk byggesten i forhold til før:
class Report {
RCreator& rc;
5.3.1 Overvejelser om arv 379

RAnalyzer& ra;
RPrinter& rp;
public:
Report (RCreator& c, RAnalyzer& a, RPrinter& p) :
rc (c), ra (a), rp (p) { }
void Create () { rc.doIt (); }
void Analyze () { ra.doIt (); }
void Print () { rp.doIt (); }
};
Klassen Report er et eksempel på en indkapslet polymorf datastruktur, hvis grænseflade blot
kalder metoder i strukturens elementer og intet andet. En sådan klasse kaldes for en aggregat,
fordi den sammenføjer kompleksitet fra andre klasser. Forskellen fra arvede klasser er, at klienten
er i en kontrolposition i forhold til klassen, fordi det dynamisk kan lade sig gøre at opbygge
funktionaliteten i en Rapport. Aggregate klasser giver således meget større frihed for klassens
klient, hvilket må siges at være et vigtigt kriterium for en klasse, som oftest netop er skrevet til en
klient. Klassen AdjacencyList fra afsnit 4.5.3 er et eksempel på en aggregat klasse i en
mere virkelig situation.
Når klasser skal organiseres er det således ikke blot et spørgsmål om, hvad man skal arve fra.
Ved kun at udtrykke klasseforhold ved arv bliver den enkelte klasse meget statisk set fra
klientens synspunkt, og bliver svær at forme til det egentlige formål. Vi opstiller derfor nogle
relationer mellem klasser og mellem objekter. Klasserelationer eller typerelationer foregår på et
entitetsplan, hvor klasserne har visse ligheder i struktur og form mens objektrelationer sker på et
instansplan, hvor objekterne relaterer direkte til klasser. Følgende relationer er væsentlige:
• Hvis klasse A er-en klasse B, bør A arves fra B. Undertonen i dette spørgsmål er, at
så mange metoder som muligt skal kunne genbruges, og at alle datamedlemmer i B har
mening i A. Et eksempel på dette er forholdet mellem Figur og Linie i afsnit
4.2.5. På normal dansk betyder dette typeforhold, at en Linie er en Figur, og det
faktum, at vi kan beskrive det direkte i kildeteksten gør, at programmets design
umiddelbart er lettere at forstå. En anden måde at sige det på, er at en Linie er en
slags Figur, mens ikke alle Figurer er Linier. Normalt taler vi om er-en
relationer i entitetsplanet og ikke i instansplanet. De hjælper til at identificere generelle
karakteristika og ikke specifikke forhold. Afsnit 4.3.1 og 4.4.1 indeholder en diskussion
af en sådan opbygning.
• Hvis klasse A har-en klasse B, bør A være klient af B. Spørgsmålet om typen af
reference (forekomst, pointer eller reference) er ikke ligefremt, og behandles nedenfor.
Forholdet mellem Figur og Koordinat i afsnit 4.2.5 er et eksempel på denne
typerelation, som normalt også kan kaldes bruger-i-implementationen relation (klasse A
bruger klasse B i implementationen). I modsætning til er-en forholdet, som
kun giver mening i entitetsplanet, definerer et har-en forhold mellem enten to klasser, en
klasse og et objekt eller to objekter. Hvis vi begynder i entitetsplanet og ser på eksempel
4-4 i afsnit 4.3.10 opdager vi, at klassen Figur har et typeforhold til en Koordinat
380 Organisering af klasser 5.3

som kan beskrives som, at Figur har-en Koordinat. Da dette gælder for alle
figurer, også de, som arver fra Figur, er dette et konceptuelt ejerforhold som kun
eksisterer på entitetsplanet, altså på klasseniveau. Anderledes forholder det sig med
klassen Billede fra afsnit 4.4.7. Denne klasse har et forhold til Figurer som er
temmeligt kompliceret. Ikke nok med, at klassen er-en Figur, og dermed opretter et
typeforhold på entitetsplanet, den har også Figurer. Men en given forekomst af
Billede kan indeholde både Firkanter og Linier. Her har Billede et har-en
forhold til alle de klasser, der er arvet fra Figur. På samme måde forholder det sig
med klasser, hvis arvinger kan være klienter af andre klasser. Sådanne baseklasser har et
løst objekt-per-klasse forhold til forekomster af andre typer.
• Hvis klasse A er-en-del-af klasse B, bør der enten slet ikke arves (da typeforholdet
ikke er entydigt) eller også bør der skabes en fælles baseklasse for A og B, som
indeholder fællesnævnerne for de to klasser. Alternativet er, hvis den del, som B har i
overskud er meget lille, at omskrive B's afvigende metoder i A, men vel at mærke kun,
hvis metoderne har mening i A. Klassen Transformation (afsnit 4.2.3) er en del af
et Koordinat, men arver ikke, fordi en Transformation ikke kan erstatte et
Koordinat i praksis. Derimod arver SortedList fra LinkedList (afsnit
4.5.3), fordi typeforholdet kan udtrykkes ved at omskrive netop den metode, som
differentierer de to klasser.
• Vi definerer også et bruger-en relation, som opstår, hvis en klasses medlemsfunktion
modtager en forekomst af en anden klasse som parameter. Klassen HeadNode fra
afsnit 4.5.7 bruger-en forekomst af ostream til at udskrive sine data. Det er ikke et
har-en forhold, fordi kaldene til medlemsfunktionerne i ostream-objektet ikke
medfører, at en ostream er indeholdt i en HeadNode-forekomst som del af dette
objekt.
• Det sidste forhold er forholdet skaber-en, som betyder, at et objekt skaber et andet
objekt gennem et kald til dens konstruktør (enten gennem et kald til operator new
eller som automatisk allokeret returværdi fra en medlemsfunktion). Det minder meget
om bruger-en forholdet, men er her mellem to objekter og ikke mellem en klasse og et
objekt.
Hvis klasse A har relationer i entitetsplanet af ovenstående karakter med mere end én anden
klasse er der i reglen to muligheder, enten multipel arv eller aggregat klasse. Forskellen er ikke så
stor, som man skulle tro, og valget ligger i en erkendelse af, hvordan klassen skal bruges fra
klientens side. Det drejer sig altså konkret om, hvorvidt den ene klasse skal være arvtager eller
klient af den anden. Det fundamentale ligger i, om klassen A er en speciel slags af klassen B,
eller om A har en B. Det lyder simpelt, men kan i praksis være lidt af et problem. I eksemplet
med Figur-hierarkiet fra afsnit 4.2.5 er det klart at se, hvordan de afledte klasser er specielle
typer af baseklassen. Abstraktionen er med andre ord letforståelig. Programmer er desværre oftest
ikke nær så simple i deres natur, fordi de repræsenterer dårligt forståede abstraktioner og ikke
objekter fra virkeligheden. Er UnderBillede et slags Billede eller har et Billede et
5.3.2 Alternativer til arv 381

UnderBillede? Er et BinaryTree en slags LinkedList eller omvendt? Det er
spørgsmål som disse, der optager hovedparten af udviklingen af en fundamental objekt-orienteret
designmetode, og som jeg vil forsøge at belyse i resten af dette kapitel.
De ovenstående regler for type-relationer virker altså kun, hvis begreberne, som klasserne
repræsenterer, er forstået fuldt ud af programmøren. Modsat den gældende mening er denne
forståelse ikke umiddelbar, og en fremgangsmåde til at hjælpe forståelsen for en klasses
repræsentation er nødvendig. Der er to udgangspunkter at tage, klassens data og klassens
metoder. Beskrives klassen udfra dens data, er reglen om ikke at arve unødvendige data
tilstrækkelig. Producerer arvefølget objekter med overskudsdata, som klassen ikke har brug for,
er det et sikkert symptom på, at arven ikke er korrekt. Det betyder ikke, at de to klasser intet har
til fælles, men blot at de skal relateres til hinanden på en anden måde, for eksempel ved
introduktion af en mellemliggende klasse eller en ny baseklasse, som klistrer de to klasser
sammen. De arvede metoder er sværere at fastsætte betydningen af. Hvis arven medfører
metoder, som ikke direkte kan bruges af den afledte klasse, hverken som den ser ud eller i
forbindelse med en omskrivning, betyder det, at de to klasser ligger længere fra hinanden end de
måske ser ud til. Det ses ofte, at en arvet metode kun næsten er korrekt for den afledte klasse,
men må skrives helt om for at være fuldstændig korrekt. Et eksempel på dette er en klasse, som
definerer en kø. Klassen har meget tilfælles med en hægtet liste, og da en kø er bredere defineret
end en hægtet liste, ser en arvefølge fra denne rigtig ud:
class Queue : public LinkedList {
Node* tail;
public:
// ...
};
Klassen Queue har udover en arvet pointer til den første hægte i listen også en ny pointer til den
sidste hægte i listen. Data fyldes i listen i starten og hentes fra listen i slutningen. De to metoder
LinkedList::Insert() og LinkedList::Retrieve() arbejder begge på starten af
listen, og en omskrivning af den sidste skulle derfor være tilstrækkelig. Desværre skal det ny
datamedlem opdateres i både indsættelse og udtagning af data, og den arvede metode
Insert() kan ved nærmere eftersyn ikke bruges, fordi den ikke opdaterer pointeren til
sluthægten. Men det er ikke det værste: Den arvede metode kan heller ikke bruges som del af en
ny rutine:
void Queue::Insert (Node* p) {
LinkedList::Insert (p);
// hvordan opdateres tail?
}
En undersøgelse af LinkedList::Insert() viser, at informationen til sluthægten vil gå
tabt under visse omstændigheder, hvorved denne skal opdateres. Det kan reddes ved at traversere
listen fra start til slut og tildele sluthægte-pointeren den sidst fundne. Men effektiviteten vil lide
under, at listen skal traverseres ved hver indsættelse, en væsentlig bivirkning ved en sådan
382 Organisering af klasser 5.3

implementation. Queue må derfor helt omskrive metoden, og det arvede materiale indskrænker
sig faktisk til et enkelt datamedlem, pointeren til den første hægte. Eksemplet viser, hvordan to
klasser, hvis relation ser åbenbar ud, viser sig at udvise forskellighed på et par nøglepunkter, som
gør de fleste af de arvede metoder ubrugelige. Til gengæld er fordelen ved arven, at klienten kan
bruge en Queue som en LinkedList og således kalde alle eksisterende funktioner, som
arbejder på hægtede lister.
Somme tider er arv dog ikke den rette løsning. I eksemplet fra afsnit 4.2 kan vi se på forholdet
mellem klasserne Koordinat og Figur. En Figur har samme egenskaber som et
Koordinat, nemlig en bestemmelse i et plan og metoder til at ændre på dette. Men de to
klasser er ikke type-ækvivalente: koordinater og figurer er to helt forskellige begreber. En måde
at afsløre et sådant forhold er at se på klasserne fra klientens side, og opstille følgende
overvejelse: Hvis en funktion, som arbejder på baseklassen, uden modifikation og med mening
vil kunne arbejde på den afledte klasse, bør der arves. For klasserne Koordinat og Figur
gælder, at Koordinat har en grænseflade, som går langt ud over Figur's omfang, for
eksempel de mange operator-metoder samt udskrivning af indholdet. Polymorfe kald arbejder på
metoder, og jo flere overskuds-metoder, baseklassen indeholder, des flere eksterne generiske
funktioner vil ikke kunne bruges polymorft for den afledte klasse. Figur benytter en
Koordinat som medlemsforekomst i stedet, og er dermed klient i stedet for arvtager.
Hvis typeforholdet mellem to klasser indebærer, at den ene klasse er klient af den anden, rejser
spørgsmålet sig om hvilken type af reference, klientklassen skal have til udbyderklassen:
medlemsforekomst (objekt), pointer eller reference. Hvis vi erklærer en klasse A med en
medlemsforekomst af en anden klasse B, og dermed gør A til klient af B med
class A {
B b_object;
// ...
};
vil enhver forekomst af A indeholde et B-objekt, ganske som under arv. Det betyder
selvfølgelig, at en klasse ikke kan være sin egen klient, ligesom en klasse ikke kan arve fra sig
selv. En fundamental forskel mellem klientering og arv er, at de to klassers relation ikke
udtrykker et semantisk forhold mellem de to klasser. Det er umuligt at bruge A som polymorf
reference i kode, som arbejder på B-referencer. En anden forskel er, at det er muligt for klientklassen
at styre hvilke funktioner, der skal skinne igennem til klassens grænseflade: da der ikke
arves, vil ingen af B's metoder kunne ses af A's klient. Hvis B har en public metode f(),
kan A's grænseflade indeholde en lignende metode f(), som blot viderefører kaldet til B - vi
siger, at A er en delegerende klasse:
class B {
public:
// ...
void f ();
};
5.3.2 Alternativer til arv 383

class A {
B b_object;
public:
// ...
void f () { b.f(); }
};
På den måde kan kun de metoder, som udbyderen af A ønsker at "arve" fra B skrives som del af
klassens grænseflade. Den lille, men væsentlige forskel fra eksplicit skjulning af data og metoder
i en afledt klasse, som vi så i afsnit 5.3.1 er, at metodernes prototyper tillades at afvige i
specifikation. Hvis B's metode modtager en double, kan A's metode specificeres på en anden
måde, som passer til A. Her er A og B erstattet af en Name-klasse og en Person-klasse:
class Name {
char* s;
public:
// ...
void Set (char*);
};
class Person {
Name first, last;
public:
// ...
void Set (char* f, char* l) {
first.Set (f);
last.Set (l);
}
};
De to klassers Set()-metoder afviger i specifikation, og hvis Person arvede fra Name, ville
der optræde to overstyrede metoder af dette navn. I dette eksempel antages, at klassen Person
kun kan sætte sit indhold til både et fornavn og et efternavn, så metoden Set(char*) er
meningsløs. Under arv kan vi kun ændre på adgangskriterierne til metoden, men kan ikke fjerne
den. Her er den nye Set()-metode entydig for Person-klassen. Der er i øvrigt et andet
forhold i denne relation mellem Person og Navn som umuliggør arv, nemlig Persons
dobbelte instantiering af Navn som forekomst. Skulle klassen i stedet arve, ville det ikke være
muligt at specificere Navn to gange i erklæringen. Et udmærket tegn på, at medlemsforekomster
er at foretrække frem for arv er således, at hvis den ny klasse skal bruge flere forekomster af den
eksisterende klasse, er klientering den uafvigelige løsning.
En tredie metode til relatering af klasser er at bruge den eksisterende klasse med en indirekte
reference i den ny klasse, enten med pointer eller med reference. Hvis klassen A indeholder en
indirekte reference til B kaldes A for en løs klient af B, fordi instantieringer af A ikke
umiddelbart resulterer i underforståede B-objekter. B's konstruktør kaldes først, når et B-objekt
384 Organisering af klasser 5.3

instantieres, og med følgende klasseerklæring vil det ikke ske under konstruktionen af A:
class A {
B* B_ptr;
public:
// ...
};
Forskellen fra instantiering som i forrige eksempel er, at ingen af B's data automatisk bliver
instantieret for objekter af A. En lighed med forrige eksempel, men en forskel fra arv, er, at ingen
af B's metoder bliver defineret for objekter af A. De samme regler gælder således for selektion
af metoder, som skal bruges i A med eksplicit reference til den indeholdte B-pointer. Med en
pointer kan referencen i A ydermere henvise til ethvert objekt, som er afledt fra B. Det betyder
flere ting:
• Det indeholdte B-objekt kan være polymorft. Klienten kan, med en eksisterende Bklasse
og en passende grænseflade i A, arve en ny klasse C fra B og lade objekter af
A arbejde på forekomster af C. Polymorfe kald vil være mulige gennem virtuelle
metoder erklæret i B.
• Da referencen til B kan henvise til enhver subtype under denne klasse, kan der i praksis
skabes en reference til et A-objekt, såfremt A er afledt fra B. Ved normal instantiering
i A, eller ved arv, er det ikke muligt for en klasse at indeholde en forekomst af sig selv.
• Abstrakte klasser kan refereres, hvilket ikke er muligt under normal klientering.
• Det er muligt for to A-objekter at dele den samme forekomst af et B-objekt ved at lade
begge objekters pointere pege på samme data.
Et andet forhold ved pointere til forekomster indeholdt i objekter er, at det refererede objekts
levetid ikke nødvendigvis falder sammen med det omsluttende objekt. Det skaber først og
fremmest et udvidet ansvar for, at forekomster af det refererede objekt administreres korrekt og
allokeres og deallokeres som det skal, mens det for medlemsforekomster varetages af
oversætteren. Videre betyder det, at den omsluttende klasse blot er en midlertidig holdeplads for
det indeholdte objekt, og på den måde kan anskues som en container. Container-klasser skaber
således avancerede relationer mellem andre objekter, uden at være statisk bundne til forekomster
af bestemte klasser. Som beskrevet i afsnit 3.5.12 er indirekte referencer i objekter en kilde til
fejl, når det omsluttende objekt kopieres. Hele klassen skal designes således, at en kopiering
enten skaber en kopi af pointeren eller rent faktisk kopierer hele det refererede objekt. I praksis
betyder det, at specielle metoder som kopi-konstruktører og tildelings-operatorer skal defineres
for klasser, som indeholder pointere til objekter. At bruge indirekte referencer til
medlemsvariable er således farligere og kræver mere arbejde, men er tillige en langt mere
fleksibel teknik. Brug af referencer i stedet for pointere gør ikke den store forskel, og begrænser
endda fleksibiliteten en smule, fordi det ikke er muligt at tildele en værdi til en referencevariabel
5.3.2 Alternativer til arv 385

efter erklæringen og initieringen. I princippet bør prioriteringen ved undersøgelse af et
typeforhold være:
• Undersøg, om arv er fornuftigt ved brug af de beskrevne regler for type-ækvivalens.
Hvis den ene klasse, set fra klientens side, kan drage fordel af at være en subtype af den
anden klasse ved for eksempel polymorft brug er arv den tvungne løsning.
• Hvis arv ikke er realistisk, undersøg da muligheden for klientering. Hvis den ene klasse
har alle forudsætninger for arv med undtagelse af subtype-forholdet, er klientering den
rigtige løsning.
• Hvis type-forholdet er for statisk med klientering, brug da en indirekte reference. Er den
eksisterende klasse abstrakt, er en pointer til en afledt forekomst ligefrem nødvendig, da
klassen ikke kan instantieres.
Om de specifikke C++ friend-funktioner og -klasser skal det nævnes, at de ikke udtrykker et
typeforhold. Brug dem derfor aldrig til at underbygge det egentlige design.
5.3.3 Medlemsvariable
En klasses medlemsvariable er klassens egentlige repræsentation. Et objekt af en klasse vil have
en opbygning, som er defineret af klassens variable †
. Det er derfor vitalt, at klassens data er
defineret korrekt. Hvilke data, en klasse skal have, afhænger helt af, hvad klassens funktion er.
Valg af type for medlemsvariable kan der derfor ikke opstilles regler for. Der er imidlertid
forskellige overordnede attributter for medlemsdata, som har betydning for objekters brug.
Først og fremmest skelnes mellem tre slags klasser:
• Tomme klasser: klasser uden variable,
• Simple klasser: klasser med variable af udelukkende fundamentale typer, og
• Komplekse klasser: klasser, som indeholder andre brugerdefinerede objekter.
Klasser uden data er normalt abstrakte klasser, som enten blot er prototyper på korrekte
implementationer i afledte klasser, eller som har en "klister-funktion" idet de sørger for et korrekt
type-forhold mellem baseklasser og afledte klasser. En klasse uden medlemsvariable består
således kun af metoder og/eller prototyper på metoder og er simpelthen et indkapslet modul af
funktioner. Har en klasse udelukkende variable, som er af fundamentale typer, vil klassens
funktion ofte være som grundpille i programmet. Idet klassen har en ekstern definition, som går
ud over de fundamentale typer, mens den selv blot indeholder fundamentale typer, skaber denne
klasse en egentlig abstraktion for det koncept, den repræsenterer på et maskinnært niveau. Hvis
† Forekomsten indeholder også en pointer til eventuelle virtuelle metodetabeller, se afsnit 4.4.5.
386 Organisering af klasser 5.3

klassen indeholder forekomster af andre objekter, er der oftest tale om et aggregat, dvs. en klasse,
som samler funktionaliteten fra andre klasser. De kaldes også for komplekse klasser, fordi et
større antal konstruktører kan blive resultatet af en enkelt instantiering, se afsnit 4.5.5.
Medlemsvariable kan erklæres statiske, hvorved alle forekomster af klassen deler den samme
forekomst af medlemsvariablen. Statiske data bruges i sammenhænge, hvor en global variabel
brugtes før i tiden, blot relateret til et begrænset antal funktioner. Ved statiske medlemsdata opnås
to ting: pladsbesparelse, fordi der kun findes én forekomst, ligegyldigt hvor mange objekter, der
instantieres og konsistenssikring, hvis alle objekter af den pågældende klasse afhænger af samme
variabel. En medlemsvariabel bør erklæres static, hvis den ikke er relateret til et bestemt
objekt, men til klassen som helhed. For eksempel er en god kandidat til en statisk
medlemsvariabel en pointer til en fejlbehandlings-funktion, som er den samme for alle
forekomster af klassen. Husk, at en statisk medlemsvariabel skal initieres udenfor klassens krop.
Konstante medlemsdata har meget begrænset anvendelighed, men kan hjælpe med at sikre
konsistensen af et objekt. Hvis en medlemsvariabel ikke skal ændre værdi efter konstruktøren har
initieret den, kan den med fordel erklæres konstant. Hermed sikres, at ingen metoder fejlagtigt
ændrer på variablens værdi. Et eksempel på en konstant medlemsvariabel er pointere til
specifikke adresser i lageret, for eksempel I/O-adresserum.
5.3.4 Metoder
Hvilke metoder bør en klasse indeholde? Generelt er en klasses metoder definitionen på dens
grænseflade, men de er mere end det. Der er nogle væsentlige grundfunktioner, som alle klasser
har, og som gør valget af metoder lettere at overskue. En klasse har typisk brug for:
• Administrative metoder, herunder konstruktører og destruktører, kopieringsmetoder,
sammenlignignsmetoder, konverteringsmetoder, operator-overstyringer og
filtreringsmetoder. Disse metoder ændrer sjældent på objektets data, men har en
underforstået betydning for objektets brug i en større sammenhæng, dvs. i sammenhæng
med andre objekter. Administrative metoder kaldes også grænseflade-metoder.
• Bearbejdende metoder, hvilke er de metoder, som laver det grove arbejde i forbindelse
med objektets data. De bearbejdende metoder er oftest de største og mest komplicerede
at skrive, og er ydermere ofte de elementer, som er årsagen til klassens oprettelse.
• Statusmetoder, som returnerer et objekts status på en veldefineret måde, normalt uden at
ændre på objektets data. En statusmetode er for eksempel en angivelse af objektets
størrelse, lokation eller hash-værdi.
De administrative metoders omfang er afhængig af systemet som helhed, og ikke af den enkelte
klasse. Derfor er antallet af og størrelsen på disse metoder ofte ret konstante for de fleste klasser.
At skrive dem er trivielt og skaber ikke de største problemer. De bearbejdende metoder er
definitionen på klassens egentlige funktionalitet, og indeholder de algoritmer, som klassens
objekter manipuleres med. Disse er normalt de største, mest komplicerede metoder, hvis omfang
5.3.3 Medlemsvariable 387

og antal afhænger af den enkelte klasse. Statusmetoderne er de mindste og mindst
betydningsfulde metoder i klassen. Denne definition af metodetyper er rent indholdsmæssig. Der
er eksterne krav, som har indflydelse på metodernes specifikation og implementation, og som
enten kan gøre en metode enkel eller kompliceret at skrive.
Det vigtigste at huske er følgende: tænk på klienten. Klassens metoder skal bruges af en klient,
og de skal derfor skrives så klienten får færrest mulige problemer med at bruge og forstå dem.
Det første og vigtigste valg, der skal tages er, om en metode skal være virtuel eller ej. Virtuelle
metoder har den egenskab, at de kan bruges polymorft af en klient, og skaber dermed en blød
relation til eventuelle base- og afledte klasser. Er den aktuelle klasse afledt fra en anden klasse
med virtuelle metoder, vil klassen arve alle disse. En nedarvet virtuel metode betyder normalt, at
den bør redefineres i den afledte klasse. Hvis en ny metode introduceres i den aktuelle klasse bør
den erklæres virtuel, hvis der er den mindste smule mistanke om, at en afledt klasse kan erstatte
den aktuelle klasse i eksterne generiske funktioner.
I C++ kan man stille det andet, ikke særlig objekt-orienterede spørgsmål, om en metode
overhovedet skal være medlem af klassen. Der er visse forhold, specielt i forbindelse med
numeriske datatyper og operator-metoder, som nødvendiggør eksternt erklærede, globale
funktioner med relation til klassen. Normalt erklæres metoder udenfor klasser for at opnå en
bedre grænseflade og dermed bedre syntaks i klientens program. Skrives for eksempel en metode
sin() for Complex-klassen fra kapitel 3 til udledning af sinus for det komplekse tal, vil den
sandsynligvis se således ud:
Complex Complex::sin () {
return Complex (sin(re) * sinh (im), sin (re) * sinh
(im));
};
og bruges på følgende måde:
void f () {
Complex a (2, -1);
Complex b = a.sin ();
// ...
}
Denne syntaks følger den objekt-orienterede forståelse for en afsendt besked til et objekt, her
sin() anvendt på Complex. Set ud fra en normal behandling af numeriske typer, for
eksempel en double, er syntaksen imidlertid dårlig. Der burde stå:
void f () {
Complex a (2, -1);
Complex b = sin (a);
}
For at opnå dette må metoden sin() udtages af Complex og skrives som normal, global
388 Organisering af klasser 5.3

metode med speciel tilgang til et Complex-objekt gennem en friend-erklæring. En
friend-funktion modtager som regel et eller flere objekter som parametre af den type, metoden
er friend af. Andre tvungent nødvendige anvendelser for friend-funktioner omfatter
generelle operator-metoder mellem en bestemt klasse og en fundamental type. Som illustreret i
afsnit 3.5.11 kan en medlemsmetode misfortolkes, hvis den bruges forkert af klienten:
a = 1 + b; // 1.operator+ (b) ?
Metoden kan ikke være medlem af konstanten 1, men må erklæres udenfor klasseskop og
erklæres friend for den eller de klasser, operatoren arbejder på. Der er intet teknisk problem i
at skrive en medlemsfunktion om som en global funktion. Overstyring af funktionsnavne sikrer,
at der ikke opstår navnekonflikter med andre globale funktioner.
Der er et specielt forhold ved friend-funktioner, som gør dem uegnede til visse
implementationer. Disse metoders manglende underforståede objekt gør det nemlig umuligt for
en friend-funktion at være virtuel. Det kan skabe problemer, for eksempel i forbindelse med
polymorfe kald til operator-funktioner:
class A {
public:
// ...
friend ostream& operator

};
class B : public A {
// ...
public:
// ...
virtual void printOn (ostream&);
};
inline ostream& operator

• Konstante metoder bruges til at tillade klienten at oprette og behandle konstante
forekomster af den aktuelle klasse. Hvis klienten kalder en ikke-konstant metode for et
konstant objekt, vil oversætteren advare om det. Husk, at en konstant og en ikkekonstant
metode afviger semantisk fra hinanden og fortolkes af C++ som en overstyring,
se afsnit 3.3.17.
Der har også været fokuseret på en ensartet opbygning af klasser efter et bestemt mønster, som
skulle give større mulighed for integration af disse i hierarkier. [Coplien 92] nævner som
eksempel den ortodokse, kanoniske form som en mulighed. Det er en konvention, der siger, at en
klasse skal indeholde et minimum af medlemsfunktioner, som gør det muligt at benytte dem i
tildelinger, initieringer, som parametre og som returværdier ganske som de fundamentale typer.
Følgende klasseerklæring er et eksempel på denne kanoniske struktur:
class X {
// ... repræsentationen af abstraktionen "X" ...
public:
// underforstået konstruktør
X ();
// kopi-konstruktør, vigtig i initieringer
X (const X&);
// destruktør
~X ();
// tildelingsoperator
const X& operator= (const X&);
// sammenligningsoparator
int operator== (const X&) const;
// ... andre offentlige medlemsfunktioner i "X" ...
};
5.3.5 Adgangskontrol
En klasses data bør i næsten alle tilfælde erklæres i den private sektor af klassen, så klienten ikke
kan se dem direkte. Den første grund til denne meget fundamentale regel er, at kun klassens
metoder kan arbejde direkte på disse data, og at eventuelle fejl isoleres til klassen selv. I bredere
forstand sikrer en indskrænkelse af tilgangen til en klasses data, at klienten gør sig uafhængig af
implementationen (de indkapslede datas natur) af klassen. Det skal forstås således, at en
klasseudbyder kan ændre på klassens interne repræsentation uden at klientens kode bryder
sammen. Det bunder i en syntaksmæssig konvention om altid at gå gennem en funktion i stedet
for at gå direkte til klassens data, hvilket i grunden er en indirekte måde at skrive den samme
kode på. Faktisk specificerer klassens udbyder en udvidet semantik formelt i form af klassens
grænseflade, hvilket før i tiden kun var en del af det designet. Mens det øgede forbrug ved
5.3.4 Metoder 391

indirekte referencer til data gennem funktioner kan normaliseres ved brug af inline-kode, kan
den syntaksmæssige ulempe ikke siges at være et problem. Tværtimod kan en tekstuel
beskrivelse af en grænseflade være konsistent fra design til kode.
Et eksempel vil være på sin plads. Overvej følgende stak-klasse og en simpel anvendelse for
ombytning af elementer:
// eksempel 5-1a: vektor-repræsenteret stak af heltal
class IntStack {
public:
int *s;
IntStack (int capacity = 100) { s = new int [capacity]; }
~IntStack () { delete s; }
void Push (int i) { *s++ = i; }
int Pop () { return *--s; }
};
// ombyt de to øverste elementer på stakken
void swap (IntStack& stk) { // uha: gør sig afhængig
int temp = *stk.s; // af implementationen
*stk.s = stk.s [-1];
stk.s [-1] = temp;
}
Funktionen swap() arbejder direkte på et datamedlem for at ombytte de to øverste elementer i
stakken. Sæt nu, at vi omskriver klassen og giver den en anden intern repræsenation:
// eksempel 5-1b: hægtet liste-repræsenteret stak af heltal
class IntStack {
public:
class IntNode {
public:
IntNode* next;
int d;
IntNode (IntNode* n, int i) : next (n), d (i) { }
};
IntNode* s;
IntStack (int capacity = 100) { s = 0; }
~IntStack () { delete s; }
void Push (int i) { s = new IntNode (s, i); }
int Pop () {
if (!s) { cerr next;
392 Organisering af klasser 5.3

};
delete remove;
return i;
}
Hvis klienten genoversætter ovenstående kode vil funktionen swap() bryde sammen med en
oversætterfejl, der handler om en typekonflikt i den første tildeling. Typekonflikten er opstået,
fordi klassen har ændret sin implementation fra vektor til hægtet repræsentation af stakken.
Klienten må nu ændre sin kode, fordi den er afhængig af klassens implementation: Ændres
klassen, må klientens kode også ændres. I de ovenstående klasser har klienten adgang til alle data.
Ved at erklære pointer-variablen s i den private del af klassen vil klientens swap()-funktion
give en fejl ved første oversættelse, som beklager, at der ingen adgang er til de nævnte data.
Klienten må anmode om en special adgangsmetode i stedet, som passer til problemet. En sådan
metode kunne for eksempel være en overstyring af []-operatoren, som indekserer stakken, og
som kan give klassen og swap() følgende udseende:
class IntStack {
// klassens implementation, skjult fra klienten...
public:
IntStack ();
~IntStack ();
void Push (int);
int Pop ();
int& operator[] (int);
};
// ombyt de to øverste elementer på stakken
void swap (IntStack& stk) {
int tmp = stk [0];
stk [0] = stk [-1];
stk [-1] = tmp;
}
Nu kan klassens udbyder repræsentere stakken på vilkårlige måder, foretage ændringer i klassens
data og omdøbe interne navne, fordi ingen udefra gør brug af dem. Den grænseflade, som en
tilgangsfunktion giver klassen, gør klientens kode langt mere robust, fordi den ikke fejler på
grund af omstændigheder, som ligger udenfor dennes domæne. Både klassen og klientens kode
kan oversættes separat uden risiko for konflikter. Klassens specificerede grænseflade er således
en protokol for dataudveksling mellem klassen og dens klienter.
Tilgangsmetoder i klassen skal dog skrives, så de ikke ved en fejltagelse afslører den interne
repræsentation. Enhver klasse indeholder en eller flere metoder til filtrering af den information,
som klassen indeholder, så den præsenteres til klienten på en meningsfuld måde. En sådan
filtreringsmetode er den skrøbeligste del af klassens grænseflade, fordi klienten kan gøre sig
afhængig af implementationen, selv om den er skjult. For eksempel,
5.3.5 Adgangskontrol 393

class String {
char* s;
public:
// ...
operator char* () { return s; }
};
I denne klasse findes, ganske fornuftigt, en konverteringsmetode, som laver en String om til
en char*. Dermed kan forekomster af String bruges i alle sammenhænge, hvor en char*
er påkrævet. Men uden at oversætteren beklager sig, er konverteringsmetoden en fuldstændig
blottelse af klassens interne repræsentation. Den returnerer en pointer-variabel til klassens private
data, som derefter kan manipuleres af klienten. Beskyttelsen er dermed intet værd. Metoder, som
returnerer pointere eller referencer til de private data bør altid returnere konstanter, så klienten
ikke kan manipulere med de sensitive data:
class String {
char* s;
public:
// ...
operator const char* () { return s; }
};
Indkapsling af klassens implementation er derfor en nødvendighed, hvis klientens kode skal være
robust og ikke bryde sammen ved mindre ændringer. Er en grænseflade først defineret, er det blot
et spørgsmål om fra både klasseudbyderen og klienten om at holde sig til denne specifikation.
Klassens anden grænseflade, forholdet til den afledte klasse, skal derimod sjældent trækkes så
skarpt op. Et sæt af klassens data bør erklæres protected, så en afledt klasse kan arbejde på
dem uden at skulle gå gennem filtermetoder. Ofte vil en filtermetode ikke være nær så fleksibel
som en direkte tilgang, og vil i alle tilfæde være mindre effektiv. Da den indkapslede del af både
baseklassen og den afledte klasse er usynlig for klienterne, skal effektiviteten være højest mulig i
selve klassens kode. Derfor vil en overspecificeret grænseflade fra baseklasse til afledt klasse gå
ud over klienten, som skal vente unødigt på disse to klassers interkommunikation. Argumentet
den anden vej lyder, at en klient blot kan arve fra klassen og få adgang til de private dele. Det
gøres imidlertid næppe uden at være højest tilsigtet, så en tilfældig afhængighed af klassens
implementation vil ikke opstå på grund af en løs specificeret grænseflade i den beskyttede del af
klassen.
Klassens metoder bør følge stort set de samme regler for indkapsling, blot af den grund, at en
metode, som ikke kommer klienten ved let kan skabe kaos i klassen, hvis den kaldes. Et utilsigtet
metodekald kan skabe større rod end en utilsigtet tildeling til interne data. Metoder, som klienten
ikke har brug for, bør erklæres private, hvis de er helt specifikke til den aktuelle klasse eller
protected, hvis de har betydning udover den og eventuelt kan bruges i en afledt klasse. Ofte
har en klasse brug for et par mindre private metoder, som gør de offentlige, større metoder lettere
at skrive. Et eksempel på dette er de to private metoder i klassen Set fra afsnit 3.8.4, som
394 Organisering af klasser 5.3

udfører logaritmiske beregninger for næsten alle generelle metoder i klassen. Disse metoder er,
selvom de ikke har betydning for objekter af Sets status, ikke brugbare for klienten. Under arv
opstår ydermere det problem, at en nedarvet offentlig metode mister sin betydning for den afledte
klasse, hvorved den kan skjules ved privat arv eller eksplicit reerklæring i den private del af
klassen. Det er på en måde den samme problematik som problemerne med transparensen til de
private data i forhold til klienten, så det er et spørgsmål om at balancere medlemmerne mellem de
private og de beskyttede dele af klassen.
Der kan opstå et mindre problem i forbindelse med arv af virtuelle metoder, som ikke har
betydning for den afledte klasse. Ofte er disse tilfælde en konsekvens af et ugennemtænkt design,
men kan også være resultatet af en meget specialiseret afledt klasse. En virtuel metode vil altid
have den adgangsspecifikation, som den klasse der bruges i klientens reference erklærer metoden
som. Med andre ord, hvis en baseklasse erklærer en public virtuel metode, der skrives i en
afledt klasse i den private del, vil et kald til metoden under reference til baseklassen til et
objekt af den afledte klasse rent faktisk kalde den private metode i denne. For eksempel:
// eksempel 5-2a: en endimensionel mængde-klasse
class Set {
public:
Set (int);
// ...
virtual int operator[] (int);
};
// eksempel 5-2b: en todimensionel mængde-klasse
class Grid : public Set {
virtual int operator[] (int);
public:
Grid (int x, int y) : Set (x * y) { }
// ...
virtual int operator[] (int, int);
};
Klassen Grid er en udvidelse af Set fra afsnit 3.8.4, og udvider mængde-begrebet med en
dimension. Indekserings-operatoren [] med én parameter mister således sin betydning, og
erklæres derfor i den private del af Grid, mens en ny metode med to parametre erklæres i den
offentlige del. Det forhindrer imidlertid ikke klienten i at bruge Grid som erstatning for Set i
polymorfe referencer, og kalde operator[](int) for Grid:
void f () {
Set& s = *new Grid (320,256);
cout

Problemet er, at den nødvendige information for kaldet til en virtuel metode ligger i baseklassen
alene, her Set. Den sene binding er mulig, fordi oversætteren ikke behøver kende til afledte
klasser på oversættelsestidspunktet. Derfor kan den ikke se, at Grid skjuler den virtuelle
metode fra klienten, og metoden kaldes alligevel. Et sådant kald vil normalt resultere i en runtime
fejl, fordi en metode kaldes, for hvilken der ikke findes en meningsfuld repræsentation. I
disse tilfælde bør den private virtuelle metode udskrive en fejlmeddelelse, returnere et fejlobjekt
eller foretage en anden form for undtagelsesaktion. I afsnit 5.9 vises, hvorfor netop sådanne
arvefølger er eksempler på dårligt klassedesign.
Læg mærke til, at referencen altid er relativ til den klasse, som kaldet foretages fra. Hvis
klienten i ovenstående kodefragment i stedet skrev
void f () {
Grid& s = *new Grid (320,256);
cout

Arv er en lineær form for genbrug, fordi baseklassens elementer er entydige i måden de
genbruges på. Det er indlysende, hvilke data og metoder, som den ny klasse direkte kan overtage
og arbejde med. Arv er, som beskrevet i afsnit 5.3.1, i første omgang en genbrugs-teknik, som
vedrører klassedesigneren. Men arv gør også ekstern kode mere genbrugelig, fordi de opsatte
type-forhold mellem baseklasser og afledte klasser tillader udvikling af generisk kode. Generisk
kode er defineret ved funktioner og programfragmenter, som kan arbejde på mange forskellige
typer af objekter uden at skulle modificeres. Generisk kode er ikke det samme som generel kode;
forskellen ligger i en definition af generalitet som noget statisk og anvendt og genericitet som
noget dynamisk, klient-kontrolleret og ofte typeuafhængigt. Disse forhold diskuteres i detaljer i
afsnit 5.9. Til en klasse med virtuelle metoder hører ofte en eller flere funktioner (enten
medlemmer i klassen eller ej), som arbejder på de virtuelle metoder. Disse funktioner har karakter
af genericitet, fordi de typer, de arbejder på, kan erstattes af klienten uden at skulle modificere
eller genoversætte dem. Generel kode arbejder derimod på homogene datatyper.
De generiske elementer udgør således en mere omfattende og subtil form for genbrug, og er
mere fremadrettede, fordi de under klientens kontrol tillader en anden funktionalitet. Et typisk
eksempel på en generisk funktion er
bool operator== (const LinkedList& a, const LinkedList& b) {
return a.isEqual (b);
}
som sammenligner to hægtede lister ved et kald til en virtuel metode. Denne funktion kan kaldes
med alle subtyper under LinkedList, og kan således bruges for både SortedList,
IndexedList og SortedIndexedList fra afsnit 4.5.3, hvis metoden isEqual()
implementeres i de nødvendige klasser. Generisk kode hænger således sammen med virtuelle
metoder, dynamisk binding og polymorfi. En samling af funktioner, som ikke er medlemmer af
klasser, og som benytter virtuelle metodekald er derfor højest genbrugelig, som visualiseret i
figur 5-2, hvor adskillige klientmoduler og klasser bindes sammen af genericiteten i den
mellemliggende kode. Generisk kode er genbrugelig i den forstand, at den klistrer forskellige
klient-elementer dynamisk sammen med objekter af forskellige klasser uden at skulle undergå
ændringer.
Figur 5-2: Generisk kode som klister-element mellem klienter og klasser.
Det er klassens virtuelle metoder, som suverænt bestemmer, hvordan klassen kan anvendes i
5.3.6 Polymorfi og genbrug 397

generiske kodefragmenter. Da generisk kode er ønskværdig, er virtuelle metoder også
ønskværdige. Spørgsmålet bliver altså, hvilken regel der bestemmer om en given metode skal
være virtuel eller ej. Det simple svar er, at en generel klasse skal indeholde mange virtuelle
metoder og at en specifik klasse skal indeholde få nye virtuelle metoder, dvs. ud over de, der er
defineret i baseklassen. Men det kan også betale sig at se på, hvor meget polymorfi der egentlig
er brug for i forbindelse med den aktuelle klasse.
Generelt er de virtuelle metoder meget små og har karakter af filtreringsmetoder og andre af de
administrative slags. En virtuel metode udfører næsten altid en simpel beregning, et opslag i en
tabel eller en sammenligning af data. Metoder, som kun har relevans for den aktuelle klasse skal
ikke være virtuelle. Metoderne Insert() og Retrieve() i LinkedList-klassen i afsnit
4.5.3 er virtuelle, fordi de af natur kan have en anden betydning i en afledt klasse. Metoden
len() i String-klassen i afsnit 3.7.1 er ikke virtuel, fordi en String sandsynligvis ikke
skal erstattes af andre klasser i generiske funktioner. Problemet er, at man ikke kan vide sig
sikker på, om en klasse alligevel skal bruges polymorft på et senere tidspunkt, og en forhastet
regel vil være, at er man i tvivl, bør metoden erklæres virtuel. Grunden til, at det er forhastet er, at
der også er minusser ved at erklære virtuelle metoder.
Har en klasse virtuelle metoder, vil en forekomst af klassen indeholde en skjult pointer til
klassens virtuelle tabel. Denne tabel, som eksisterer én gang for hver klasse med virtuelle
metoder, indeholder adresserne på implementationerne af de virtuelle metoder for den aktuelle
klasse. Har en klasse således virtuelle metoder, vil en forekomst have et skjult ekstra
pladsforbrug. Under multipel arv vil en instantiering resultere i et antal skjulte
pointermedlemmer, der svarer til antallet af baseklasser med virtuelle metoder. På mit system vil
en forekomst af en klasse med virtuelle metoder, afledt fra 3 baseklasser, indeholde 12 bytes i
ekstra skjulte medlemmer. Og 1000 forekomster kræver 12.000 bytes. Objekter med virtuelle
metoder egner sig således slet ikke til at blive instantieret alt for mange gange i et program, og
vektorer (lineære lister) er da heller ikke typisk komponeret af objekter, hvis typer ikke er kendt.
5.3.7 Generalitet
Generalitet er defineret som muligheden for at skabe programelementer, der kan bruges i mange
forskellige sammenhænge. Polymorfi er til dels en generalitets-mekanisme, fordi den tillader
samme kode forskellige anvendelser. Men der er alligevel begrænsninger for polymorfe klasser,
som beskrevet i forrige afsnit. Det handler på en måde om forskellien mellem arv og generalitet.
I mange objekt-orienterede systemer findes muligheden for, at klienten bestemmer visse
statiske parametre af selve klassen (ikke objektet). I C++ er parameteriserede typer (se afsnit 3.8)
en meget velfungerende mulighed. Det tillader klienten at specificere parametre til selve typen
under instantiering af et objekt. På den måde bliver det muligt at instantiere et objekt af typen A
med relation til typen B, hvor B er bestemt af klienten. For eksempel kan et stak-objekt
instantieres med klient-kontrol over hvilke typer af data, stakken skal arbejde på.
I tidligere versioner af C++ er generalitet ofte realiseret gennem avanceret brug af
præprocessor-makroer eller en ekstern makro-processor (UNIX M4 eller lignende), som tillader
ekspansion af kode under klientens parameteriserede kontrol. En simplificering af dette, blot for
at tjene til eksempel, er en parameteriseret type med brug af typedef:
398 Organisering af klasser 5.3

typedef int T;
// enkel stakklasse, kopierer medlemmer ved Push og Pop
class Stack { // parameteriseret ved T
T* _vec;
unsigned size;
public:
Stack (int sz) : size (sz) { _vec = new T [sz]; }
~Stack () { delete _vec; }
void Push (T& elem) { *_vec++ = elem; }
T Pop () { return *--_vec; }
};
I C++ 3.0, og efter al sandsynlighed også i ANSI C++, vil parameteriserede typer kunne forbedre
sådanne klasser. Det er især fordi sproget selv overtager parameteriseringen og således kan lade
de nye klasser indgå i typesystemet. Ovenstående klasse vil med parameterisering se således ud:
// enkel stakklasse, kopierer medlemmer ved Push og Pop
template
class Stack { // parameteriseret ved T
T* _vec;
unsigned size;
public:
Stack (int sz) : size (sz) { _vec = new T [sz]; }
~Stack () { delete _vec; }
void Push (T& elem) { *_vec++ = elem; }
T Pop () { return *--_vec; }
};
5.3.8 Overvejelser om multipel arv
Multipel arv findes kun i få objekt-orienterede sprog, og er som sådan ikke determinant for, om et
system er rigtig objekt-orienteret. Multipel arv kan gøre programudviklingen mere fleksibel, fordi
modulariseringen kan flettes sammen på flere niveauer, men kan også gøre et klassehierarki
meget kompliceret. Med multipel arv er det vigtigt, at klasserne ikke bliver for specialiserede, at
de er små og funktionelle og at de strengt holder sig til deres egne domæner. Multipel arv er på
sin vis en revers teknik i forhold til lineær arv: hvor lineær arv er en dekomposition af
kompleksitet i programmet, som søger at specialisere de enkelte og fjerneste klasser, er mulitpel
arv derimod en rekomposition af de enkelte klasser i hybride, komplekse moduler. Figur 5-3(a)
viser, hvordan arv delegerer opgaver fra et kompleks ud i de enkelte klasser og senere i figur 5-
3(b), hvordan disse klasser kan kombineres igen med multipel arv. Således reflekterer multipel
arv en forståelse af de enkelte klasser, som skal kunne opfattes som isolerede entiteter i
klassebiblioteket.
5.3.7 Generalitet 399

Figur 5-3: Modulær dekomposition (a) og rekomposition (b).
Det første spørgsmål som falder for, er om det altid er muligt og fornuftigt at arve fra to eller
flere tilfældige klasser og få fordelen ved alle disse klassers funktionalitet i en ny klasse. Svaret er
sådan set nej. Multipel arv er en teknik, der ikke kan bruges vilkårligt. Baseklassernes funktion,
arbejdsområde og specielt dataindhold er bestemmende for, om to eller flere klasser kan
kombineres i en multipelt afledt klasse. Det er derfor nødvendigt med et indgående kendskab til
alle klasser i hierarkiet fra baseklasserne til hierarkiets rod, og det er i praksis tit nødvendigt at
modificere disse klasser mere eller mindre før en multipel afledning er fornuftig. Det skal derfor
understreges, at multipel arv ikke er en grundpille i objekt-orienterede systemer og ikke udgør et
fundamentalt aspekt. Ydermere er multipel arv en relativ ny teknik, set i forhold til eksistensen af
det objekt-orienterede paradigme. I litteraturen er multipel arv defineret med syntaksmæssige
regler og måder at komme udenom problemer på, men en egentlig anvendelse i et større
perspektiv findes ikke endnu. Der er med andre ord ingen bredt accepteret designmetode, som
anvender en objekt-orienteret datamodel med multipel arv som en grundlæggende mekanisme.
Der skal med under alle omstændigheder tænkes målrettet og fremadrettet, når der skal bruges
multipel arv. I eksemplet med de fire LinkedList-klasser i afsnit 4.5.3 er det tydeligt, at de er
konstrueret på samme tid og på den måde er tiltænkt hinanden. De fleste anvendelser for multipel
arv indebærer, at de klasserne opefter i hierarkiet indgår i en kombineret klynge, som alle er med
til at realisere en eller flere multipelt afledte klasser. Det hænger i høj grad sammen med, at en
multipel afledning af to fuldstændig forskellige klasser ikke giver den store fordel for hverken
klassen eller klienten:
class LinkedList;
class Complex;
class ComplexLinkedList :
public LinkedList, public Complex { // ... ?!
En multipel afledt klasse skal derudover i næsten alle tilfælde indeholde ekstra metoder for at
skabe den rigtige forbindelse mellem baseklasserne. Det er sjældent nok at kombinere to klasser
uden at omskrive enkelte metoder eller flytte rundt på dem. Multipel arv er således ikke en teknik
400 Organisering af klasser 5.3

til impulsive udvidelser af hierarkiet. Det er nødvendigt at tænke fremad.
En af grundene hertil er, at multipel arv med relaterede baseklasser vil skabe flere subobjekter
af en fælles baseklasse, som demonstreret i afsnit 4.5.3. En sammenlægning af disse subobjekter
indebærer i C++ en modifikation i de klasser, som ligger umiddelbart under klassen med de
multiple forekomster, hvor den fælles baseklasse erklæres virtuel.
Eksemplet ovenfor kan også overføres på brugen af kommercielle klassebiblioteker, som
forsøges integreret i samme program. Det er sjældent fordelagtigt, og ofte umuligt, at skabe
multipelt afledte klasser af baseklasser, som tilhører hvert sit isolerede hierarki. To
klassebiblioteker, for eksempel med ophav i henholdsvis vinduesstyring og matematik, har tit en
så forskellig opbygning med virtuelle metoder, konstruktøropbygninger og statiske medlemmer,
at en multipel afledning simpelthen ikke kan lade sig gøre. Konsekvensen heraf bliver før eller
siden, at generelle retningslinier for samarbejde mellem klassebiblioteker bliver nødvendig,
eventuelt med perifere grænseklasser til brug for integration med andre, isolerede klasser. Indtil
da må koncentrationen centreres om at anvende multipel arv mellem klasser, der har en vis
kohærens.
Multipel arv er ofte udråbt som en avanceret mekanisme til genbrug af kode. I virkeligheden er
teknikken mere en metode til at relatere klasser på, så de kan bruges polymorft fra flere
forskellige baseklasser. En multipel afledt klasse indeholder typisk ikke mange medlemmer
udover de, der eventuelt skal løse tvetydigheder, fordi baseklasserne normalt er i bunden af
hierarkiet og derfor sjældent er abstrakte klasser. Ved generelt at anskue multipel arv som en
relationsmekanisme i stedet for en genbrugsmekanisme bliver vi automatisk mere fremsynede.
Det gælder nu ikke om at få en "hurtig profit" ved at arve, men om senere at kunne benytte den
multipelt afledte klasse polymorft fra flere forskellige baseklasser. Et eksempel herpå er et
generelt hierarki til organisering af vinduer i et grafisk miljø. Vinduer har ofte forskellige
attributter, bla. menuer og gensidigt udelukkende "knapper", som danner indholdet af vinduerne.
Disse attributter bliver determinanter for, hvordan et vindue kan manipuleres udefra. I følgende
eksempel findes fire forskellige attributter, som normalt er til stede i en grafisk brugerflade:
redigeringsboks (EditBox), tænd/sluk-knap (RadioButton), menuvalg (Menu) og ikon
(Icon). Disse fire elementer er erklæret i hver sin isolerede klasse, ligesom et generelt vindue
(Window), som beskriver dimensioner og ramme.
Med disse grænsefladeprimitiver skabes nu fire nye klasser, alle lineært afledt fra Window,
som beskriver henholdsvis vinduer med redigeringsboks(e), vinduer med tænd/sluk-knap(per),
vinduer med menu(er) og vinduer med ikon(er). De fire nye klasser er således subklasser af
Window, men ikke af de fire attribut-klasser. Der afledes altså ikke multipelt. Der er flere
principielle grunde: et vindue med attributter er for forskellig fra en enkelt attribut til, at de kan
have et tilhørsforhold i type. Desuden skal "et vindue med ikoner" klart kunne have mere end én
ikon, hvorfor der bruges klientering (med en pointer) i stedet. Men allerede under oprettelsen af
de fire specifikke vindues-klasser kan vi begynde at tænke fremad. Der er sandsynligvis brug for
vinduer med både menuer og ikoner, redigeringsbokse og knapper osv., og disse klasser kan
drage fordel af multipel arv. Derfor erklærer vi Window virtuel i alle klasserne, da der for hvert
vindue kun skal være et enkelt objekt af denne type.
class EditBox; // redigeringsboks
class RadioButton; // tænd/sluk-knap
5.3.8 Overvejelser om multipel arv 401

class Menu; // menu
class Icon; // ikon
class Window; // vindue
// vindue med tilhørende redigeringsbokse
class WinEditBox : virtual public Window {
EditBox* EBlist; // liste af redigeringsbokse
// ...
};
// vindue med tilhørende tænd/sluk-knapper
class WinRadioButton : virtual public Window {
RadioButton* RBlist; // liste af knapper
// ...
};
// vindue med tilhørende menuer
class WinMenu : virtual public Window {
Menu* Mlist; // liste af menuer
// ...
};
// vindue med tilhørende ikoner
class WinIcon : virtual public Window {
Icon* Ilist; // liste af ikoner
// ...
};
At skabe kombinationer af disse klasser er nu trivielt. Vinduer med ikoner og menuer og vinduer
med redigeringsbokse og knapper samt vinduer med alle fire attributter kan erklæres på følende
vis:
class WinMenuIcon : public WinMenu, public WinIcon {
// ...
};
class WinEditBoxRadioButton : public WinEditBox,
public WinRadioButton {
// ...
}
class WinTotal : public WinMenu,
public WinIcon,
public WinEditBox,
402 Organisering af klasser 5.3

...
};
public WinRadioButton {
Det er tydeligt, at disse klasser hænger solidt sammen, at der er tænkt på klasserne i bunden af
hierarkiet, før deres baseklasser er færdigtskrevede. Denne kendsgerning afspejler kompleksiteten
af hierarkidesign med multipel arv og viser samtidig, at samspillet mellem klasser i en større
sammenhæng skaber nye perspektiver i programdesign. Det typesystem, som nye klasser
repræsenterer, skal konstrueres med klassernes egentlige attributter som grundlag. Som
eksemplificeret i afsnit 4.3 er dette ikke en triviel opgave, fordi de færreste reelle klasser
repræsenterer letforståelige abstraktioner.
Figur 5-4: Hierarki af klasser i et vinduessystem.
En vis hjælp er dog at se efter de enkelte klassers egenskaber, og hæfte substantiver og adjektiver
på disse, for eksempel åbent vindue. Skal en ny klasse integreres, bruges disse termer til en tidlig
identifikation af klassens placering. Deler to klasser, som begge skal bruges i forbindelse med
den ny klasse, et substantiv, benyttes multipel arv - uanset, om der forekommer uens adjektiver
mellem de to. Deler to klasser adjektiv, arves fra den vigtigste (med flest datamedlemmer, med
flest afledte klasser eller med flest virtuelle metoder) og den anden klienteres. Metoden kan
karakteriseres som opbyggelsen af et semantisk katalog.
5.3.8 Overvejelser om multipel arv 403

Med et semantisk katalog er det muligt at identificere de væsentligste attributter i alle klasser,
en vigtig ledetråd i valget mellem klientering og arv. En mangel i metoden er hensyntagen til
polymorfi, som kræver nedarvning for at kunne fungere. At det kun er en ledetråd skal derfor
understreges med, at den væsentligste baseklasse ofte også er den, som har egentlig type-relevans
med den ny klasse og derfor vil indeholde de virtuelle metoder, der skal implementeres.
Klassenavn Substantiv Adjektiv(er) Afledt fra Klient af
Window Vindue (ingen) (ingen) (ingen)
Icon Ikon (ingen) (ingen) (ingen)
Menu Menu (ingen) (ingen) (ingen)
WIconMenu Window Icon
Vindue Ikon, Menu
Menu
IconWin Icon Window
Ikoniseret Vindue
Tabel 5-1: Et eksempel på et semantisk katalog over klasser.
Selv om multipel arv virker kompliceret og lidet brugbar kan en model således hjælpe med
udvælgelsen. Tilbage er spørgsmålet om, i hvilke situationer multipel arv gør mest nytte og
hvordan den - set fra den ny klasses synspunkt - skal iværksættes for at opnå de optimale
betingelser i et objekt-orienteret system med genbrugelighed, generalitet og type-ækvivalens. Her
følger et antal sammenhænge, som multipel arv oftest bruges i:
• En multipelt afledt klasse kan kombinere rene virtuelle metoder i en abstrakt klasse med
implementationer af samme metoder i en anden klasse og dermed ved en simpel
nedarvningskonstruktion skabe en fungerende, aktiv klasse for den givne abstrakte
klasse. På den måde kan man tænke sig en generel liste-klasse, som indeholder en
virtuel metode Sort(). Ved multipelt at aflede fra både denne klasse og en anden
klasse, som implementerer metoden Sort() opnås en aktiv klasse, der er i stand til at
sortere elementerne i listen. Ved videre at indkapsle forskellige sorteringsalgoritmer i
klasser er det herved muligt at vælge sorteringsmetode (QuickSort, HeapSort, Merge
Sort etc.) efter behov ved blot at specificere den ønskede sorteringsklasse. Et andet
eksempel kunne være en abstrakt stak, som ved multipel arv kan kombineres med en
liste-implementation, en array-implementation eller lignende.
• Når der arbejdes med polymorfi er det ofte ønskværdigt at have flere forskellige
indgange til samme klasse gennem virtuelle metoder, for derigennem at kunne gøre brug
af så mange generiske funktioner som muligt. En multipelt afledt klasse er en subtype af
alle de klasser, den arver fra, og kan således erstatte enhver af disse i funktionskald, som
forventer den som parameter. Her er tale om en semantisk kontekst, som gør det lettere
at bruge samme objekt i ellers urelaterede dele af et program. En
SortedIndexedList som beskrevet i afsnit 4.5 har den fordel, at den både kan
404 Organisering af klasser 5.3

optræde som indekseret liste, som sorteret liste og som almindelig hægtet liste, og
følgelig derfor kan bruges som parameter i kald til funktioner, der arbejder på objekter
af disse typer. Det giver klassen et umiddelbar stort klientel, som allerede er skrevet og
kan genbruges for instanser af den nye klasse.
• En speciel familie af klasser indkaplser blot konstanter, statiske metoder og/eller statiske
data og kan på sin vis karakteriseres som et "modul". Eksempeler på en sådan klasse er
et matematisk eller grafisk bibliotek, som ikke egner sig til egentlig instantiering, men
som blot samordner et antal relaterede metoder og datastrukturer. En multipel afledning
fra en vilkårlig klasse og et indkapslet "modul" giver den nye klasse adgang til modulet,
som kan benytte sig af de indkapslede faciliteter. Dette er egentlig rudimentær
modulærprogrammering, men viser, hvordan klasser i C++ har alsidighed.
• En af baseklasserne kan have egenskaber, som har betydning for behandlingen af de
andre baseklasser, og som derved mere eller mindre transparent bidrager til en
specialisering af disse klasser. Et eksempel er en klasse, der implementerer bestandige
objekter, dvs. objekter, hvis levetid er på et højere niveau end programmets eksekvering.
Bestandige objekter gemmes på et sekundærlager, og det er administrationen af denne
lagring, der varetages i den bestandige klasse. De andre baseklasser behøver for så vidt
ikke at være klare over denne specialisering, hvorved egenskaben helt kan isoleres i én
klasse. Den multipelt afledte klasse indeholder i dette tilfælde ofte ingen medlemmer,
men erklærer blot et typeforhold mellem baseklasserne (en videre diskussion af
bestandige objekter findes i afsnit 5.6).
• Til test-formål kan det være givtigt at vedligeholde en standardiseret test-klasse, som
varetager nogle basale metoder så som brugerkommunikation, inspektion af virtuelle
metodetabeller og opgørelse af lagerforbrug. Da mange klasser skal gennemgå den
samme type tests, kan en multipel afledning mellem en nyskreven klasse K og en
generel klasse Test samles i K_Test. Der spares både tid og sikres konsistens ved at
bruge samme test-klasse i forbindelse med test af alle nye klasser.
I mange tilfælde er multipel arv altså en teknik, som tillader et kald i et objekt at resultere i et
transparent kald til et andet, ellers urelateret, objekt. I version 2.0 af AT&T C++ Language
System er det nødvendigt at reerklære rene virtuelle metoder i en afledt klasse, der ikke
implementerer dem. Dette krav er fjernet fra og med version 2.1, hvorved multiple afledninger
ofte kan være helt tomme klasseerklæringer. I det følgende eksempel ses, hvordan et kald til en
klasse resulterer i et "parallelt" kald til en anden, fra klassens synspunkt helt urelateret klasse.
class A { public: f(); };
class B { public: virtual f() = 0; };
class C : public A, public B { };
B& bref = new C;
int i = b.f(); // kalder a.f()
5.3.8 Overvejelser om multipel arv 405

Tilbage er at diskutere virtuelle baseklasser. Generelt bør en klasse, der er base for flere andre
klasser erklæres virtuel i disse klasser, for simpelthen at undgå en uønsket dublering af objekter.
Det er sandsynligt, at der i et lavere lag i hierarkiet vil forekomme en multipel afledning, som
resulterer i en dobbelt instantiering af base-objektet. Typesystemet kan omgås ved brug af skopoperatoren,
og et dobbelt-objekt vil i nogle tilfælde ikke kunne opdages og vil være en potentiel
fejlkilde. Man kan sige, at virtuelle baseklasser i næsten alle tilfælde er det ønskelige, og det er
bare ærgeligt, at der ikke arves underforstået på denne måde. Det er på den anden side svært at
opstille endegyldige regler for, hvornår der ikke skal bruges virtuelle baseklasser. Et eksempel
tjener derfor bedre:
I et banksystem er hovedklassen en Kunde. Denne klasse arver fra forskellige administrative
klasser, bla. PersonData og LoenKonto. Klassen LoenKonto er igen nedarvet fra den
generelle klasse Konto, som arbejder med indbetalinger og udtræk samt saldo- og
renteberegninger. Et andet sted i systemet findes andre klasser, som også er nedarvet fra Konto,
nemlig EtableringsKonto og PensionsKonto. Da en kunde udmærket kan have
forskellige konti i samme bank, skal arvingerne af Konto ikke erklære denne klasse virtuel, da
der vil opstå seriøse problemer med pengenes beliggenhed! Der kan i dette tilfælde være mange
Konto-subobjekter i et Kunde-objekt.
Beslutningen om, at en baseklasse skal være virtuel er en smule svær at tage, ikke mindst fordi
den syntaktisk skal nedfældes på et sted, hvor hverken den virtuelle baseklasse eller den afledte
klasse, der bliver direkte berørt af virtualiseringen befinder sig. Der er to omstændigheder, der
skal være til stede for, at en virtuel baseklasse er tilrådelig: først skal baseklassen repræsentere et
subobjekt, der egner sig til multipel arv og dernæst skal dette subbjekt være af så tilpas generel
karakter, at enhver instantiering af objektet kun har en og samme betydning. Med andre ord, hvis
et objekt af baseklassens type repræsenterer et begreb, som i sig selv er udeleligt (for eksempel en
printer), er en virtualisering nødvendig. Modsat, hvis baseklassen kan opfattes på forskellige
måder, givet sammenblandingen med andre objekter under multipel arv (som i eksemplet
ovenfor) er det en dårlig idé at bruge virtuelle baseklasser. En forhastet beslutning på denne front
vil enten skabe unødig tvetydighed i de fjernere afledte klasser eller umuliggøre den lineære
genbrugelighed, der ligger i normal arv. Det er imidlertid sådan, at der meget sjældent er brug for
ikke at erklære en baseklasse virtuel. At den ikke er virtuel som standard har syntaksmæssige og
historiske årsager (multipel arv blev først introduceret i version 2).
5.3.9 Overblik
Objekt-orienteret programmering bliver først en rigtig profitabel teknik, når stadiet over
indkapsling og generel dataabstraktion, nemlig opbygningen af avancerede relationer mellem
klasserne, forstås og sættes i perspektiv til et givet problem. I dette afsnit har vi set, hvordan
valget af relationer skal gribes an, og hvordan klientering, arv og polymorfi på hver sin måde har
grundlæggende egenskaber og muligheder i forhold til klassens grænseflade. I C++ er der visse
andre forhold, en programmør er nødt til at være opmærksom på, hvis en applikation ikke skal
ende i urede. Udover rationaler for abstraktion og relatering er det vigtigt at være opmærksom på
sprogets anvendelse af disse teknikker, så en forståelse for pladsforbrug og effektivitet kommer
på plads. Vi tager tre hovedpunkter op:
406 Organisering af klasser 5.3

• Enhver virtuel metode er i virkeligeheden en pointer til en funktion, som ligger i ethvert
objekt, der er en forekomst af klassen. En klasse med en eller flere virtuelle metoder
indeholder en virtuel metodetabel med adresser, der indekseres med et fortløbende
nummer på en given metode i klassen, hvorefter der foretages et indirekte kald til denne
adresse. Hvis et array på 1000 elementer af en type, der indeholder virtuelle metoder
erklæres, vil et skjult dataforbrug i form af tabeller udgøre 1000 pointere. På mit system
er det 4000 bytes, hvilket forøges med 4000 bytes for hver yderligere baseklasse (under
multipel arv). Vær derfor opmærksom på ikke at overdynge klasser, som skal
instantieres mange gange (dvs. mere end et par snese), med virtuelle metoder. Der er
også et mindre tidsmæssigt overhead i kaldet til en virtuel metode, fordi metodens
effektive adresse først skal beregnes. I praksis er der dog tale om en eller to primitive
instruktioner, hvilket ikke udgør en alarmerende faktor.
• Metoder, der defineres indenfor klassens erklæring eller som erklæres inline
erstatter fysisk metodekaldet på kalderens side. For selv små inline-metoder kan
frekvente kald til dem medføre en betydelig stigning i størrelsen af det eksekverbare
program. Specielt overstyrede operatorer, typekoverteringer, konstruktører og
destruktører, som alle kaldes underforstået og på en måde skjult, kan udgøre en
væsentlig del af programkoden. Her er egentlig tale om en klassisk hastighed-versuspladsforbrug
problemstilling, som ikke lader sig løse ved simple regler. Det er blot
vigtigt kun at bruge inline-metoder i situationer, hvor høj hastighed virkelig er påkrævet.
• Medlemsfunktioner, der kaldes underforstået, skal generelt være meget korte. Idet
klienten ikke direkte kan styre kaldene, vil ineffektive eller overadministrative
konstruktører, typekonverteringer eller lignende tage en stor bid af programmets
kørselstid. Det gælder også overstyrede operatorer samt new og delete, ligesom
tildelinger og initieringer medfører disse skjulte kald. Hvis programmet på mystisk vis
kører langsomt er det sandsynligvis en af de specielle metoder, der er synderen.
Udover konkretiserede områder som disse er kommunikation mellem objekter et
tidskonsumerende element. Gør så vidt muligt brug af referencer og/eller pointere under
interobjekt-kommunikation eller flyt metoder, der modtager parametre af store objekter by-value
ind i klasserne. Ofte skrives metoder i de forkerte klasser (på grund af procedural tænkning), og
modtager unødigt mange og identiske parametre.
5.4 GRÆNSEFLADER
Indkapsling gør ikke blot objekter til centrum for programkonstruktion med både data og
funktionalitet under samme tag, det åbner også nye perspektiver i kommunikationen mellem
programmets bestanddele - objekterne - konkretiseret i udvekslingen af data, visibiliteten og
opfattelsen af datastrukturer samt den semantiske forståelse for objektet: kort og godt,
grænsefladerne mellem objekterne. Grænsefladen er bestemmende for, hvor anvendelig objektet
5.3.9 Overblik 407

er i praksis, og da grænsefladen beskrives ved adgangskontrol og tilgangsmetoder, er en god
grænseflade en fornuftig indkapsling og et sæt brugbare metoder til at jonglere med objektet. En
klasses metoder kan kategoriseres i to grupper, behandlende metoder og grænseflademetoder.
Mens de behandlende metoder implementerer algoritmer og arbejder på objektets data er
grænseflademetoderne ansvarlige for ind- og udlæsning, konvertering og præsentation af data og
er på en måde en hjørnestenen i bestræbelsen på at opnå en ensartethed mellem den eksterne
opfattelse af relaterede objekter.
Grænseflademetoder findes sjældent under andre paradigmer. Struktureret programmering
definerer en grænseflade som en parameterliste og/eller en returværdi i en funktionserklæring. I
den forstand er en grænseflade mere eller mindre begrænset til datastrukturernes udseende. Når vi
arbejder objekt-orienteret indfører vi praktiske, håndgribelige metoder til varetagelse af
objekternes grænseflader og lader disse være den mest betydende faktor for, hvordan objektet
behandles syntaktisk og opfattes semantisk af resten af programmet. Fordi denne type metoder
ikke bruges under andre former for programkonstruktion og derfor udgør et nyt fundament, er en
forståelse for deres sammenhæng med objekt-orienteret programmering vigtig.
Skal man følge de basale objekt-orienterede designmetoder, der eksisterer i dag, er
grænsefladen identisk med skillelinien mellem den åbne og den lukkede del af objektet. Den
lukkede del af objektet, som indeholder de implementations-sensitive data, kan ikke manipuleres
udefra. To ting sikres, nemlig intern konsistens og sikkerhed samt robustheden af den eksterne
kode. Denne definition er korrekt, men ufuldstændig i forbindelse med et konkret
programmeringssprog. Som de fleste sprog indeholder C++ specielle konstruktioner og
muligheder, som gør en udvidet definition nødvendig. Overstyring af operatorer, brugerdefineret
typekonvertering og skop-kontrol mellem baseklasser og afledte klasser i flere led komplicerer
ikke blot selve designet af grænsefladen, men gør den reelt todelt: grænsefladen til klienten og
grænsefladen til den afledte klasse. Klasser skrives med klienter som modtager eller med en
potentiel afledt klasse som modtager, og i de fleste tilfælde, begge. Disse to modtagergrupper er
helt forskellige og et godt grænsefladedesign er derfor i yderste konsekvens bestemmende for en
klasses succes.
Figur 5-5: Dualisme i klassens grænseflade.
408 Grænseflader 5.4

5.4.1 Grænsefladen til klienten
Fra klientens side er det primære spørgsmål "gør klassen det arbejde, den skal", altså fungerer
dens metoder korrekt og indkapsler den ikke fejl, som klienten ikke kan gøre noget ved. Det
næste kriterion er, hvordan klassen gør dette arbejde, stadig set fra klientens side. Når en klasse,
der repræsenterer et specifikt koncept skal tages i brug, er graden af "klient-venlighed" nemlig
bestemt af grænsefladens opbygning. Faktisk er selve abstraktionen nedfældet i
grænseflademetoderne.
Hvilke krav bør en klient så stille til en grænseflade? Spørgsmålet kan ikke besvares entydigt,
da det helt og holdent kommer an på klassens indhold. Men der er overordnede mål, som enhver
klassedesigner bør sætte sig, før klassen udbydes til klienten. Klassens grænseflade skal være
konsistent på flere måder. I metoder, der arbejder på et subset af klassens data, skal dette subset så
vidt muligt altid være det samme. Med andre ord, hvis en Hent()-metode returnerer en
bestemt datastruktur, bør en tilsvarende Indsaet()-metode modtage samme datastruktur.
Ligeledes skal klassens natur æres gennem grænsefladen. Hvis klassen repræsenterer et
algebraisk eller numerisk begreb, bør der være metoder til at behandle objekter af denne klasse
algebraisk eller numerisk. Denne konsistens er til dels tvungen gennem brug af arv og polymorfi,
men i mange andre tilfælde, hvor der ikke er arvefølge mellem to objekter, bør ensartetheden
alligevel være til stede. Hvadenten der er tale om en hægtet liste eller et binært træ, bør den
overordnede grænseflade for de to klasser minde om hinanden. Så der er tale om både
grænsefladens udseende, en kvalitativ faktor, og om dets omfang, en kvantitativ faktor. Klassen
bør være konsistent både i form af metodernes betydning (og det kræver en forståelse for andre
klasser i systemet) og deres antal. hverken for få eller for mange grænseflademetoder er en fordel.
Selvom det ofte siges, at designet skal starte langt væk fra et bestemt programmeringssprog, har
de fleste sprog imidlertid faciliteter, som kan gavne konstruktionsfasen væsentligt, specielt hvad
angår interobjektkommunikation. Derfor følger nu et antal generelle overvejelser om brugen af
konkrete abstraktionsmekanismer i C++, når de bruges i forbindelse med en grænseflade til en
klasse.
• Overstyring af operatorer giver klasser, især de mindre, en mulighed for at udvide
sprogets semantik. Klienten får mulighed for at benytte sig af en standardiseret syntaks i
sammenhæng med forekomster af den nye type. Desværre kan valget af operatorer give
problemer, fordi klassens indhold ofte ikke lader sig blande med andre objekter, hverken
brugerdefinerede eller fundamentale. I så tilfælde må operatorerne vælges meget
forsigtigt og dokumenteres meget præcist. Der skal først og fremmest fokuseres på
klassens indhold på følgende måde: hvordan kan (dele af) objekter af denne type
relateres med andre (dele af) objekter af denne type? Kan de adderes, sammenlignes,
åbnes, lukkes, komprimeres, tømmes eller måske skrives ud? Findes en operator, der
med sund fornuft dækker den operation, der er tale om? Hvis der ikke findes en sådan,
bør en ganske normal metode benyttes i stedet. I anden omgang kan samme spørgsmål
gentages for objekter af denne type sammenblandet med objekter af andre typer -
samtidig med, at vi husker, at typekonverteringer kan erstatte mange operator-
5.3.9 Overblik 409

overstyringer.
• Overstyring af funktioner giver klienten stor frihed, hvadenten funktionerne er metoder i
en klasse eller ej. Denne form for flertydighed er meget håndgribelig, fordi den tillader
samme syntaks (funktionsnavn) med parametre af forskellige typer. Det er egentlig en
syntaksmæssig fordel, fordi klienten ganske simpelt undgår at skulle benytte specielle
funktionsnavne afhængig af typen †
. Klienten skal blot huske, at funktionen f() har en
bestemt mening, og kan så kalde den for alle objekter, for hvilke den er skrevet.
• Brugerdefineret typekonvertering er en teknik, der findes i meget få objekt-orienterede
systemer. Det er en meget avanceret måde, som tillader os at sidestille "klasser" og
"typer" med hinanden uden forbehold, og fortælle klassen, hvordan andre klasser i
systemet kan konverteres til og fra den aktuelle. Det interessante ved netop C++ er, at
konverteringen kan foregå uden klientens indblanding, hvorved klassen selv er ansvarlig
for at kaste og gribe boldene fra andre klasser. Et eksempel på denne form for
abstraktion ses i afsnit 3.7.1, hvor klienten aldrig opdager, at han undertiden arbejder på
substrenge. Brugerdefineret typekonvertering giver også klasseudbyderen en enorm
frihed, fordi han kan overlade det til oversætteren at give objekter af de rette typer til
metoder i klassen eller tilbage til klienten. Når først der findes en konvertering til det
objekt, der skal bruges i en given situation, kan en metode være fællesnævner for
objekter af mange typer. Denne håndgribelige form for polymorfi er illustreret i figur 5-
6, hvor det tydeligt ses, at ved implementation af en enkelt konverteringsmetode (for
eksempel fra A til X) får en klasse umiddelbar adgang til mange andre metoder.
Konverteringen kan både tage formen "fra type" og "til type", implementeret som enten
reel konverteringsmetode i fra-klassen eller som konstruktør i til-klassen.
† Oversætteren vil normalt generere et unikt internt navn på alle overstyrede funktioner og metoder, ofte med ekstra
tegn, der har sammenhæng med parameterlisterne. Dette forhold kan skabe problemer i situationer, hvor der bruges
meget lange overstyrede funktionsnavne: oversætteren kan være nødt til at addere så mange tegn til
funktionsnavnene, at de løber ud over den tillade bredde. Denne fejl fanges ikke af alle oversættere, og vil normalt
resultere i en "dobbeltreferencefejl" fra lænkeren.
410 Grænseflader 5.4

Figur 5-6: Brugerdefineret typekonvertering har også skjulte polymorfe egenskaber.
Der er, for alle typer af grænseflademetoder, en gylden regel: dyng ikke klassen til med et væld
af konverteringsmetoder, operatoroverstyringer og andre metoder, der blot udgør én af mange
måder at komme til klassens data på. Jo simplere des bedre, des mere konsistent og des lettere
forståeligt.
5.4.2 Grænsefladen til den afledte klasse
Enhver klasse bør skrives, så den på et senere tidspunkt kan bruges som baseklasse i en afledning.
Der rejser sig derfor, omend mindre end i sidste afsnit, adskillige spørgsmål vedrørende
grænsefladen mellem de to klasser, basen og den afledte. Det er klart, at grænsefladen skal
implementeres i baseklassen, da den er primær, og at den vigtigste funktion af denne grænseflade
er at beskytte data. Der er imidlertid en åbenlys modsætning i dette mål.
Den afledte klasse skal kunne stå alene og opføre sig overfor klienten som en singularitet, der er
fungerende og effektiv - den skal altså ikke belastes for meget af intern administration og
beskyttelse af data i andet og tredie led. Samtidig skal den afledte klasse ikke kunne manipulere
direkte med data i baseklassen, medmindre denne tillader det. Hvis det altid var lovligt for en
afledt klasse at røre ved baseklassens implementation, kunne enhver klient, der ønskede dette
privilegium blot gøre klassen til base. Så problemet bliver: hvordan skrives baseklassens
grænseflade til den afledte klasse, således at den afledte klasse både bliver tilpas
implementationsuafhængig og samtidig ikke belastes af for mange indirekte kald? Som så ofte er
svaret ikke entydigt, men må bygge på en helhedsvurdering med de obligatoriske forhandlinger
mellem kodestørrelse og eksekveringstid. Der er for så vidt tre muligheder:
1. Baseklassens sensitive data indkapsles private, og skinner slet ikke igennem til den
afledte klasse, der ganske som klienter af baseklassen må benytte de offentlige metoder
som indgang. Denne løsning er kendt fra mange andre objekt-orienterede systemer, har
en stor grad af beskyttelse, men er i praksis meget bindende for effektiviteten i den
afledte klasse. Hvis der forekommer indirekte kald op gennem mange klasser i et
hierarki efter denne metode, kan en klient af en afledt klasse i femte generation komme
til at vente længe på, at en metode gør sig færdig mens den bobler op og ned gennem
5.4.1 Grænsefladen til klienten 411

klassernes tunge, klientorienterede metoder.
2. Baseklassens sensitive data indkapsles private, og der udbydes et antal
adgangsmetoder i den beskyttede del af klassen, som implementeres inline. Herved
får den afledte klasse en stor uafhængighed af baseklassens data for en minimal pris i
eksekveringstid. Kodens størrelse vokser ikke desto mindre for hvert kald til
adgangsmetoderne.
3. Baseklassens sensitive data indkapsles protected. Den afledte klasse tillades
dermed at gøre sig afhængig af disse datas beskaffenhed med en effektivitetsforøgelse i
eksekveringstid til følge. Denne løsning er god i forbindelse med manipulation af data
gennem pointere i den afledte klasse. Det kræver blot, at der lægges vægt på, at den
afledte klasse skal følge visse regler vedrørende implementationen i baseklassen.
Et andet interessant forhold ved den afledte klasse er, at den kan udbygge og/eller ændre på
baseklassens grænseflade mod klienten. Det er på den måde muligt at skabe forskellige
grænseflade-specifikke subklasser af en generel klasse, som hver opfører sig på en speciel måde
og er designet til specielle klienter. Specialiseringen omfatter både konverteringer, operatoroverstyringer,
adgangskontrol og konstruktion. De fire klasser, der alle er former for hægtede
lister gennem afsnit 4.5 er et eksempel på dette, idet de afledte klasser næsten udelukkende
udbygger med grænseflademetoder.
5.5 KLASSER SOM PROCESSER
Det meste af programmeringsaktiviteten i C++ handler om at skabe abstrakte datatyper, som
bruges på samme måde som de fundamentale. Vi har også set, hvordan datatyper ved brug af arv
og polymorfi kan blandes sammen og præsenteres for klienten på en ensartet og robust måde. En
anden anskuelse af klassebegrebet går ud fra klassens processerende egenskaber frem for dens
dataindhold; klassen beskriver en aktiv del af programmet, en proces. Faktisk er forskellen blot,
at det væsentlige, der skinner igennem til klienten ikke er klassens data, men klassens algoritme.
De data, der arbejdes på, er enten mindre væsentlige eller bliver leveret af klienten selv, og
klassen bliver til en slags indkapslet og velpræsenteret algoritme. Et eksempel på en indkapslet
algoritme er en liste-klasse, som arbejder på polymorfe hægter. Klienten kan indsætte vilkårlige
data i listen, hvis egentlige abstraktion er mekanismerne for indsættelse, søgning osv. Listeklasser
har da også normalt blot et enkelt pointer-medlem.
De forskellige metoder og sproglige mekanismer i C++ gør proces- eller algoritmeindkapslende
klasser lette at skrive. Det eneste, der skal være klart, er algoritmens beskaffenhed,
altså hvad den egentlig gør og hvordan. Det er til gengæld ikke så let endda, fordi en algoritme
netop er så svær at abstrahere fra en given programkompleksitet. De funktions- og
procedurebiblioteker, der benyttes i de fleste systemer er ikke helstøbte elementer, der blot kan
sammensættes til et fungerende program.
412 Grænseflader 5.4

5.5.1 Algoritmers transparens
En vigtig, og i konventionelle systemer ofte overset faktor, er en given algoritmes transparens.
Spørgsmålet er rettet mod hvor meget af algoritmens indre funktionalitet, der er brug for på den
anden side af grænsefladen, altså hos klienten. I nogle sammenhænge kan klienten funktionelt
abstrahere fra hele algoritmen, for eksempel i grafiske subsystemer eller matemetiske rutiner. I
andre må elementer af klientens verden blive en del af algoritmen, for eksempel en søgning eller
sortering.
At tale om en algoritmes transparens er altså en kvalitativ vurdering af, hvor meget vi kan
tillade os at skjule fra klienten uden at miste noget væsentligt. Metoderne bør ideelt indkapsles, så
klienten slet ikke bør bekymre sig om implementationerne. Det virker også i praksis, men det
glemmes ofte, at klienten i høj grad skal bekymre sig om hvad og i hvilken rækkefølge metoden
laver. Enten brydes en enkelt proces på et objekt op i flere efterfølgende metodekald, hvor
klienten har mulighed for indblanding mellem kaldene, eller også må metodekaldet involvere
ekstra information om klientens ønske. Overvej for eksempel en traversering af en binær
træstruktur, som forekommer triviel, men alligevel problematisk:
class BinTree {
struct BinNode { BinNode *Left, *Right; } *root;
public:
// ...
void inOrderTraverse (BinNode* = root);
};
void BinTree::inOrderTraverse (BinNode* cursor) {
if (cursor->Reft) inOrderTraverse (cursor->Reft);
// gør noget ved hægten ...
if (cursor->Right) inOrderTraverse (cursor->Right);
};
I midten af traverseringsmetoden skal BinTree pludseltig tage stilling til, hvad der skal gøres
ved indholdet af hægten. Enten må metoden skrives, så en virtuel funktion kaldes, som klienten
kan skrive i en afledt klasse, eller også må klienten som parameter overføre information til
inOrderTraverse(), så metoden ved, hvad den skal gøre. I dette tilfælde er transparensen af
algoritmen inorder traversering af binært træ meget lille - klienten skal være så meget med i
arbejdsgangen, at den skal forstås til det inderste. Det kan godt være, at implementationen af
metoden kan skrives på en ikke-rekursiv eller anden måde, hvor klienten kan være ligeglad, men
for at benytte sig af metoden, skal en vis viden om algoritmens opbygning være kendt. Det er
naturligvis klart, at en algoritme og dens implementation ingenlunde er det samme, hvorfor det er
algoritmens, og ikke implementationens, transparens, der er interessant.
Klasseudbyderen skal altså i høj grad tage stilling til, hvor transparent en given operation på
objekter af klassen er, og finde en passende metode, hvorpå klienten kan være med.
5.5.1 Algoritmers transparens 413

5.5.2 Datastrukturers transparens
Helt analogt med algoritmers transparens er en transparensen af en indkapslet datastruktur præcis
ligeså vigtig at være klar over. Det er ydermere en erkendelse, som har betydning for både
grænseflademetoder og adgangskontrol. En datastruktur bruges i næsten alle klasser som
fundament for klassens indre virkemåde. Klasseudbyderen må tage stilling til, om den
datastruktur, som klassen bygger på, er væsentlig for klienten eller ej. I mange tilfælde er
klassens fundamentale datastruktur en implementationsdetalje, som klienten ikke behøver være
vidende om, men ofte er den identisk med klassens abstraktion, og må skinne igennem til klienten
i en højere grad.
Eksemplet fra forrige afsnit med et binært træ ses nedenfor i sammenligning med en generel
stak-klasse. Begge klasser er en abstraktion af en datastruktur, men stakken er mere afgrænset. En
klient af Stack skal blot vide, hvordan en stak fungerer. Datastrukturen, der underbygger
klassen, kan følgelig være en hægtet liste, et array eller andet; klassen sørger for den eksterne
forståelse af strukturen som en stak. Med BinTree-eksemplet er situationen næsten den
samme. Klassen repræsenterer en kendt datastruktur, men i dette tilfælde er anvendelsen af
strukturen så meget mere kompliceret, at implementationen bliver meget lig den eksterne
forståelse, ligemeget hvad klasseudbyderen gør for at indkapslse den. Når der skal arbejdes med
en binær træstruktur er det nødvendigt at kunne komme tæt på de enkelte hægter, bytte dem
rundt, rearrangere træet osv. Derfor er datastrukturen ikke transparent, og må skrives, så den
skinner igennem til klienten.
class Element;
class Stack {
// ...
public:
void Push (Element&);
Element& Pop ();
};
class BinTree {
// ...
public:
Element& getParent ();
Element& getLeftChild ();
Element& getRightChild ();
void insertParent (Element&);
void insertRightChild (Element&);
void insertLeftChild (Element&);
};
414 Klasser som processer 5.5

Den mest åbenlyse måde at gør dette på for BinTrees vedkommende er at placere
strukturens implementation i den beskyttede del af klassen, så klienten i en afledt klasse kan
udbygge med de metoder, der er brug for.
5.5.3 Modulærprogrammering
Man skal ikke overse klassemekanismens mulighed for indkapsling af konstanter og globale
funktioner i "modul-klasser", som letter organiseringen af biblioteker, header-filer og meget
andet. Et klasse, der optræder som modul, karakteriseres ved, at den kun indeholder statiske
konstanter og eventuelt et antal friend-metoder. Fordelen ved denne modularisering er dels en
samling af alle konstanter, der har med et bestemt overordnet område at gøre, og dels, at navnene
på disse konstanter ikke forurener det globale navnerum. Modularisering er, som eksemplificeret
i afsnit 3.3.10, blot en administrativ teknik.
5.5.4 Differentialprogrammering
At anskue klasser som processer er i virkeligheden en måde at se klasserne som miniprogrammer
på. En proces-klasse er blot en indkapslet del af en større sammenhæng, men er ikke
et egentligt objekt, fordi det aldrig instantieres. Forskellen fra dette til modulærprogrammering er
ikke stor, men kan underbygges med proces-klassernes mulighed for at benytte sig af en form for
differentialprogrammering. Tilgangen til metoderne sker gennem kvalificerede navne, altså med
reference til klassen, hvorved polymorfi er udelukket fordi der ikke er et underforstået objekt og
dermed ingen virtuel metodetabel. Men teknikken er god, fordi den dels sikrer en bestemt
grænseflade til relaterede klasser og dels organiserer relaterede metoder. Det giver mulighed for
mange andre ting, blandt andet overvågning og fejlfindings-dæmoner, som lettere kan integreres i
differentierede klasser end i globale funktioner.
I det følgende eksempel vises nogle skeletter på sorteringsklasser, som bruges på næsten
samme måde som standard-sorteringsfunktioner i C-biblioteker. En klient af klassen Sort kan
kalde sorteringsklassens Sort-metode som om, det var en normal funktion, blot her med skopet
sat til klassens navn.
class Sort {
public:
virtual void Sort (void*, int) = 0;
virtual void Swap (void*, void*) = 0;
};
void IntSort : public Sort {
public:
virtual void Sort (void*, int);
virtual void Swap (void*, void*);
};
5.5.2 Datastrukturers transparens 415

void IntArray {
int* _vec;
unsigned size:
public:
// ...
void Sort () { IntSort::Sort (_vec, size); }
};
Parametiserede typer (se afsnit 3.8) er en anden mulighed. Her differentieres klasserne direkte i
skabelonen, hvilket frigør klienten fra at vælge den rette funktion:
template
void Sort (T* vector, int size);
5.5.4 Funktionoider
Syntaks er vigtig for abstrakte datatyper og for proces-klasser. Klienten er bedre tjent med selv at
implementere en simpel funktion end at bruge en eksisterende klasse med en dårlig grænseflade
og dermed syntaks i anvendelsen af dens objekter. I forbindelse med proces-klasser er det ofte en
enkelt indgang, der er interessant for klienten. Faktisk er en proces-klasse kendetegnet ved, at den
instantieres og derefter kaldes igen og igen med samme metode.
Da instantieringen foregår ved konstruktionen er det metoden, der gentagne gange kaldes, der
er interessant. En god kandidat til omslutning af denne metode er funktionskalds-operatoren, som
kan overstyres med henblik på brugen af objekter af klassen som ganske normale funktioner. Der
er blot den ikke så lidt væsentlige forskel, at klassen har mulighed for at operere med en indre
"status". Skulle en global funktion gøre det samme med statiske data, ville kun den funktion have
mulighed for at operere på dem. Idet en proces-klasse af denne karakter på nogle punkter er
hævet over normale funktionskald og har mulighed for indre statusbehandling, men samtidig
deler syntaks med funktioner, kaldes de funktionoider.
Funktionoider kan bruges i næsten alle sammenhænge, hvor en lille funktion skal bruges igen
og igen for forskellige simple data. Ofte bruges en makro eller en stor, global datastruktur med
samme resultat, men funktionoider giver klienten en større bevægelsesfrihed i form af en nydelig
syntaks. Specielt i multiprogrammerede systemer er funktionider brugbare, fordi de kan deles
mellem flere processer. De kan således repræsentere en sanhedsværdi for, om en enhed er fri, om
en besked er modtaget eller om der er lavvande i lageret. De er også som syet til implementering
af dæmoner, små overvågningsprocesser, der af og til skal bruges af applikationerne.
class Prime {
unsigned currentPrime;
unsigned nextPrime ();
// ...
public:
416 Klasser som processer 5.5

Prime () : currentPrime (0) { }
virtual operator unsigned () { return nextPrime (); }
// ...
};
Funktionoider kan også benytte andre operatorer end (), men hovedreglen er, at en eller få
syntaksmæssigt enkle indgange giver objekter af klassen sin styrke. I eksemplet nedenfor vises,
hvordan semaforstyring kan indkapsles i en funktionoide-klasse med overstyringer af
fortegnsoperatorerne + og - samt dernæst benyttes til simpel ressourcedeling. Semafor-klassen
kan faktisk med en smule tilpasning bruges i multiprogrammerede systemer og sørge for en
meget enkel, men effektiv kontrol med delte enheder og gensidig udelukkelse.
// eksempel 5-3
// en generel lineær semafor
class Semaphore {
int nr; // antal ressourcer
public:
Semaphore (int i = 1) : nr (i) { }
void operator+ () { // fortegnsplus (monadisk)
while (nr

sammenhænge, enten implementeret som letvægtsprocesser eller som bestandige objekter.
Når to eller flere processer skal deles om et objekt, kræver det en global instantiering af klassen,
som alle de separat oversatte programmer lænker sig til. Operativsystemet spiller en stor rolle, og
på systemer, som ikke understøtter objekt-orienteret dynamisk lænkning er det mest af akademisk
interesse. En objekt, der skal deles mellem mange forskellige processer må naturligvis have et
globalt skop og en levetid, der ikke er bestemt af de enkelte processer, der kører på et vilkårligt
tidspunkt. Objekterne skal have en vis bestandighed, et forhold, en egenskab, der diskuteres i
næste afsnit. Eksempler på emner til objekter, der kræver deling mellem processer er semaforer,
I/O-klasser, message-passing mekanismer og pipe-klasser. Såfremt det tillades af systemet kan
statiske objekter befinde sig i dynamisk-link biblioteker (DLL'er eller lignende), som kan
benyttes af flere processer på samme tid.
5.5.6 Arv og brugerdefineret lageradministration
Det følgende eksempel på brugerdefineret lageradministration er en klasse CustMemMgr
(Custom Memory Manager), der implementerer en simpel first-fit lageradministration, som på
klasse-basis kan erstatte den indbyggede. Det er tanken, at andre klasser arver fra CustMemMgr
og dermed overtager overstyringerne af new og delete. CustMemMgr er en statisk klasse,
som vil benytte samme lager for alle afledninger og instantieringer. Den anvender et lagerområde
som heap, dvs. som helt frit lager, og har altid en pointer til starten på det. Den indeholder også
en liste over frie blokke, som tidligere har været allokeret men som er blevet frigivet til
"systemet" igen. Disse blokke, som ved hyppig allokering af objekter af forskellig størrelse leder
til fragmentering af lageret, bliver gennemgsøgt inden lageret tages fra heap'en.
// eksempel 5-4
// lageradministrationsklassen CustMemMgr
#include
#include
const unsigned MEMSIZE = 0x4000; // størrelsen på lageret
class CustMemMgr {
typedef struct free_block { // beskriver en fri blok
uns igned size; // størrelsen på blokken
free_block* next; // adressen på næste blok
} *FBP; // en pointer til en blok
static char memory [MEMSIZE]; // det præallokerede lager
static FBP heap; // starten af det fri lager
static FBP freelist; // liste af fragmentering
static unsigned avail, hwm; // frit lager i bytes
protected:
de i sig selv er opdelt i mindre objekter.
418 Klasser som processer 5.5

void Dump (const char*); // dump alt til en fil
public:
static void* operator new (size_t); // vores allokator
static void operator delete (void*); // vores deallokator
};
// initiér de statiske medlemmer i CustMemMgr
char CustMemMgr::memory [MEMSIZE];
CustMemMgr::FBP CustMemMgr::heap = FBP (CustMemMgr::memory);
CustMemMgr::FBP CustMemMgr::freelist = 0;
unsigned CustMemMgr::avail = MEMSIZE;
unsigned CustMemMgr::hwm = 0;
// allokeringsfunktion/operator, kaldes før konstruktøren
void* CustMemMgr::operator new (size_t size) {
if (freelist) { // fragmenteret lager?
FBP last = 0; // husk forrige hægte
for (FBP fbp = freelist; fbp; fbp = fbp->next) {
if (fbp->size >= size) { // er blokken stor nok?
if (last) last->next = fbp->next;
else freelist = fbp->next;
void* ptr = (void*)
((char*)(fbp) + sizeof (free_block));
avail -= fbp->size + sizeof (free_block);
return ptr; // returnér da denne
}
last = fbp;// ellers følg efter hægten
}
}
// ingen klumper data i det fragmenterede lager var
// store nok, brug i stedet lager fra heap'en
if (hwm + size + sizeof (free_block) next = 0, heap->size = size;
void* ptr = ((char*) heap + sizeof (free_block));
heap = FBP ((char*) ptr + size);
avail -= size + sizeof (free_block);
hwm += size + sizeof (free_block);
return ptr;
}
else return NULL; // ikke mere lager!
}
// deallokeringsfunktion, kaldes efter destruktøren
5.5.6 Arv og brugerdefineret lageradministration 419

void CustMemMgr::operator delete (void* ptr) {
FBP p = FBP ((char*) ptr - sizeof (free_block));
p->next = freelist, freelist = p;
avail += p->size + sizeof (free_block);
}
// en enkel dump-funktion af lageret
void CustMemMgr::Dump (const char* file) {
ofstream of (file, ios::binary | ios::out);
of.write (memory, MEMSIZE);
}
Klassen CustMemMgr er et godt eksempel på modularisering. Men arvemekanismen i C++
tillader os at nedarve egenskaberne (stort set kun de to operatoroverstyringer) i andre klasser, som
blot behøver angive CustMemMgr som baseklasse for at erstatte lageradministrationen. For
eksempel,
class String : public CustMemMgr {
char* rep;
public:
String ();
String (const char*);
String (const String&);
~String ();
String& operator= (const String&);
operator const char* () const;
int operator== (const String&) const;
// ... andre interessante funktioner ...
};
Forekomster af String vil kunne allokeres dynamisk med new således at det er den
brugerdefinerede lagerstyring fra CustMemMgr, der benyttes. Læg mærke til, at String ikke
foretager sig andet end at angive baseklassen, mere skal der ikke til. En lille detalje i denne
implementation er for øvrigt interessant. Alle medlemmer i CustMemMgr er erklæret
static, hvorfor de kun eksisterer én gang. Der kan med andre ord kun være en "kopi" af
lageradministratoren. Hvis disse medlemmer ikke var statiske, kunne de afledte klasser ved hjælp
af virtuelle og ikke-virtuelle baseklasser styre individuelle, separerede lageradministratorer.
5.6 CONTAINERKLASSER
Vi har stiftet bekandskab med en bestemt type objekter flere gange gennem de sidste kapitler,
som har den særlige egenskab, at de dynamisk indeholder objekter af andre typer. Klasser, der
beskriver disse typer objekter går under fællesbetegnelsen containere. En container er et objekt,
420 Klasser som processer 5.5

som indeholder en pointer eller reference til et andet objekt, eller hvis medlemsforekomster har
denne egenskab. LinkedList og de relaterede klasser, der repræsenterer køer, stakke og
buffere er typiske eksempler på containere.
Man kan sige, at en container er en avanceret datastruktur med udbygget anvendelse i form af
medlemsfunktioner. Containere er de fundamentale byggesten i programmerne, selv i normal
procedural programmering forekommer containere også i form af komplekse datastrukturer og
funktioner til manipulation af dem. Mange objekt-orienterede systemer leveres med et standard
sæt af containerklasser (ligesom C++ normalt leveres med et standard I/O-bibliotek), for
eksempel indeholder både Smalltalk og Eiffel et stort antal, der kan udbygges og modificeres af
programmøren. Eftersom C++ ikke har et standard sæt af containere, er det fornuftigt at opbygge
et antal generelle klasser til eget brug, der kan videreudvikles og genbruges. En container har
typisk en grænseflade, som indeholder en indsættelses-metode og en udtagnings-metode.
Klienten er dermed i stand til at indsætte objekter og udtage dem igen efter behov. Afhængig af
den datastruktur, som containeren beskriver, kan der også findes metoder til traversering,
sortering, søgning eller beregning.
5.6.1 Objekters ejerforhold
Inden vi begynder at skrive containerklasser, skal et fundamentalt koncept på plads i forståelsen
af, hvor et objekt hører til. Grunden til dette er, at objekternes destruktion skal sikres - de skal
deallokeres og de skal kun deallokeres en gang. Når et objekt befinder sig i en container, dvs. når
containeren indeholder en pointer til objektet, siger vi, at containeren "ejer" det pågældende
objekt. Selv om objektet teknisk set ikke er instantieret inde i containerklassen er det alligevel en
vigtig erkendelse. For siden en container refererer sine objekter indirekte, skal disse objekter
allokeres dynamisk. Og eftersom det skal være klienten, der bestemmer typen af objekter i en
container, skal klienten allokere dem.
Hermed opstår så spørgsmålet om, hvem der skal deallokere dem igen. Klienten kan have dette
ansvar, men det er besværligt og trivielt. Derudover kan man forestille sig, at en container
kopieres med en simpel tildeling, hvorved klienten ikke har de nødvendige adresser på de
dynamiske objekter, der er allokeret. Så skal kilde-containeren (som klient) selv adminstrere
deallokeringen, og med mange forskellige containere, der kan kopieres til hinanden, begynder det
at blive rigtigt kompliceret.
Derfor er reglen, at containeren ejer de objekter, den indeholder, og dermed er ansvarlig for
udtrykkelig destruktion af dem. Af denne regel følger, at det er ulovligt at indsætte andet end
dynamisk allokerede objekter i en container. Hvis vi nemlig gør det, vil både containeren og
oversætteren forsøge at deallokere objektet henholdsvis underforstået og udtrykkeligt. Når en
container forlader sit skop, vil dens destruktør automatisk fjerne alle objekter, der befinder sig i
containeren på det tidspunkt ved udtrykkeligt at delete dem. Af reglen følger envidere, at når
et objekt tages ud af en container, så har den pågældende klient ansvaret for destruktionen.
Hvis flere containere har brug for at deles om objekter, er det muligt at undgå en dobbelt
destruktion ved introduktion af en mellemliggende container, som ejer det pågældende objekt, og
som er transparent for containeren i den forstand, at alle kald til medlemsfunktioner i den
mellemliggende klasse vil fortsætte direkte til det egentlige objekt - med undtagelse af
5.5.6 Arv og brugerdefineret lageradministration 421

destruktøren, som er tom. På den måde undgås multiple destruktioner af de samme objekter. Det
kan også lade sig gøre gennem at overtage kontrollen med lageradministrationen i de klasser, der
skal ind i containeren. Klassespecifikke overstyringer af operator delete kan undersøge,
om lageret allerede er frigivet for det pågældende objekt og blot returnere, hvis det er tilfældet.
5.6.2 Polymorfe containere
Containere er mest interessante, når de har en bred anvendelse og kan bruges i flere forskellige
sammenhænge. For en containerklasse er polymorfi todelt. Dels er det en fordel, hvis koden for to
klasser (for eksempel en kø og en stak) er den samme, og dels er det ønskværdigt, at den samme
container kan indeholde objekter af forskellige typer.
For at opnå det første, er det nødvendigt at skrive en abstrakt containerklasse, som definerer,
hvordan containere generelt skal opføre sig samt en generel klasse, der definerer et objekt i
containeren. Prototyper på sådanne klasser kan se ud som følger:
class ContainedObject { // et objekt i containeren
};
class AbstractContainer { // containeren selv
protected:
unsigned count; // antal objekter i containeren
AbstractContainer () : count (0) { }
public:
virtual ~AbstractContainer () { };
virtual Insert (ContainedObject*) = 0; // indsæt
virtual ContainedObject* Retrieve () = 0; // udtag
// ...
};
Klassen ContainedObject er en overordnet type, der beskriver de objekter, der kan befinde
sig i enhver container, mens AbstractContainer er den abstrakte type, der beskriver de
minimale forudsætninger for en container. Der skal arves fra disse to, før der fås instantiérbare
klasser, der kan bruges til noget. Eksempelvis kan vi skabe en Stack-klasse, der repræsenterer
en ikke-indeksérbar først-ind-sidst-ud buffer, implementeret internt som en hægtet liste:
class Stack : public AbstractContainer {
class SLink {
friend Stack;
StackLink* next;
ContainedObject* data;
};
SLink* s;
public:
422 Containerklasser 5.6

Stack () : AbstractContainer (), s (0);
virtual ~Queue ( delete s; }
virtual void Insert (ContainedObject*);
ContainedObject* Retrieve ();
};
void Stack::Insert (ContainedObject* o) {
SLink* sl = new SLink, s->next = s, s = sl, s->data = o;
}
ContainedObject* Stack::Retrieve () {
ContainedObject* o = s->data; SLink* sl = s, s = s->next;
delete sl;
return o;
}
Graden af polymorfi på containerklassen kan ses, hvis vi yderligere erklærer en lignende klasse,
for eksempel en Queue, som blot er en først-ind-først-ud buffer. Al kode, der arbejder på en
Stack, vil også kunne arbejde på en Queue, så længe de to klasser arver fra den fælles base
AbstractContainer og anvender dennes grænseflade. På indholdssiden kan en Stack
arbejde med alle typer af objekter, der er nedarvet fra ContainedObject, så vi på den måde
kan forestille os både heltal, kommatal, komplekse tal osv. i samme Stack.
5.6.3 Programmering med containere
Anvendelsen af containerklasser frigør os fra al den trivielle administration af placering og
organisering af data. Containerne overtager simpelthen alle operationer, som vedrører gentagne
operationer på multiple forekomster af homogene data, normalt benyttet i forbindelse med lister
af en bestemt datastruktur. Hvor ofte har man ikke skrevet en datastruktur med en indbygget
hægte, for derefter at konstruere funktioner til administration af disse hægter for netop den
struktur. Med containere skrives koden en gang for alle i en klasse, som kan udbygges i en
afledning eller anvendes på polymorfe objekter. Klienten af en container får en sikkerhed for en
kompleks datastrukturs konsistens og kan koncentrere sig om behandlingen af objekterne ud fra
problemstillingen.
Et sprogmæssigt problem med containerklasser er, at en abstrakt baseklasse ikke altid erklærer
prototyper, som direkte kan bruges i en afledt klasse. For eksempel kan en container, som finder
et bestemt objekt på en nøgle, ikke implementere den rene virtuelle medlemsfunktion
Retrieve(), da der også skal være en parameter. På samme måde med indsættelsesmetoderne,
som måske skal modtage mere end én parameter. Endvidere vil en afledt container ofte arbejde
på bestemte typer af objekter, men bliver grundet de virtuelle metoders prototyper nødt til at
returnere en polymorf reference. Resultatet bliver, at klienten må benytte tvungen
typekonvertering på sin side af kaldet, hvilket er farligt og repetitivt. Den bedste løsning, hvis
containeren er specifik, at omskrive grænsefladen i en afledt klasse og returnere objekter af de
5.6.2 Polymorfe containere 423

ette typer. Den tvungne konvertering bliver således foretaget i klassen, og klienten kan forvente
objekter af de faktiske typer i kald til containeren.
En næsten uundværlig container er en associativ vektor, dvs. en samling af relaterede objekter,
som kan hentes fra containeren ved brug af en nøgle. I eksemplet nedenfor vises en sådan klasse,
kaldet Dictionary, som gør brug af polymorfe indeholdte objekter. Containeren indeholder
en liste af associationer mellem to objekter af typen Associateable, eller subklasser af
denne, og tillader klienten at forespørge om en association med en nøgle. Associative lister har
blandt andet stor anvendelighed indenfor symboltabelbehandling og katalogadministration i det
hele taget. For enkelthedens skyld er klassen simplificeret på en del vigtige områder, for
eksempel under dynamisk allokering af strenge, som blot kopieres som pointere.
// eksempel 5-5: et generelt, associérbart objekt
class Associateable {
public:
virtual int operator== (Associateable& a) { return 0; }
} NoAssociationFound; // bruges som fejlkode
// et katalog over associationer
class Dictionary {
struct AssociatedPair {
Associateable* First, *Second;
AssociatedPair* Next;
AssociatedPair (Associateable* a, Associateable* b) :
First (a), Second (b) { }
~AssociatedPair () { delete First; delete Second; }
} *assocList;
public:
Dictionary () : assocList (0) { }
virtual ~Dictionary ();
void Insert (Associateable&, Associateable&);
Associateable* Retrieve (Associateable&);
};
Dictionary::~Dictionary () {
for (AssociatedPair* p = assocList; p;) {
AssociatedPair* temp = p;
p = p->Next; delete temp;
}
}
// indsæt en association i kataloget
void Dictionary::Insert(Associateable& a,Associateable& b) {
AssociatedPair* temp = assocList;
424 Containerklasser 5.6

assocList = new AssociatedPair (&a, &b);
assocList->Next = temp;
}
// hent en association i kataloget
Associateable* Dictionary::Retrieve (Associateable& o) {
for (AssociatedPair* p = assocList; p; p = p->Next) {
if (*(p->First) == o) return p->Second;
if (*(p->Second) == o) return p->First;
}
return &NoAssociationFound;
}
Der arves nu to klasser fra Associateable for at teste containeren. Country indeholder
navnet på et land, mens Code repræsenterer en landekode:
struct Country : Associateable {
char* s;
Country (char* i) : s (i) { }
int operator== (Associateable& a) {
return !strcmp (s, ((Country&) a).s);
}
// ...
};
struct Code : Associateable {
unsigned c;
Code (unsigned i) : c (i) { }
int operator== (Associateable& a) {
return c == ((Code&) a).c;
}
// ...
};
Disse to klasser er ingenlunde komplette, men vil dog kunne oversættes. Den tvungne
konvertering i operator==()-funktionerne er temmelig farlig, da der ingen garanti er for om
parameteren er af samme type som klassen. Ikke desto mindre kan disse klasser benyttes i
sammenhæng med Dictionary med følgende funktionalitet til følge:
// eksempel 5-6: anvendelse af associérbare lister
void main () {
Dictionary D;
D.Insert (*new Country ("Denmark"), *new Code (45));
D.Insert (*new Country ("England"), *new Code (44));
5.6.3 Programmering med containere 425

Output:
D.Insert (*new Country ("USA"), *new Code (1));
// hvilket land har kode nummer 44?
Country* c = (Country*) D.Retrieve (Code (44));
cout

underforståede konvertering til en heltalsværdi, så gennemløbet kan sluttes på den rigtige måde.
class IndexableContainer : public AbstractContainer {
// ...
public:
// ...
ContainedObject* operator[] (unsigned);
};
class ContainerIterator {
IndexableContainer& ic;
unsigned currentIndex;
public:
ContainerIterator (IndexableContainer& i) :
ic (i), currentIndex (0) { }
unsigned operator++ () { return currentIndex++; }
operator int () { return ic [currentIndex] != 0; }
ContainedObject* operator*() { return ic [currentIndex]; }
};
Forekomster af klassen ContainerIterator har næsten sammme semantik som en generel
pointer til en lineær liste. Det letter containergennemløb for klienten, som får en ensartet og
overskuelig måde at besøge alle objekter på. For eksempel,
void printContents (IndexableContainer& c) {
for (ContainerIterator p = c; p; p++) cout

administrationen af dette påhviler enten et dedikeret databasesystem, der kaldes fra programmet,
eller programmet selv gennem filmanipulation. Der er fordele og ulemper ved begge dele. En
database-underbygning betyder mindre kode og større fleksibilitet, for eksempel i forbindelse
med standarder for datalagring og flerbrugeradgang, men gør til gengæld næsten altid
tilgangstiden meget formaliseret og langsom. Et specialskrevet fil-lag i programmet kræver
programmørressourcer, tager tid og kan være en stor potentiel kilde til fejl. Men i begge tilfælde
skal programmøren være klar over, at programmets data kan findes på et sekundærlager.
Principielt er det underordnet, om data findes på disk eller i hovedlageret. Det, vi som
programmører er interesserede i, er at behandle disse data og ikke at læse dem ud og ind og holde
styr på, hvor de befinder sig. Faktisk er selve bevidstheden om et sekundærlager en unødig faktor,
der blot sinker programmets udvikling og gør programmeringen triviel. For at kunne opnå en
transparens i forhold til objekternes placering i systemet må vi skrive klasser, der selv varetager
ind- og udlæsning til sekundærlageret, og som på den måde introducerer et fil-lag, der ikke kan
ses af klienten.
5.7.1 Objekters levetid
Et objekt kan have tre levetider,
• temporært, hvilket vil sige, at objektet oprettes og nedbrydes dynamisk i programmets
eksekverignsforløb, kontrolleret af programmet selv. Det er klart, at brugeren kan har
stor indflydelse på, hvornår temporære objekter allokeres.
• permanent, som er et objekt, der oprettes ved programmets start og nedbrydes, når det
afsluttes. Brugeren har ingen kontrol med allokeringen.
• bestandigt, som gør objektet uafhængigt af programmets kørsel, og som i princippet kan
benyttes af forskellige uafhængige programmer eller processer, endda på samme tid
givet adækvat samtidighedskontrol. Brugeren har samme grad af kontrol over
bestandige objekter som over temporære objekter, og programmet arbejder i princippet
på samme måde med de to.
Temporære og statiske objekter understøttes i C++ ved henholdsvis automatisk/dynamisk
allokering og statisk allokering. Der er faciliteter i sproget til at foretage en (minimal) intern
lageradministration og sikre korrekt oprettelse og nedbrydning. Bestandige objekter understøttes
ikke af C++, og må således implementeres. Det er ofte blevet pointeret, at en udvidet
lageradministration er et kriterion for et objekt-orienteret sprog, men i henhold til minimalistfilosifien
i C++ er faciliteten udeladt.
5.7.2 Implementation af bestandige objekter
428 Bestandighed 5.7

En simpel implementation af bestandighed er to medlemsfunktioner i alle objekter, som skal have
egenskaben, til indlæsning og udlæsning. Det gør ikke objekterne bestandige i sig selv, men giver
dem muligheden for at ind- og udlæse sig selv, når de bliver bedt om det:
class Complex {
double re, im;
public:
// ...
void dumpOn (ostream&); // udlæsning
static Complex* readFrom (istream&); // indlæsning
};
void Complex::dumpOn (ostream& strm) {
strm >> re >> "\n" >> im >> "\n";
}
Complex* Complex::readFrom (istream& strm) {
Complex* c = new Complex;
strm re im;
}
De to medlemsfunktioner dumpOn() og readFrom(), som minder meget om de simple
objekt-I/O-metoder fra afsnit 3.7.4, kan kaldes af klienten for at ind- og udlæse objekter af
Complex med
ostream file ("test.dat");
Complex* c = Complex::readFrom (file);
c.dumpOn (file);
Indlæsningsmetoden er statisk og skal kaldes med direkte reference til typenavnet, der ønskes
indlæst, og vil returnere en ny - dynamisk allokeret - forekomst. Grunden er, at der på
kaldetidspunktet ikke findes et objekt af typen i hvilket nye data kan læses ind, hvorfor metoden
ikke kan kaldes for et eksisterende objekt. Udlæsningsmetoden er en normal medlemsfunktion,
som kaldes med en reference til en forekomst af et aktuelt objekt. Denne metode kan med fordel
være virtuel, fordi en generisk mekanisme for udlæsning af mange forskellige typer objekter så
kan skrives et andet sted i programmet.
Der er to fundamentale svagheder ved denne simple I/O-model. For det første påhviler
organiseringen af data på det eksterne lager klienten, og for det andet er det ikke muligt at udlæse
komplekse objekter, for eksempel polymorfe containerklasser (5.6.2). Det første problem venter
vi lidt med, da det griber ind i principper for dataorganisering på lageret med nøgler, hash- og
søgetabeller. Det andet problem afslører imidlertid et meget dunkelt hjørne i objekt-orienteret
programmering, som er svært at løse med et sprog som C++ uden at foretage adskillige
manøvrer.
5.7.2 Implementation af bestandige objekter 429

Overvej følgende situation: En polymorf container er udlæst i en fil og ønskes nu genindlæst.
Containeren, for eksemplets skyld en LinkedList, kan indeholde objekter af forskellige typer
og skal under indlæsningen rekonstruere alle disse objekter til deres respektive originale status.
Men hvordan ved containeren, hvilken type, den indlæser? Da containeren med stor
sandsynlighed ikke er i arvefølge med de objekter, den indlæser, skal den have eksplicit viden om
typen af det objekt, den læser, af objektet selv. Og da objektet ikke eksisterer endnu, må denne
information stå skrevet på sekundærlageret. Containeren skal altså have objektets type at vide, så
readFrom()-metoden i den rette klasse kan kaldes, ellers render LinkedLists
indlæsningsmetode ind i følgende problem:
LinkedList* LinkedList::readFrom (istream& strm) {
while (data_at_laese)
Insert (???::readFrom (strm));
};
De tre spørgsmåltegn repræsenterer den uvidenhed, som LinkedLists funktion har. Den ved
ganske simpelt ikke, hvilken type den er i færd med at læse ind. For at løse problemet må
dumpOn() skrive en typeidentifikation på strømmen før selve objektet udlæses. Det giver en
indlæsningsmetode mulighed for at identificere objektets type og via en tabel kalde den rette
indlæsningsmetode. Alle klasser får dermed et typenavn eller -nummer, hvilket til dels går stik
imod den objekt-orienterede filosofi om, at et polymorft objekts type i princippet er underordnet
set fra klientens side. Men det er nødvendigt, fordi en baseklasse ikke har den nødvendige viden
om de afledte klasser til at identificere en objekttype. Oversætteren har denne viden, men er ude
af billedet, når programmet eksekveres.
Vi implementerer altså en virtuel Type()-metode (undertiden kaldet isA() i gængse
klassebiblioteker), som returnerer en identifikation af objektets type. En sådan metode findes
indbygget i enkelte andre objekt-orienterede sprog, og giver her en heltalskonstant, som unikt
beskriver den givne klasse. I C++ er vi nødt til at gøre dette eksplicit, for eksempel med en
opremsning af alle ikke-abstrakte (dvs. læsbare) klasser i systemet:
enum Class { aString, aComplex, aLinkedList, NoOfClasses };
Type()-metoden har en meget simpel implementation, og returnerer blot typeidentifikationen
på objektet. Men vi er nødt til at relatere klasser, der kan indlæses fra sekundærlageret i samme
klynge, fordi Type() skal bruges polymorft. Vi afleder således alle klasser fra en fælles
baseklasse, for eksempel Persistent:
class Persistent {
// ...
public:
// ...
virtual Class Type () const = 0;
};
430 Bestandighed 5.7

Herefter implementeres Type() på følgende måde i de afledte klasser:
class String : public Persistent {
// ...
public:
// ...
virtual Class Type () const { return aString; }
};
class Complex : public Persistent {
// ...
public:
// ...
virtual Class Type () const { return aComplex; }
};
class LinkedList : public Persistent {
// ...
public:
// ...
virtual Class Type () const { return aLinkedList; }
};
Ethvert objekt er altså bekendt med sin type. Læg mærke til, at typeinformationen ikke optager
plads i objektet som en konstant, men i stedet som en virtuel funktion. Det tillader os at
undersøge typen på et bestandigt objekt i en situation, hvor vi er nødt til at have denne
information, for eksempel når et objekt skal udlæses. Dermed kan vi også skrive funktioner af
den type, der ikke bør findes i et velskrevet objekt-orienteret program:
const char* typeNavn (Persistent& p) {
switch (p->Type ()) { // eksplicit typecheck!
case aString : return "String";
case aComplex : return "Complex";
case aLinkedList : return "LinkedList";
default: return "Unknown";
}
}
På samme måde er det nu muligt, når et objekt udlæses, at skrive objektets klassenummer, så en
indlæsningsmetode i Persistent kan kalde en anden metode i den rette afledte klasse. Når
dumpOn() kaldes, udskrives således returværdien af klassens Type()-metode, efterfulgt af
objektets egentlige data. Da denne metode er virtuel, er en udlæsning af en polymorf container
ikke noget problem. Indlæsningen involverer et eksplicit type-check på det indlæste objekt og et
kald til den rette readFrom()-metode.
5.7.2 Implementation af bestandige objekter 431

5.7.3 Administration af bestandige objekter
Klassebiblioteket, der beskrives i kapitel 8, indeholder en simpel mulighed for bestandige
objekter. I denne implementation bruges eksplicit type-information i alle klasser,
udlæsningsmetoderne er virtuelle og indlæsningsmetoderne er statiske. Hierarkiets øverste klasse,
Object (som blandt andet har samme funktionalitet som Persistent fra forrige afsnit) har
en tabel over adresser på readFrom()-metoder i alle ikke-abstrakte klasser. Denne tabel
initieres af en statisk erklæring i det respektive klassemodul, som kalder en
"annonceringsmetode" i Object. På den måde garanteres, at tabellen er initieret før main():
// Tabel over adresser på indlæsningsmetoder
Object* (*readFromTable) (istream&) [NoOfClasses];
// en simpel annonceringsmetode
bool Object::Announce (Class n, Object* (*p) (istream&)) {
readFromTable [n] = p;
}
// prototype på en readFrom-metode
Object* String::readFrom (istream&);
// initiering af adressetabel-indgang for denne klasse
static init = Object::Announce (aString, String::readFrom)
Et krav til alle dumpOn()-metoder er, at de først skal kalde baseklassens dumpOn() og
dernæst udlæse sig selv. Object::dumpOn() ser således ud:
void Object::dumpOn (ostream& s) { s classNumber;
return (readFromTable [classNumber]) (s);
}
432 Bestandighed 5.7

Denne måde at administrere kald til statiske metoder i polymorfe objekter kan sammenlignes
med programmørkontrollerede virtuelle kald. Der er ikke megen forskel fra dette til oversætterens
egen implementation af rigtige virtuelle funktioner. Den eneste reelle forskel er, at systemet er
mere statisk i sit design. Hver gang, en ny klasse skal introduceres, skal klassenavnet også
oprettes i opremsningen, som står i en global benyttet headerfil. Det betyder direkte, at hele
systemet skal genoversættes, når en ny klasse introduceres, en ikke lille pris at betale for eksplicit
typekontrol. Det er muligt at forestille sig en oversætter, som er i stand til automatisk at fortælle
en klasse, hvilket nummer den har. En sådan oversætter gør det muligt at påføre systemet en ny
klasse uden at skulle foretage en global genoversættelse.
Figur 5-7: En adressetabel udgør programmørkontrolleret polymorfi.
Formatet på sekundærlageret indeholder således al information tilstrækkelig til at oprette
objekter, der er blevet udlæst på et tidligere tidspunkt. Formatet på en sådan fil kan se ud som
følger for en LinkedList, der indeholder to String-objekter og et Complex-objekt
(formatteret pænt for læsbarhedens skyld og med kommentarer i parantes):
2 4 (en LinkedList med fire objekter)
0 13 Første streng (en String på 13 tegn)
0 12 Anden streng (en String på 12 tegn)
1 4 -1 (en Complex (4,-1))
1 3.3333333 0 (en Complex (3.3333333,0))
Hele strukturen kan indlæses med et enkelt kald fra klienten, som kalder fællesnævnermetoden i
Object-klassen:
5.7.3 Administration af bestandige objekter 433

Object& o = *Object::readFrom (file); // indlæs et objekt
if (o->Type () == aLinkedList)
LinkedList& l = (LinkedList&) o;
else
cerr

1 2 2 (objekt 1: en LinkedList på 2 elementer)
2 0 6 Første (objekt 2: en String på 6 tegn)
3 0 5 Anden (objekt 3: en String på 5 tegn)
4 2 3 (objekt 4: en LinkedList på 3 elementer)
5 0 6 Tredie (objekt 4: en String på 6 tegn)
3 (objekt 3 igen)
2 (objekt 2 igen)
De to sidste objekter på sekundærlageret er direkte referencer til to objekter, der allerede findes et
andet sted. Indlæses disse to strukturer lineært, må systemet således holde rede på, at
objektnumrene 2 og 3 allerede er indlæst og blot oprette en reference til det eksisterende objekt. I
nogle objekt-orienterede databasesystemer til C++ skelnes mellem klasserelationer og
objektrelationer på følgende måde. En klasserelation er en pointervariabel (ofte af en bestemt
type, en transparent reference, som er i stand til at udlæse sig selv som en pointer til et
objektnummer) skrevet i klassens implementation, mens en objektrelation er en forekomst af en
bestemt associeringsklasse, som relaterer to objekter. Forskellen er graden af polymorfi i enten
det ene eller i begge objekter.
Systemet kan konfigurere filerne på sekundærlageret, så det bliver let at finde et bestemt
objektnummer, hvilket egentlig er det essentielle. Indekseringstabeller eller hash-tabeller er ofte
brugte metoder til dette, ligesom objekter og objektreferencer typisk vil skrives med ud i to
forskellige filer, da de har forskellig mening.
En anden vigtig bestanddel i OODBMS er, at objekterne skal kunne benyttes af en C++programmør
helt uden bekymring om fil-laget. For at opnå en total abstraktion fra sekundærlageret
må operatorerne new og delete overstyres for alle bestandige klasser. Det har
yderligere den fordel, at systemet dynamisk kan udlæse sjældent brugte objekter, hvis
hovedlageret viser sig at løbe tomt.
5.8 KLASSEBIBLIOTEKER
Når de mange forskellige typer af klasser, som er beskrevet gennem dette kapitel skal integreres i
en større sammenhæng, en reel applikation, bliver resultatet et helt bibliotek af klasser. Et
klassebibliotek er fundamentet i alle objekt-orienterede udviklingsprojekter, hvor alle involverede
må være enige om opbygningen for at sikre alle klassernes integritet. Klassebiblioteker sælges
også kommercielt til specifikke formål, for eksempel lettere tilgang til grafiske brugerflader eller
databaser. Ofte støder man på udtrykket et klassehierarki i stedet for et klassebibliotek, en term
der dækker næsten det samme. Et klassehierarki indebærer en opbygning, hvor en enkelt klasse er
rod for alle andre klasser i systemet, mens et klassebibliotek kan indeholde mange ikke-relaterede
klasser.
Udviklingen af et klassebibliotek rejser flere designspørgsmål, som går ud over de enkelte
klassers opbygning. Hvorfor er dette så vigtigt? Fordi klassebiblioteket repræsenterer selve
strukturen af programmet, relationerne mellem klasserne. Specifikationen på de abstrakte
baseklasser i et system, opbygningen af container-klasserne og en direkte associering mellem
objekter, der skal dele funktionalitet, så instantiérbare klasser får den rette grænseflade og kan
5.7.4 OODBMS 435

læne sig bedst muligt op af baseklasserne er de væsentlige punkter. I et udviklingsprojekt er det
essentielt, at alle involverede er enige om en bestemt klasses placering i biblioteket, om dens
grænseflade og virkemåde og dens relation til andre klasser.
Et klassebibliotek skal fra klientens side anskues som et enkelt objektmodul, som lænkes med
applikationskoden til et færdigt program. Klienten modtager typeinformation om klassernes
grænseflade fra header-filerne, som blot indeholder erklæringer på klasserne og eventuelle inlinemetoder
og konstanter. Der er i princippet ingen forskel i anvendelsen af et klassebibliotek i
forhold til et normalt funktionsbibliotek, set fra et oversættermæssigt synspunkt.
5.8.1 Klassebibliotekets anvendelse
Et klassebibliotek har typisk en bestemt hensigt, nemlig at være basis for applikationer af en
særlig type. For at nævne blot et par,
• Grafiske brugerflader, som i sig selv er objekt-orienterede. Vinduer og subvinduer,
præsentationsflader, ikoner, menuer og submenuer, knapper og input-felter kan alle
anskues som objekter med et indhold og en bestemt måde at opføre sig på. Et
klassebibliotek, der arbejder som et mellemliggende lag mellem en applikationsprogrammør
til GUI'er (grafiske brugerflader) og et vinduessystem, kan præsentere
miljøet på en måde, der hæver abstraktionen til et naturligt og passende niveau samt
skjuler ikke blot kompleksitet men også irrelevante, trivielle og forstyrrende elementer.
• Operativsystemer, som har mange softwarekomponenter, der har en relevant betydning
for et program. Arbejdsopgaver som afsending og modtagelse af beskeder, systemkald,
filmanipulation, lagerstyring, semaforstyring og kontrol med ydre enheder kan med stor
fordel for en applikationsprogrammør indkapsles i klasser, som samler relaterede
datatyper og systemkald under ét.
• Under opgaver med datatransmission og datakommunikation, som traditionelt er
opbygget i flere "lag". Hvert lag i en kommunikationsmodel kan implementeres som en
klasse, hvor en baseklasse udgør det laget lige under og en afledt klasse udgør det
umiddelbart øvre. En klient kan på den måde bruge netop det lag, som der er brug for,
uden tab af abstraktion på nogen måde i forhold til den konceptuelle model. Denne
fremgangsmåde er af stor fordel i alle applikationer, som implementerer en trinvist
opbygget model.
• Databasesystemer og dataopsamlingssytemer, som arbejder med bestemte typer og
relationer. Et klassebibliotek, som er let at udvide med nye typer gør systemets
robusthed og ensartethed stor, og kan en gang for alle indeholde implementationer af de
metoder, der er ens for alle typer af data i et system.
436 Klassebiblioteker 5.8

Der er naturligvis uanede muligheder, for objekt-orienteret teknologi er løsningen til mange af de
aktuelle problemer i softwaredesign. De eneste applikationer, der ikke drager nytte af
klassebiblioteker, er enten små og i udviklingstid og kompleksitet meget enkle programmer eller
dele af systemer, der af specifikationsmæssige årsager er nødt til at skrives på en anden måde.
En anden type klassebibliotek, som både er illustrativ som eksempel og som er anvendelig i
mange forskellige applikationer er det generelle klassebibliotek. Et generelt bibliotek indeholder
datatyper, som kan benyttes i næsten alle sammenhænge, fordi de repræsenterer datastrukturer og
algoritmer, der forekommer i ethvert program. Klassebiblioteket XCL i kapitel 7 er af en sådan
type, og er brugbart både som fundament for mere komplekse klasser eller direkte som
underbygning for specifikke programmer.
5.8.2 Klassebibliotekets indhold og opbygning
Indholdet af et klassebibliotek kan opdeles i fem klynger af klasser, som har hver deres bestemte
plads og funktion:
• Abstrakte klasser, som er prototyper på aktive, instantiérbare klasser, og som er et typisk
indgangspunkt for polymorfe kald,
• Aktive klasser, som er de klasser, klienten direkte instantierer og arbejder med eller på,
• Containerklasser, som indeholder indirekte referencer til forekomster af andre klasser af
bestemte typer, både abstrakte og aktive,
• Private klasser, som kun har betydning for bestemte andre klasser i biblioteket, og som
klienten kun arbejder indirekte med eller på,
• Aggregate klasser, eller komplekse klasser, som indeholder forekomster af andre klasser
i biblioteket.
Containerklasser og private klasser kan også selv være abstrakte, mens aktive klasser altid er
instantiérbare. De aktive klasser er enten generelle, applikationsorienterede eller
systemorienterede. Containerklasser er altid associeret med en algoritme eller en datastruktur, der
skal fjernes fra klientens domæne. Aggregate klasser indeholder kun aktive klasser.
Et ofte stillet spørsmål er, hvordan klasserne identificeres. Problemet med at finde de relevante
klasser i et projekt har ofte udgangspunkt i en forkert indgangsvinkel til et objekt-orienteret miljø.
Hvis der kun fokuseres på den sproglige struktur af for eksempel C++, og ikke på anvendelsen af
klassebegrebets forskellige faciliteter, vil man overse og måske forbigå det essentielle. Uden at gå
ind på forskellige teorier for hvordan et objekt-orienteret design bør se ud, er der imidlertid visse
retningslinier for identifikationen af klasserne. Først skal systemets grundlag revideres med
henblik på, hvordan data er organiseret. Der er normalt en eller anden form for entitetrelationsmodel
i en systemspecifikation, altså en opstillig af datatyper og deres indbyrdes forhold.
5.8.1 Klassebibliotekets anvendelse 437

Denne model kan bruges til at opstille nogle konkrete termer. Entiteter med et simpelt indhold
bliver til en klasse, mens komplekse entiteter bliver til aggregate klasser. Relationerne mellem
klasserne specificeres enten på klasse-basis eller på objekt-basis (se afsnit 5.7.4) afhængigt af, om
der er tale om en aggregering eller en association. For entiteter som er relateret på andet end
indhold (det kan ses på måden, entiteterne omtales på - en bruger kan indtaste både en ansøgning
og et memorandum) skabes abstrakte klasser, der bruges som baseklasser for de behandlingsrelaterede
(aktive) klasser. Enhver behandling på en entitet bliver til en metode. Hvis
behandlingen kun vedrører én entitet, indkapsles den som medlemsfunktion i den klasse. Hvis
behandlingen er centreret omkring en anden entitet, skrives den som medlemsfunktion i den
klasse og modtager som parameter et objekt af den første klasse.
5.8.3 Topologi
Der er mange forskellige måder at opbygge arvefølgen i et klassebibliotek på, men der er til
gengæld ingen af dem, som definitivt er den bedste. Det kommer ganske simpelt an på de enkelte
klassers beskaffenhed.
Der skelnes mellem to slags opbygninger: enten findes en særlig rod-klasse i toppen af et
hierarki, som er baseklasse for alle andre klasser i hierarkiet, eller også er klasserne distribueret
på flere mindre hierarkier og helt separate, ikke-afledte klasser. Spørgsmålet om hvorvidt et
enkelt træ eller en skov af træer er bedst er det ikke muligt at give et generelt svar på. Mindre
biblioteker har dog en tendens til at tage form som et træ, mens større biblioteker med mange
forskellige klassearter er implementeret som en skov. Skoven af separerede træer er også lettere
at have med at gøre i større udviklingsprojekter, fordi den gør det lettere for de enkelte deltagere
at arbejde koncentreret på deres eget træ i skoven.
Brugen af multipel arv i en større sammenhæng er også lettere at adminstrere, hvis
klassebiblioteket indeholder flere uafhængige hierarkier. Hvert hierarki i biblioteket får en
bestemt ansvarsflade og henvender sig til specifikke klienter. To eller flere hierarkier kan lettere
samles med multipel arv på denne måde, fordi der ikke skal tages hensyn til virtuelle baseklasser
og de relaterede problemer (afsnit 4.5.8). Multipel arv skal bruges til at dele en egenskab fra én
klasse med en andre klasser, og ved at arve multipelt fra aktive klasser skal kun et minimum af
kode skrives om.
438 Klassebiblioteker 5.8

Figur 5-8: Klassetopologisk opbygning: enkelt træ (a) og skov af træer (b).
En god regel er imidlertid følgende. Selv om arv inspirerer til mange led af klasser i et stort
hierarki, er graden af genbrug ikke altid ligefrem proportional med hierarkiets størrelse. Ofte vil
en introduktion af en ny klasse i et kompekst klassehierarki være meget besværligt med mange
trivielle virtuelle metoder, der skal skrives (og også optager plads i lageret), mens de mindre
hierarkier i en skov af træer er lettere at udbygge.
Eksempler på kommercielle klassebiblioteker, som benytter forskellige filosofier for designet af
hierarkiet er
• CommonView, som er en løs grænseflade til et (egentligt vilkårligt) vinduessystem. Det
er implementeret træ-hierarkisk, og indeholder meget få klasser. Systemet har kun en
enkelt abstrakt klasse, som alle de aktive klasser arver direkte fra. Der benyttes ikke
multipel arv. CommonView findes til næsten alle miljøer, blandt andet Macintosh,
DOS, Windows, HP NewWave, OS/2 Presentation Manager og OSF/Motif, og
programmer, der benytter CommonView er (i teorien) flytbart mellem alle disse
systemer.
• NIH Class Library, udviklet af det amerikanske sundhedsvæsen. Det er et generelt
system til brug i databaseapplikationer. Dette system er implementeret som ét hierarki,
men gør stor brug af abstrakte klasser og multipel arv. NIH Class Library indeholder
mange generelle klasser, for eksempel lister, kataloger, strenge og numeriske typer og
indeholder en enkel form for bestandighed via en speciel klasse, der implementerer I/O
på nøglebasis. BIDS-biblioteket, som følger med Borland C++ oversætterne er løst
inspireret af NIH Class Library.
• Andre sprog, der kommer med et standard sæt af generelle klasser. Smalltalk [Goldberg
83a] sælges for eksempel med et stort antal generelle datatyper og containerklasser, der
er basis for al Smalltalk-udvikling, mens Eiffel [Meyer 88] også har indbyggede klasser
for listebehandling, filmanipulation og lageradministration.
Desværre er en uheldig konsekvens af mange klassebibliotekers opbygning, at de ikke arbejder
sammen med andre klassebiblioteker. De består ikke blot af indkapslede klasser, men har også
globale sideeffekter, som gør det umuligt at integrere dem i den samme applikation. For eksempel
er det med sikkerhed ikke muligt at foretage en multipel afledning mellem en grafisk klasse i et
vinduessystem-bibliotek med en bestandigheds-klasse i et database-orienteret bibliotek. Hvad der
skal til, er en standard for grænseflader til hele biblioteker eller hierarkier, og ikke blot klasser.
5.8.3 Topologi 439

En sådan standard findes ikke de første mange år, så integration af store klassebiblioteker er ikke
en fornuftig målsætning foreløbig.
5.9 GENBRUGSMEKANISMER I C++
Termen software-genbrug har været anvendt mange gange gennem denne bog. Genbrug har groet
fra en disciplin af akademisk interesse til en nødvendighed, fordi det har vist sig, at
kompleksiteten af software er meget stejlt stigende. De programmer, vi skriver i dag, er mange
gange så komplicerede som bare for ti år siden. Dengang var genbrug ikke en kardinal faktor,
fordi selve opgaverne var relativt simple. Programmerne var simpelthen begrænsede. Det faktum,
at kompleksiteten har vokset eksponentielt lader os til at tro, at denne udvikling sandsynligvis vil
fortsætte på samme måde i fremtiden. Det betyder, at vi står overfor programmeringsopgaver af
en kompleksitet, som ikke har været forudset endsige overvejet for bare få år siden.
Genbrug er et nøglepunkt i forsøget på at opløse denne kompleksitet. Termen betyder ikke, at vi
genbruger softwareelementer, som er blevet smidt væk - på engelsk kaldes softwaregenbrug reuse
og ikke re-cycling - målet er tværtimod at forsøge at udvikle programmer, som tillader os at
frakoble visse dele og skabe nye programmer med dem uden at tabe abstraktion, dvs. uden at
skulle tænke så meget over det detaljerede indhold af disse dele. Genbrug forudsætter på den
måde abstraktion. I andre fagområder såsom industri og elektronik er genbrug et vigtigt element.
Når en bilfabrik udvikler en ny bil, starter de ikke forfra med et hvidt stykke papir, de anvender
både tidligere design, teknologi og maskinel til opgaven. Ligeledes benytter elektronikbranchen
sig i høj grad af genbrugsprincippet. Computere, CD-afspillere, telefonsvarere osv. bliver ikke
bygget op helt fra bunden. Der findes allerede etableret og tilgængelig teknologi, der kan
anvendes (genbruges) til de forskellige applikationer. Bortset fra standardkomponenter bruges i
meget stor stil integrerede kredse til alle elektroniske produkter. Disse kredse har en intern
funktionalitet og en ydre grænseflade til omverdenen. De kan anvendes ved blot at kende til hvad
de gør og hvordan grænsefladen ser ud (kredsens pin-out, de små bens betydninger) mens selve
måden de virker på er et abstraktionsniveau længere nede og er i konteksten ligegyldig. Vi kan
således belejligt sammenligne sådanne kredse med vores klassebegreb. Det, vi søger efter, er at
udvikle software-VLSI'er som kan anvendes i mange forskellige applikationer, fordi de har
generiske træk. Et softwareprojekt bør tage udgangspunkt i et antal standardkomponenter, som
modulariseres, parametiseres og integreres med et minimum af ekstra kode til en færdig
applikation. Men dette mål kræver, at vi klart definerer, hvad vi mener med genbrug.
I eksisterende udviklingssystemer og -sprog anvender vi allerede eksisterende kode og
definitioner af typer om og om igen. For eksempel findes de fleste steder standardbiblioteker,
som indeholder funktioner til lavniveau-I/O, tegntransformation, matematik og grafisk
databehandling. At de kan genbruges skyldes netop, at de er defineret som standarder. Men det
repræsenterer ikke egentlig genbrug, fordi der oftest er tale om meget statiske biblioteker af kode,
som ikke følger et egentligt designkoncept. En klient af disse biblioteker er således nødt til at
gøre sig afhængig af deres opbygning og især indhold af prædefinerede typer på en måde, der
ikke fremmer dataabstraktionen mellem klienten og biblioteket. Jeg vil betegne denne form for
integration mellem standardkomponenter og klientkode som en avanceret form for inklusion af
kode, ikke som en reel genbrugsmekanisme.
440 Klassebiblioteker 5.8

I udviklingsprojekter har man i mange år på samme måde anvendt tidligere skrevne
programmer og designkomponenter i nye projekter. Fremgangsmåden har ofte været, at en del af
et færdigt program er blevet skåret fra og modificeret, så det passer til det nye programs krav.
Denne praksis er sandsynligvis meget kendt blandt de fleste programmører, men jeg vil dog
hævde, at den ikke repræsenterer egentlig genbrug. De småstykker, der klippes ud af de gamle
programmer, bliver ændret med det samme, hvorfor der straks bliver tale om to forskellige
versioner af samme delprogram. Det er således et eksempel på reverse engineering, hvor man
tager udgangspunkt i et kompleks og går tilbage og finder virkemåden i de konkrete dele, og
bærer ofte benævnelsen software-bjærgning. Man bjærger simpelthen den kode i eksisterende
programmer, der lige netop opfylder ens behov på et givet tidspunkt. Det er imidlertid klart, at
denne praksis, hvis den anvendes i for eksempel sideløbende projekter, vil være meget
uhænsigtsmæssig, fordi delprogrammer, der repræsenterer abstraktioner på skæve plan
distribueres og således findes adskillige steder i samme virksomhed. Når den originale forfatter af
koden finder et par fejl, er det en større administrativ opgave at lokalisere alle de bjærgede kopier
af koden, og den person, der i første omgang foretog bjærgningen (og overtog ansvaret for selve
koden) skal bruge lang tid på at forstå, hvordan den egentlig virker. Det er ikke en velfungerende
abstraktionsmekanisme og er derfor (jvf. ovenfor) ikke genbrug.
Et langt mere repræsentativt eksempel for genbrug er hvad der sker, når en hovedbestanddel af
et projekt overlever og kan bruges senere. Sådan en bestanddel kan være en underliggende
database-administrator, der behandler data på en måde, der er uniform for de fleste af de
projekter, der udvikles. Det kan benævnes software-overlevering og er et eksempel på, hvordan
modulærprogrammering, fordi det bygger på abstraktioner, støtter genbrug. Det kræver imidlertid
disciplin at udvikle programmer på denne måde. Der skal allokeres ressourcer til programmører,
således at de bruger en væsentlig del af deres arbejdstid i et specifikt projekt til at udvikle
generelle programmer.
Genbrug af software er med andre ord ikke noget, der bare sker. Genbrugstanken starter
allerede ved designet af de programmer, der selv senere skal genbruges. Det er en udbyderopgave
og ikke en klient-opgave. Det omfatter både et godt design, en robust implementation,
faciliteter for distribution af udbudte klasser og moduler, dokumentationsprincipper og
projektledelse. Selve udbyder-klient modellen er en underliggende faktor for genbrug, fordi den
bygger på en klasse, der tilbyder visse faciliteter til en klient, og ikke omvendt, hvor en klient
anvender en klasse efter behov. Der skal nødvendigvis være overensstemmelse mellem
udbyderen og klienten (og deres kode) for at få det hele til at virke. Klienten anvender en
genbrugelig klasse ved at konsultere udbyderen (eller dennes dokumentation) og forholder sig
iøvrigt strengt til de regler, der er opsat af denne. Af disse grunde har vi brug for sprog og
udviklingsmiljøer, der understøtter indkapsling og informationsskjul. I elektronikverdenen er det
af gode grunde ikke muligt at åbne en integreret kreds og patch'e hist og her for at kunne
integrere den i en aktuel applikation. Grænsefladereglerne skal simpelthen følges til punkt og
prikke. Softwaregenbrug kan også kun lykkes, hvis grænsefladerne reguleres, så ansvaret for
vilkårlige dele af programmet kan placeres. C++ indeholder i rimelig grad de mekanismer, vi har
brug for i form af privatisering af data, men udviklingsmiljøet bør også konfigureres på en måde,
hvor oversættelsesenheder beskyttes mod skrivning af uautoriserede programmører. De regler,
der er fremsat for grænseflader i afsnit 5.4 bør tillige følges af udbyderen. Det er i grunden en
analyseopgave at skrive grænseflader, fordi det foregår på entitetsplanet (se afsnit 5.3.2) og
5.9 Genbrugsmekanismer i C++ 441

forholder sig udelukkende til anvendelsen af det, der ligger bag grænsefladen. En dårlig
grænseflade medfører derfor uvilkårligt dårlige klientprogrammer.
En høj grad af genbrugelighed i koden forudsætter derfor genbrugelighed i andre domæner end
blot i kildeteksten. Hvis vi skal kunne anvende abstraktionsmekanismerne i det sprog og den
programmeringsmetode, vi har valgt, må vi være vores domæner bevidste til alle tider, ellers kan
vi ikke finde de rette abstraktionsniveauer. Hvis vi taber abstraktion taber vi også
genbrugelighed.
5.9.1 Domæneanalyse
Det, vi forstår ved en klasse, eksisterer ikke blot som en konkretisering af et begreb i vores
kildetekst. Som nævnt i afsnit 4.3.1 er klasser fundamentet for den måde, vi inddeler alle former
for begreber på. I traditionel forstand et det en intuitiv proces at klassificere, fordi begreberne
ligger os lige for, men indenfor programmering kræver det, at vi forstår abstraktionerne bag
klasserne for at kunne konstruere dem rigtigt.
For at kunne skabe software, der er så generisk som muligt, må vi først forstå på hvilket
abstraktionsniveau, den aktuelle klassificering foregår. Som nævnt er et genbrugeligt design
fundamentalt for genbrugelig software. Et design af en klasse forudsætter en solid forståelse for
semantikken bag det koncept, den repræsenterer, for at grænsefladen til klassen kan skrives så
robust som muligt. I designdomænet beskæftiger vi os således med begreberne type-ækvivalens
og type-evolution. Det er et designspørgsmål, om en type A skal kunne konverteres til en type
B, fordi det indebærer en semantisk forståelse for begge klasser samt en fremsynethed i omfanget
af dem. Det giver mening at konvertere en Complex til en double, som det er gjort i afsnit
3.6, men en given containerklasse skal for eksempel ikke nødvendigvis kunne konverteres til en
anden. Selvom en LinkedList og et Array begge er containere, ligger type-ækvivalensen
på et plan, som gør dem til ligestillede subtyper af en mere generel type - altså en ensartet
grænseflade - og ikke på et plan, som gør dem til ligestillede typer i semantisk forstand - et
ensartet indhold. Det giver på samme måde heller ikke mening at konvertere fra en Linie til et
Punkt eller fra en Cykel til en Bil. I designdomænet må vi tage stilling til, hvordan
klasserne forholder sig til hinanden for at kunne producere den bedst mulige organisering af dem.
Designdomænet kan underinddeles i et applikationsdomæne og et variansdomæne.
Applikationsdomænet repræsenterer det aktuelle projekt og de begreber, der skal komme til
udtryk deri. Typisk vil et design primært fokusere på de klasser, som applikationen anvender i
processeringen og beskrive dem som entiteter med solid binding til implementationen. Hvis der
udelukkende fokuseres på applikationsdomænet i designet, vil meget af både designet og senere
af koden gå tabt, fordi klasserne i systemet hurtigt bliver specifikke og applikationsafhængige.
Introduktionen af et variansdomæne som afgørende faktor i udformningen af selve klasserne
skaber et fundament for genbrugeligheden i systemets bestanddele. Det gælder om at tænke i
varianter hele tiden for at opnå den største generalitet, mens applikationen, selvom den er i fokus,
bliver et produkt af variansen. Det lyder som en bagvendt måde at udvikle programmer på, men
vil faktisk sænke produktionstiden, fordi genbrugeligheden allerede manifesterer sig indenfor
samme projekt. En typisk applikation indeholder dusinvis af implementationer af hægtede lister,
sorteringer, skærmbehandlinger, tilstandsmaskiner og brugerinteraktioner fordi der hele tiden
442 Genbrugsmekanismer i C++ 5.9

fokuseres på applikationen. Hvis enhver udvidelse i stedet foretages med udgangspunkt i de
varianter, den pågældende klasse kan tænkes at optræde i, vil applikationen hurtigt drage fordel af
variansen. Variansdomænet er imidlertid det sværerste at sætte i system, fordi det umiddelbart
stiller spørgsmål om graden af den ønskede generalitet. Hvis vi udvikler en simulator for et IC3tog
skal vi overveje, om der skal fokuseres på diesel-baserede tog eller også lade systemet
omfatte eldrevne tog, om det kun skal være Scandia-udviklede tog eller tog af andre fabrikater,
om det skal være køretøjer af enhver art, der kører på skinner, om det skal være alle køretøj eller
som det skal være alle simulatorer. Det er faktisk et spørgsmål om at finde balancepunktet i
variansdomænet og indebærer en definition af hensigten med softwareudviklingen i det hele
taget. Balancepunktet bør findes i konsultation med alle involverede parter og bygge på
udviklingsafdelingens fremtidige planer for produktion og markedsføring.
Alt dette skal stå i kontrast til implementationsdomænet, eller løsningsdomænet, fordi de
abstraktionsmekanismer, det aktuelle system tilbyder i form af indkapsling, arv, delegering,
parametisering, polymorfi osv. ikke nødvendigvis kan afspejles i designet. I det næste afsnit
beskrives de abstraktionsmekanismer i C++ som er fundamentale for et genbrugeligt design. I
figur 5-9 vises, hvordan de fire nævnte domæner kan relateres til hinanden på en måde, som
skaber en balancelinie. Afhængigt af, om det aktuelle projekt er meget enestående eller meget
generelt vil denne linie være mere eller mindre vandret.
5.9.1 Domæneanalyse 443

5.9.2 Abstraktionsmekanismer
I dette afsnit rekapituleres og samles en hel del af de overvejelser om anvendelsen af
abstraktionerne i C++ og de idiomatiske særegenheder, de lægger op til. De fremgangsmåder for
valg af grænseflader, medlemsfunktioner og operatorer samt organisering af klasser og
konverteringer kan grupperes i fire familier af reele abstraktionsmekanismer, som har konkrete
forbindelser til både design og implementation.
Figur 5-9: Balancen i et objekt-orienteret design.
Den første abstraktionsmekanisme benævnes delegering og indebærer, at en klasse selektivt
udbyder medlemmer til klienten på forskellige måder. Delegering er en anvendt teknik i mange
andre sprog og simuleres i C++ ved forwarding, hvilket vil sige, at vi ved hjælp af indkapsling og
offentlige medlemsfunktioner kan differentiere eksisterende klasser. Delegering er den rigtige
løsning, når der ikke findes entydig type-ækvivalens mellem to eller flere klasser eller når en
eksisterende klasse uden polymorfe egenskaber skal udbygges. Den nye klasse indkapsler den
eksisterende klasse som forekomst eller via en pointer og klassens grænseflade designes, så den
reflekterer de ønskede transformationer og den ønskede transparens i relation til den eksisterende
klasse. Et eksempel på, hvornår delegering er den rette mekanisme at anvende er forholdet
mellem en LinkedList og en Node (fra afsnit 4.5.4). Typeforholdet mellem disse to klasser
er en mellemting af er-en og bruger-en. LinkedList indkapsler en Node* og arbejder
således indirekte (som en slags "priviligeret klient") på forekomster af Node. En egentligt typeækvivalens
er ikke til stede, fordi abstraktionen i en Node (en next-pointer, for eksempel)
ikke giver mening i en LinkedList. I stedet uddelegerer LinkedList attributter fra
Node i form af medlemsfunktioner, der hæver forståelsen for hægter ét niveau - for eksempel
kan LinkedLister sammenlignes med hinanden. I designdomænet betyder dette, at der
444 Genbrugsmekanismer i C++ 5.9

lægges vægt på varians, fordi vilkårlige klienter kan arve fra Node og igen tilbyde nye klasser til
andre klienter, som ikke er afhængig af den originale implementation af de originale klasser. Den
delegerende klasse er generisk, fordi den ikke er afhængig af subtypeforhold i de indkapslede
klasser og er derfor direkte genbrugelig i både design- og i implementationsdomænet: Variansen i
en LinkedList er meget høj.
Den næste og måske mest betydningsfulde abstraktionsmekanisme er arv. Dette koncept er
blevet behandlet på mange forskellige plan gennem denne bog, både i helt abstrakt og ikkedatalogisk
forstand, som en generaliserende teknik og som konkret idiom i C++. I forhold til
førnævnte domæneanalyse er arv i stand til at udvide anvendelsesmulighederne i design og kode,
der selv benytter den klasse, der arves fra. Med andre ord, entiteter, der allerede arbejder med en
klasse bliver mere generisk, når der arves fra denne klasse, fordi arv erklærer et lineært
typeforhold. I designdomænet lægges således mere vægt på applikationsdelen end på
variansdelen, fordi den afledte klasse altid vil være mere specifik og applikationsafhængig end
baseklassen. I den forstand, at arv fremmer generalitet gennem større muligheder i fremmede
klientklasser, er genbrugeligheden i sig selv ikke manifesteret i variansen af designet. Arv er ikke
en genbrugelighedsmekanisme i sig selv; brug aldrig arv med henblik på at genbruge kode i
baseklassen. Dén form for genbrug er netop, hvad ovenfor er beskrevet som softwareoverlevering
og er ikke spor generisk. Som eksempel kan nævnes en klasse, der arver fra Node
og udbygger begrebet en hægte med nye egenskaber. Det forhold, som Node har med for
eksempel LinkedList gør LinkedLists anvendelsesområde større. Genericiteten er
allerede beskrevet i en anden klasse og det er den, programmøren skal have i tankerne, når der
anvendes arv som abstraktionsmekanisme. Husk, at det ikke er baseklassen selv, der nedarves
men derimod baseklassens egenskaber. Nævnes skal også, at man arver både gode og dårlige
sygdomme, så vær altid opmærksom på at analysere de abstraktioner, som baseklassen
repræsenterer inden der arves. Ellers går de dårlige sygdomme i arv generation efter generation.
Som eksempel på en arvefølge, der foretages hændeligt men uhensigtsmæssigt, enten med
udgangspunkt i egalitet mellem klassernes grænseflader eller på grundlag af deres anvendelse
som containerklasser eller andet, kan vi erklære to anvendelige klasser, en liste (afsnit 3.8.1) og
en liste (afsnit 3.8.4). Klassedefinitionen på en generel LinkedList kan se således ud:
template
class LinkedList {
// ... implementation skjult ...
public:
void Insert (Element*);
Element* Head ();
Element* Tail ();
Element* Next ();
int hasElement (Element*);
int memberCount ();
};
Denne klasse indeholder referencer til objekter af typen Element (gennem skabelonparametisering)
og kan for eksempel tænkes at sortere disse. LinkedList gør ikke forskel på
5.9.2 Abstraktionsmekanismer 445

objekterne i listen, samme objekt kan forekomme flere gange og være af enhver type, for
eksempel void-pointere. Mængdeklassen Set ligner List en hel del:
template
class Set {
// ... implementation skjult ...
public:
void Insert (Element*);
int hasElement (Element*);
int memberCount ();
};
Faktisk er de offentlige medlemmer i Set syntaktisk et subset af de, vi finder i LinkedList,
hvorfor vi i en iver efter at arve kan skabe et subtypeforhold mellem de to klasser som følger:
template
class Set : public LinkedList {
// ... implementation skjult ...
public:
void Insert (Element* e) {
if (!hasElement (e)) LinkedList::Insert (e);
}
};
Nu har vi gjort Set type-ækvivalent med LinkedList idet vi har taget udgangspunkt i
klassernes grænseflader. Problemet (og det er stort) i det er, at semantikken bag de enkelte
medlemsfunktioner er dybt forskellige. En LinkedList kan indeholde det samme objekt flere
gange, mens et Set er defineret som en container, der kun kan omfatte et enkelt objekt én gang.
Ved at arve siger vi, at et Set er-en LinkedList og at alle klientmoduler, der anvender
LinkedList-objekter også kan anvende Set-objekter. Det er blot ikke korrekt. Den
semantik, der ligger bag operationerne i medlemsfunktionerne Head(), Tail() og Next()
i LinkedList giver ingen mening i Set, så hvordan skal vi forholde os til dem? Vi kan ikke
selektivt gøre dem private ved eksplicit at reerklære dem i den private del af klassen, fordi vi ikke
kan ændre på adgangskriterierne, der er beskrevet i baseklassen. Så vi ser, at selvom de to klasser
udviser homonyme træk - de ser næsten ens ud - så er abstraktionerne bag klasserne og
semantikken bag operationerne i grænsefladen meget forskellige. Ved at beskrive forholdet
mellem dem ved arv, skaber vi et seriøst hul i vores brugerdefinerede typesystem, fordi
klientkoden vil slå fejl ved brug af Set-objekter gennem LinkedList-pointere eller
lignende. [Liskov 88] beskriver kriterierne for at arrangere klasser og udtrykke forhold ved arv på
følgende måde:
Hvis der for hvert objekt o1 af typen S er et objekt o2 af typen T, således at
ingen programmer P defineret i forhold til T ændrer opførsel, hvis o1 skiftes
ud med o2, så er S en subtype af T.
446 Genbrugsmekanismer i C++ 5.9

Dette princip (ofte kaldet the Liskov Substitution Principle) er en grundpille i objekt-orienteret
design og repræsenterer et væsentligt kriterium for designets succes. Hvis dette princip ikke
følges er det ofte fordi, arv benyttes i implementationsdomænet og ikke i designdomænet. Det
leder til en slags bagvendt opfattelse af det objekt-orienterede paradigme, fordi man forsøger at
generalisere på de afledte klasser og ikke på baseklasserne ved kun at benytte sig af en del af
baseklassens indhold.
Vi kan også kalde polymorfi for en abstraktionsmekanisme. Polymorfi er en teknik, der kun får
ægte styrke gennem gennemført analyse og design, fordi det indebærer et større kompleks af
klasser, der anvender både arv og delegering. Polymorfi er i sig selv ikke en konkret
genbrugsfaktor i implementationsdomænet, fordi det handler om anvendelser af klasser et sted
midt mellem variansdomænet og applikationsdomænet. Det genbrugelige i polymorfi ligger
således i anvendelsen af de polymorfe elementer og er en udfordring, der starter i
designdomænet. Jævnfør ovenstående substitutionsprincip vil alle programmer P være generiske
og dermed genbrugelige og dette gælder også for det design, der ligger til grund for P. Designet
af en abstrakt datatype, som indgår i et klassehierarki på en eller anden måde og anvender
polymorfe funktioner eller datastrukturer, vil kunne udnyttes i andre sammenhænge i fremtiden,
fordi de typer, den er defineret i forhold til er erstattelige. Faktisk er det sådanne programmer
(funktioner, klasser, oversættelsesenheder eller datastrukturer) af mængden P, som i realiteten er
det mest generiske, vi kan opnå med objekt-orienteret programmering.
Den sidste form for abstraktionsmekanisme i C++ er muligheden for parametrisk polymorfi,
hvilket er implementeret som skabeloner eller parametiserede typer (afsnit 4.9). Det er
sandsynligvis den mekanisme, som i højest grad opfordrer til genbrug, fordi den arbejder på
abstrakte typer. Genericiteten i en skabelonklasse eller -funktion er meget udtalt, idet der
abstraheres fuldstændigt fra de typer, der arbejdes med - de skal ikke nødvendigvis være
ækvivalente med andre typer og skal ikke indgå i et klassehierarki med genericiteten
implementeret som virtuelle funktioner. Det forhold, at klienten har kontrol over de typer, som
skabelonklasser og -funktioner arbejder med internt gør koden lineært genbrugelig på et plan,
som afviger fra alle andre genbrugsmekanismer. Klienten er i stand til at parametisere
eksisterende kode på typer og ikke på objekter, hvilket maksimerer friheden i genbrugsfasen fra
komplet integration i en programmeringsmodel til en slags lykkehjul, hvor der er frit valg på alle
hylder. At både fundamentale typer, brugerdefinerede typer men også pointer-typer og flerledet
afledte typer kan anvendes i parametiseringen siger noget om, hvor stor anvendelse skabeloner
har. Som vist ovenfor i eksemplet med List og Set kan parametisering anvendes i
sammenhæng med arv, hvorved klienten kan blande parametrisk polymorfi med anvendt
polymorfi og opnå det bedste fra begge verdener. Som genbrugsmekanisme har parametiserede
typer størst relevans i implementationsdomænet.
Når vi taler om abstraktionsmekanismer er generalisering nøgleordet for at få magien til at virke
og for at maksimere genbrugeligheden i design og i kode. Sørg altid for at generalisere nedefter i
klassehierarkier, for at specialisere de afledte klasser og for at anvende de rigtige
abstraktionsmekanismer i C++ i forhold til de typerelationer, der gør sig gældende i det aktuelle
design. Det fremmer robustheden i klientens kode, dvs. at den ikke bryder sammen på grund af
eksterne omstændigheder hvilket igen fremmer typeevolutionen i et softwareprojekt, fordi
afhængighederne mellem klasserne og programdelene kan blive meget kompliceret. Husk altid at
5.9.2 Abstraktionsmekanismer 447

anvende udbyder/klient-modellen.
5.9.3 Granularitet og genbrug
I lyset af de retningslinier for forståelse af abstraktionsmekanismerne i C++, som er blevet
opremset gennem sidste afsnit, skal vi her se på, hvad klassernes omfang har af betydning for
genbrugeligheden. Dette er i modsætning til de konkrete konstruktioner i C++ et spørgsmål, der
rejser sig allerede i designdomænet og som har stor betydning for, hvordan klasserne organiseres
så genbrugeligt som muligt.
Som nævnt tidligere i dette kapitel kan programmørens opfattelse af "en klasse" og "en abstrakt
datatype" i forhold til traditionelle udviklingsmetoder være uhensigtsmæssig, fordi man ofte får
en opfattelse af disse entiteter som helskabte og rene. Det er en fejl at antage, at klasser skal
repræsentere letforståelige abstraktioner. De skal derimod være de byggeklodser, softwaremodstykkerne
til integrerede kredse, som skal være det bærende element i et program. Af den
grund er det ofte en fordel at fokusere på, hvilke funktioner og datamedlemmer en klasse ikke bør
indeholde i stedet for det omvendte. Generaliteten i en klasse er netop en funktion af, hvad
klassen ikke indeholder og hvad det er muligt at udbygge den med i form af delegering, arv eller
parametisering.
5.9.4 Identifikation af abstraktioner og entiteter
I introduktionen til dette kapitel beskrev jeg fire hovedpunkter, som repræsenterer de aktiviteter,
som ethvert objekt-orienteret softwareprojekt bør rette sig efter. Efter dette kapitels gennemgang
af organisation og modellering af klasser samt anvendelser af paradigmet og C++'s
abstraktionsmekanismer vil jeg nu rekapitulere og raffinere disse punkter i en generel men
uformel "recept" for objekt-orienteret design.
Først skal de egentlig koncepter og abstraktioner i selve målsætningen lokaliseres og
identificeres. Vi befinder os her i applikationsdomænet og arbejder på et meget generelt niveau,
hvor entiteter og andre veldefinerede områder er til at forstå for både bruger og udvikler. De kan
repræsenteres af de substantiver, der blev beskrevet i det semantiske katalog i tabel 5-1 i afsnit
5.3.8 og bliver ofte direkte til klasser eller små klassehierarkier i koden. Hvordan identificeres da
entiteterne i et program? Spørgsmålet er faktisk det samme, som blev stillet på flere forskellige
måder gennem afsnit 5.2 og er blandt de mest spurgte blandt nyankomne til den objektorienterede
verden: "Hvordan finder jeg mine klasser?". Som nævnt kan det være et problem,
fordi entiteterne i applikationsdomænet ofte repræsenterer dårlige abstraktioner som ikke
umiddelbart kan beskrives entydigt i et design. Dog kan vi opstille nogle heuristikker for
identifikation af entiteter i designet:
• Hvis et begreb anvendes som substantiv, når man taler om programmet, og hvis det har
en veldefineret opførsel, er det en god kandidat til en implementering som abstrakt
datatype - ellers skal der måske anvendes en ikke-medlemsfunktion eller en anden form
for abstraktion i C++. En "bankkunde" egner sig som klasse mens et "overtræk" bør
448 Genbrugsmekanismer i C++ 5.9

være en form for tilstandsvariabel og en "rentetilskrivning" mere ligner en
medlemsfunktion i en konto-klasse.
• Gode, traditionelle datalogiske begreber kan være svære at identificere som entiteter og
placere i et design. Her kan det være en fordel at se på, hvordan de abstraktionsmekanismer
som sproget tilbyder, kan anvendes. Et begreb som en containerklasse, som er et
idiom og ikke en abstraktion, er den objekt-orienterede løsning på mange af de kendte
strukturer som stakke, køer og lister. Værre er det med prædefinerede algoritmer, de bør
enten integreres fuldstændigt i en klasse eller baseklasse eller måske implementeres som
parametiseret funktion. Det giver ikke mening at skabe klasser for algoritmer.
• Granulariten i entiteten kan have en afgørende betydning for genbrugeligheden i
designet. Overvej eventuelt at opdele en entitetskandidat i flere klasser og anvend C++faciliteter
som arv, delegering og klientering til at relatere klasserne. Det, der kommer
ud af en sådan differentiering af en entitet, er et lille del-hierarki, som udbydes på en
måde, der er mere fri end hvad ville være tilfældet med en stor, kompliceret og meget
"lukket" klasse.
• Hvis en formodet entitet har en opførsel, som resulterer i medlemsfunktioner, der virker
uden relation til hinanden, er der sikkert ikke tale om et veldefineret begreb i designet.
Det vil ofte resultere i "beskidte" klasser med karakter af forhastede implementationer.
Sådanne er meget ugenbrugelige.
I dette afsnit har vi set på, hvordan en programmeringsopgave ved en analyse af abstraktioner
kan angribes ved at fokusere på henholdsvis applikationsdomænet og variansdomænet. Det er
afhængigt af det enkelte projekt, hvorvidt designet skal balancere i retning af
applikationsafhængige entiteter, klasser og funktioner. Denne balance har også betydning for, om
genbrugeligheden er vertikal eller horisontal i forhold til andre udviklingsprojekter. Vertikal
genbrugelighed betyder, at komponenterne i projektet kan genbruges andre steder i det aktuelle
projekt, mens horisontal genbrugelighed betyder, at komponenternes anvendelighed kan
defineres mere bredt og kan genbruges i andre projekter end lige netop det aktuelle. Begge
retninger er lige ønskværdige at fremme, hvorfor det er en fordel at balancere designet jævnfør
figur 5-9.
5.10 UDVIKLINGSMÆSSIGE OVERVEJELSER
Der er flere følgevirkninger af objekt-orientering på udviklingsprocessen, end de åbenlyse fordele
og ulemper, der er diskuteret i dette kapitel. Systemudvikling er næsten altid et spørgsmål om at
forsøge på at tilfredsstille et antal krav med indbyggede modsætninger, for eksempel
funktionalitet, tid og plads. Det strengeste af kravene vil altid tynge udviklingen ned. Forskellen
mellem softwareudvikling og andre former for udvikling er, at der i for eksempel industri og
håndværk altid er mulighed for at ændre på faktorer og nå en anden specifikation på et problem.
Softwareudvikling er mere kompliceret, fordi det først skal designes meget omhyggeligt, da en
5.9.4 Identifikation af abstraktioner og entiteter 449

ettelse i sidste led næsten altid er umulig.
Den udviklingsmæssige forskel på traditionel programmering og objekt-orienteret
programmering er, at der ikke forekommer de kendte "milepælsdage", hvor alle samler den sidst
fungerende version af deres del af programmet. Et objekt-orienteret program startes med en
simpel prototype, som ganske langsomt udvikler sig til en færdig applikation. Denne
inkrementale proces er mulig, fordi alle involverede altid må sørge for at have specifikationerne
på deres klasser i orden, for at deres egen kode kan fungere, og dermed er specifikationen også
sikret for andre medlemmer af projektet.
Der er adskillige fordele at se i dette:
• Det vil altid være muligt at få en eksekverbar version op at køre og se, hvordan projektet
ser ud, så det kan sikres, at det lever op til forventningerne og specifikationen,
• Programmørerne kan se programmet udvikle sig støt, hvilket hæver moralen og gør
arbejdet sjovere,
• Test og kodning kan begyndes allerede før designet er helt færdigt,
• De vigtigste dele af hele programmet bruges oftest og testes oftest,
• Det er altid muligt at se, om programmet er på linie med tidsplanen.
Tillige gør inkrementale prototyper det muligt at revidere designet på et tidligt tidspunkt, og med
få omkostninger, hvis det viser sig, at der er en fejl i specifikationerne.
5.10.1 Evolutionære ændringer
Der er fem typer af ændringer, som typisk foretages hyppigt i en objekt-orienteret applikation,
1. Introduktion af en ny klasse,
2. Modifikation af en klasses medlemsfunktion,
3. Modifikation af en klasses medlemsdata,
4. Modifikation af en klasses grænseflade,
5. Omstrukturering af klassehierarkiet.
Der er forskellige årsager for og konsekvenser af disse ændringer. En ny klasse introduceres, når
nye abstraktioner er forstået og specificeret eller når der er plads til klassen under de påkrævede
forudsætninger. Prisen for dette er temmelig proportional med klassens kompleksitet, men har
ingen direkte negativ faktor. At ændre en medlemsfunktion, for eksempel på grund af nye
datamedlemmer eller en bedre algoritme, indebærer normalt heller ikke nogen negative
konsekvenser, da specifikationen på funktionen skal overholdes, så andre dele af programmet
ikke bryder sammen. Blot skal den nye implementation af funktionen være fejlfri. Medlemsdata
ændres, når der er brug for en forbedring i enten plads- eller tidsforbrug i klassens
450 Udviklingsmæssige overvejelser 5.10

medlemsfunktioner. Prisen for dette er, at mange medlemsfunktioner også skal ændres, og det
kan tage unødigt meget tid i forhold til fordelen ved at foretage modifikationen.
En modifikation af klassens grænseflade har til gengæld flere konsekvenser. Hvis prototypen på
en medlemsfunktion ændres, skal al klientkode, der benytter funktionen, også skrives om, hvilket
igen med stor sandsynlighed indebærer substantielle ændringer i klientens kode. Er der tale om en
ny medlemsfunktion, der bare introduceres i klassen, fordi en ny abstraktion for klassens
repræsentation er fundet, er det ikke så stort et problem, blot ikke funktionsnavnet kolliderer med
en funktion i en eventuel baseklasse. En medlemsfunktion fjernes meget sjældent, kun hvis den
ikke behøver ses af klienten flyttes den undertiden ind i den beskyttede eller private del af
klassen. Som et resultat heraf er en klasses grænseflade næsten altid opadkompatibel, hvilket gør
integration af mange moduler med forskellige programmører smertefri.
Hvis klassehierarkiets struktur skal ændres, skal det helst foregå meget tidligt i programmets
udviklingsforløb, helst før klientering er udbredt. At ændre en klasses placering i hierarkiet har
betydning for alle klienter, som i bedste fald skal genoversætte deres kode og i værste fald skal
omskrive den. Alle afledte klasser af den pågældende omplacerede klasse skal sandsynligvis også
ændres, og klienter af disse skal ligeledes genoversættes eller revideres. Derfor er det en fordel,
hvis en forkert placeret klasse hurtigt identificeres, før der er for mange afhængigheder i
systemet.
Det er i øvrigt god praksis at foretage periodiske evalueringer af hierarkiet/hierarkierne i
biblioteket, for at sikre klassernes konsistens og berettigelse. Ofte bærer en klasse på en arv, som
til dels er unødvendig i form af overflødige data eller redundante metoder. En evaluering af
biblioteket foretages med en test af alle klasser én for én og en analyse af deres anvendelse i
relation til applikationen.
Mange CASE-redskaber findes i dag, som kan lette mange af de trivielle dele af
programkonstruktionen. Blandt andet indenfor opbygning af containere, generisk kode og
parameterisering er mulighederne store og kan automatisere processen. Analyseværktøj findes til
pladsforbrug, metodeplacering og klasseidentifikation, som letter arbejdet med at oprette klasser,
finde datamedlemmer og skrive medlemsfunktioner.
5.10.2 Dokumentation
Det er, som altid, vigtigt at dokumentere software på en ensartet og koncis måde. Dokumentation
af objekt-orienteret software forenkles en del på grund af klassebregrebet: Da en klasse i sig selv
er en specifikation på en datatype med et indhold og en grænseflade, kan klasseerklæringen
bruges som udgangspunkt for en dokumentation. Headerfilen med klassens specifikation, påført
en tekstuel anvendelsesbeskrivelse og hensigtserklæring samt de tekniske kommentarer, der
måtte være væsentlige, er ofte nok for, at en klasse umiddelbart kan forstås af en klient.
I afsnit 5.2.3 så vi et forslag til organisering af kildeteksten i specifikationsfilerne. Fra denne
specifikation vil det med et enkelt værktøj være muligt at uddrage essentielle data om klassen,
blandt andet
• Navnet på klassen,
• Eventuelle baseklasser,
5.10.1 Evolutionære ændringer 451

• Eventuelle indeholdte klasser,
• Polymorfe muligheder i klassen (og antallet af virtuelle funktioner),
• Grænsefladen (syntaks og semantik) til klassen,
• Grænsefladen til en eventuel afledt klasse,
• Konstruktionssyntaksen.
Det er ligeledes muligt automatisk at determinere, om en klasse er aggregat, container, abstrakt
eller aktiv. Disse data kan opstilles i standardskemaer (på et elektronisk medie), så det altid er
muligt at se, hvordan en given klasse er repræsenteret.
5.10.3 Udviklingstekniske følger
Omstillingen til objekt-orienterede metoder har også klare arbejdsmæssige konsekvenser. Før var
det en smal sag at skrive en headerfil med en specifikation på et modul, og den store
koncentration blev lagt i selve koden. Headerfilen indeholdt blot prototyper på datastrukturer,
som blev modificeret et par gange i udviklingsforløbet. Nu er det faktisk størstedelen af tiden, der
bliver brugt på headerfilerne. Det er på grund af, at klasseudbyderen selv skal rette sig efter den
samme specifikation som klienten, at headeren bliver central.
Det vil også vise sig, at linieantallet mindskes. Programmerne fylder simpelthen mindre i
kildetekst. Objektkoden er større for de mindre applikationer, men har en mindre stigning i
størrelse for mere komplekse applikationer end for traditionelt skrevne programmer. Linieantallet
er således ikke en indikator for, hvor godt et udviklingsprojekt former sig, men i højere grad en
rettesnor for sandsynligheden for fejl.
Alt taget i betragtning indebærer objekt-orienteret programmering, at den tidligere meget
underforståede konsens mellem deltagere i et udviklingsprojekt nu bliver mere eksplicit. Et
udviklingsprojekt bliver mindre frustrerende, fordi ansvar for fejl hurtigt kan placeres og fordi der
aldrig hersker tvivl om, hvordan en klasse skal anvendes.
5.11 OPGAVER TIL KAPITEL 5
1. Overvej forskellen mellem bestandighed, der administreres af et klassebibliotek og
kontrolleres af klienten, og bestandighed, der både administreres og kontrolleres af
klassebiblioteket. Hvilket arbejde skal biblioteket foretage sig for at give klienten denne
transparens?
2. Hvornår bør klassebiblioteker designes med en enkelt rod (ét træ), og hvornår er det
mere hensigtsmæssigt at skrive det med flere uafhængige rod-klasser (en skov af træer)?
Hvad er følgerne i polymorf henseende? Hvad er forskellen, hvis der skal arves
multipelt?
3. Implementér en containerklasse, der indeholder referencer til polymorfe objekter. Skriv
nu medlemsfunktioner i containerklassen, der er i stand til at udlæse og indlæse
indholdet på en strøm, så et containerobjekt kan lagres på sekundærlageret. Hvilke
452 Udviklingsmæssige overvejelser 5.10

problemer render du ind i, og hvorfor?
4. Forklar nødvendigheden af abstrakte klasser i objekt-orienteret programmering.
5. Forklar om forskellen på udvikling af software i C og C++. Bliver arbejdsdagen
anderledes? Hvordan?
6. Forklar begrebene (a) Abstrakte klasser, (b) Containerklasser og (c) Aktive klasser og
uddyb deres funktion i et objekt-orienteret program, helst med eksempler. Er der
paralleller i disse begreber til elementer i traditionel programmering, for eksempel C
eller Pascal?
7. Beskriv med dine egne ord Liskov's substitutionsprincip. Hvorfor er det så vigtigt, at
dette princip efterkommes i objekt-orienteret design?
8. Implementér klasser til repræsentation af (a) stakke, (b) associative lister og (c)
sorterede lister. Argumentér for dine valg af abstraktions- og genbrugsmekanismer.
5.12 REFERENCER OG UDVALGT LITTERATUR
Der findes mange gode referenceværker om objekt-orienteret design og opbygning af
klassebiblioteker. Forfatteren kan dog ikke anbefale nogen af dem som fundamental. I [Goldberg
83a] findes interessante bemærkninger om udviklingen af OOP-software, og om hvordan det har
indflydelse på vores syn på software. [Meyer 88] har sin egen definition af et objekt-orienteret
system, Eiffel, i sin bog Object-oriented Software Construction. Information om det tidlige
objekt-orienterede sprog, Smalltalk, kan findes i [Goldberg 83b]. [Kirslis 86] har nogle bud på et
standardformat for klassespecifikationer til brug i integration mellem biblioteker. I [Johnson 88]
findes forslag til design af genbrugelige klasser, med udgangspunkt i entydige og konsistente
specifikationer. [Coplien 92] indeholder en meget robust gennemgang af idiomer i C++, dvs.
sproglige egenarter, som i konsistent brug gør C++-programmering sikrere. Der henvises også til
[Liskov 88] for definitioner af generelle objekt-orienterede synspunkter og argumentationer for
konstruktionsfremgangsmåder og til [Gorlen 88] for gode historier om problemerne med
klassehierarkier i C++.
5.11 Opgaver til kapitel 5 453

Standardbiblioteket
Den primære årsag til C++-programmers høje grad af flytbarhed, dvs. den lethed,
hvormed de kan genoversættes på et andet system, er sprogets distance fra den
underliggende arkitektur. C++ er designet uden nogen væsentlig specifikation af
system-afhængighed og er helt uden indbyggede faciliteter for I/O. Som i C
udføres I/O-operationer normalt gennem kald til et standardbibliotek, som tager
sig af tegnbaserede konverteringer til og fra sprogets typer. Dette kapitel beskriver
standardbibliotekets funktion og omfang. Standardbiblioteket er udover en
uundværlig del af C++-miljøet også en god inføring i objekt-orienteret
programkonstruktion.
6.1 INTRODUKTION
I/O-operationer ligger ikke fast som en indbygget del af C++, men er en defineret standard, som
er implementeret på det enkelte system, og som normalt følger med et oversættersystem. Ved at
bruge standardbiblioteket til simple operationer som skærm-output, læsning fra tastaturet og
filmanipulation kan et C++-program flyttes til andre arkitekturer og operativsystemer uden
besvær, sålænge disse også understøtter denne standard. I/O-biblioteket, som beskrives her,
følger med stort set alle C++-implementationer, og refereres normalt som iostream-biblioteket.
iostream erstatter det tidligere stream-bibliotek, som er standard under C++-systemer med
versionsnumre under 2.0. Med ganske få undtagelser er programmer, som bruger
stream-biblioteket opadkompatible med iostream, så gammel kode vil også kunne oversættes
under det nye bibliotek. Filosofien med eksternt definerede I/O-operationer er den samme i C,
hvor der benyttes specielle funktioner og datastrukturer til ind- og udlæsning af diverse typer.
Således findes funktioner til at læse og skrive tegn, strenge, lagerblokke og forskellige
fundamentale typer, formateret efter regler, som kan opstilles af programmøren. Både i C og i
C++ er I/O-bibliotekets funktion at konvertere sprogets typer til og fra sekvenser af tegn og være
i stand til at ind- og udlæse disse kontinuerligt fra og til en "strøm" på den givne arkitektur.
Forskellen mellem C-biblioteket stdio og C++biblioteket iostream er, at iostream er opbygget af
klasser og tillader således via specialisering og arv, at biblioteket kan udvides dynamisk med
I/O-operationer for de abstrakte datatyper, der findes i en vilkårlig applikation. stdio fungerer
naturligvis også sammen med C++.
En strøm er abstraktionen ved en kontinuert sekvens af tegn, som i bibliotekets laveste niveau
454 Opgaver til kapitel 5 5.11
6

kan læses og skrives fra og til forskellige enheder (indre og ydre) i systemet. På dette niveau
behandler iostream blot de hardware-afhægige aspekter af I/O, og arbejder ikke med datatyper,
hverken fundamentale eller bruger-definerede. På det bruger-orienterede niveau repræsenterer en
sekvens mange og eventuelt blandede forekomster af typer, som i bibliotekets specialiserede lag
bliver identificeret og konverteret. iostream indeholder et omfattende sæt af operationer for
manipulation af de forskellige fundamentale typer, og kan let udvides til at arbejde med
brugerdefinerede typer ved simple overstyringer. Biblioteket er således en modulær og konsistent
grænseflade til maskinens hardware-arkitektur. En strøm kan være til læsning, til skrivning eller
til begge dele. Klassen istream (input-stream) læser tegn og konverterer til type-forekomster
mens klassen ostream (output-stream) konverterer type-forekomster til tegnsekvenser. En
hybrid mellem dem, iostream, er bidirektionel og kan konvertere begge veje. iostream er et
fuldt klassehierarki, som består af relaterede klasser med forskellig funktionalitet. På toppen
findes klassen ios, som indeholder de basale hardware-konstanter og metoder til
maskinspecifik læsning og skrivning. Fra ios arves klasserne istream og ostream, som
udbygger med en brugergrænseflade til henholdsvis input og output, og dermed introducerer
abstraktionen "en strøm". Klassen iostream er multipelt arvet fra istream og ostream.
Udover disse klasser, som erklæres i header-filen , findes fil-relaterede
strømme i og streng-relaterede strømme i . I figur 6-1 ses
klassehierarkiet for standardbiblioteket i C++. Fra klientens synspunkt er en strøm definitionen
på en kilde hvor data af vilkårlige typer kan ifyldes eller hentes fra. Standardbiblioteket erklærer
fire forekomster, som udgør standard input, standard output, standard fejl-output og en bufferet
version af sidstnævnte:
istream cin;
ostream cout, cerr, clog;
I konventionelle UNIX-lignende miljøer er cin normalt bundet til tastaturet mens de tre
andre er bundet til skærmen. Derudover er det oftest muligt at omdirrigere destinationerne til
andre enheder, for eksempel filer eller serielle porte. Specialiseringer af strøm-klasserne kan også
skrives, så de kommunikerer med specifikke dele af et bestemt system, for eksempel beskeder
mellem processer i et operativsystem.
6.1 Introduktion 455

Figur 6-1: Standardbibliotekets klassehierarki.
Klassenavn Headerfil Funktion
ios
streambuf
istream
ostream
iostream
fstreambase
filebuf
ifstream
ofstream
fstream
I/O-operationer
Buffer
Input-strøm
Output-strøm
I/O-strøm
Fil-operationer
Diskbuffer
Fil-input
Fil-output
Fil-I/O
456 Introduktion 6.1

strstreambase
strstreambuf
istrstream
ostrstream
strstream
6.1.1 Klasser og objekter i biblioteket
Tabel 6-1: Klasser i standardbiblioteket.
Streng-strøm
Tekstbuffer
Streng-input
Streng-output
Streng-I/O
Standardbibliotekets klasser ses i tabel 6-1. Klasserne i bruges til standard-
I/O, dvs. input fra tastaturet og output til skærmen. De tilsvarende klasser i har
med læsning og skrivning af filer at gøre, mens læasserne i er helliget
formatering af tekst i lageret uden relation til en ydre enhed. Forekomster i tabel 6-2 er erklæret i
biblioteket og kan ses af klienten.
Objektnavn Type
cin
cout
cerr
clog
streampos
streamoff
istream
ostream
ostream
ostream
typedef
typedef
Tabel 6-2: Objekter i standardbiblioteket.
Derudover indeholder biblioteket et stort antal interne variable og objekter, som er indkapslet i
klasserne og kun kan ses af medlemsfunktionerne. Klassernes medlemsfunktioner bruges til at
arbejde på strømme af forskellige arter, og brugen af dem afviger normalt kun i form af
forskellige strømnavne og datatyper, der skal ud- eller indlæses.
Der bruges overstyring af to bestemte operatorer i klasserne istream og ostream, nemlig
de binære skifteoperatorer > (outputoperator). Denne operator er valgt,
fordi den passer godt til abstraktionen "at hente data" og "at sende data" til en strøm. På den
måde kan man ved operatorens orientering (højre eller venstre) se, hvor data kommer fra (strøm
eller data) og hvor de går til. "Pilen peger" i den retning, data bevæger sig:
str >> x; // læs objektet "x" fra strømmen "str"
str

semantisk sammenhæng. Det kan hjælpe en smule at tænke på, at sætningerne, som beskrevet
ovenfor, er ækvivalente til funktionskaldene
str.operator>> (x);
str.operator> x;
ostream& d = str

6.2 STANDARD I/O
Standard-I/O er betegnelsen for standardiserede metoder for udførelse af tegnbaseret input og
output. Standardiseringen generaliserer over I/O på terminal (konsol), disk, printer- og
kommunikationsporte, interproceskommunikation osv. Dette afsnit beskriver standardklasserne
ostream og istream, hvordan de anvendes, hvilke metoder de indeholder og hvordan de
relateres til hinanden.
6.2.1 Output
Den oftest benyttede outputmetode er en anvendelse af outputoperatoren på standardstrømmen
cout. For eksempel vil
#include
void main () {
cout

Output:
Skov
double n = 10;
cout

cout.put ('S').write ("kovtur", 3).put ('\n');
med det samme resultat. Der er ikke meget at gå fejl af i brugen af outputstrømme. Følgende
eksempel viser imidlertid to hyppige fejltagelser.
#include
void main () {
char s [] = "En streng";
cout

emærke, at det kun er objektindhold, som læses ind, ikke selve objekterne, som skal erklæres og
allokeres først. Derudover skal det bemærkes, at indlæsning altid er mere kompliceret end
udlæsning, netop fordi man ikke er bekendt med udseendet af de data, der kommer ind.
#include
void main () {
int x, y;
cout > x >> y;
cout "Adderet giver de "

#include
void main () {
char i, j;
cin.get (i).get (j);
}
get() returnerer det aktuelle tegn som en heltalsværdi. Denne værdi er en int, så klienten
kan se, om der er indlæst en valid værdi eller en fejl, for eksempel EOF. EOF er en konstant
defineret i iostream.h, og er normalt -1, og betyder, at slutningen på inputstrømmen er
nået. For at kunne skelne mellem en returneret værdi i char-intervallet og en fejlværdi, er den
returnerede type således større end en char. En typisk anvendelse af dette er
#include
void main () {
for (int c = cin.get (); c != EOF; c = cin.get ())
cout.put (c);
}
Hvis dette program præsenteres for inputstrømmen
D I K U
vil løkken gennemløbes 7 gange, både for de alfabetiske tegn og for mellemrummene mellem
dem.
Medlemsfunktionen read() er modstykket til ostreams write(). read() læser et
antal tegn ind i en buffer, hvor antallet og bufferens adresse er givet som parametre, og returnerer
i øvrigt den aktuelle strøm:
char Buffer [0x80];
cin.read (Buffer, 0x80); // læs 128 tegn
En lignende funktion er readline(), som ligesom read() læser et bestemt antal tegn
ind i en buffer, men har den udvidelse, at et bestemt tegn i inputstrømmen også kan slutte den
aktuelle læsning. Det kan bruges til at læse poster eller andre formaterede data af forskellige
længder fra en strøm og samtidig undgå overløb. readline() har samme parameterliste som
read() plus en underforstået tredie parameter, som er terminator-tegnet for indlæsningen. Hvis
den ikke specificeres, er den underforståede værdi '\n'.
getline() og read() bruges ofte sammen med en anden medlemsfunktion,
gcount(), som returnerer antallet af læste tegn. Det er anvendeligt i forbindelse med
gennemløb af den buffer, der er indlæst. En istream har også en underforstået værdi, som
fortæller, om der er en fejl på strømmen. Med denne standardkonvertering og med for eksempel
6.2.2 Input 463

ead() og gcount() kan en enkel bufferet søgerutine let implementeres:
// eksempel 6-3
// søgning i et istream-objekt
#include
#include
typedef int bool;
bool Search (istream& strm, char* searchString) {
const Size = 0x80;
char Buffer [Size];
while (strm.read (Buffer, Size))
if (!strncmp (Buffer, searchString, strm.gcount ())
return 1;
return 0;
}
Tre andre medlemsfunktioner i istream er væsentlige for arbejdet med at læse fra en strøm.
putback() indsætter et tegn i starten af bufferen, som bliver det næste tegn, der indæses igen.
peek() henter det næste tegn, ligesom get(), men lader det stå i bufferen, så det bliver det
næste, der læses. Funktionen ignore() smider et antal tegn væk i strømmen, eller op til og
med den første forekomst af et bestemt tegn. En anvendelse af disse tre medlemsfunktioner kan
ses i følgende eksempel, som fjerner C++-kommentarer fra kildetekster:
// eksempel 6-4
// filtrering af kommentarer fra kildetekst
#include
void main () {
int i, Size = 0x80;
char Buffer [Size];
while (cin.get (i))
if (i == '/' && cin.peek () == '/') // kommentar?
cin.ignore (Size, '\n'); // ja, fjern den
else {
cin.getline (Buffer, Size, '\n');
cout

6.3 FORMATERING
Både istream og ostream er afledt fra klassen ios, som arbejder generelt med I/O, og
som formaterer tegn til specifikke formål. Begge klasser arver således et antal formateringsmetoder,
som kan bruges til specialisering af strømklassernes opførsel. I eksempler som det
ovenfor har vi ofte brug for at kunne kontrollere måden, hvorpå data formateres under ind- og
udlæsning, for eksempel det anvendte talsystem, justering på skærmen og bredden af bufferen i
strømmen.
I alle stømobjekter findes et antal flag, der bestemmer, hvordan objekter konverteres til tegn
når de ind- og udlæses. Disse flag er erklæret i ios-klassen, og har følgende betydninger, hvis
de er sat:
• ios::skipws vil hoppe over mellemrumstegn etc. under indlæsning fra en strøm med
inputoperatoren. Ellers medtages mellemrummstegnene. Flaget er normalt sat.
• ios::left, ios::right og bestemmer justeringen af udskrevne objekter. Kun ét
af disse flag kan sættes på samme tid. Hvis left er sat, vil teksten venstrejusteres i en
buffer, hvis længde er sat af width()-metoden og hvis tomme tegn er bestemt af
fill()-metoden. Er right sat, vil teksten justeres op ad højremargen af bufferen.
right er normalt sat.
• ios::dec, ios::oct, ios::hex bestemmer det talsystem, som numeriske
objekter udskrives eller indlæses i. Kun ét kan være sat ad gangen. Sættes for eksempel
hex-flaget, vil alle heltalsvariable forventes i sekstentalssystemet. dec er normalt sat.
• ios::showbase vil automatisk indsætte en indikator på det aktuelle talsystem før
numeriske data indsættes i eller udskrives fra en strøm. For eksempel, hvis ios::hex
er sat, vil alle tal, der sendes til cout automatisk efterfølge 0x.
• ios::showpos vil automatisk indsætte et plustegn (+) før alle positive tal, ganske som
negative tal har et minus-præfix.
• ios::showpoint vil sørge for, at alle kommatal udskrives med et tvungent komma,
hvad enten tallet er helt eller ej. Det har kun betydning for float og double, og er
normalt ikke sat.
• ios::uppercase vil sørge for, at alle alfabatiske indsættelser i strømmene bliver
konverteret til versaler. For eksempel vil en hexadecimal notation hedde 0X.
• ios::scientific og ios::fixed styrer formatet på kommatal. Hvis
scientific er sat, vil alle kommatal udskrives og indlæses i formatet 1.2345E2,
mens fixed vil udskrive det samme tal som 123.45. Normalt er ingen af flagene sat,
og formatet vælges afhængig af tallets størrelse: hvis eksponenten er mindre end -4 eller
6.2.2 Input 465

større end precision, bruges scientific, ellers bruges fixed.
• ios::unitbuf vil automatisk tømme bufferen efter hver operation, det samme som
nonbufferet I/O. Flaget er normalt ikke sat.
Disse flag gemmes i enhver strøm i en bitvektor (en long), der kan sættes og nulstilles af
klienten. Følgende medemsfunktioner arbejder på alle flagene på én gang:
• flags() returnerer de aktuelle flag i strømmen. Funktionen bruges mest til at gemme
den aktuelle status af flagene.
• flags(long) sætter alle flagene, og returnerer den hidtidige status i strømmen.
Funktionens anvendes hovedsageligt til at genskabe en status af alle flagene i en strøm.
Udover disse to findes to flag-specifikke metoder, som sætter og nulstiller enkelte flag uden at
have effekt på de andre. setf() sætter et bestemt flag i strømmen, mens unsetf() slår
flaget fra. setf() og unsetf() kan kaldes med alle ovenstående flag-værdier, og vil
returnere den aktuelle værdi før kaldet. Følgende eksempel viser de forskellige flags betydning
samt brugen af de fire metoder:
flag
// eksempel 6-5
// brugerdefinerede formateringer
#include
void main () {
int i = 12345;
double pi = 3.1415927;
long origFlags = cout.flags (); // gem strømmens status
cout.setf ( // sæt følgende flag:
ios::hex | // hexadecimale heltal
ios::showbase | // vis talsystemet
ios::scientific | // potensnotation
ios::uppercase // store bogstaver
);
cout

}
Programmet skriver følgende output ved kørsel:
i == 0x3039 pi == 3.141593e+00;
i == 12345 pi == 3.141593
Udover de enkelte flag findes et antal andre indkapslede værdier i strømmene, som beskriver
forhold, der ikke kan udtrykkes som et binært valg. Disse værdier sættes til en bestemt skalær
værdi, der har en bestemt betydning for formateringen. Hver værdi har en associeret
medlemsfunktion, der både læser og skriver den aktuelle værdi. Disse funktioner er
• width() sætter strømbufferens størrelse til et bestemt antal tegn, hvorefter strømmens
indhold vil blive udlæst. Normalt er denne værdi 0, hvorved bufferen først udlæses, når
den bliver tømt explicit. Ved at sætte width til en anden værdi, vil det være muligt at
få en strøm til at være bekendt med størrelsen på en destinations-streng, der er allokeret
af klienten, for at undgå overløb. For eksempel,
#include
void main () {
char buffer [5];
cin.width (sizeof (buffer));
while (cin >> buffer) cout

Output:
void main () {
cout.fill ('0');
cout.width (4);
cout

er beskrevet i de forrige afsnit, er meget proceduralt orienterede og har en lidt triviel syntaks.
Derfor findes et alternativ, nemlig brugen af særlige manipulatorer. En manipulator er en global
funktion, der kan bruges som argument efter en cout-sætning eller et andet objekt af typen
ostream. En manipulator er således mulig at kalde i samme sætning som egentlige
udlæsninger af objekter. For eksempel,
// eksempel 6-6
// anvendelse af manipulatorer
#include
void main () {
int i = 11;
cout

• flush() vil tømme strømmens buffer og udlæse alle data med det samme.
• setfill(c) vil sætte det aktuelle filler-tegn til t, hvilket svarer til et kald til
strømklassens fill()-medlemsfunktion.
• setw(n) vil sætte strømmens bufferbredde til n, hvilket svarer til at kalde
strømklassens width()-medlemsfunktion.
• setprecision(n) sætter præcisionen i udlæsninger af kommatal til n, hvilket er det
samme som et kald til strømklassens precision()-medlemsfunktion.
• setiosflags(n) sætter flagene i den pågældende strøm til n OR den aktuelle
værdi, ækvivalent til et kald til klassens setf()-medlemsfunktion.
• resetiosflags(n) nulstiller flagene i den pågældende strøm til n NAND den
aktuelle værdi, ækvivalent til et kald til klassens unsetf()-medlemsfunktion.
Manupulatorer gør ganske simpelt syntaksen bedre og kildeteksten mere koncis. I afsnit 6.6.2
vises, hvordan manipulatorer kan brugerdefineres til specifikke formål og integreres i
standardbiblioteket.
6.3.2 Formatering uden I/O
Objekter kan konverteres til tegn og omvendt uden at skulle skrives til eller læses fra en konkret
I/O-strøm. En særlig strøm for in-core formatering, altså formatering direkte i lageret, varetager
denne opgave. Klassen strstream (strengstrøm) er afledt fra iostream, men benytter en
anden buffer, som både læser fra og skriver til lageret. Som for standard-I/O findes tre klasser.
Konvertering af tegn fra en streng til et objekt varetages af klassen istrstream, konvertering
den anden vej foretages med klassen ostrstream og begge veje klares af klassen
strstream. Der er ingen instantieringer af disse klasser i standardbiblioteket, så klienten må
selv erklære et objekt af den ønskede type. Klasserne er erklæret i headerfilen
, og skal inkluderes af alle programmer, som bruger dem.
Alle medlemsfunktioner, manipulatorer og overstyrede operatorer, der kan bruges på en
iostream kan også bruges på en strstream. Her følger et eksempel på brugen af
ostrstream:
// eksempel 6-7
// in-core formatering
#include
#include
470 Formatering 6.3

void main () {
ostrstream sstrm;
sstrm.setf (ios::fixed | ios::showpos | ios::showpoint);
sstrm

Output:
cout > a >> b >> c;
cout

float VersionCode;
istrstream (Version, sizeof (Version)) >> VersionCode;
// ...
}
Klassen strstream har både input- og outputfaciliteter, og har primær anvendelse som en
ganske normal FIFO-buffer eller kø, med den udvidede mulighed for konvertering af objekter.
6.4 STRØMSTATUS OG FEJLBEHANDLING
Der kan opstå en fejl i en strøm, for eksempel hvis en outputstrøm ikke kan skrive til den
associerede buffer, eller hvis en inputstrøm ikke kan konvertere bufferens aktuelle inhold til den
ønskede type eller hvis bufferen er løbet tom. Enhver iostream kan implicit konverteres til en
sanhedsværdi, ved brug af konverteringsmetoden til en void* og operator-overstyringen af !.
Disse to konverteringer fortæller, om strømmens status er "god" eller "dårlig". Hvis en
outputstrømstatus er dårlig, betyder det oftest, at der er problemer med en ekstern enhed - for
eksempel en printer. Fejl på en inputstrøm er normalt resultatet af slutningen på data fra
strømmen.
For eksempel,
#include
void main () {
if (cin) cout Buffer) wordCnt++; // indtil cin er
"dårlig"
cout

Det er muligt at få bedre besked om en eventuel fejl i en strøm. Enhver strøm har fem flag, der
fortæller mere detaljeret om strømmens status. Disse flags navne og betydninger er:
• ios::goodbit er sat, hvis strømmen ikke har fejl af nogen art.
• ios::eofbit er sat, hvis en inputstrøm er tom og indikerer altså, at der ikke er flere
tegn at læse. Det er altså mere end status end en fejl.
• ios::failbit er sat, hvis den sidste indsættelse i en ostream eller sidste
udlæsning fra en istream slog fejl, af årsager som beskrevet i starten af dette afsnit.
• ios::badbit er sat, hvis en ind- eller udlæsning i en strøm ikke var lovlig. Denne fejl
opstår for eksempel, hvis en ostrstream's buffer er fjernet med et kald til str()funktionen
(se afsnit 6.3.2). Det er altså en reel indikation af en programmeringsfejl, og
ikke en uventet ekstern hændelse.
• ios::hardfail er sat, hvis en seriøs fejl er opstået i en strøm. Generelt er den
forårsaget af en ekstern enhed, der slet ikke fungerer som den skal. Fejl af denne type er
det normalt ikke muligt at gøre noget ved, og bør afstedkomme en afslutning af
programmet med en fejlmeddelelse til brugeren.
Disse flag læses af et antal funktioner, som associerer de relevante flag:
• good() returnerer 1, hvis der ingen fejl er i strømmen og et 0, hvis en af ovenstående
fejl er opstået. Værdien er den samme, som returneres implicit ved den underforståede
konvertering til en void*.
• bad() returnerer 0, hvis enten ios::badbit eller ios::hardfail er sat, ellers
returneres 1. Værdien er den samme, som returneres implicit via den overstyrede
operatorfunktion for !.
• eof() returnerer 1, hvis flaget ios::eofbit er sat, ellers 0, og bruges til at teste
for slutningen på en inputstrøm.
• fail() returnerer 1, hvis enten ios::failbit, ios::hardfail eller
ios::badbit er sat, ellers 0. Den anvendes især som modsætning til eof() for at
se, om en opstået fejl kan rettes i programmet eller ej.
• rdstate() returnerer alle flagene i en int.
Flagene kan også skrives, hvis en klient har opdaget en fejl i en strøm, eller hvis en
brugerdefineret datatype eller manipulator (se afsnit 6.6) ikke kan fortolke strømmens buffer
ordentligt. Når en fejl explicit skrives i en strøm, vil senere brug af strømmen automatisk
474 Strømstatus og fejlbehandling 6.4

esultere i den pågældende fejl. En fejl kan kun rettes op ved at nulstille det pågældende flag, der
beskriver fejlen. Skrivefunktionerne er:
• clear() vil nulstille alle flag i strømmen. Et valgfrit, underforstået parameter vil
maske de bits fra, der ikke ønskes nulstillet.
• setstate(n) vil sætte bitvektoren til den værdi, der angives som parameter. Denne
funktion er protected, og kan kun kaldes af afledte klasser og medlemsfunktioner,
inklusive brugerdefinerede operatorfunktioner og manipulatorer.
Her er en simpel anvendelse af disse funktioner i et program, der tester inputstrømmens status:
// eksempel 6-10
// anvendelse af strømmenes statusflag
#include
void main () {
char c;
while (cin.get (c)) cout.put (c);
if (cin.fail ())
cerr

ind til et eksisterende file-handle
char Buffer [100];
ofstream testData3 (4, Buffer, sizeof (Buffer)); // printer
// bind til et eksisterende file-handle, uden buffering
ofstream testData4 (4, 0L, 0);
// blot opret en filstrøm
ofstream testData;
Disse forskellige konstruktørkald tillader en filstrøm at blive åbnet enten ved specifikation af et
filnavn plus eventuel modus (ios::out eller ios::app), en præallokeret buffer og dens
længde, uden buffer eller blot som en filstrøm, der ikke er tøjret til en bestemt fil. Efter
konstruktion af et filstrømobjekt kan det stort set bruges på samme måde som en iostream,
idet objekter kan indlæses fra og udskrives til filen uden bekymring typen. For eksempel:
#include
#include
void main () {
ostream testData ("test.dat");
testData

eksempel 6-11
// læsning og skrivning af filer med fstream
#include
#include
int main () {
ofstream tabelFil ("output.dat");
if (!tabelFil) {
cerr

#include
#include
int main (int argc, char** argv) {
if (argc != 2) return -1;
char Buffer [100];
ifstream nextWord (argv [1]);
if (!nextWord) return -1;
ifstream > Buffer) count++;
cout

#include
#include
const fileCnt = 3;
char* Filename [fileCnt] = {
"data.hex", "data.oct", "data.dec"
};
void main () {
ofstream outputFile;
for (int i = 0; i < fileCnt; i++) {
outputFile.open (Filename [i], ios::app);
outputFile

• ios::noreplace betyder, at filen ikke må eksistere i forvejen. Hvis den gør, sættes
strømmens badbit.
• ios::text åbner filen i tekst-modus, dvs. tegn fortolkes under konverteringen, så
sekvenser med \n\r eller \r\n oversættes til \n under indlæsning og omvendt
under udlæsning. Dette er den underforståede fortolkning af strømme, og er i konstrast til
ios::binary.
• ios::binary åbner filen i binær modus, så alle tegn, der læses eller skrives
fuldstændig reflekteres i strømmen. En \n\r-sekvens læses altså som to tegn. Det er
nødvendigt at specificere ios::binary, hvis der skal arbejdes på binære data, da
flaget har betydning for alle metoder, også put() og get().
For eksempel, hvis en fil skal åbnes for output, men hvis programmet skal konfirmere en
eventuel overskrivning, kan følgende flag benyttes:
char Bekraeft;
ofstream outputFil ("output.dat", ios::out | ios::noreplace);
if (!outputFile) {
cout > Bekraeft;
if (Bekraeft == 'J' || Bekraeft == 'j')
outputFil.open ("output.dat", ios::out | ios::trunc);
}
Undertiden er der brug for at specificere den position, hvor data læses fra en fil. Denne position
beskrives med en long, hvis værdi er den byte-position, data befinder sig på. På næsten alle
systemer er spændvidden på en long 32 bits, altså et godt stykke over fire gigabytes lineært
adresserum. Vi kan spørge en strøm, hvor dens datapointer befinder sig relativt til starten af filen
med
long position = inputFil.tellg();
og sætte den med
inputFil.seekg (n);
hvor n er den ønskede position. En valgfri parameter i seekg() bestemmer relativiteten i
forhold til den ønskede slutposition: ios::beg, den underforståede værdi, søger fra starten af
strømmen, ios::end søger fra slutningen og ios::cur fra den aktuelle position. Hvis den
absolutte destination bliver en værdi mindre end 0 eller større end filens længde, sættes flaget
eofbit i strømmen.
For eksempel,
480 Filer 6.5

#include
#include
void main () {
istream inputFil ("input.dat");
char Buffer [100];
for (i = 0; i < 4; i++) {
inputFil >> Buffer;
cout

Som beskrevet i afsnit 6.1.1 findes kun overstyringer af ind- og udlæsningsoperatorerne for de
fundamentale typer. Der er ingen indbygget mulighed for at udlæse en brugerdefineret type. Af
den grund vil kode som
class Complex;
Complex c;
cout > cplx.re >> c >> cplx.im >> c;
// ... test for korrekt indlæsning herefter ...
}
De to funktioner, som i øvrigt fordi de rører ved de private data i Complex-objektet skal
erklæres som friend-funktioner i Complex, vil blive kaldt, hvis klienten skriver kode som
Complex c (5, 7);
cout

Det er også muligt for en klient at skrive sin egen manipulator ved en simpel funktionserklæring
af typen
ostream& manipulator (ostream& strm) {
// ...
return strm;
}
Dermed kan et programmør- eller applikationsspecifikt sæt af manipulatorer defineres og bruges
i strømudlæsninger for at gøre kildeteksten koncis. Følgende er et eksempel på en manipulator,
der udlæser en sekvens for at slette skærmen på en ANSI-terminal:
#define Escape = char(0x1B);
ostream& cls (ostream& strm) {
return o

Herefter kan klienten kalde manipulatoren colour efter de normale regler, blot med et
parameter i parantes:
cout

6.7 OPGAVER TIL KAPITEL 6
1. Erklær en type Person med navn og alder, og overstyr operatorerne > for
istream og ostream, så objekter af klassen kan ind- og udlæses på normal vis.
2. Skriv en klasse DiskFile, som tillader læsning fra vilkårlige steder. Brug eventuelt
indekserings-operatoren til formålet.
3. Udvid DiskFile fra opgave 6-2, så den indekserer på Person-objekterne fra
opgave 6-1 i stedet for på byteværdier.
4. Ved hjælp af arv og polymorfi, skriv klassen fra opgave 6-3 om, så den kan indeksere
vilkårlige objekter i filen.
5. Skriv manipulatorer til (a) at kopiere en fil til strømmen, (b) at slette skærmen, (c) at
skrive med kursiv skrift på printeren, (d) at forvente et "ja/nej" svar, (e) at indsætte tid og
klokkeslet.
6. Nedarv en klasse ww_ostream fra ostream, og implementér den virtuelle metode
operator

Klassebiblioteket XCL
På de følgende sider vil et komplet klassebibliotek blive præsenteret, med
forskellige faciliteter for kombinationer af objekter, integration med klassiske
strukturer og algoritmer, integration med standardbiblioteket, simpel bestandighed
og naturligvis som fundament for objekt-orienteret udvikling. Biblioteket er et
eksempel på design af biblioteker, og kan i vid udstrækning bruges til at lære at
forstå de forskellige fordele og ulemper ved programkonstruktion af denne art.
7.1 INTRODUKTION
Klassebiblioteket XCL, Example Class Library, er en samling af cirka 20 klasser til generel
databehandling. Der findes klasser til listebehandling, køer, stakke og kataloger med
associationer mellem data. Der er både dynamiske og lineære lister, sorterede og tilfældigt
arrangerede, indeksérbare og associative. Der er strenge og numeriske datatyper samt værktøj til
integration af forskellige typer af objekter i containerklasser. Biblioteket gør naturligvis stor brug
af polymorfi og arv, og indkapsler omhyggeligt de respektive implementationer i klasserne. Det
kan bruges til enhver opgave, der indeholder trivielle administrative behandlinger og kan
naturligvis udbygges efter behov. Da første udgave af denne bog udkom, var skabeloner og
parametiserede typer endnu ikke en del af sproget, hvorfor template'r ikke tog del i XCL. I
denne udgave beskrives en ny version af XCL, version 3.0, som benytter sig af skabelon-klasser
som fundament for containerklasser.
Vi har i de forrige kapitler allerede stiftet bekendtskab med flere af de containerklasser og
aktive klasser, som indgår i XCL. Forskellen er blot, at de her alle er relateret til hinanden, og
alle har en fælles grænseflade gennem almene baseklasser. Det er altså en god lektion og
indføring i integration af datatyper, som allerede er skrevet eller defineret, men som skal indgå i
en større sammenhæng. XCL er implementeret som ét hierarki, og alle klasser er på en eller
anden måde subtyper af en og samme baseklasse.
Som det kan ses i figur 7-1, er hierarkiet over klasserne i XCL opdelt i et par forgreninger, som
kan benævnes containerklasser, sortérbare klasser og private værktøjsklasser. Der er kun fire
abstrakte klasser, resten er aktive og umiddelbart brugbare.
486 Opgaver til kapitel 7 6.7
7

7.1.1 Funktionalitet i XCL
Figur 7-1: Hierarkisk fordeling af klasserne i XCL.
Klassebiblioteket er holdt lille, så det er overskueligt, men dog anvendeligt. Der er lagt stor vægt
på, at de forskellige typer skal kunne blandes sammen af klienten, som skal have mulighed for at
arbejde med polymorfi uden de store problemer, kunne arbejde med vektorer og lister som
fundamentale datatyper (i tildelinger, additioner osv.) samt at kunne ind- og udlæse
komplicerede datastrukturer til disk i et maskinuafhængigt, implementationsuafhængigt format.
Til beskrivelsen af hver klasse følger også et eller flere eksempler på brugen af klassen. Som
flere nye klasser introduceres, bliver deres sammenhæng åbenbar.
7.1.2 Opbygning af klassebiblioteket
XCLs abstrakte "superklasse", som er base for alle klasser i biblioteket, indeholder et antal rene
virtuelle funktioner, som er implementeret i de aktive klasser længere nede. Disse funktioner gør
det muligt at
• Sammenligne to objekter,
• Udskrive et objektindhold på en læselig måde,
6.6.2 Brugerdefinerede manipulatorer 487

• Udlæse et objekt med typeinformation på en strøm,
• Indlæse et objekt fra en strøm,
• Kopiere et objekt,
• Finde typen på et objekt og
• Finde navnet på et objekt.
Disse operationer har alle XCL-objekter til fælles. For containerklasser i XCL gælder, at de har
en udvidet polymorf grænseflade, idet deres virtuelle funktioner muliggør at
• Indsætte et objekt i en container,
• Udtage et objekt fra en container,
• Undersøge (se på) et objekt i en container og
• Sammenlægge to conatinere.
ud over den øvrige funktionalitet. De forskellige typer af containerklasser er skrevet, så de
lægger et fundament for videre udvidelse. I toppen af hierarkiet findes en ikke-abstrakt
baseklasse for alle containere, ContainerBase. Denne klasse bruges til at klistre
parameteriserede og ikke-parameteriserede containerklasser sammen, så de har et minimum af
dataelementer, de kan deles om. Klassen Container er arvet fra Object og definerer et
stort antal rene virtuelle metoder og implementerer et par metoder, der er ens for alle containere.
Der er desuden to parameteriserede container-baseklasser for henholdsvis hægtede lister og
lineære lister, GenericList og GenericArray, som også arver fra ContainerBase
og som instansieres under arv i de afledte klasser. Pointen er her, at de parameteriserede
containerklasser skaber en frihed i instantieringer, fordi de ikke er polymorfisk afhængige af
baseklasser med virtuelle metoder mens de polymorfe containerklasser kan blandes sammen af
klienten og samtidig drage fordel af de parameteriserede klasser. Denne delegering af
mekanikken bag containerne gør, at nye containere kan defineres med meget lidt besvær.
Samtidig er alle instantieringer af de parameteriserede klasser gjort med samme type - en
Object-pointer - så der er ikke tale om overforbrug af de parameteriserede klassers
medlemsfunktioner.
Containerklasser i XCL indeholder et begreb om placeringen de objekter, de besidder, og
ladder denne skinne svagt igennem til klienten. Således kan en klient arbejde med "abstrakte
pointere" til elementer i containerne på en meget transparent måde. Denne transparens er
implementeret via en opfattelse af containerklassen som en række af objekter, som kan findes
ved kald til medlemsfunktioner, der returnerer henholdsvis det første, næste og aktuelle element i
containeren. På den måde kan alle containere gennemløbes og behandles i den kontekst, som den
underliggende datastruktur repræsenterer.
7.1.3 Hierarkiet og standardbiblioteket
XCL arbejder sammen med standardbiblioteket iostream.h, altså version 2 af AT&Ts
standardbibliotek, beskrevet i kapitel 6. Strømme bruges i alle ind- og udlæsningssituationer
samt til at udskrive objekternes indhold. Af den grund rådes klienter af XCL også til at benytte
488 Introduktion 7.1

strømbiblioteket. Der er absolut ingen maskin-, oversætter- eller miljøspecifikke detaljer i XCL,
som vil kunne oversættes under alle systemer, der holder sig til C++ 3.0 eller det udkast, ANSI
har lavet til sproget.
I de følgende afsnit beskrives klassere én for én. I starten af hvert underafsnit opremses
arvefølgen for den aktuelle klasse samt headerfilen, hvor klassens erklæring er foretaget. For
eksempel,
BaseKlasse
AfledtKlasse
betyder, at der kommer en forklaring af AfledtKlasse, som er arvet fra BaseKlasse
som findes i de nævnte filer. Disse filer findes i deres helhed i appendiks F. I de tilfælde, hvor
der anvendes multipel arv, gentages arvefølgerne for hver baseklasse, som i
BaseKlasse1
AfledtKlasse
BaseKlasse2
AfledtKlasse
7.2 ABSTRAKTE KLASSER
De abstrakte klasser i biblioteket er få, men vigtige. Den første klasse, Object er moderklasse
til alle andre klasser i hierarkiet, og er grunden til, at de overhovede kan arbejde sammen. Den
anden klasse, Container, er en generel grænseflade til en klasse, der indeholder objekter af
andre klasser. Der er en polymorf container i dobbelt forstand, både fordi den tillader forskellige
subtyper af Container at blive behandlet på samme måde og fordi en Container
udelukkende arbejder på referencer til Object-objekter. Den tredie, Sortable, definerer en
grænseflade for et sortérbart objekt og implementerer de fleste af metoderne for sammenligning
af objekter på en større-end og mindre-end basis.
Disse tre abstrakte klasser indeholder størstedelen af kompleksiteten i selve hierarkiet, fordi der
generelt i XCL kun arbejdes på referencer eller pointere til disse klasser.
7.2.1 Klassen Object
Object
Superklassen, som man kunne kalde den, er så abstrakt, som den kan blive: næsten udelukkende
rene virtuelle funktioner og en beskyttet konstruktør. I Object erklæres alle de virtuelle
metoder, der skal gælde for alle klasser i hierarkiet. Her er erklæringen på Object:
class Object {
7.1.3 Hierarkiet og standardbiblioteket 489

protected:
Object () { };
Object (const Object&) { };
public:
virtual ~Object () { };
virtual void printOn (ostream& = cout) const = 0;
virtual void readFrom (istream& = cin);
virtual void dumpOn (ostream& = cout) const;
virtual bool isEqual (const Object&) const = 0;
virtual Class Type () const = 0;
virtual Object& Copy () const = 0;
virtual const char* Name () const = 0;
};
Klassen har ingen datamedlemmer, blot virtuelle funktioner. Det er altså en helt generel ramme
for afledte klasser. De forskellige funktioner har meget præcist definerede og vigtige
betydninger, og forklares én for én:
Object () { };
er den underforståede konstruktør, som kaldes for alle oprettelser af objekter uden samtidige
initieringer af klasser i XCL. Den laver ikke meget, men er et udmærket sted at sætte breakpoints
ind.
Object (const Object&) { };
er kopi-konstruktøren, som kopierer objekter. Det er vigtigt, at den afledte klasse, som
indeholder en kopi-konstruktør kalder den tilsvarende kopi-konstruktør i sin(e) baseklasse(r) med
det samme parameter. Parameteret vil automatisk blive konverteret.
virtual ~Object () { };
er den virtuelle destruktør. Den er virtuel, fordi der er andre virtuelle funktioner i Object, og
for at undgå at klienten opretter et objekt af en afledt klasse og tildeler adressen herpå til en
pointer til en baseklasse og derefter destruerer det, så den forkerte destruktør bliver kaldt (se
afsnit 4.4.9).
virtual void printOn (ostream& = cout) const = 0;
er en udskrivningsmetode, som blot skriver objektets indhold pænt ud, helt i en sammenhæng
som passer til objektets type. Med andre ord, udskriften må godt have et par ekstra mellemrum,
linieskift eller andre fyldetegn, hvis det hjælper på forståelsen af objektets indhold. Et eksempel
er, at et komplekst tal udskrives som (1,-1) uden at der er hverken paranteser eller komma i
objektet.
490 Abstrakte klasser 7.2

virtual void readFrom (istream& = cin);
er en indlæsningsmetode, som læser et objekt ind fra en strøm. Strømmen skal være positioneret,
således at objektets data står på den aktuelle plads og er klar til at blive indlæst i objektets data.
Funktionen er ikke statisk, og arbejder altså på et allerede allokeret objekt, med den store fordel
til følge, at den er virtuel. Det er altså muligt for en klient at indlæse indholdet af et objekt, for
hvilken den egentlige type ikke er kendt. readFrom() arbejder sammen med dumpOn(),
og disse to er de eneste normale metoder, der er implementeret for klassen Object.
virtual void dumpOn (ostream& = cout) const;
er en udlæsningsmetode, der er komplimentær til readFrom(). dumpOn() er
implementeret for Object, og vil udlæse både objektets type og objektets indhold på
strømmen. Grunden til, at typen er så vigtig at udlæse er, at readFrom()-funktionen (samt
visse andre associerede funktioner i klassen ObjectManager) skal have en chance for at
kunne identificere hvad de læser ind igen. Typen udlæses som en streng, navnet på objektets
klasse, ved et kald til Name().
virtual bool isEqual (const Object&) const = 0;
er en sammenligningsoperation, der tillader to vilkårlige objekter at blive sammenlignet.
Klienten bør dog ikke kalde isEqual() uden at være helt sikker på de egentlige typer, der
arbejdes på, for de fleste implementationer af funktionen foretager en tvungen typekonvertering
af parameteret. Der er erklæret en global sammenligningsoperator, som sikrer typeækvialens før
den kalder isEqual().
virtual Class Type () const = 0;
returnerer objektets type. Class er en opremsning, hvori alle XCL-klasser erklæres som
medlemsværdi, og således får en unik identifikation. Type() bruges blandt andet til
sammenligning af objekter.
virtual Object& Copy () const = 0;
er en kopi-funktion, der allokerer en kopi af objektet og returnerer denne kopi til klienten som
reference. Anvendelsen af denne funktion, som på en måde kan sammenlignes en kopikonstruktør,
er at kunne kopiere en pointer til et polymorft objekt. Med kopi-konstruktøren, som
ikke kan være virtuel, er det ikke muligt at skabe en kopi uden at kende til typen af objektet.
Copy() kalder typisk objektets kopi-konstruktør for et nyallokeret objekt.
virtual const char* Name () const = 0;
returnerer blot objektets navn. Anvendelsen af denne funktion er primært henvendt til
7.2.1 Klassen Object 491

administration af objekt-I/O (se afsnit 3.7.4 og 5.7), hvorved objektets typenavn bliver udlæst
sammen med dets indhold. Grunden til, at et navn og ikke et nummer (for eksempel returværdien
fra Type()) bruges er, at navnet er applikationsuafhængigt mens typenummeret kommer an på
det aktuelle program.
Med klassen Object som den gennemgående grænseflade er det muligt at skrive forskellige
generelle funktioner og klasser. For eksempel sammenligningsoperatorer:
bool operator== (const Object& o1, const Object& o2) {
return o1.Type () == o2.Type () ? o1.isEqual (o2) : 0;
}
bool operator!= (const Object& o2, const Object& o2) {
return ! (o1 == o2);
}
eller til integration med standardbibliotekets ind- og udlæsningsoperatorer, så disse gælder for
alle objekter i XCL:
ostream& operator> (istream& strm, const Object& o) {
o.readFrom (strm);
}
Den næste abstrakte klasse, Container, benytter udelukkende pointere og referencer til
Objecter i sin grænseflade. Denne lille klasse er således en fundamental platform for den
videre udvikling af biblioteket.
7.2.2 Klassen ContainerBase
ContainerBase
Denne klasse definerer minimums-fællestræk for alle containere i XCL. Den er abstrakt for
klienter, fordi dens konstruktør er protected og bruges derfor kun som baseklasse fra bla.
Container, GenericList og GenericArray. Klassens funktion er at holde rede på
noget så fundamentalt som antallet af elementer i containeren samt det aktuelle element, som
containeren på et givet tidspunkt arbejder på. Containere i XCL 3.0 har nemlig den facilitet, at de
indeholder begrebet "aktuelt indholdt objekt", som gør det muligt for klienten at arbejde mere
lineært på containere.
Her er erklæringen af ContainerBase:
492 Abstrakte klasser 7.2

class ContainerBase {
protected:
unsigned long elementCount; // størrelse på container
unsigned long currentIndex; // aktuelt index i container
ContainerBase (unsigned long size = 0)
: elementCount (size), currentIndex (0) { }
ContainerBase (const ContainerBase& other)
: elementCount(other.elementCount), currentIndex(0) { }
};
Klassens to datamedlemmer, elementCount og currentIndex repræsenterer
henholdsvis det aktuelle antal af elementer i containeren og indekset på det aktuelle. De er
erklæret som unsigned long, og der kan således være et stort antal objekter i en container
(typisk lidt over fire milliarder, mere præcist konstanten ULONG_MAX i ). De to
konstruktører opretter henholdsvis en "tom" container og kopierer medlemmerne fra en anden
container. Det er kun afledte klasser, der kan arbejde med ContainerBase, ikke klienter, og
klassens funktion er da også at klistre specifikke containerklasser sammen længere nede i
hierarkiet. De to datamedlemmer skal nemlig kunne bruges af søsterklasser, som begge er
baseklasser til multipelt afledte containere, som for eksempel LinkedList.
7.2.3 Klassen Container
Object
Container
ContainerBase
Container
Den abstrakte containerklasse er baseklasse for alle containere i XCL-biblioteket. Container
er multipelt afledt fra både Object og fra ContainerBase, og arver således en hel del rene
virtuelle metoder fra Object samt to datamedlemmer fra ContainerBase.
Her er erklæringen af Container (læg mærke til, at de rene virtuelle metoder, som den
arver fra Object og ikke generklærer består som rene virtuelle metoder):
class Container : public Object,
public virtual ContainerBase {
friend Iterator;
protected:
Container (unsigned long size = 0)
: ContainerBase (size) { }
Container (const Container& other)
: ContainerBase (other), Object (other) { }
public:
7.2.2 Klassen ContainerBase 493

virtual ~Container () { }
virtual void Insert (Object*) = 0;
virtual Object* Retrieve () = 0;
virtual unsigned Size () const;
virtual Container& operator+= (Container&);
virtual const Object& operator[]
(const unsigned long) const = 0;
virtual const Object* getFirst () const = 0;
virtual const Object* getNext () const = 0;
virtual const Object* getCurrent () const = 0;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
};
Alle medlemsfunktioner, med undtagelse af de beskyttede konstruktører, er virtuelle. Der
udvides således med 9 virtuelle funktioner ud over de 8, der arves fra Object, og der defineres
ingen data. Her følger en forklaring på Containers medlemsfunktioner:
Container (unsigned long size =0) : ContainerBase (size) { }
opretter en "tom" container, uden indhold. Her kaldes Objects underforståede konstruktør
automatisk og ContainerBases initierings-konstruktør eksplicit. Det er en protected
konstruktør, fordi kun afledte klasser må specificere en størrelse ved konstruktionen.
Container (const Container& other) :
ContainerBase (other), Object (other) { }
er kopi-konstruktøren, som initierer containeren med en anden container og kalder baseklassen
Objects kopi-konstruktør.
virtual ~Container () { }
destruerer en container. Der er ingen data at destruere, fordi det eneste datamedlem er af typen
auto og deallokeres af systemet. I de afledte klasser, som implementerer en egentlig container,
skal destruktøren sørge for også eksplicit at deallokere eventuelle indeholdte objekter. Se afsnit
5.6.1.
virtual void Insert (Object*) = 0;
indsætter data i containeren. Parameteren er objektet, der skal indsættes i containeren, en adresse
på et Object. Placeringen af dette objekt i selve containeren kommer helt an på containerens
natur - en kø, stak, mængde eller hvad det nu er. Den ikke-abstrakte, parametiserede klasse
GenericList, som beskrives i afsnittet nedenfor om containerklasserne i XCL indeholder et
"aktuelt element" efter hvilket Insert() vil indsætte det nye. Det væsentlige her er, at
494 Abstrakte klasser 7.2

metoden overdrager et objekt fra klientens til containerens hænder.
virtual Object* Retrieve () = 0;
udtager et objekt fra containeren, og overgiver det til klienten. Det er den omvendte operation i
forhold til Insert(). Placeringen af det objekt, der udtages afhænger igen af den egentlige
afledte containerklasse. Når klienten kalder Retrieve() fjerner containeren objektet fra sig
selv, og klienten får ansvaret for det.
virtual const Object* getCurrent () const = 0;
er en funktion, der finder det "første" element i containeren. Opfattelsen af dette første element
afhænger af den afledte klasse, som implementerer funktionen. Det er et "kig" ind i en container
uden at fjerne objektet fra containeren. Derfor returnerer funktionen en konstant objektreference,
så klienten ikke kan manipulere med objektet. Hele funktionen er tillige konstant, og kan ikke
ændre på de indeholdte data. Det sikrer konsistensen nedad i hierarkiet, og getCurrent()
bliver en metode til blot at se ind i containeren uden hverken ansvar eller pligter.
De to næste funktioner arbejder sekventielt på elementerne i containeren på en måde, der giver
containeren en simpel lineær semantik. Begrebet "første element", "næste element" og "aktuelle
element" implementeres med de tre medlemsfunktioner getFirst(), getNext() og
getCurrent().
virtual const Object* getFirst () const = 0;
virtual const Object* getNext () const = 0;
Det er de samme regler for konstante returværdier, der ligger til grund for disse to funktioner, så
klienten kun kan læse dem og ikke skrive til dem.
virtual unsigned long Size () const { return count; }
returnerer størrelsen på containeren, altså antallet af elementer. Metoden er implementeret i
Container som den eneste sammen med operator+=().
virtual Container& operator+= (Container&);
er en metode til at addere to containere, eller mere specifikt til at lægge en anden container
sammen med den aktuelle. Metoden er implementeret i Container og benytter sig af
Container::getCurrent(), Container::Insert() og Object::Copy() til at
kopiere containeren.
virtual const Object& operator[] (int) const = 0;
har den samme betydning som getCurrent(), men med en bedre grænseflade.
7.2.3 Klassen Container 495

Resten af Containers medlemmer er direkte arvet fra Object og er blot igen erklæret
som virtuelle rene funktioner. Da en Container er abstrakt er der ingen grund til at
implementere dem. Med den ny viden om Container-objekters opførsel kan vi for eksempel
skrive en generel funktion til at undersøge, om en given Container er en delmængde af en
anden, dvs. om alle objekterne i den ene også forekommer i den anden.
bool subSet (Container& a, Container& b) {
for (int i = 0; i < a.Size (); i++) {
Object& searchFor = a [i];
for (int j = 0; j < b.Size (); j++)
if (searchFor == b [i]) break;
if (j == b.Size ()) return 0;
}
return 1;
}
7.2.4 Klassen Sortable
Object
Sortable
I Object findes en metode til sammenligning af objekter, isEqual(). I mange situationer,
eksempelvis sortering eller søgning, er det vigtigt at kunne sammenligne objekter og få at vide
hvilket som er "størst" fremfor blot en sandhedsværdi om lighedsforholdet. For at opnå at kunne
sammenligne objekter på en større/mindre-end basis introduceres klassen Sortable som
baseklasse for alle klasser, der skal have denne egenskab.
Sortable indeholder kun én ny ren virtuel metode, som ganske simpelt tester om det
aktuelle objekt er større end et givet andet sortérbart objekt. Klassens erklæring er
class Sortable : public Object {
public:
virtual bool isGreater (const Sortable&) const = 0;
};
Medlemsfunktionen isGreater() sammenligner de to sortérbare objekter og returnerer en
sandhedsværdi - sand, hvis *this er større end det angivne parameter, ellers falsk. Det
interessante ved isGreater() i forbindelse med den nedarvede isEqual() er, at vi med
disse to funktioner (og lidt logik) globalt kan overstyre alle de forskellige operatorer for
sammenligning af objekter på forskellige måder:
bool operator> (const Sortable& a, const Sortable& b) {
return a.isGreater (b);
}
496 Abstrakte klasser 7.2

ool operator< (const Sortable& a, const Sortable& b) {
return ! (a.isGreater (b) || a.isEqual (b));
}
bool operator>=(const Sortable& a, const Sortable& b) {
return a.isGreater (b) || a.isEqual (b);
}
bool operator

aIterator, // gennemløb af containere
aAssociation, // en association mellem objekter
aDictionary, // et katalog over associationer
};
Hver ny klasse, der introduceres i hierarkiet, bør påføres denne liste - eller gives et vilkårligt,
helst højt, nummer. Bemærk, at det ikke er en stavefejl når der optræder navne som
aAssociation, men engelsk morfologi kommer trods alt i anden række. Udover disse typer
indeholder headerfilen tre vigtige makrodefinitioner, nemlig
DECLARE_AS_STOREABLE (class)
som vil annoncere den aktuelle klasse i XCL-typesystemet, og tillade at objekter af klassen kan
ind- og udlæses med typeinformation,
DECLARE_TRIVIAL_FUNCTIONS (class)
som erklærer de funktioner i klassen, som er helt trivielle og åbenlyse, men som dog ikke kan
nedarves af andre årsager, for eksempel Copy() og Name(),
DEFINE_TRIVIAL_FUNCTIONS (class)
som implementerer de funktioner, som forrige makro erklærer. De to sidste makroer skal
henholdsvis optræde i klasseerklæringen i headerfilen og i selve implementationsfilen. Hvis de
ønskes implementeret som inline-funktioner, skal DEFINE_TRIVIAL_FUNCTIONS stå i
klassens erklæring i stedet for DECLARE_TRIVIAL_FUNCTIONS.
7.3.1 Klassen Nil
Object
Nil
Nil er XCL-modstykket til C's NULL-pointer. Et objekt er nul, ulovligt, fejl eller hvad man har
lyst til at kalde det, hvis det er lig en forekomst af Nil. I XCL er der kun én forekomst af
klassen Nil, nemlig det statisk allokerede objekt nil (med lille forbogstav). Metoderne i
Nil er skrevet, så de regner med, at der kun findes en enkelt forekomst og bekymrer sig i øvrigt
ikke om adresser og indhold. Hvis klienten således erklærer et nyt Nil-objekt med et andet
navn vil det være identisk med nil.
Nil er det første eksempel på en aktiv, ikke-abstrakt klasse i XCL, men implementationerne
af de virtuelle funktioner er ikke særlig rammende for en XCL-klasse idet Nil-klassen er meget
enkel i funktion. Den skal bare gøre opmærksom på sin eksistens og ellers fylde så lidt som
muligt. Da der ingen data er i et Nil-objekt, og heller ikke i et Object-objekt, som det arver,
vil det blot bestå af en pointer til en virtuel tabel, hvilket ofte kan indeholdes i et register på
498 Værktøjsklasser 7.3

maskinen. Her er Nil's erklæring og implementation:
extern Nil nil; // den eneste forekomst
class Nil : public Object {
public:
Nil () { }
virtual ~Nil () { }
virtual void printOn (ostream& strm = cout) const {
strm > ws;
}
virtual bool isEqual (const Object& o) const {
return bool (&o);
}
virtual Class Type () const { return aNil; }
virtual Object& Copy () const { return nil; }
virtual const char* Name () const { return "Nil"; }
};
Klassen Nil laver således ikke ret meget, men har sin anvendelse i situationer som
konsistenscheck af objekter. Forestil dig for eksempel, at du udtager et objekt fra en tom
Container:
void getOb (Container& cont) {
Object& o = *cont.Retrieve ();
if (o == nil) cerr

eferencer eller to objektpointere, der sammenlignes. Det er på visse systemer med segmenteret
lager (for eksempel IBM PC/AT) svært at foretage ordentlig pointeraritmetik, hvorfor følgende
kode er uønskelig:
bool Consistency (Object* o) {
return o == &nil;
}
fordi den blot sammenligner pointerne. Brug i stedet
bool Consistency (Object* o) {
return *o == nil;
}
hvilket vil kalde den rette operator-funktion og, i anden række, binde dynamisk til de to objekters
isEqual()-metoder. Denne regel gælder for sammenligning af alle typer af objekter i XCL.
Typesystemet er hævet til så højt et plan på kørselstidspunktet, at gemen pointeraritmetik ikke
slår til.
7.3.2 Klassen ObjectManager
ObjectManager
classInfo
Der er i XCL brug for en smule overordnet administration af objekterne. Denne administration er
indkapslet som statiske metoder og medlemsdata i klassen ObjectManager, som indeholder
noget af den "klister" der er nødvendig for visse af de avancerede funktioner i biblioteket - for
eksempel at kunne indlæse et objekt fra en strøm uden at kende typen af objektet.
ObjectManager har en central og enkel funktion, nemlig at løse det problem, der opstår,
når et objekt af en given type skal allokeres, men hvor vi på oversættertidspunktet ikke kender
typen. I ObjectManager findes en database over de forskellige ikke-abstrakte klassers navne
tillige med adresser på særlige funktioner, som eksplicit allokerer en forekomst af den klasse.
Denne information er gemt i en hægtet liste af classInfo-strukturer, som associerer et
klassenavn med en eksplicit allokationsfunktion.
Alt dette foregår selvfølgelig uden klientens indblanding. Alle klasser i systemet "annonceres"
til ObjectManager før klientens program startes via statiske initieringer i de forskellige
moduler, for eksempel som
static Object* CreateSomething () {
return new Something;
}
static bool initSomething = ObjectManager::Announce (
500 Værktøjsklasser 7.3

"Something", CreateSomething
);
hvorved ObjectManager nu er klar over, at et objekt med navnet Something kan
konstrures ved at kalde funktionen CreateSomething(). Faktisk er det lidt af
oversætterens arbejde, vi her overtager, men C++ arbejder som bekendt slet ikke med navne, kun
adresser og værdier, så et symbol som CreateSomething eksisterer ikke på
kørselstidspunktet. Implementationen af disse to funktioner for en given klasse er ideen med
makroen DECLARE_AS_STOREABLE, som ekspanderer til disse to (temmelig trivielle)
funktioner givet et parameter, navnet på klassen. Denne makro forekommer derfor i de fleste
moduler i XCL.
Her er erklæringen på ObjectManager:
class ObjectManager {
static classInfo* classList; // liste over objekter
public:
~ObjectManager ();
static Object* readPolymorphicObject (istream& = cin);
static bool Announce (char*, PTOM);
};
Den anden statiske medlemsfunktion, readPolymorphicObject() benytter sig af
informationen om de eksplicitte klassekonstruktioner til at indlæse et klassenavn, allokere en
forekomst af denne klasse, kalde klassens readFrom()-funktion for at indlæse det fra
strømmen og til sidst returnere det til klienten. Det tillader kode som
Object* o = ObjectManager::readPolymorphicObject ();
hvor o kan være af en hvilkensomhelst type, og, som vi skal se senere, kan være en meget
kompleks datastruktur af kombinerede XCL-klasser.
Destruktøren sørger for, at den hægtede liste af classInfo-strukturer med information om
klassernes allokationsfunktioner bliver slettet (faktisk er det kun hægterne, der slettes - navnene
er blot pointere til de samme konstanter, som bruges i de virtuelle Name()-funktioner).
7.3.3 Klassen SharedObject
Object
SharedObject
Selv om reglen om containerklasser siger, at en container "ejer" det objekt, det indeholder og
derfor er ansvarlig for at destruere det, er der dog tidspunkter, hvor der må undtages fra denne
regel. Et typisk eksempel er, hvis to containere skal deles om samme objekt. Hvad gør man så?
Enten må den ene container skrives helt om (i en afledning) eller også må klienten lave lidt
7.3.2 Klassen ObjectManager 501

akrobatik. XCL vælger det sidste, fordi det er det enkleste.
Klassen SharedObject er både arvtager og klient af Object. Den indeholder en pointer
til et Object, og alle de virtuelle funktioner, den arver fra Object føres direkte videre til det
indkapslede objekt - med én undtagelse: destruktøren. Den er tom.
class SharedObject : public Object {
Object* ref;
public:
SharedObject (Object* o) : ref (o) { }
SharedObject (Object& o) : ref (&o) { }
virtual ~SharedObject () { }
virtual void printOn (ostream& s = cout) const {
ref->printOn (s);
}
virtual void readFrom (istream& s = cin) {
ref->readFrom (s);
}
virtual void dumpOn (ostream& s = cout) const {
ref->dumpOn (s);
}
virtual bool isEqual (const Object& o) const {
return ref->isEqual (o);
}
virtual Class Type () const {
return ref->Type ();
}
virtual Object& Copy () const {
return ref->Copy ();
}
virtual const char* Name () const {
return ref->Name ();
}
};
Det tillader en komplet transparent indsættelse af et objekt i en container, men sikrer, at når
containeren forsøger at destruere sit indhold, så vil SharedObject's destruktør sikre, at
objektet forbliver intakt. Og så påhviler det naturligvis klienten at destruere objektet. Et
eksempel (der benytter String-objekter fra afsnit 7.4.1) er:
void Share (Contaier& c1, Container& c2) {
String* s = new String ("Delt streng");
c1.Insert (*new SharedObject (s));
c2.Insert (*new SharedObject (s));
}
502 Værktøjsklasser 7.3

Når de to Containere, der bruges i funktionen her, deallokeres, vil deres kald til destruktøren
i de objekter, de indeholder standse i SharedObjects destruktør.
7.3.4 Klassen Iterator
Object
Iterator
Iterationer, eller gennemløb, af containere på samme måde som en normal C-vektor eller liste er
beskrevet i detaljer i afsnit 5.6.4. I XCL implementeres en Iterator-klasse, der virker på alle
typer af containere, så længe de er arvet fra Container. En Iterator initieres af enten en
anden Iterator eller en Container. I begge tilfælde vil den ny Itarator pege på en
Container og begynde at indeksere den.
Til dette formål vedligeholder Iterator en indeksværdi, som benyttes i kald til
Container::getNext(), indtil indeksværdien kommer op på siden af
Container::Size() for et givet container-objekt. Dette indeks optælles hver gang
Iteratoren optælles via kald til operator++(). Den anden overstyrede operator,
dereferencen (ikke multiplikation, som er binær), returnerer en konstant reference til det objekt,
der står på den position i containeren, som iteratoren for øjeblikket refererer. For også med enkel
syntaks at kunne teste en Iterators tilstand, specifikt om den stadig peger på valide data i
containeren, kan en Iterator konverteres til en bool.
Her er erklæringen af Iterator:
class Iterator : public Object {
Container* ref;
int index;
public:
DECLARE_TRIVIAL_FUNCTIONS (Iterator);
Iterator () : ref (NULL), index (0) { }
Iterator (const Iterator& i) :
ref (i.ref), index (i.index) { }
Iterator (Container& c) : ref (&c), index (0) { }
virtual ~Iterator () { }
virtual bool isEqual (const Object&) const;
virtual void printOn (ostream& = cout) const;
const Object& operator* ();
Iterator& operator++ (); // prefix
Iterator& operator++ (int); // postfix
operator bool ();
bool More ();
};
7.3.3 Klassen SharedObject 503

Vi kan for eksempel løbe gennem en container på følgende måde:
void printContainer (Container& c) {
for (Iterator i = c; i; i++) cout

implementation af readFrom() og dumpOn(), derfor:
void String::readFrom (istream& strm) {
Sortable::readFrom (strm); // indlæs baseklassen
if (len) delete sptr; // noget i forvejen?
strm >> len; // længde på streng
sptr = new char [len + 1]; // allokér ny streng
strm.getline (sptr, len); // indlæs den
}
void String::dumpOn (ostream& strm) const {
Sortable::dumpOn (strm); // udlæs baseklassen
strm

Object& o = *ObjectManager::readPolymorphicObject (input);
cout

Object
Sortable
Complex
Denne klasse er næsten identisk med den gennemgående eksempelklasse fra kapitel 3, og
indeholder derudover kun implementationer af virtuelle funktioner fra baseklasserne
Sortable og Object.
7.5 CONTAINERKLASSER
Containerne i XCL er hierarkiets egentlige substans. Containerklasser er i det hele taget den
grundpille i et objekt-orienteret system, som har størst betydning og anvendelse. I XCL er alle
containerne afledt fra klassen Container, og er polymorfe både i anvendelse (de kan erstatte
hinanden) og i indhold (de kan indeholde objekter af forskellige klasser på samme tid). I dette
afsnit beskrives de seks containerklasser samt den private klasse Association, der arbejder
sammen med nogle af containerne.
Containerhierarkiet er udbygget en del i forhold til tidligere versioner af XCL, idet
parameteriserede typer nu spiller aktivt ind.
7.5.1 Klassen GenericList::GenericNode
GenericList::GenericNode
Alle containere, der bygger på hægtede lister, arbejder på hægter, der indirekte refererer de
objekter, containeren indeholder. Hægter i XCL var tidligere gennemført med en generel klasse
Node, som klienten havde i sit skop, men aldrig så, fordi det foregik gennem Object-pointere.
Det gav en del spildtid i form af kald til funktioner, der blot videreførte disse kald. Nu er
hægtearbejdet lagt ind i den parameteriserede klasse GenericList (som beskrives nedenfor)
og ser ganske simpelt ud som følger:
struct GenericList::GenericNode {
GenericNode* next;
Element* objptr;
GenericNode (Element* obj) : objptr (obj), next (0) { }
};
Klassen GenericNode er indlejret i den parameteriserede klasse GenericList og
indeholder ikke selv nogen form for mekanik hvad angår hægtning. Figur 7-2 er en illustration af
GenericNodes måde at kæde forekomster sammen på.
Et alternativ til denne private hægteklasse er en reel XCL-klasse, som klienten må arve fra, når
objekter skal kædes ind i lister. Denne fremgangsmåde betyder imidlertid, at alle klasser, der skal
hægtes, skal nedarves specielt og udfyldes med visse adminstrative funktioner, en arbejdsgang,
7.4.2 Klassen Complex 507

der ikke altid er lige hensigtsmæssig. Den nuværende implementation skjuler helt mekanikken
bag grænsefladen i GenericList.
7.5.2 Skabelonklassen GenericList
ContainerBase
GenericList
Denne klasse er en parametrisk definition af den mekanik, der ligger bag XCLs måde at arbejde
med hægtede lister på. Det er en minimumsdefinition af en hægtet liste og udgør sammen med
GenericArray det underliggende, maskinnære arbejde med fordeling, organisering og
lokalisering af data i XCL. GenericList indkapsler typen GenericNode, som hægter de
enkelte objekter sammen, og det er disse objekter, der er parameteret i instantieringen af klassen.
template
class GenericList : public virtual ContainerBase {
public:
struct GenericNode {
GenericNode* next;
Element* objptr;
GenericNode (Element* obj)
: objptr (obj), next (0) { }
};
protected:
GenericNode* head; // begyndelsen
GenericNode* cursor; // aktuel hægte
GenericNode* trail; // følger cursor
GenericNode* tail; // slutningen
GenericList ();
~GenericList ();
void insertAt (Element*, GenericNode*);
void Insert (Element*);
Element* Retrieve ();
Element* getCurrent() const;
Element* getFirst ();
Element* getNext ();
};
Der er fire datamedlemmer i GenericList, der alle er pointere til forekomster af
GenericNode. head peger altid på den første hægte i listen og har værdien 0, hvis listen er
tom. Denne pointer bruges til altid at kunne lokalisere den første hægte, hvilket er brugbart, når
data skal indsættes i starten og nødvendigt, når hele listen skal gennemløbes i for eksempel
destruktøren. tail peger på samme måde på den sidste hægte i listen og er især anvendelig,
508 Containerklasser 7.5

når data skal sættes ind her. Det sparer, at listen gennemløbes hver gang, den sidste hægte skal
findes. Klassen garanterer, at tail altid peger på den sidste hægte. Den pointer, der nok
(implicit) benyttes oftest af klienten, er cursor, som peger på den aktuelle hægte i listen. Det
betyder, at en hægtet liste altid har et objekt i fokus, som kan udtages eller undersøges. Der er tre
funktioner, der specielt arbejder med denne pointer, og som beskrives nedenfor. Den sidste
pointer er trail, som altid peger på den hægte, der kommer lige før cursor. Klienten ser
aldrig denne pointer, som kun anvendes, når han fjerner objekter fra listen. Det er nemlig
nødvendigt for GenericList at have information om både den forrige hægte i forhold til
cursor og den hægte, der kommer lige efter cursor, fordi disse to skal hægtes sammen, når
cursor-hægten fjernes. Adressen på den næste hægte findes inde i cursor-hægten
(cursor->next), men den forrige hægtes adresse står ikke her. Derfor følger trail i
cursors fodspor og giver os denne information. Alternativet ville være en dobbelthægtet liste,
som ville tillade os at gennemløbe listen begge veje og som ville unødvendiggøre trail, men
også optage en pointervariabel for hver hægte.
Her følger en gennemgang af de interessante medlemsfunktioner i GenericList:
void insertAt (Element*, GenericNode*);
indsætter et element i listen på en angivet position. Ved at kalde insertAt() med for
eksempel head som andenparameter kan objekter lægges ind på særlige steder. Her tages altså
ikke hensyn til cursor-positionen, som iøvrigt ikke berøres. Det skal bemærkes, at
insertAt() indsætter data i listen efter den hægte, der er angivet. Den eneste undtagelse er,
hvis vi vil indsætte et element før den første hægte, altså head. I det tilfælde skal
GenericNode-pointeren være 0. Så er alle muligheder dækket for indsættelse på alle
positioner i listen.
void Insert (Element*);
indsætter ganske simpelt et element på cursor-positionen i listen og lader cursor pege på
det ny element.
Element* Retrieve ();
fjerner et element fra listen og overgiver det til klienten. En GenericList vil automatisk
fjerne alle hægter og elementer på hægterne, når den går ud af skop. Elementer, der udtages fra
listen er det derfor klientens ansvar at delete. Hægten, dvs. forekomsten af GenericNode
fjernes af Retrieve() umiddelbart før elementet returneres, så det skal klienten ikke
bekymre sig om.
De næste tre medlemsfunktioner returnerer den første, den aktuelle og den næste (efter den
aktuelle) hægte på listen. Hvis der ikke er data på det sted, klienten ønsker at udtage information
fra, returneres en NULL-pointer.
Element* getFirst ();
Element* getCurrent() const;
7.5.2 Skabelonklassen GenericList 509

Element* getNext ();
Figur 7-2 viser, hvordan GenericList hægter elementerne sammen, hvordan de fire pointere
i ethvert GenericList-objekt opfører sig og hvordan indholdet af GenericNode ser ud,
når de er hægtet sammen.
510 Containerklasser 7.5

Figur 7-2: Den interne (fundamentale) repræsentation af hægtede lister i XCL.
Det er klart, at det ikke er tilladt blot at tildele værdier til GenericLists pointervariable, idet
de skal have en vis struktur. Medlemsfunktionerne i klassen sørger for konsistens mellem de fire
pointere, så der ikke går noget galt - de skal altid ligge i den rækkefølge, som figur 7-2 illustrerer,
dvs. logisk efter hinanden i kæden. Bemærk dog, at hvis cursor == head, så er trail
== NULL, fordi der ikke er en forrige hægte, hvis head == NULL, så er alle de andre også
NULL samt hvis der kun er én hægte i listen har både cursor og tail den samme værdi som
head og trail værdien NULL.
Der erklæres også to typenavne for at lette syntaken i erklæringer af GenericNode
parameteriseret med Object,
typedef GenericList ObjList;
typedef GenericList::GenericNode ObjNode;
7.5.3 Skabelonklassen GenericArray
ContainerBase
GenericArray
Denne klasse er analog til GenericList i den forstand, at den implementerer
minimumskravene for en container. Forskellen er, at denne klasse bygger på lineære lister i
stedet for hægtede. Den lineære repræsentation kræver, at størrelsen på listen er kendt på
instantieringstidspunktet og er derfor et parameter til konstruktøren. Klassens definition er som
følger:
template
class GenericArray : public virtual ContainerBase {
protected:
Element** rep;
GenericArray (const unsigned long);
~GenericArray ();
const Element* getCurrent () const;
const Element* getFirst ();
const Element* getNext ();
};
7.5.2 Skabelonklassen GenericList 511

Der er tale om en meget enkel repræsentation af en lineær liste, nemlig en vektor af pointere,
som allokeres i konstruktøren. De fra ContainerBase arvede data definerer den aktuelle
position samt den fysiske størrelse på containeren. De tre medlemsfunktioner getCurrent(),
getFirst() og getNext() har akkurat samme funktion som de, der findes i
GenericList, blot er der her ingen indre pointere.
Klassen bruges som baseklasse (sammen med Container) for alle XCL-klasser, som
bygger på lineære lister som den fundamentale datastruktur, for eksempel Array.
7.5.4 Klassen LinkedList
Object
Container
LinkedList
ContainerBase
GenericList
LinkedList
Den hægtede liste, som denne klasse repræsenterer, er sammen med Array den vigtigste
containerklasse i XCL, fordi alle andre containere bruger implementationen i den til
specialisering og rekomposition. LinkedList hægter Object-pointere på en liste, og
arbejder således på alle typer af XCL-objekter. Den benytter sig af GenericList-klassen til
at hægte objekterne sammen. Klassen implementerer de virtuelle funktioner i Container,
udbygger med to funktioner til hurtig søgning i listen samt implementerer en tildelingsoperator
og en additionsoperator.
LinkedList arver multipelt fra GenericList og Container. Det er i selve arven,
at klassen specificerer parameteret til skabelonklassen GenericList. På den måde får
LinkedList fordelen fra både en parameteriseret klasse, hvis funktioner den kan anvende i
den kontekst, som er krævet af Container, nemlig polymorfe Object-objekter. Det kan
virke overkompliceret, men letter faktisk arbejdet med klasser, at der findes en balance mellem
klasser, der er afhængige af et strengt, brugerdefineret typesystem og klasser, der er helt
uafhængige og har en høj grad af parametisérbarhed.
class LinkedList : public GenericList,
public Container {
public:
DECLARE_TRIVIAL_FUNCTIONS (LinkedList)
LinkedList () : GenericList (), Container () { }
LinkedList (const LinkedList&);
LinkedList& operator= (const LinkedList&);
virtual LinkedList operator+ (const LinkedList&);
virtual ~LinkedList () { };
virtual void printOn (ostream& = cout) const;
512 Containerklasser 7.5

virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
virtual void Insert (Object*);
virtual Object* Retrieve ();
virtual const Object* getCurrent () const;
virtual const Object* getFirst () const;
virtual const Object* getNext () const;
virtual void goTo (const unsigned long);
virtual const Object& operator[] (const unsigned long);
virtual const unsigned long Locate (const Object&) const;
virtual const Object* Locate (const unsigned long) const;
};
De fra Object arvede metoder implementeres på vektor-basis, dvs. de arbejder på alle
indeholdte objekter efter tur, mens de fra Container arvede metoder benytter sig af indeksparameteret
til at identificere positionen på en hægte i listen - om den er forrest, bagest eller et
sted i midten. Da LinkedList-indeholdte objekter refereres helt dynamisk er det nemlig altid
et spørgsmål om at traversere listen for at finde et bestemt objekt eller en bestemt indeksværdi.
Denne traversering findes i de funktioner, som er arvet fra GenericList.
De forskellige medlemsfunktioner fungerer som specificeret i baseklasserne, men da disse er
abstrakte, har vi ikke haft mulighed for egentlige eksempler med containerklasser. Derfor følger
nu nogle eksempler på anvendelser. LinkedList-objekter kan tildeles hinanden samt
adderes:
#include "linklist.h"
#include "dstring.h"
void main () {
LinkedList komponister, forfattere, kunstnere;
komponister.Insert (*new String ("Franz Liszt"));
komponister.Insert (*new String ("Felix Mendelssohn"));
komponister.Insert (*new String ("Edward Elgar"));
forfattere.Insert (*new String ("Oscar Wilde"));
forfattere.Insert (*new String ("Robert Burns"));
forfattere.Insert (*new String ("William Shakespeare"));
kunstnere = komponister + forfattere;
cout

if (forfattere == komponister) cerr

associerer to objekter på en nøgle/værdi-basis, dvs. et objekt bruges som opslag og et andet som
værdi. Med andre ord, et Object kan associeres til et andet Object, og begge to kan være
en forekomst af enhver XCL-klasse, selv en containerklasse.
På den måde har Association samme betydning for Dictionary, som
GenericNode har for GenericList, blot genbruger både Association og
Dictionary en stor del af funktionaliteten i de to andre klasser. Associations erklæring
ser således ud:
class Association : public Object {
friend Dictionary;
protected:
Object* Key;
Object* Value;
Association () : Key (0), Value (0) { }
Association (Object& a, Object& b) :
Key (&a), Value (&b) { }
Association (const Association&);
public:
DECLARE_TRIVIAL_FUNCTIONS (Association)
virtual ~Association () { delete Key; delete Value; }
Object* getKey () const { return Key; }
Object* getValue () const { return Value; }
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
};
Associationen er beskrevet på en dynamisk basis, idet pointerne til de to associerede objekter
ikke ligger i objekterne selv, men i denne tredie klasse. De to ny medlemsfunktioner
getKey() og getValue() leverer henholdsvis opslagsobjektet og værdiobjektet til
klienten.
Kun Dictionary kan allokere og destruere Associationer.
7.5.6 Klassen Dictionary
Object
Container
LinkedList
Dictionary
ContainerBase
7.5.5 Klassen Association 515

GenericList
LinkedList
Dictionary
Hvor LinkedList er en lineær indeksérbar liste udbygger Dictionary den med mulighed
for opslag på indholdet af hægterne. Dictionary repræsenterer således en associativ liste,
fordi klienten kan slå en værdi op på en anden værdi i stedet for blot en indeksværdi.
Dictionary holder rede på objekternes placering, indhold og søgenøgler gennem forekomster
af Association.
Dictionary er afledt fra LinkedList og udbygger blot med to medlemsfunktioner til
indsættelse og udtagning af en association. Den erklæres således:
class Dictionary : public LinkedList {
public:
DECLARE_TRIVIAL_FUNCTIONS (Dictionary)
Dictionary () : LinkedList () { }
Dictionary (const Dictionary& from) : LinkedList (from) {}
virtual void addAssociation (Object&, Object&);
virtual Object* getAssociation (Object&);
};
Typiske anvendelser for et Dictionary er i situationer, hvor data skal lagres, søges efter og
behandles efter deres værdier. Et trivielt eksempel er en symboltabel, der associerer en værdi
med et navn. For eksempel,
Output:
void main () {
Dictionary SymbolTable;
SymbolTable.addAssociation (
*new String ("en"), *new Complex (1));
SymbolTable.addAssociation (
*new String ("to"), *new Complex (2));
SymbolTable.addAssociation (
*new String ("tre"), *new Complex (3));
String id = "to";
cout

i en container og associeres kollektivt) har en vilkårlig betydning afhængigt af indholdet, som er
bestemt på kørselstidspunktet. Objekter af typen Dictionary kan naturligvis ind- og udlæses
på samme vis som LinkedList-objekter, og er i samme forstand begrænset bestandige.
Objekter af forskellige typer kan indsættes vilkårligt i et Dictionary, hvilket betyder, at
der kan forekomme både nøgler og værdier af alle slags XCL-klasser i samme Dictionary.
Der er altså ikke tale om en nøgleværdi af statisk type, men en total frihed for klienten til at
associere data i samme kontekst.
Med Dictionary kan det også illustreres, hvordan der kan arbejdes indirekte på data i en
container. I følgende kodefragment indsættes en LinkedList i et Dictionary, hvorefter
der fyldes data i listen. Selv om listen "ejes" af Dictionary-objektet, er det altså muligt at
manipulere med det direkte og uden problemer:
Dictionary dict;
dict.Insert (
new String("A"),
LinkedList* list = new LinkedList
);
list->Insert (new String ("B"));
list->Insert (new String ("C"));
cout

objekter på en kø. Klassen Queue vil udtage objekter (med Retrieve()) i samme
rækkefølge som den indsætter dem (med Insert()), og repræsenterer således en form for
FIFO-buffer, der er brugbar i processtyring, avancerede traverseringer af træstrukturer og grafer
og som generelt værktøj til at gemme data af vejen.
Queue kan genbruge næsten hele LinkedList, og udbygger kun med to funktioner for
indsættelse og udtagning af data explicit fra henholdsvis slutningen og starten af listen. Grunden
til disse to funktioners eksistens er, at en nedarvet klasse DeQueue indeholder de omvendte
funktioner og således bliver komplet ved arv af disse to. Det tillader nemlig en DeQueue at
bruges som en Queue i dennes sammenhæng. Queue har følgende erklæring:
class Queue : public LinkedList {
public:
DECLARE_TRIVIAL_FUNCTIONS (Queue)
Queue () : LinkedList () { };
Queue (Queue& q) : LinkedList (q) { };
virtual void insertBack (Object& o) { Insert (o); }
virtual Object* retrieveFront () { return Retrieve (); }
};
og har faktisk ingen ikke-inline medlemsfunktioner ud over de trivielle par stykker, der genereres
af makroerne.
Her et eksempel på brugen af Queue:
#include "queue.h"
#include "dstring.h"
void testContainer (Container& c) {
String LVB [3] = { "Eroica", "Waldstein", "Emperor" };
LVB.Insert (&s [0]);
LVB.Insert (&s [1]);
LVB.Insert (&s [2]);
while (LVB.Size ()) cout

Waldstein
Emperor
7.5.8 Klassen DeQueue
Object
Container
LinkedList
Queue
DeQueue
ContainerBae
GenericList
LinkedList
Queue
DeQueue
Denne klasse har akkurat samme funktion som Queue, blot er det muligt både at udtage og
indsætte objekter i begge ender af køen (dequeue betyder double-ended queue, altså med hul i
begge ender). Der arves fra Queue og udbygges med to metoder for henholdsvis indsættelse af
data først i køen og udtagning af data sidst i køen, altså det omvendte af de udbyggede metoder i
Queue:
class DeQueue : public Queue {
public:
DECLARE_TRIVIAL_FUNCTIONS (DeQueue)
DeQueue () : Queue () { };
DeQueue (DeQueue& q) : Queue (q) { };
virtual void insertFront (Object& o) {
Insert (o, head);
}
virtual Object* retrieveBack () {
cursor = tail; return Retrieve ();
}
};
Et eksempel på anvendelsen af denne klasse er i visse sorteringsalgoritmer og søgninger med
prioritet. Ligeledes kan en DeQueue være brugbar, når rekursivitet skal omdannes til
iterationer. Lad følgende eksempel være en illustration af klassen:
#include "dequeue.h"
#include "dstring.h"
7.5.7 Klassen Queue 519

void main () {
char buf [100];
int i = 0;
DeQueue dq;
while (cin >> buf) sq.Insert (new String (buf));
while (sq.Size ()) {
Object* o = (sq.Size () & 1) ?
dq.retrieveFront () : dq.retrieveBack ();
cout

Stack (Stack& s) : LinkedList (s) { };
void Push (Object& o) { insertAt (o, NULL); }
Object* Pop () { cursor = head; return Retrieve (); }
virtual void Insert (Object&, int = LAST_ITEM);
};
Med henvisning til funktionen testContainer() i afsnit 7.5.7 kan vi kalde denne funktion
med en Stack og lade den udskrive indholdet:
Output:
#include "stack.h"
#include "dstring.h"
void main () {
Stack st;
testContainer (st);
}
Emperor
Waldstein
Erioca
7.5.10 Klassen Array
Object
Container
Array
ContainerBase
GenericArray
Array
Hvor LinkedList er en dynamisk container er Array en statisk container. Objekter af
typen Array skal erklæres med en størrelsesangivelse, og vil indeholde en lineær liste af
Object-pointere. Bortset derfra er grænsefladen magen til LinkList på nær en ekstra
indekseringsoperator. Array er afledt multipelt fra Container og fra GenericArray og
samler ligesom LinkedList parametrisk polymorfi og horisontal, brugerdefineret polymorfi
gennem disse to klasser.
Array er hurtigere end LinkedList, fordi den ikke skal spilde tid med at finde data ved
gennemløb af lister. Til gengæld er den mere pladskrævende, fordi den typisk vil være en del
større end den har brug for at være. Den er henvendt til opgaver med lister af data, hvis antal er
kendt fra starten. Indeksopslag er typisk log 2 hurtigere end tilsvarende i LinkedList.
7.5.9 Klassen Stack 521

Klassen har følgende specifikation:
class Array : public Container,
public GenericArray {
public:
DECLARE_TRIVIAL_FUNCTIONS (Array)
Array (const unsigned long = DEFAULT_CAP);
Array (const Array&);
virtual ~Array ();
virtual void Insert (Object*);
virtual Object* Retrieve ();
virtual const Object* getCurrent () const;
virtual const Object* getFirst () const;
virtual const Object* getNext () const;
virtual const Object& operator[] (const unsigned long);
virtual Array operator+ (const Array&);
virtual Object*& operator[] (const unsigned long);
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
};
Den interessante nye funktion, som ikke findes i andre containerklasser i XCL, er
operator[] som ikke-konstant funktion. Den returnerer en reference til en pointer, og kan
dermed bruges på venstre side af lighedstegnet, eller som en lvalue:
Array a (3); // 3 elementer
a [0] = new String ("streng-objekt");
a [2] = new String ("streng-objekt");
cout

indeksering, der returnerer en nil-pointer, er derfor en tom eller ulovlig (eller hvordan man har
lyst til at fortlkee det) reference.
7.5.11 Samarbejde mellem containerklasser
De fleste containerklasser i XCL kan arbejde sammen, så deres elementer kan kopieres mellem
forskellige typer af containere. For eksempel kan en LinkedList og en Array adderes:
#include "linklist.h"
#include "array.h"
#include "string.h"
void main () {
Array a (2);
LinkedList l;
l.Insert (new String ("A"));
l.Insert (new String ("B"));
a.Insert (new String ("C"));
a.Insert (new String ("D"));
l += a;
cout

dette på er at gennemgå et eksempel. Antag, at et operativsystem skal administrere forskellige
køer til printere. Der er en kø for hver printer, og køerne selv hægtes sammen i en liste. Vi får
demed en grafstruktur, som minder om figur 7-2.
Figur 7-3: Struktur over liste af printerkøer.
Hver kø er en forekomst af klassen Queue, og alle køerne hægtes på et Dictionary, så de
kan refereres associativt i listen af et printerovervågningsprogram (skal vi sige en proces i
operativsystemet) med henvisning til printerens navn. Instantieringen af denne stuktur er simpel:
Dictionary pQueues;
pQueues.addAssociation (*new String ("LaserJet"), *new
Queue);
pQueues.addAssociation (*new String ("EpsonFX"), *new Queue);
// osv...
Vi kan indsætte data i køerne på en generel måde med en funktion,
void putDataForPrint (String pName, Object& Data) {
Queue* q = (Queue*) pQueues.getAssociation (pName);
q->Insert (Data);
}
524 Objekt-I/O 7.6

Når en printer bliver fri, kan en anden simpel funktion ligeledes finde de data, der skal udskrives
næste gang:
Object* getDataForPrint (String pName) {
Queue* q = (Queue*) pQueues.getAssociation (pName);
return q->Retrieve ();
}
Nu antager vi, at systemet pludselig skal lukkes ned, men at printerkøerne skal gemmes til
systemet startes igen - vi vil jo ikke miste udskrifterne. Det foregår med det enkle kollektive kald
til printerkøernes udlæsningsmetoder:
pQueues.dumpOn (outputStream);
hvor outputStream er en normal ostream-forekomst. Hvad sker nu? Medlemsfunktionen
Dictionary::dumpOn() har følgende implementation, som den arver fra LinkedList:
void LinkedList::dumpOn (ostream& strm) const {
Container::dumpOn (strm);
for (ObjNode* p = head; p; p = p->Next ())
p->objptr->dumpOn (strm);
}
Først kaldes altså baseklassens udlæsningsmetode Container::dumpOn(), som ser således
ud:
void Container::dumpOn (ostream& strm) const {
Object::dumpOn (strm);
strm

strømmen. Disse køer udlæses én for én i løkken, som kalder de enkelte køers udlæsningsmetoder.
Queue arver samme dumpOn() fra LinkedList som Dictionary gør, og
udlæser således ved primære kald til baseklassernes udlæsningsmetoder navnet på sig selv
(Queue) samt antallet af elementer (data til print) i dem. For hver Queue, der udlæses,
gennemløbes derfor også alle dens indeholdte objekter ét for ét og udlæses gennem deres
respektive dumpOn().
Lad os for enkelthedens skyld lagre teksten til udskrift som String-objekter i køerne. De to
køer som erklæredes før fyldes nu op med tekst til print med følgende funktionskald:
putDataForPrint ("LaserJet", *new String ("Første
tekst..."));
putDataForPrint ("EpsonFX", *new String ("Anden tekst..."));
putDataForPrint ("LaserJet", *new String ("Tredie
tekst..."));
putDataForPrint ("EpsonFX", *new String ("Fjerde tekst..."));
Nu indeholder printerkølisten to køer med hver to ventende objekter. Når de udlæses kaldes de
forskellige klassers dumpOn()-metoder i den rækkefølge, de forekommer i figur 7-3. I venstre
spalte vises navnene på de klasser, hvis dumpOn() kaldes. Læg mærke til, at det ikke
nødvendigvis er den ovenstående klasse, der kalder metoden; den kaldende klasse står i højre
spalte. I midten ses det output, den pågældende metode producerer. Det skal dog ikke tages som
den rækkefølge, de udlæses i, for dumpOn()-metoderne kalder først sin klasses base og
udlæser derefter egne data, så baseklassens output kommer altid før den afledte klasses.
Det simple kald til Dictionary-klassens dumpOn()-metode vil således resultere i 36
kald mellem de forskellige klasser i det komplekse pQueues-objekt, hvoraf de 14 er
klientorienterede (et objekt kalder et andet objekt) og de 22 er kald i egen klasse (objektet kalder
en metode i baseklassen). Det største administrative forbrug ligger altså i udlæsningen af
nedarvede objekter, især i flere led, fordi alle baseobjekterne skal udlæses ét for ét mens
klientorienterede kald kommer an på, hvordan objektet er repræsenteret.
Det reelle output fra kaldet til Dictionary::dumpOn() bliver:
Dictionary 2
Association
String 8 LaserJet
Queue 2
String 15 Første tekst...
String 15 Tredie tekst...
Association
String 7 EpsonFX
Queue 2
String 14 Anden tekst...
String 15 Fjerde tekst...
526 Objekt-I/O 7.6

dumpOn() i klasse Udlæser (preorder) Kaldes af
Dictionary
Container
Object
Association
Object
String
Sortable
Object
Queue
Container
Object
String
Sortable
Object
String
Sortable
Object
Queue
Container
Object
String
Sortable
Object
String
Sortable
Object
2
Dictionary
Association
8 LaserJet
String
2
Queue
15 Første tekst...
String
15 Tredie tekst...
String
2
Queue
14 Anden tekst...
String
15 Fjerde tekst...
String
Klient
Dictionary
Container
Dictionary
Association
Association
String
Sortable
Association
Queue
Container
Queue
String
Sortable
Queue
String
Sortable
Association
Queue
Container
Queue
String
Sortable
Queue
String
Sortable
Tabel 7-1: Propagation gennem dumpOn()-metoder i komplekst objekt.
Grunden til, at dumpOn() først kalder baseklassernes tilsvarende metoder før den udlæser
egne medlemsdata bliver klar, når vi overvejer indlæsningsproceduren. Skal samme struktur
læses af XCL igen, så den eksakte struktur bliver genskabt, er det nødvendigt med baseklassernes
mere generelle information først og de afledte klassers mere specifikke information
senere. Det nytter for eksempel ikke noget at udlæse en streng med indholdet først, dernæst
længden og til sidst typen. Hvordan skal indlæsningskoden hitte ud af, at der er tale om en
streng? Rækkefølgen må og skal være nedefter i klassehierarkiet - og faktisk minder det en hel
del om normal konstruktion af afledte objekter, hvor base-klassens konstruktør altid kaldes før
den afledte konstruktør eksekveres. Det afledte objekt afhænger af baseobjektets indhold, og kan
derfor aldrig konstrueres eller initieres først.
Indlæsning af objekter foregår på en fuldstændig spejlet måde i forhold til udlæsningen. Når et
objekt skal indlæses, bruges den særlige klasse ObjectManager til automatisk identifikation
af objekternes typer. Idet klienten ikke nødvendigvis selv kender til disse typer, generaliserer
7.6 Objekt-I/O 527

XCL, så der altid skal indlæses polymorfe objekter. Med andre ord, der indlæses altid et objekt,
der tildeles en Object-reference. ObjectManagers indlæsningsmetode hedder
readPolymorphicObject, og har følgende enkle funktion:
1. Først indlæses typenavnet, som er det første element på strømmen. ObjectManager
har en liste over alle kendte indlæsbare klasser med associerede pointere til eksplicitte
allokeringsfunktioner. På den måde kan den allokere en forekomst af objektet. Den
eneste ydre forudsætning for dette er, at alle klasser, der skal være en del af det
indlæsbare system skal annoncere sig selv til ObjectManager, hvilket automatisk
gøres med makroen i headeren som hedder
DECLARE_AS_STOREABLE.
2. Når ObjectManager har allokeret en forekomst af objektet kaldes den virtuelle
funktion readFrom() for dette objekt, og herfra indlæses det egentlige indhold.
Denne funktion følger samme regler for udformning som dumpOn(), idet baseklassens
readFrom() skal kaldes som det første. Ellers vil data på strømmen ikke blive indlæst
i samme rækkefølge (i et komplekst objekt) som det var udlæst i. Afhængigt af, om
objektet, der indlæses, er en forekomst af en mere eller mindre sammensat klasse
allokeres og indlæses andre objekter med gentagne kald til
ObjectManager::readPolymorphicObject(). Det er af den grund, at en
containerklasse med et indhold af forskellige typer kan indlæses.
At indlæse det aggregate objekt pQueues er altså et spørgsmål om et enkelt funktionskald til
den statiske metode i ObjectManager,
Dictionary& pQueue =
(Dictionary&) *ObjectManager::readPolymorphicObject ();
hvorefter objektet har præcis det samme indhold som det, der tidligere blev udlæst, inklusive alle
indeholdte objekter og baseobjekter. Den løkke, som indlæser objekterne i containerklassens
readFrom()-metode har følgende udformning:
void LinkedList::readFrom (ostream& strm) {
Container::readFrom (strm);
int i = count; // antal objekter, der skal indlæses
for (count = 0; i; i--)
Insert (*ObjectManager::readPolymorphicObject (strm));
}
Containerklasserne kalder altså selv den statiske indlæsningsmetode, hvilket gør det muligt at
indlæse objekter af enhver XCL-klasse i en container, selv andre containere. Og det er netop det,
der sker, når pQueues skal genskabes; objektet er en liste af køer.
Objekt-I/O i XCL er således meget robust og anvendelig. Det er især interessant, at de små ind-
og udlæsningsmetode er få og små samt har en høj grad af genbrugelighed i hierarkiet.
528 Objekt-I/O 7.6

Komplekse objekter, for eksempel store grafer eller tilstødende lister kan udlæses uden at skrive
en eneste ny specialiseret funktion til formålet.
7.7 UDVIDELSER OG TILPASNINGER
Klassebiblioteket XCL er et fundament for programudvikling. Af den grund er det naturligt at
udvide med nye klasser for en given applikation, særligt i erkendelse af, at det næsten
udelukkende består af containerklasser og værktøjsklasser. Der er kun to egentlige aktive klasser,
og deres anvendelse er tillige meget begrænset.
Men der er visse regler, der skal følges, når hierarkiet udvides med nye klasser. De i afsnit 5.1
beskrevne fremgangsmåder for introduktion af nye klasser i et klassebibliotek gælder fuldt ud for
XCL, så det første spørgsmål er, om der findes en klasse der har en funktion som ligner den
aktuelle klasse. Her er det vigtigst at se på de abstrakte klasser Object, Container og
Sortable. Den ny klasse vil i mange tilfælde også kunne drage fordel af at være klient af en
eksisterende XCL-klasse, for eksempel en container eller en hægte.
Ud over disse forhold mellem en ny klasse og en eksisterende klasse skal en XCL-klasse
indeholde et antal medlemsfunktioner, der tillader den at indgå i systemet på lige fod med alle
andre klasser. Alle disse funktioner er virtuelle og opdeles i to grupper,
1. de klassespecifikke metoder, som skal implementeres for enhver XCL-klasse, og
2. de artsspecifikke metoder, som kan arves fra en baseklasse.
De klassespecifikke metoder er:
virtual Class Type () const;
virtual Object& Copy () const;
virtual const char* Name () const;
Da de alle tre er meget trivielle implementeres de ved hjælp af de to makroer
DECLARE_TRIVIAL_FUNCTIONS og DEFINE_TRIVIAL_FUNCTIONS, som henholdsvis
erklærer funktionerne i klassens specifikation (den skal altså stå i klassedefinitionen i
headerfilen) og implementerer dem. Begge makroer kaldes med klassens navn.
Den anden gruppe, de artsspecifikke metoder, varierer lidt fra baseklasse til baseklasse
afhængigt af, om den ny klasse er en Container eller en Sortable eller noget helt tredie.
De rene virtuelle metoder i de abstrakte klasser kan findes i kildeteksten i appendiks F, så her
gengives blot de vigtigste metoder fra Object-klassen. Disse er alle rene virtuelle metoder i
Object, og skal implementeres for en nedarvet klasse. Dog kan de arves fra en mellemliggende
klasse, der implementerer dem, hvis der ikke skal foretages ændringer eller udvidelser.
Metoderne er:
virtual void printOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
7.6 Objekt-I/O 529

virtual void dumpOn (ostream& = cout) const;
virtual bool isEqual (const Object&) const;
samt den virtuelle destruktør. Derudover skal klassen have en kopi-konstruktør, så den tvungne
klassespecifikke Copy()-metode kan skabe en identisk kopi. Hvis klassen skal kunne ind- og
udlæses via ObjectManager skal der tillige være en tom konstruktør.
Hvis den ny klasse er abstrakt, kan de virtuelle metoder erklæres rene (sættes lig nul, se afsnit
4.4) medmindre de allerede er implementeret i en baseklasse. Det tilfælde vil dog være atypisk.
Ud over disse funktioner kan den ny klasse indeholde et vilkårligt antal nye metoder, både
virtuelle og ikke-virtuelle. Der er også total frihed i overstyring af operatorer, medlemsfunktioner
og konstruktører. Tildelingsoperatoren, der som bekendt ikke arves, bør normalt også
implementeres.
Her er et skelet for en XCL-klasse (udskift KLASSE med klassens navn og BASEKLASSE
med baseklassens):
class KLASSE : public BASEKLASSE {
// datamedlemmer her
protected:
// eventuelle medlemsfunktioner og datamedlemmer her
public:
DECLARE_TRIVIAL_FUNCTIONS (KLASSE);
KLASSE (/* ... */);
KLASSE (const KLASSE&);
virtual ~KLASSE ();
virtual void printOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual void dumpOn (ostream& = cout) const;
virtual bool isEqual (const Object&) const;
};
Lad os tage et eksempel. Vi er interesserede i at benytte hierarkiet til konstruktion af et system,
der holder rede på udlån af bøger i et bibliotek. Vi har brug for en klasse til at registrere lånernes
navne, adresser og CPR-numre. Denne klasse arver vi fra Sortable, så det bliver muligt at
indsætte objekter af klassen i sorterede lister, og samtidig gør vi den klient til klassen String,
fordi de indeholdte data kan udtrykkes som sådanne. De forskellige metoder i ovenstående
skeletklasse erstattes med det reelle indhold, der beskriver et Person-objekt. Her er
specifikationen på klassen (headerfilen):
// person.h
#include "object.h"
#include "dstring.h"
class Person : public Sortable {
530 Udvidelser og tilpasninger 7.7

String Fornavn, Efternavn, Adresse;
String CPR_nummer;
public:
DECLARE_TRIVIAL_FUNCTIONS (Person)
Person ();
Person (const Person&);
Person (const char*,const char*,const char*,const char*);
virtual ~Person ();
virtual void printOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual void dumpOn (ostream& = cout) const;
virtual bool isEqual (const Object&) const;
virtual bool isGreater (const Sortable&) const;
};
Du undrer dig måske over, hvorfor funktionerne printOn(), readFrom(), dumpOn()
og isEqual() ikke kan erklæres samtidig med Copy(), Type() og Name(). Svaret er,
at disse funktioner ikke absolut skal erklæres i en klasse - de kan være nedarvet fra en baseklasse.
En makro vil ikke kunne se dette, og derfår må de slavisk kopieres ind i klasseerklæringen. En
anden vigtig makro i implementationen er den, der erklærer den aktuelle klasse som ind- og
udlæsbart. Denne makro, DECLARE_AS_STOREABLE, skal blot skrives et sted i filen, udenfor
funktioner og strukturerklæringer. En forklaring af makroens funktion følger nedenfor.
Her er en simpel implementation af klassen:
// person.cpp
#include "person.h"
DECLARE_AS_STORABLE (Person)
DEFINE_TRIVIAL_FUNCTIONS (Person)
// konstruér en "tom" personpost
Person () : Fornavn (), Efternavn (),
Adresse (), CPR_nummer () { }
// kopiér en eksisterende Person ind i dette objekt
Person (const Person& other) : Fornavn (other.Fornavn),
Efternavn (other.Efternavn), Adresse (other.Adresse),
CPR_nummer (other.CPR_nummer) { }
// konstruér fra tre strenge / String-objekter
Person (const char* f, const char* e, const char* a,
const char* c) : Fornavn (f), Efternavn (e), Adresse (a),
CPR_nummer (c) { }
7.7 Udvidelser og tilpasninger 531

destruér en Person - tom destruktør!
virtual ~Person () { }
// udskriv en Person, pænt formateret
virtual void printOn (ostream& strm) const {
strm

Mere skal der ikke til; nu er Person et gyldigt medlem af XCL-hierarkiet, og kan benyttes af
de globale funktioner, der kalder de virtuelle funktioner i objekterne. For eksempel,
#include "person.h"
void main () {
// test printOn ()-funktionen...
Person enMand ("J.","Hansen","Dalstrøget 7","111111-
1111");
Person enDame ("E.","Gallumbits","Eroticon 5", "?");
cout

hvor CLASS er klassens navn. Hvis klassenavnet starter med en vokal, skriver du ikke "an" i
stedet for "a". Denne konstant benyttes af den trivielle implementation af Type(), som
returnerer denne værdi. Det gør det muligt at type-checke før sammenligning af objekter fra den
globale funktion bool operator== (const Object&, const Object&).
Makroen DECLARE_AS_STOREABLE, som er defineret i annoncerer
automatisk klassen til ObjectManager. Den består af en statisk funktiosdefinition, som blot
allokerer en forekomst af den aktuelle klasse og returnerer en Object-pointer til denne samt en
statisk erklæring af en konstant, som tildeles returværdien af et kald til ObjectManager. På
den måde kaldes ObjectManager før main() begynder, og det er dermed sikret, at alle
klasser er kendt i ObjectManager når de skal indlæses og udlæses.
De to funktioner er meget enkle og har dette skelet:
static Object* createCLASS () {
return new CLASS;
}
static bool initCLASS = ObjectManager::Announce (
"CLASS", createCLASS
);
Den statiske funktion ObjectManager::Announce() modtager henholdsvis en
karakterstreng, som er navnet på klassen samt en pointer til den funktion, der allokerer en
forekomst af denne klasse. Det er alt, hvad systemet behøver af viden om den ny klasse for at
indlemme den i det dynamiske typesystem under objekt-I/O.
7.8 OPGAVER TIL KAPITEL 7
1. Skriv en containerklasse Tree, som repræsenterer et generelt n-vejs træ. Klassen skal
kunne indeholde ethvert ikke-abstrakt objekt i XCL (godt råd: nedarv fra en af de
eksisterende containere).
2. Skriv en klasse BinaryTree, som repræsenterer et binært træ og indeholder
funktionalitet til traversering af træet. Retfærdiggør dit valg af grænseflade til klassen.
3. Nedarv en ny klasse fra Tree i forrige opgave, og implementér særlige metoder til
bearbejdning af det binære træ på særlige måder. Ideer: AVL-sortering, Huffmanorganisering.
Skal hægterne laves om?
4. Implementér en virtual funktion Hash() i alle XCL-klasserne, som returnerer en hashværdi
for det aktuelle objekt. Fjern klassen Sortable og alle isGreater()metoderne.
Omskriv den globale operator==(), så den kalder Hash() i stedet for
isGreater(). Skal klassen SortedList modificeres for at kunne benytte den nye
534 Udvidelser og tilpasninger 7.7

form for sammenligning af objekter?
5. Implementér en mængdeklasse Set, som har den virkemåde, at den kun kan indeholde
ét objekt med samme værdi på samme tid. Skriv medlemsfunktioner til at uddrage
fællesmængder, foreningsmængder og til at sammenligne mængder. Benyt for eksempel
en LinkedList som baseklasse, men husk, at rækkefølgen af elementerne i en
mængden er ligegyldig - to mængder er ens, hvis de indeholder de samme elementer
uanset rækkefølgen. Redegør for implementationen og beskriv overvejelserne for
effektivitet.
7.9 REFERENCER OG UDVALGT LITTERATUR
Eksempler på design af klassebiblioteker er [Gorlen 87] og [Gorlen 90], som indeholder
beskrivelser af NIH Class Library, der er blevet en standard mange steder. Der henvises i øvrigt
til dokumentationen af særlige klassebiblioteker som Zortech C++ Tools, M++ Math Class
Library, Screens++ User Interface Library, Classix, ObjectStore samt Borland International Data
Structures (BIDS), som er et parameteriseret klassebibliotek, der følger med Borland's
oversættersystemer til MS-DOS og OS/2.
7.7 Udvidelser og tilpasninger 535

Fremtidsudsigter
Denne bog beskriver C++ version 3.0, som den foreligger fra producenten
AT&T. Indtil for nylig var det svært at finde oversættersystemer, der holdt sig til
den. Sproget har udviklet sig fantastisk meget gennem de sidse fem år; det er
meget sjældent at et nyt sprog, særligt på dette tidspunkt i udviklingen, får så
umiddelbar en succes. Det har skyldes, at designerne at C++ har sørget for at
udgive referencemanualer på et tidligt tidspunkt samt at de har inddraget
udviklere verden over i overvejelserne om sprogets muligheder. Af samme grund
har der været stor debat om sprogets faciliteter og eventuelle udvidelser. AT&T
lancerede i 1992 version 3.0 af sproget, og det ser ud som om, at denne standard
bliver mere eller mindre direkte accepteret af ANSI som en reel standardisering.
Arbejdsgrupperne ANSI X3J11 og X3J16 forventer at være færdige med en
færdig standard medio 1993. I dette appendiks findes en oversigt over de
væsentligste foreslåede udviklinger i deres udkast.
A.1 ANSI C++
A
ANSI, det amerikanske standardiseringsinstitut, arbejder med at skabe en fællesnævner for de
forskellige krav, der findes til en eksisterende de facto standard. Der arbejdes med meget andet
end computersprog og computerkoder, og samarbejdes i vid udstrækning med den internationale
standardiseringsorganisation, ISO.
ANSI er i en særlig kommite for standardisering af C++ i færd med at lægge sidste hånd på et
dokument om sprogets udformning. Denne udformning er ikke nødvendigvis den samme som de
eksisterende versioner af C++ fra AT&T eller andre, men forskellene vil være minimale. Et
arbejdsdokument findes i [Ellis 90].
A.2 Fejlbehandling
Behandlingen af fejl, der opstår uventet på kørselstidspunktet, er blandt de største problemer i
softwareudviklingen. Netop fordi der skal tages hensyn til fejl, der kun måske opstår, bliver
programmerne ofte til store betingede strukturer, der ikke bidrager til den egentlig opgave, der
536 Opgaver til kapitel 7 7.8

skal løses. I mange tilfælde er et ordentligt design den primære vej til eliminering af run-time
fejl, men for de applikationer, der bygger kontrolsekvensen på I/O kan det være et mareridt.
Sprogunderstøttet fejlbehandling er en elegant måde at komme dette til livs på. Den foreslåede
struktur af en indbygget fejlbehandling (Exception Handling) i C++ består af en enkel metode til
overførsel af kontrollen fra en del af programmet til en anden via særlige sprogkonstruktioner,
der kaldes undtagelser. En undtagelse er en opstået situation, der bryder med programmets
egentlige sekvens. Normalt gør vi dette med gentagne betingelser, der hverken gavner
effektiviteten eller læsbarheden, men med undtagelser som et generelt begreb kan vi arbejde med
fejl helt parallelt til det egentlige program. Vi kan implementere fejlbehandling på et
hvilketsomhelst tidspunkt, fordi det egentlig ikke interfererer med den øvrige software.
Fejlbehandling i C++ 2.1 består af særlige nøgleord til at sætte programmet i
"undtagelsestilstand" og til at fange disse undtagelser på de rette steder i programmet. Det
foregår på en kaldt/kalder-basis, hvor den kaldte funktion returnerer til kalderen med en eventuel
undtagelse i baghånden. Kalderen kan så behandle undtagelsen og eventuelt igen sende den
tilbage til sin egen kalder. I sammenhæng med nedarvede klasser, der kalder hinanden opefter
eller nedefter i hierarkiet, betyder dette, at en fejl i en fjern klasse kan "boble op" til den øverste
klasse mens der ryddes pænt op i alle subobjekterne i det komplekse objekt ét efter ét.
Til formålet introduceres tre nye nøgleord, try, throw og catch. En kalder omkranser de
kald, der eventuelt kan fejle, i en try-blok ("forsøg disse kald"). Den kaldte funktion kan
derefter "kaste" undtagelser tilbage til kalderen med en throw-sætning, og kalderen kan
"fange" disse med en eller flere catch-sætninger. Grunden til, at denne udformning er valgt er,
at hvis den kaldte funktion ikke kaster en untagelse, så vil det ikke være en tidsstraf i
programeksekveringen. Dette har været et primært mål i designet af C++ i alle leder og kanter,
og fejlbehandling er ingen afvigelse. Hvis den kaldte funktion returnerer normalt, vil catchblokken
blive sprunget over.
Det er en meget simpel form for fejlbehandling. Det eneste, der sker er, at en fejl med
sikkerhed vil blive fundet og kan behandles. Der er ingen avancerede faciliteter for automatisk at
prøve at "redde" en undtaglese ved at starte på det sted, hvor den blev kastet fra. En throwsætning
afslutter altid funktionen og den eneste mulighed er at foretage et nyt kald. Til gengæld
kan en throw-sætning overføre vilkårlige informationer til kalderen, som med disse kan
afgøre, hvad der skal foretages for at redde så meget som muligt - eller eventuelt afslutte
programmet pænt og ordentligt.
Et eksempel på et kast af en undtagelse er:
throw "division med nul";
Denne sætning vil afslutte funktionen ummidelbart og forsøge at finde en catch-sætning i den
kaldende funktion, der har et argument af samme type som throw-sætningen. Her er det en
char*, så
catch (char* s) {
cout

fanger og udskriver en undtagelse med en pointer til en char og udskriver den som
fejlmeddelelse. Blokken i catch-sætningen skal følge en try-blok. I kalderens funktion
bliver udformningen af en undtagelsesstruktur derfor noget i retning af:
try {
// funktioner, der kan kaste en undtagelse
}
catch (/* undtagelsestype */) { /* behandl */ }
catch (/* undtagelsestype */) { /* behandl */ }
// osv...
Alle funktionskald i en try-sætning vil være genstand for et undtagelsescheck. Hvis en
funktion kaster en undtagelse, vil try-blokken terminere (resten af funktionerne vil ikke blive
kaldt), og en catch-blok, der passer til typen af undtagelse vil forsøges fundet og udført.
Typesystemet i C++ er altså en integreret del af fejlbehandlingsstrukturen, og både fundamentale
og brugerdefinerede typer kan kastes.
Faktisk kan en throw-sætning ses som et slags funktionskald, og en catch-sætning som en
funktionserklæring. De har blot en anden opførsel. Typisk vil en catch kun behandle en del af
undtagelsen og så kaste den videre:
catch (int errnum) {
// deallokér dynamiske data i denne funktion etc.
throw errnum;
}
Dermed kan alle funktioner rydde så meget op, som de kan (skal), og lade kalderen klare resten
af problemet. Dermed undgås den besværlige administration af programmets status, især over
dynamisk allokerede data, som ryddes op i særlige funktioner.
Med brugerdefinerede typer kan fejlsystemet specialiseres. For eksempel,
// fejltyper i systemet
struct device_error { /* ... */ };
struct math_error { /* ... */ };
struct memory_error { /* ... */ };
Disse fejl kan kastes på følgende måde:
void g () {
// ...
if (timeout) throw device_error;
// ...
double* a = new double [400];
if (a == NULL) throw memory_error;
// ...
538 Fremtidsudsigter A.0

}
og ligeledes fanges med
void f () {
try {
// ...
g ();
// ...
}
catch (device_error d) {
// behandl fejl på en enhed
}
catch (math_error m) {
// behandl matematisk fejl
}
catch (memory_error m) {
// behandl lagerfejl
}
}
Det gode ved denne måde at arbejde med fejlsituationer på, er at hvis ingen fejl opstår, så vil
programmet ingenting foretage sig. Dermed kan et underliggende fejlbehandlende system bygges
ind i programmet på en sådan måde, at det ikke vil lide tidsmæssigt under det. Med den form for
fejlbehandling, der ikke er understøttet af sproget, men som må skrives i det, er der et stort
forbrug i forbindelse med test af situationer og statusflag. Et ideelt standardbibliotek vil således
indeholde throw-sætninger i stedet for at returnere særlige værdier i særlige situationer, sådan
som for eksempel C-biblioteksfunktioner som malloc() og printf() gør.
Det er en god idé at modtage reference- eller pointertyper i en catch-sætning, fordi det
tillader at vi indbygger polymorfi i fejlsystemet. Der er ingen standard-formel for design af et
fejlbehandlingsystem, men oplæget her giver mulighed for mange forskellige slags
implementationer, ganske i C++'s natur. Overvej følgende måde at arbejde med fejl på, hvor en
enkelt catch fanger forskellige underordnede fejl i samme sætning:
struct math_error { /* ... */ };
struct divide_by_zero : math_error { /* ... */ };
struct overflow : math_error { /* ... */ };
struct underflow : math_error { /* ... */ };
void g () {
// ...
throw overflow;
}
A.2 Fejlbehandling 539

void f () {
try {
g ();
}
catch (math_error& m) {
// alle slags matematiske fejl
}
}
Her har kalderen, som fanger undtagelsen, en frihed til enten at fange en overordnet fejl (en
baseklasse) eller en underordnet fejl (en afledt klasse). Hvis kalderen vil specialisere sig indenfor
de forskellige typer af matematiske fejl, der er tale om her, er det blot et spørgsmål om at benytte
disse typer i stedet:
void f () {
try {
g ();
}
catch (overflow& m) {
// overløbstilstand
}
}
På den måde kan der med arv specificeres forskellige niveauer af fejl, som er naturlige i deres
udformning og entydige i deres brug, når fejl skal boble op gennem funktionerne. Jo længere op,
vi kommer, des mere generelle kan vi tillade os at være i vores catch-sætninger. Virtuelle
funktioner spiller også en vigtig rolle her, da de kan bruges til en standardoprydning for fejlen.
Læg mærke til, at catch-sætningerne gennemløbes i den rækkefølge, de står i kildeteksten.
Det er også muligt at kaste og fange undtagelser uden information om typen:
// kast en generel undtagelse
throw;
catch (...) {
// alle typer af fejl fanges her
}
Fordi catch-sætningerne gennemløbes i rækkefølge, bør en catch(...) stå til sidst. Hvis
en throw uden parameter står i en catch-sætning vil samme undtagelse dog blive kastet som
den aktuelle catch modtager:
catch (math_error& a) {
// ...
throw; // kaster en math_error-undtagelse
540 Fremtidsudsigter A.0

}
Der er en underforstået undtagelses-fanger, som automatisk oprettes, hvis der ikke specificeres
en catch(...), som har udformningen
catch (...) { throw; }
Hvis der på det øverste niveau i programmet ikke findes en passende catch-sætning, vil den
indbyggede funktion terminate() automatisk blive kaldt. terminate() kan anmodes
om at kalde en brugerfunktion med et kald til set_terminate(), som modtager et
parameter af typen void(*)(), altså pointer til void-funktion.
Når en undtagelse kastes, deallokeres alle automatisk allokerede objekter, der er erklæret efter
try-blokkens start. Dynamisk allokerede objekter er, som altid, programmørens ansvar. En
undtagelse kan kastes i en konstruktør, altså i et objekt under konstruktion. Hvis en undtagelse
kastes i en konstruktør i en baseklasse, er subobjekterne (i de afledte klasser) endnu ikke
konstrueret, så destruktørne for disse vil ikke blive kaldt. Kun færdigtkonstruerede subobjekter
vil blive destrueret.
Det er muligt at specificere, hvilke undtagelser en given funktion er i stand til at kaste, hvilket
er en måde at automatisere fejlbehandlingen på. Specifikationen på undtagelserne skrives efter
funktionserklæringens navn og parameterliste, som i
void funk () throw (dette, hint) {
// ...
}
Dette betyder i klare termer, at funk() kan kaste (kaster) undtagelserne dette og hint
videre fra en af funk() kaldt funktion til den funktion, der kaldte funk(). Dermed behøver
vi ikke skrive try- og catch-blokke i funk(). Hvis en af funk() kaldt funktion kaster
en undtagelse, som ikke står i funk()'s specifikation af tilladte undtagelser, vil funktionen
unexpected() blive kaldt. unexpected() kan ligesom terminate() sættes til at
kalde en brugerfunktion, her blot med et kald til set_unexpected(), som modtager samme
parametertype som set_terminate() (se ovenfor).
Erklæringen af funk() ovenfor vil generere denne underforståede kode, eller noget i
lignende:
void funk() throw (dette, hint) {
try { /* alle sætninger i funktionen */ }
catch (dette) { throw; }
catch (hint) { throw; }
catch (...) { unexpected (); }
}
Specifikationen af mulige undtagelser i en funktion har også muligheder indenfor statisk
analyse, fordi den specificerer et forhold mellem funktioner. Hvis der ikke er en specifikation af
A.2 Fejlbehandling 541

undtagelser, kan funktionen kaste alle slags, og hvis specifikationen udtrykker en tom liste af
typer - throw() - er det ulovligt for funktionen at kaste undtagelser. Læg for øvrigt mærke til,
at en funktion, som kaster en undtagelse af typen T rent faktisk er i stand til at kaste untagelser
af enhver type afledt fra T.
Det skal nævnes, at fejlbehandling, som er beskrevet i dette afsnit, er genstand for megen
diskussion blandt udviklere. Mange oversættersystemer indeholder ikke faciliteten mens andre
implementerer den i nedskåret grad. Microsoft's C/C++ 7.0 indeholder fejlbehandling, mens
Borland's C++ 3.0 ikke gør. Det ser heller ikke ud til, at ANSI vil lade fejlbehandling være
omfattet af standarden.
A.3 Parameteriserede typer
Ikke alle C++-oversættere indeholder faciliteter for parameteriserede typer, som beskrives i
denne bog som en del af sproget. Microsoft's C/C++ 7.0 har for eksempel satset på andre
faciliteter, mens Borland's oversætter bygger meget på skabeloner. Det ser dog alligevel ud til, at
denne facilitet bliver medtaget i ANSI C++ og at AT&T C++ 3.0 har været meget populær netop
af den grund.
A.4 Typeidentifikation på kørselstidspunktet
En mulig og for mange velkommen udvidelse af C++ har at gøre med entydig identifikation af
typer under programmets kørsel. Som det ser ud nu, har kun oversætteren viden om de egentlige
typer af objekter, der bruges polymorft, mens programmet, når det kører, må læne sig op af
virtuelle funktioner. Problemet er, at polymorfien i C++'s objekt-orienterede muligheder kun
virker opad i hierarkiet; man kan konvertere fra en afledt klasse til en baseklase. Hvis nu man har
en pointer til en baseklasse, som måske er abstrakt, hvordan ved man så, hvilken klasse den
egentlig peger på?
Lad os tage et eksempel fra XCL-biblioteket. En gennemgående funktion i de fleste klasser
sammenligner objekter, og ser nogenlunde således ud:
bool Klasse::isEqual (const Object* obj) {
return (Klasse*) obj == this);
}
Parameteren skal være af typen const Object*, fordi der er tale om en virtuel funktion, der
skal være identis med baseklassernes erklæringer. Derfor bliver funktionen nødt til at foretage en
tvungen typekonvertering fra en Object* ned til en Klasse* (Klasse er en eller anden
ikke-abstrakt XCL-klasse) og sammenligne de to. Men hvordan ved isEqual(), om denne
konvertering gik godt? Hvad nu, hvis obj faktisk var en helt anden type, så de to slet ikke
542 Fremtidsudsigter A.0

kunne sammenlignes (hvordan sammenlignes en Complex og en String, for eksempel)?
Forslaget til en ændring går ud på, at typekonverteringen skal resultere i en NULL-pointer, hvis
konverteringen gik galt. Det er faktisk den slags manglende indbyggede typeidentifikation, som
nødvendiggør de typiske isA()- og typeOf()-funktioner i de fleste C++-biblioteker. For
eksempel,
bool Klasse::isEqual (const Object* obj) {
Klasse* kp = (Klasse*) obj;
if (kp) // ok: obj var en Klasse-pointer
return obj == this;
else // ups: obj var IKKE en Klasse-pointer
return 0;
}
Generelt hvad angår forslag til udvidelser af C++ henvises til de artikler og notater fra AT&T,
der periodisk publiceres i tidsskrifter med objekt-orienteret tilknytning. Især The C++ Report,
Journal of Object-Oriented Programming og Hotline on Object-Oriented Technology indeholder
seneste nyheder om sprogets udvikling. Der må også især henvises til Bjarne Stroustrups The
Annotated C++ Reference Manual [Stroustrup 91], som er et arbejdsdokument for ANSIkomiteen,
der arbejder med udkastet til standardiseringen. Bogen udkommer snart i en anden
udgave med et rationale for de forskellige forslag til udvidelser og ændringer, der er kommet til i
løbet af de sidste to år.
A.3 Parameteriserede typer 543

Gode råd til C-programmører
C++ har en stor fordel i at være næsten kompatibelt med C. C-programmører kan
uden videre foretage skiftet og begynde at benytte de ny faciliteter. Der skal ikke
læres ny syntaks, regler for oversættelse, organisation af kildetekst eller
udviklingsmiljø. Dog, som beskrevet i introduktionen, skal visse begreber aflæres
- for eksempel globale og delte data - før der kan skrives objekt-orienterede
programmer i sproget. Til gengæld er indlæringskurven for en C-programmør
lettere i begyndelsen end for folk med en anden baggrund. I dette appendiks
opremses et antal nøglepunkter, hvor C-programmører umiddelbart skulle kunne
se en fordel i at bruge en bedre C.
1. Brug const i stedet for #define
const WC_PAINT = 1;
const double PI = 3.1415927;
const int EOF = -1;
B
Makroer benyttes overalt i konventionelle C-programmer. Den hyppigste anvendelse er til
erklæring af konstanter. Ved i stedet at erklære konstanterne med const-nøgleordet kan de
indgå i typesystemet og begrænses i skop, i modsætning til makroerne, som ikke har typer og er
helt globale. Typeinformationen hjælper oversætteren i deduktion af ulovlige tildelinger,
parameteroverførsler mv.
Hvor der i C skrives
#define WM_PAINT 1
#define PI 3.1415927
#define EOF -1
skrives i C++ som
544 Fremtidsudsigter A.0

Makroer har stadig anvendelse i C++, men kun i tilfælde, hvor indholdet af makroen er mere
end en konstant. Når der for eksempel skal erklæres komplicerede makroer til substitution af
egentlig kode, til at undgå gentagne gennemløb af headerfiler eller til erklæring af navne, der skal
benyttes af oversætteren:
#if !defined _OBJECT_H
#define _OBJECT_H
#define DECLARE_AS_STOREABLE(CLASS) \
static Object* Create ## CLASS (void) { \
return new CLASS; \
} \
static bool init ## CLASS = \
ObjectManager::Announce (#CLASS, Create ## CLASS); \
#define TARGET_SYSTEM OS_2_20
#endif
2. Brug ikke typedef
I C er det kutyme at skrive kode som
typedef struct _MONIN {
USHORT cb;
BYTE abBuffer [18];
} MONIN;
hvilket erklærer en type MONIN som en datastruktur. Det gøres for at undgå at skulle bruge
struct, hver eneste gang strukturen bruges i programmet. I C++ har typer og variable samme
navnerum, dvs. et strukturnavn indgår som et leksikalt element. Skriv i stedet:
struct MONIN {
USHORT cb;
BYTE abBuffer [18];
};
hvorved oversætteren kan benytte strukturen (eller klassen) som et normalt typenavn. Brug dog
stadig typedef til erklæring af typer, der har en meget lang og forvirrende syntaks, som for
eksempel
typedef int (*Handler) (const unsigned long&);
A.3 Parameteriserede typer 545

hvis fordel i koden kan illustreres af forskellen mellem disse to funktionsprototyper:
int (*) (const unsigned long&)
set_new_handler (int (*) (const unsigned long&) = 0);
Handler set_new_handler (Handler = 0);
Læsbarheden vinder i den sidste.
2. Brug inline-funktioner i stedet for makroer
Makroer, der består af en mindre parametiseret stump kode, kan ofte med fordel konverteres til
en inline-funktion, fordi den indgår bedre i typesystemet og er sikrere og mere konsistent i
brug. Overvej
#define max(x,y) ( (x) > (y) ? (x) : (y) )
Hvad sker der, når vi skriver
a = max (b++, --c);
hvilket ekspanderes til noget i retning af
a = ( (b++) > (--c) ? (b++) : (--c) );
hvilket vist ikke er meningen? Desuden vil
a = max ("A", "B");
sandsynligvis kunne oversættes uden problemer, men vil være meningsløst og sikkert generere en
fejl under kørslen. En inline-funktion er et godt alternativ, og bærer typeinformation med sig.
Skal den bruges til forskellige typer, kan den overstyres eller skrives som en skabelonklasse:
inline int max (int x, int y) { return x > y ? x : y; }
Nu vil oversætteren med en meningsfuld fejl fange de ovenstående forkerte anvendelser af
makroen. I de fleste tilfælde kan en makro erstattes af en inline-funktion (eller flere) uden at
der skal ændres i andet kode.
Makroer skal dog stadig bruges i stedet for inline-funktioner i de situationer, hvor det er en
type eller et andet navn, der skal overføres til makroen som parameter.
546 Fremtidsudsigter A.0

4. Erklær variabelnavne hvor de bruges første gang
I C er det påkrævet, at alle variable (objekter) erklæres før den første sætning i funktionen,
hvilket skaber en del moslen rundt i kildeteksten, når typen på en variabel et sted midt i en
funktion skal identificeres. C++ tillader, at vi erklærer variablen hvor den bruges første gang, så
bliver til
void f () {
int i;
// ...
for (i = 0; i < 100; i++) { /* ... */ }
};
void f () {
// ...
for (int i = 0; i < 100; i++) { /* ... */ }
};
Det gør det for det første lettere hurtigt at identificere objekters typer og sparer også på
navnerummet, fordi lokale erklæringer (lejret ind i blokke) ikke forurener de ydre.
5. Brug konstante referencer som parametre
I C bruges pointere til datastrukturer ofte som parametre for at spare tid i funktionskald, da en
pointer fylder langt mindre end en stor datastruktur. Der er dog tilfælde, hvor en funktion ikke må
ændre i strukturens indhold, hvorfor den overføres som kopi. For eksempel,
void f (struct INFO infoblock) { /* ... */ }
Her er det bedre at erklære parameteren som en konstant pointer, hvilket sikrer at den ikke bliver
ændret og samtidig at den overføres langt hurtigere:
void f (const INFO* infoblock) { /* ... */ }
Eller endnu bedre, en referenceparameter, hvilket lader klienten slippe for at bruge adresseoperatoren,
når funktionen kaldes:
void f (const INFO& infoblock) { /* ... */ }
6. Brug statiske klasser i stedet for globale data
A.3 Parameteriserede typer 547

Næsten alle C-programmer, der består af mere end en main()-funktion indeholder globale
data. Globale data skaber rodede programmer, der er svære at ændre på (se afsnit 5.2), fordi de
netop består af funktioner, der afhænger af data udenfor ethvert domæne. Brug i stedet en statisk
klasse (afsnit 3.13 og 3.14) med en eventuel statisk konstruktør, og gå gennem klassens statiske
metoder (med et kvalificeret typenavn) for at komme til de indkapslede data deri. Det er en
modularisering, der indskrænker de globale data, og som også kan gælde for globale funktioner.
For eksempel,
class MemoryAllocator {
static void** alloctable;
static void (*ErrorHandler) (void);
public:
static int status;
static void* Allocate (size_t);
static void FreeUp ();
static void heapWalk ();
// ...
};
Kald til de statiske metoder giver en indgang til de statiske data, som nu ikke længere forurener
det globale navnerum. For eksempel,
char* pcBuf = (char*) MemoryAllocator::Allocate (1000);
if (MemoryAllocator::status == 0) cerr

struct Node;
// ...
bliver til
Node* n = (Node*) malloc (sizeof (Node));
// ...
free (n);
struct Node;
// ...
Node* n = new Node;
// ...
delete n;
new sikrer, at konstruktøren (konstruktørerne) for det nye objekt kaldes, og dermed, at objektet
initieres korrekt - eller, hvis lageret ikke kunne findes, at det slet ikke bliver initieret.
malloc() lægger derimod op til en del statuskontrol hos klienten.
8. Brug i stedet for
Selv om C++ fungerer med både C-biblitoteket stdio og det nye standardbibliotek i C++,
iostream, bør det gamle bibliotek ikke benyttes. iostream har langt bedre faciliteter for I/O, fordi
det er implementeret som et klassehierarki, som tillader, at klienten integrerer egne datatyper i
I/O-biblioteket (se afsnit 6.6). Specifikt bør du bruge de overstyrede operatorer > i
stedet for funktioner som scanf() og printf(), fordi de lader dig være ligeglad med
specifikation af typen på de data, du vil ind- og udlæse. For eksempel,
bliver til
og
bliver til
printf ("%s er %d år gammel\n", navn, alder);
cout

9. Brug konstruktører og destruktører
I C har vi for vane at skrive en sekvens som
void f () {
unsigned whdl;
// ...
whdl = WinCreateWindow (0); // opret en forekomst
WinInitialise (whdl) // initiér den
// ...
WinCloseDown (whdl); // fjern den
}
Her er tre funktionskald, som klienten må og skal huske at kalde, og tilmed i den rette
rækkefølge. I C++ kan den eksplicitte allokationsfunktion erstattes af en new, som eventuelt
overstyres af en klasse. Eller også kan konstuktører og destruktører sikre korrekt oprettelse og
nedbrydning af objektet, så klienten ikke ved at glemme at kalde en initieringsfunktion får en
banal run-time fejl.
10. Brug overstyrede funktioner
C-biblioteker har ofte forskellige implementationer af samme funktion, hvor de arbejder på hver
sin type eller parameterliste. Der findes således flere funktioner til at tage den absolutte værdi af
et tal, både til heltal og til kommatal. Disse funktioner har i C-biblioteket math.h navnene
abs() og fabs(). Klienten skal huske hvilken funktion, der skal bruges, afhængig af typen,
der skal gives med.
I C++ kan dette overlades til oversætteren, som ved overstyring af funktionsnavnet skelner
mellem to funktioner med identiske navne på parameterlisten. Begge funktioner hedder abs(),
men tager henholdsvis en int og en double. Læg mærke til, at dette kun virker for
parameterlister (og konstante medlemsfunktioner), men ikke for returværdier (se afsnit 2.6.9 og
3.3.3). C++ skelner også, i modsætning til C++, mellem en unsigned int og en int. Hvis
der således er to overstyrede funktioner
unsigned int abs (unsigned int i);
int abs (int i);
vil oversætteren udtrykkeligt vælge den, der passer til parameteret.
12. Brug virtuelle funktioner i stedet for switch-sætninger
I C finder man tit switch-sætninger, der fylder flere sider. Disse typer af statiske
550 Fremtidsudsigter A.0

sammenligninger gør det svært at udvide programmet, fordi afhængighederne af de forskellige
værdier i en switch er spredt ud over hele programmet. En ofte benyttet teknik er at give en
datastruktur et typefelt i en indeholdt union, og så teste på dette felt i switch-sætninger
rundt om i programmet. For eksempel,
struct command {
enum _type { streng, heltal } type;
union _cmd_types {
char* s;
int i;
} cmd_type;
};
/* ... */
void read (struct command* c) {
switch (c->type) {
case streng: /* ... */ break;
case heltal: /* ... */ break;
/* osv... */
}
}
void write (struct command* c) {
switch (c->type) {
case streng: /* ... */ break;
case heltal: /* ... */ break;
/* osv... */
}
}
/* osv... */
På denne måde bliver koden, der arbejder på en bestemt type af strukturen spredt rundt i hele
programmet, og ofte i forskellige moduler. Dermed er det svært at lokalisere dem (og fejlene i
dem), fordi det ikke er entydigt, hvilke funktioner, der har adgang. En udvidelse af strukturen
med en ny type involverer en opdatering af alle switch-sætninger i programmet, der tester på
typefeltet.
Et godt alternativ er at skrive strukturen om til en base-klasse og de forskellige konstanter, der
beskriver typerne i opremsningen om til afledte klasser. Alle case-sætningerne skrives i stedet
som virtuelle funktioner i alle klasserne (rene i baseklassen). Dermed isoleres al kode, der
A.3 Parameteriserede typer 551

arbejder på en bestemt type i samme modul, og nye typer kan påhæftes uden at ændre koden i de
eksisterende moduler. For eksempel,
class command {
public:
virtual void read () = 0;
virtual void write () = 0;
};
class streng_command : public command {
char* s;
public:
virtual void read () { /* ... */ }
virtual void write () { /* ... */ }
};
class heltal_command : public command {
char* s;
public:
virtual void read () { /* ... */ }
virtual void write () { /* ... */ }
};
// ...
void read (command* c) {
c->read ();
}
void write (command* c) {
c->write ();
}
// osv...
13. Brug anonyme unions
unions i C har den ulempe, at typenavnet på den skal specificeres, hvis et medlem skal
refereres. For eksempel,
struct A {
552 Fremtidsudsigter A.0

union U {
int i;
long l;
char* c;
} u;
int t;
};
struct A a;
a.u.l = 5000L;
I C++ (også i ANSI C) kan en union være anonym (afsnit 2.8.3), hvilket sparer unødig tekst:
struct A {
union {
int i;
long l;
char* c;
};
int t;
};
struct A a;
a.l = 5000L;
De tre medlemmer af den anonyme union har et skop, der svarer til den blok, hvori de står, i
dette tilfælde altså A.
13. Brug type-sikker lænkning
På grund af C++ adminstration af overstyrede funktioner, kan der opstå konflikter i lænkningen
til eksisterende C-biblioteker (og for den sags skyld til Pascal, Fortran eller assemblerbiblioteker).
Konstruktionen for type-sikker lænkning sikrer, at det navn, der lænkes med ikke ændres af
oversætteren. For eksempel,
extern "C" long rand ();
extern "C" {
#include
#include
}
A.3 Parameteriserede typer 553

14. Brug skabeloner
Skabeloner og symbolske konstanter gør næsten makroer overflødige. Brug så vidt muligt
skabelonklasser (parameteriserede typer) og skabelonfunktioner (parameteriserede funktioner)
hvis der er den mindste mistanke om, at funktionens centrale datatype kan opfattes generisk, dvs.
anvendes i forskellige uafhængige sammenhænge.
En vektor med grænsecheck som den nedenfor er for eksempel centreret omkring en type, som
rent faktisk slet ikke har noget med vektorens mekanik at gøre - og derfor kan den så at sige
fjernes og gøres til et anonym parameter. Så selvom klassen er meget enkel kan den godt
parameteriseres med fordel.
template
class Vector {
T* rep;
T ERROR;
unsigned size;
public:
Vector (unsigned sz) { rep = new T [size = sz]; }
~Vector () { delete rep; }
T& operator[] (unsigned i) {
return i < size ? rep [i] : ERROR;
}
};
554 Fremtidsudsigter A.0

Andre Objekt-Orienterede Sprog
C++ er naturligvis ikke det eneste objekt-orienterede system, der findes. Man kan
heller ikke sige, at det er det bedste. Det er godt til visse formål, og forfatteren vil
sige de fleste. Der er imidlertid andre OOP-systemer, sprog mv., som har fortrin
på visse punkter frem for C++. Nogle af disse systemer gennemgås i dette
appendiks. Alle produktnavne er registrerede varemærker hos deres respektive
producenter.
C.1 Hvornår er man objekt-orienteret?
C
Der skelnes normalt mellem rene OOP-systemer, som er designet objekt-orienteret helt fra
bunden, og mellem en hybrid type system, som "låner" forskellige steder fra og som udbygger
eksisterende sprog med objekt-orienterede faciliteter. De rene sprog har normalt en leksikal
opbygning, der er meget forskellig fra de procedurale sprog. Hvad enten systemet er rent eller ej,
er det ikke en determinant for, om det er et ægte objekt-orienteret system. Simula, som var det
første ægte objekt-orienterede sprog, der blev udviklet i midten af 60'erne, var en udbygning af
Algol.
Spørgsmålet om hvilken type objekt-orienteret system er det bedste er kontroversielt. De fleste
tilhængere af de rene sprog er utilfredse med hybridernes sammensætning og mener ikke, man
kan klistre en OOP-overbygning på for eksempel procedurale sprog. Den anden vej rundt går
argumentet på, at de rene sprog oftest er fortolkede, og derfor for langsomme til "rigtige
programmer". Situationen er da også den, at de rene sprog mest bruges i forskninssammenhæng
mens hybriderne bruges i produktion og udvikling. Smalltalk og LISP er eksempler på fortolkede
sprog. Fortolkede sprog har større objekt-orienterede muligheder, fordi et subsystem konstant kan
kontrollere polymori. Der er dermed ingen overstættertid - programmet kan eksekveres
umiddelbart - og der er større muligheder for fejlfinding og hjælp på kørselstidspunktet.
En ulempe ved de rene OOP-sprog er, at det tager tid at lære syntaksen og opbygningen at
kende, fordi sproget sandsynligvis følger en helt anden fremgangsmåde end de mere udbredte. De
tvinger også programmøren op på den objekt-orienterede hest. Spørgsmålet går altså også på, om
man som programmør ønsker frihed til at vælge eller blande paradigmer. Friheden gør trods alt
programmerne mindre objekt-orienterede. C++ er et hybrid-sprog, fordi det skal være
kompatibelt med C, og fordi det skal indeholde statisk binding.
Ud over de følgende beskrivelser af andre systemer kan nævnes LOOPS (en LISP-variant),
A.3 Parameteriserede typer 555

Objective-C (en anden hybrid med C som fundament), Clu, ML, Simula og til dels Ada.
C.2 Pascal-varianter
I 1988 lanceredes to udvidede Pascal-systemer med objekt-orienterede overbygninger til MS-
DOS systemer. Microsoft og Borland brugte hver sin implementation af et simpelt klassesytem til
indkapsling af data og funktioner. Microsofts QuickPascal låner fra Smalltalk mens Borlands
Turbo Pascal låner fra C++.
Disse sprog er, hvad man kan kalde minimale OOP-sprog, fordi de understøtter netop de basale
krav til et sådant system: indkapsling, arv og polymorfi. De har ingen mulighed for
parametisering, adgangskontrol, skopkontrol, underforstået konstruktion og destruktion, multipel
arv, abstrakte klasser eller overstyring. De er imidlertid gode til at lære grundprincipperne i
objekt-orienteret programmering og programkonstruktion, og har, på grund af Pascal-sprogets
læresprogsagtige syntaks og omfang, en enklere og mere læselig definition af klasser (som iøvrigt
i disse sprog kaldes objekttyper).
Her er et eksempel på en klasseerklæring i Turbo Pascal:
type
obj = OBJECT
constructor init (i: integer); { konstruktør }
destructor down; { destruktør }
procedure doit (var j: integer); { medlemsprocedure }
integer value;
end;
{ medlemsdata }
C.3 Eiffel
Eiffel er et dedikeret sprog til professionel softwareudvikling, som har sin baggrund fra et seriøst
forskningsprojekt, ledet af Bertrand Meyer. Eiffel er et rent objekt-orienteret system, men er trods
det ikke et fortolket sprog. Systemet har visse udvidede sprogunderstøttede faciliteter så som
begrebet forudsætninger (preconditions) og følgevirkninger (postconditions), en status i alle
objekter og en bedre definitiona af multipel arv end den, der findes i andre objekt-orienterede
systemer. For eksempel kan der i Eiffel defineres to abstrakte klasser, som med en meget simpel
multipel afledning kan samles i en virkende klasse. Abstrakte klasser hedder i Eiffel afventende
klasser (deferred classes) og deres ikke-implementerede virtuelle funktioner afventende rutiner
(deferred routines). Eiffel indeholder fuld support for parametiserede typer og for omdøbning af
tvetydige navne.
556 Fremtidsudsigter A.0

Her er et eksempel med en hægtet liste fra Eiffel:
class LINKED_LIST [T] -- parametiseret af T
inherit -- arver fra LIST
LIST [T]
redefine first -- omdøbning
feature
first: T; -- indkapslede data
first_element: LINKABLE [T];
active, previous, next: like first_element;
value: T is -- en rutine
require
not offleft;
not offright;
-- forudsætninger...
do -- følgevirkninger...
Result := active.value;
end;
C.4 Smalltalk
Smalltalk er mere end et objekt-orienteret sprog, det er et komplet objekt-orienteret
udviklingsmiljø. Det er designet hos Xerox i deres Palo Alto Research Center (PARC) med
Adele Goldberg som banekvinde og er en slags gudfar for de fleste OOP-systemer (og en masse
andet: Apple Lisa og Macintosh's brugergrænseflade, som igen blev inspiration for Windows,
GEM, X osv., var en løs implementation af Smalltalk-miljøet). Dette miljø tjener både som
udviklingsmiljø og som brugergrænseflade. Det er i sig selv objekt-orienteret med vinduer, popup
menuer og alle de kendte små ting og sager på den grafiske skærm. Smalltalk er skrevet i
Smalltalk, og et komplet klassebibliotek, som også har været inspiration for talrige C++
klassebiblioteker, er også en standard del af systemet.
Smalltalk er et fortolket sprog, hvilket gør det meget fleksibelt, men gør det også begrænset i
anvendelse for kommerciel softwareudvikling. Flyrbarheden er lav, fordi Smalltalk-miljøet ikke
findes til ret mange maskintyper og operativsystemer, dog både UNIX, OS/2 Presentation
Manager, MS-Windows og MS-DOS.
Her er et uddrag af en Smalltalk-klasse:
class ObjectStream
superclass Object
instance variables stream alreadyTraced
instance creation
A.3 Parameteriserede typer 557

pathName: aString
^self new pathName: aString
instance initialization
pathName: aString
stream := File pathName: aString
querying
atEnd
^stream atEnd
initializeTracing "konstruktør"
alreadyTraced := IdentityDictionary new
finalizeTracing "destruktør"
alreadyTraced := nil
Klassebiblioteket XCL i kapitel 7 er løst inspireret af standardbiblioteket i Smalltalk-miljøet, da
klasser som Dictionary, Object, Sortable, Container og så videre ligger i dette.
C.5 Actor
Actor er et meget specialiseret system til udvikling af grafiske applikationer i MS-Windows og
OS/2, og lægger sig tæt op af dette system. Det er en krydsning mellem Pascal og Smalltalk,
benytter kun dynamisk binding og kommer med et færdigt klassebibliotek. Idet MS-Windows og
OS/2 Presentation Manager i sig selv er objekt-orienteret (vinduer, menuer, undermenuer,
rammer, forskellige slags ikoner osv.) er Actor en glimrende ramme for at gøre det komplicerede,
hændelsesdrevne programmeringsarbejde lettere.
558 Fremtidsudsigter A.0

Objekt-Orienteret Ordbog
D
Abstrakt datatype (eng. Abstract Data Type): en datatype, hvis egenskaber og interne
repræsentation i form af data- og kontrolstrukturer samt grænseflade til klienten er defineret og
implementeret af designeren af typen. Også kaldet bruger-defineret datatype eller klasse, da der
er en vis begrebsforvirring i sammenhæng med termet abstrakt klasse.
Abstrakt klasse (eng. Abstract Class): en klasse, der ikke kan instantieres. Grunden til dette kan
være (a) at klassen har beskyttede eller private konstruktører og (b) at klassen indeholder virtuelle
metoder.
ADT, se abstrakt datatype.
Afledt klasse (eng. Decendant Class eller Derived Class): en klasse, der arv egenskaber fra en
baseklasse og kan benytte sig af disse egenskaber som om, egenskaberne var erklæret direkte i
den. Også kaldet en underordnet klasse.
Aktiv klasse: en klasse, der kan instantieres.
Arv (eng. Inheritance): En egenskab i objekt-orienterede sprog, der definerer en klasses direkte
overtagelse af en andet klasses egenskaber til eget brug. Egenskaberne er både data og metoder
samt adgangskriterier for disse.
Baseklasse (eng. Ancestor Object eller Base Object): et objekt fra hvilket en eller flere andre -
afledte - klasse er nedarvet. Baseklassen repræsenterer generelle, fælles træk i de afledte klasser
og kan erstatte dem i de fleste situationer.
Beskyttede medlemmer: den del af klassen, der er utilgængelig for klienten (som må gøre sig
uafhængig af den og gå gennem den offentlige del), men som er tilgængelig for nedarvede klasser
(som har fordel af tilgangen).
Bestandighed (eng. Persistence): et forhold ved et eller flere objekter i et system, som tillader at
systemet ind- og udlæser objektindhold på sekundært lager med eller uden klientens indblanding.
Binding: Den proces, der definerer bestemmelsen af adressen (placeringen) af et bestemt navn i
computerens lager (data- eller funktionsnavn). Dette kan ske på flere forskellige tidspunkter,
A.3 Parameteriserede typer 559

enten af oversætteren under oversættelsen (statisk binding), af programmet selv under kørslen
(dynamisk binding) eller af operativsystemet under administration af virtuelt lager (virtuel
binding). Undertiden kaldes binding alternativt for lænkning, hvis administrationen foretages af
operativsystemet fremfor programmet selv.
Dataabstraktion (eng. Data Abstraction): De teorier, der ligger bag udviklingen og arbejdet med
abstrakte datatyper og indkapsling. Dataabstraktion er i vidt omfang en generel
programmeringsteknik.
Destruktør (eng. Destructor): En bestemt funktion, som er medlem af en klasse. Destruktøren
kaldes implicit ved slutningen af objektets skop, og bruges bla. til deallokeriong af lager.
Dynamisk binding (eng. Dynamic Binding eller Late Binding): Når adressen på et navn (data-
eller funktionsnavn) bestemmes under kørslen af programmet (ved run-time), nærmere bestemt
lige før referencen foretages. Også kaldet sen binding. Det tillader, at programmet har større
frihed i valg af slutadresse end tilfældet er med modstykket, tidlig binding.
Forekomst (eng. Instance): En forekomst er en fysisk tilstedeværende variabel eller objekt af en
bestemt type, for eksempel er float en type og a kan være en forekomst af float efter
deklarationen float a.
Grænseflade (eng. Interface) er den specifikation, en klasse har i den offentlige del, dvs. de
funktioner og data, der er tilgængelige for klienten. Resten af klassens definition (den indkapslede
del) er ikke tilgængelig og klienten tvinges til at være uafhængig af denne. Dermed opnås en
frihed i klassen til at ændre på den interne repræsentation og implementation af henholdsvis data
og metoder.
Indkapsling (eng. Encapsulation) er den teknik, der samler data og funktioner i samme skop og
dermed relaterer dem til hinanden.
Instans, se forekomst.
Instantiering (eng. Instantiation): Den proces at skabe en forekomst af en klasse med et objekt
som resultat. Dette gøres normalt eksplicit med en erklæring, men kan dog også foregå implicit
under returneringer, i sammensatte udtræk og i funktionskald.
Konstruktør (eng. Constructor): En bestemt funktion, som er offentligt medlem af et objekt.
Konstruktøren kaldes implicit ved starten af objektets skop, og bruges til bla. lagerallokation og
initiering. Den sikrer, at der aldrig findes objekter, der ikke er korrekte.
Medlem (eng. Member): En funktion eller en dataerklæring, som står i en klasse, anses for
medlem af klassen.
Metode (eng. Method): En funktion, som tilhører en klasse, dvs. som er defineret indenfor
560 Fremtidsudsigter A.0

klassen deklaration. En metode kaldes med reference til en forekomst af klassen. Den klassiske
terminologi refererer til, at man i teorien "sender et objekt en besked" ved et kald til en metode i
objektets klasse.
Multipel Arv (eng. Multiple Inheritance): Arv, hvor en klasse har mere end én baseklasse og
således kombinerer to eller flere klassers indhold.
Klasse, se abstrakt datatype.
Klient (eng. Client) er den person, der benytter en klasse. Der skelnes på en klient/udbyder-basis
mellem den eller de personer, der skriver en klasse og den eller de, der benytter den i
applikationer eller videreudviklinger/specialiseringer. Klienten kan også kaldes brugeren af
klassen.
Klassehierarki (eng. Class Hierarchy): en acyklisk graf af klasser, nedarvet fra hinanden i to
eller flere lag. Et klassehierarki består af komplekst relaterede klasser, ordnet efter stigende
specialisering. Flere afledte klasser kan arve fra samme baseklasser ligesom en afledt klasse kan
have flere baseklasser.
Modul (også kaldet oversættelsesenhed) er produktet af en enkelt oversættelse. Flere moduler
kan lænkes sammen til et eksekverbart program. Hvert modul indeholder egne private data og
funktioner samt andre, der eksporteres til andre moduler. Moduler kan også samles i biblioteker,
som gør programudviklingen lettere.
Offentlige medlemmer: den del af klassen, som er tilgængelig for klienten, og som udgør
klassens grænseflade.
OODBMS: Forkortelse for Object-Oriented Database Management System.
Overordnet klasse, se baseklasse.
Overstyring (eng. Overloading) er (a) en funktion, som deler navn med andre funktioner med
afvigende parameterlister og (b) en operator, der gives en udvidet semantisk betydning for en
abstrakt datatype.
Polymorfe objekter: Objekter, der indeholder virtuelle metoder og således kan bruges polymorft
i klientens referencer.
Polymorfi (eng. Polymorphism, af græsk, mange former). En egenskab ved objekt-orienteret
programmering, der via arv, virtuelle metoder og dynamisk binding tillader, at samme syntaks og
reference kan bruges på forekomster af objekter af forskellige typer, så længe de har et fælles
overordnet objekt. Ofte (fejlagtigt) kaldet "polymorfisme" på dansk.
Private medlemmer: den del af klassen, som ikke kan ses af klienten grundet en erklæring i
A.3 Parameteriserede typer 561

klassens definition. De private medlemmer er skjult fra klienten.
Sen binding, se dynamisk binding.
Statisk binding (eng. Static Binding eller Early Binding): Når adressen på et navn (data- eller
funktionsnavn) bestemmes på oversættertidspunktet og skrives statisk i objektkoden. Også kaldet
tidlig binding.
Statisk klasse: en klasse, der kun indeholder statiske data og metoder, og som ikke er bestemt for
instantiering. En statisk klasse erklæres i reglen også abstrakt.
Skabelon (eng. Template): en klasse eller funktion, som i sig selv ikke er aktiv, og som kun kan
instantieres i en eller flere andre typers kontekst. Også kaldet parameterisering.
Skop (eng. Scope) er det område, et objekt (a) lever i, dvs. fra dets konstruktion til dets
destruktion og (b) det område, som objektet er tilgængelig i i referencer. Kaldes undertiden også
for virkefelt.
Strøm (eng. Stream): Det sted, hvorfra data kommer eller går. Traditionelt er en inputstrøm de
konceptuelle inddata til et program, mens outputstrømmen er uddata. Disse begreber indkapsles i
C++ i dedikerede strømklasser til standard-, filbaseret og andet I/O.
Tidlig binding, se statisk binding.
Underordnet objekt, se afledt klasse.
Virtuel metode (eng. Virtual Method eller Virtual Function): En metode i en klasse, hvis binding
kan være dynamisk. Et kald til en virtuel funktion i en baseklasse vil i realiteten blive
omdirrigeret til en implementation af funktionen i en afledt klasse, såfremt objektet, den kaldes
for, er af en anden (afledt) type. I C++ findes desuden rene virtuelle metoder, som ikke har en
implementation.
Virtuel klasse (eng. Virtual Class) er en overordnet klasse i et multipel afledt objekt, som kun
forekommer én gang i forekomster af klassen skønt den findes to steder i klassens arvemateriale.
562 Fremtidsudsigter A.0

Bibliografi
[Aho 83] A.V. Aho, J.E. Hopcroft og J.D. Ullman: Data Structures and Algorithms.
Addison-Wesley, 1983.
[ANSI 89] ANSI: Standard for the Programming Language C, American National
Standards Institute 1989.
[Barnes 82] J.G.P. Barnes: Programming in Ada. Addison-Wesley, 1982.
[Berry 88] John Berry: C++ Programming. The Waite Group, 1988.
[Beck 89] Kent Beck og Ward Cunningham: A Laboratory for Teaching Object-
Oriented Thinking, i SIGPLAN Notices, oktober 1989.
[Booch 91] Grady Booch: Object-Oriented Design with Applications,
Benjamin/Cummings 1991.
[Coggins 89] James M. Coggins og Gregory Bollela: Managing C++ Libraries,
SIGPLAN Notices, juni 1989.
[Coplien 92] James O. Coplien: Advanced C++ Programming Styles and Idioms,
Addison-Wesley 1992.
[Dijkstra 68] Edsgar W. Dijkstra: Go To Statement Considered Harmful. i
Communications of the ACM, marts 1968.
[Ellis 90] Margaret A. Ellis og Bjarne Stroustrup: The Annotated C++ Reference
Manual. Addison-Wesley, 1990.
[Fisher 91] Charles N. Fischer og Richard J. LeBlanc, Jr.: Crafting a Compiler with
C. Benjamin/Cummings Publishing Company, 1991.
[Goldberg 83a] Adele Goldberg og David Robson: Smalltalk-80 The Language and Its
Implementation. Addison-Wesley, 1983.
[Goldberg 83b] Adele Goldberg: The Influence of an Object-Oriented Language on the
Programming Environment, i Proceedings of the 1983 ACM Computer
Science Conference, februar 1983, Florida.
A.3 Parameteriserede typer 563
E

[Gorlen 90] Keith E. Gorlen, Sanford M. Orlow og Perry S. Plexico: Data Abstraction
and Object-Oriented Programming in C++. John Wiley & Sons, 1990.
[Gorlen 87] Keith Gorlen: An Object-Oriented Class Library for C++ Programs.
Software Practice and Experience, december 1987.
[Horowitz 78] Ellis Horowitz og Sartaj Sahni: Fundamentals of Computer Algorithms.
Computer Science Press, 1978.
[Horowitz 84] Ellis Howrowitz and John Munson; An Expansive View of Reusable Software, i
IEEE Trans. on Software Engineering, 5. 1984.
[Johnson 88] Ralph Johnson og Brian Foote: Designing reusable classes in C++.
Journal of Object-Oriented Programming, juni/juli 1988.
[Kernighan 88] Brian W. Kernighan og Dennis M. Richie: The C Programming Language, 2.
edition. Prentice-Hall 1988 (ANSI C).
[Kirkpatrick 81] S. Kirkpatrick og E. Stoll: A Very Fast Shift-Register Random Number
Generator, i Journal of Computational Physics, 40, 1981.
[Kirslis 88] Peter A. Kirslis: A Style for Writing C++ Classes, AT&T, Denver,
Colorado 1988.
[Koenig 88] Andrew Koenig: An Example of Dynamic Binding in C++. Journal of
Object-Oriented Programming, august/september 1988.
[Koenig 89a] Andrew Koenig og Bjarne Stroustrup: Exception Handling for C++.
Proceedings of the C++ Conference, Massachusetts, november 1989.
[Koenig 89b] Andrew Koenig og Bjarne Stroustrup: C++: As Close as Possible to C -
But No Closer, i C++ Report, juli 1989.
[Ladd 90] Scott Robert Ladd: C++ Techniques and Applications. M&T Books
1990.
[Lippman 88] Stanley Lippman og Barbara Moo: C++: From Research to Practice.
Proceedings of the USENIX C++ Conference, Colorado, oktober 1988.
[Lippman 89] Stanley B. Lippman: C++ Primer. Addison-Wesley, 1989.
[Lippman 89b] Stanley B. Lippman: What is this? The C++ Report, marts 1989.
[Lippman 91] Stanley B. Lippman: C++ Primer, 2nd. edition, Addison-Wesley 1991.
[Liskov 88] Barbara Liskov: Data Abstraction and Hierarchy, i SIGPLAN Notices,
maj 1988.
[Meyer 88] Bertrand Meyer: Object-Oriented Software Construction. Prentice-Hall
1988.
[Pratt 85] Terrence W. Pratt: Programming Languages: Design and
Implementation, 2nd. edition. Prentice-Hall 1985.
[Russo 88] V. F. Russo og S. M. Kaplan: A C++ Interpreterfor Scheme, i
Proceedings of the C++ Workshop, oktober 1988.
[Sedgewick 88] Robert Sedgewick: Algorithms, 2nd. edition. Addison-Wesley 1988.
[Snyder 86] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
Programming Languages, i SIGPLAN Notices, november 1986.
[Strang 86] John Strang: Programming with Curses, Reilly & Associates 1986.
[Stroustrup 86a] Bjarne Stroustrup: The C++ Programming Language. Addison-Wesley
1986.
[Stroustrup 86b] Bjarne Stroustrup: Adding Classes to C: An Exercise in Language
564 Fremtidsudsigter A.0

Evolution. Software Practice & Experience, august 1986.
[Stroustrup 87a] Bjarne Stroustrup: Multiple Inheritance for C++. Proceedings of the
EUUG Conference, Helsinki, maj 1987.
[Stroustrup 87b] Bjarne Stroustrup: What Is Object-Oriented Programming? Proceedings
of the USENIX C++ Workshop, Santa Fe, november 1987.
[Stroustrup 87c] Bjarne Stroustrup: The Evolution of C++ 1985 to 1987. Proceedings of
the USENIX C++ Workshop, Santa Fa, november 1987.
[Stroustrup 87d] Bjarne Stroustrup: Type-safe Linkage for C++. Proceedings of the
USENIX C++ Workshop, Santa Fe, november 1987.
[Stroustrup 88] Bjarne Stroustrup: Parameterized Types for C++. Proceedings of the USENIX
C++ Conference, Colorado, oktober 1988.
[Stroustrup 91] Bjarne Stroustrup: The C++ Programming Language, 2nd. Edition, Addison-
Wesley 1991.
[Tracz 88a] William Tracz: Software Reuse: Emerging Technology, IEEE Computer
Society Press 1988.
[Tracz 88b] William Tracz: Software Reuse Myths, i ACM SIGSOFT (Software
Engineering Notes), januar 1988.
[Ungar 87] David Ungar og Randall Smith: Self: The Power of Simplicity, i
SIGPLAN Notices, december 1987.
[Whitehead 10] A. N. Whitehead og B. A. Russell: Principia Mathematica, Cambridge
University Press 1910.
[Wirth 76] Niklaus Wirth: Algorithms + Data Structures = Programs. Prentice-Hall
1976.
[Wirth 82] Niklaus Wirth: Programming in Modula-2. Springer-Verlag, 1982.
A.3 Parameteriserede typer 565

Kildetekst
// array.h
//
// specifikation på statisk allokeret klasse for gruppering
// af objekter.
//
// (c) 1991, 1992 Maz Spork
#if !defined _ARRAY_H
#define _ARRAY_H
#include "containr.h"
#include "genlist.h"
class Array : public Container,
public GenericArray {
public:
DECLARE_TRIVIAL_FUNCTIONS (Array)
Array (const unsigned long = DEFAULT_CAP);
Array (const Array&);
virtual ~Array ();
virtual void Insert (Object*);
virtual Object* Retrieve ();
virtual const Object* getCurrent () const;
virtual const Object* getFirst () const;
virtual const Object* getNext () const;
virtual const Object& operator[]
(const unsigned long) const;
virtual Array operator+ (const Array&);
virtual Object*& operator[] (const unsigned long);
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
};
#endif
566 Fremtidsudsigter A.0
F

assoc.h
//
// specifikation af en associations-klasse
//
// (c) 1991, Maz Spork
#if !defined _ASSOC_H
#define _ASSOC_H
#include "object.h"
class Association : public Object {
public:
Object* Key;
Object* Value;
DECLARE_TRIVIAL_FUNCTIONS (Association)
Association () : Key (0), Value (0) { }
Association (Object& a, Object& b)
: Key (&a), Value (&b) { }
Association (Association&);
virtual ~Association () { delete Key; delete Value; }
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
};
#endif
A.3 Parameteriserede typer 567

complex.h
//
// specifikation af en kompleks numerisk klasse
//
// (c) 1991, Maz Spork
#if !defined _COMPLEX_H
#define _COMPLEX_H
#include "sortable.h"
class Complex : public Sortable {
double re, im;
public:
DECLARE_TRIVIAL_FUNCTIONS (Complex)
Complex () : re (0), im (0) { }
Complex (const Complex& other)
: re (other.re), im (other.im) { };
Complex (const double& r, const double& i = 0)
: re (r), im (i) { }
virtual ~Complex () { }
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
virtual bool isGreater (const Sortable&) const;
friend double abs (const Complex&);
friend double norm (const Complex&);
friend double real (const Complex&);
friend double imag (const Complex&);
friend Complex operator+
(const Complex&, const Complex&);
friend Complex operator-
(const Complex&, const Complex&);
friend Complex operator*
(const Complex&, const Complex&);
friend Complex operator/
(const Complex&, const Complex&);
operator double () { return norm (*this); }
};
#endif
568 Fremtidsudsigter A.0

containr.h
//
// specification på abstrakt klasse for gruppering
// af objekter
//
// (c) 1991, Maz Spork
#if !defined _CONTAINR_H
#define _CONTAINR_H
#include "object.h"
#include "contbase.h"
const DEFAULT_CAP = 64; // underforstået størrelse
class Container : public Object,
public virtual ContainerBase {
friend Iterator;
protected:
Container (unsigned long size = 0)
: ContainerBase (size) { }
Container (const Container& other)
: ContainerBase (other), Object (other) { }
public:
virtual ~Container () { }
virtual void Insert (Object*) = 0;
virtual Object* Retrieve () = 0;
virtual unsigned Size () const {
return ContainerBase::elementCount;
}
virtual Container& operator+= (const Container&);
virtual const Object& operator[]
(const unsigned long) const = 0;
virtual const Object* getFirst () const = 0;
virtual const Object* getNext () const = 0;
virtual const Object* getCurrent () const = 0;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
};
#endif
A.3 Parameteriserede typer 569

contbase.h
//
// baseklasse for alle containere af alle typer
//
// (c) 1992, Maz Spork
#if !defined (_CONTBASE_H)
#define _CONTBASE_H
class ContainerBase {
protected:
unsigned long elementCount; // størrelse på container
unsigned long currentIndex; // aktuelt index i container
ContainerBase (unsigned long size)
: elementCount (size), currentIndex (0) { }
ContainerBase ()
: elementCount (0), currentIndex (0) { }
ContainerBase (const ContainerBase& other)
: elementCount (other.elementCount), currentIndex (0) {}
};
#endif
570 Fremtidsudsigter A.0

dequeue.h
//
// implementation af en generel dobbelthægtet kø
//
// (c) 1991, Maz Spork
#if !defined _DEQUEUE_H
#define _DEQUEUE_H
#include "queue.h"
class DeQueue : public Queue {
public:
DECLARE_TRIVIAL_FUNCTIONS (DeQueue)
DeQueue () : Queue () { };
DeQueue (DeQueue& q) : Queue (q) { };
virtual void insertFront (Object* o) { Insert (o); }
virtual Object* retrieveBack () { return Retrieve (); }
};
#endif
A.3 Parameteriserede typer 571

dict.h
//
// specifikation af en katalog-klasse
//
// (c) 1991, Maz Spork
#if !defined _DICT_H
#define _DICT_H
#include "linklist.h"
#include "assoc.h"
class Dictionary : public LinkedList {
public:
DECLARE_TRIVIAL_FUNCTIONS (Dictionary)
Dictionary () : LinkedList () { }
Dictionary (Dictionary& from) : LinkedList (from) { }
virtual void addAssociation (Object&, Object&);
virtual Object* getAssociation (Object&);
};
#endif
572 Fremtidsudsigter A.0

dstring.h
//
// specification på en streng-klasse
//
// (c) 1991, Maz Spork
#if !defined _STRING_H
#define _STRING_H
#include "sortable.h"
class String : public Sortable {
protected:
char* sptr;
unsigned len;
public:
DECLARE_TRIVIAL_FUNCTIONS (String)
String () : sptr (NULL), len (0) { }
String (const char*);
String (const String&);
virtual ~String ();
virtual bool isGreater (const Sortable&) const;
virtual bool isEqual (const Object&) const;
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
String& operator= (const String&);
operator const char* const () const { return sptr; }
unsigned Length () const { return len; }
bool operator () (const String) const;
String toLower () const;
String toUpper () const;
void Set (const char);
friend String operator+ (const String&, const String&);
};
#endif
A.3 Parameteriserede typer 573

genlist.h
//
// specifikation på
// en generisk hægtet liste, implementeret som skabelon,
// og en generisk lineær liste, implementeret som
// skabelon.
//
// (c) 1992, Maz Spork
#include "contbase.h"
template
class GenericList : public virtual ContainerBase {
public:
struct GenericNode { // privat struktur
GenericNode* next;
Element* objptr;
GenericNode (Element* obj)
: objptr (obj), next (0) { }
};
protected:
GenericNode* head;
GenericNode* cursor; // aktuel hægte
GenericNode* trail; // følger cursor
GenericNode* tail;
void insertAt (Element*, GenericNode*);
GenericList ()
: head (0), cursor (0), trail (0), tail (0) { }
~GenericList ();
void Insert (Element*);
Element* Retrieve ();
Element* getCurrent () const {
return cursor->objptr;
}
Element* getFirst () {
trail = 0, cursor = head, currentIndex = 0;
return cursor->objptr;
}
Element* getNext () {
if (!cursor || !cursor->next) return 0;
trail = cursor,
cursor = cursor->next, currentIndex++;
return cursor->objptr;
}
574 Fremtidsudsigter A.0

};
template
class GenericArray : public virtual ContainerBase {
protected:
Element** rep;
GenericArray (const unsigned long);
~GenericArray ();
const Element* getCurrent () const {
return rep [currentIndex];
}
const Element* getFirst () {
return rep [currentIndex = 0];
}
const Element* getNext () {
return rep [++currentIndex];
}
};
// prototype nødvendig for følgende typedef's
class Object;
// anvendelige navne for parametiserede typer
typedef GenericList ObjList;
typedef GenericList::GenericNode ObjNode;
// destruktør for generisk liste, fjerner hægter og
// objekter
template
GenericList::~GenericList () {
for (GenericNode* p = head; p;) {
GenericNode* temp = p;
p = p->next;
delete temp->objptr;
delete temp;
}
}
// indsæt element i listen på given hægteposition
template // protected medlemsfunktion
void GenericList::insertAt (
Element* elem, GenericNode* pos) {
ObjNode* temp = cursor;
cursor = pos; // præservér aktuel position
A.3 Parameteriserede typer 575

}
Insert (elem);
cursor = temp;
// indsæt hægte i listen på "aktuel" cursorposision
template
void GenericList::Insert (Element* elem) {
ContainerBase::elementCount++;
GenericNode* newNode = new GenericNode (elem);
if (head) {
if (cursor)
newNode->next = cursor->next,
cursor->next = newNode,
cursor = newNode;
else
newNode->next = head, head = cursor = newNode;
}
else
cursor = head = newNode, trail = 0;
if (!newNode->next) tail = newNode;
}
// hent fra listen på "aktuel" cursorposition
template
Element* GenericList::Retrieve () {
if (!cursor) return &nil;
elementCount--;
if (trail)
trail->next = cursor->next; // opdater listen
else head = cursor->next;
Element* elem = cursor->objptr;
delete cursor;
cursor = trail ? trail->next : head;
return elem;
}
// medlemsfunktioner i generisk lineær liste
// konstruktør, allokerer et pointerarray
// de individuelle elementer allokeres eller tildeles
// af subklasserne
template
GenericArray::GenericArray
(const unsigned long size)
576 Fremtidsudsigter A.0

: ContainerBase (size) {
rep = new Element* [size];
}
// destruktør, deallokerer array'et
template
GenericArray::~GenericArray () {
delete rep;
}
A.3 Parameteriserede typer 577

iterator.h
//
// specifikation på en klasse til gennemløb af container
//
// (c) 1991, Maz Spork
#if !defined _ITERATOR_H
#define _ITERATOR_H
#include "containr.h"
class Iterator : public Object {
Container* ref;
unsigned long index;
public:
DECLARE_TRIVIAL_FUNCTIONS (Iterator)
Iterator () : index (0), ref (NULL) { }
Iterator (const Iterator& i)
: ref (i.ref), index (i.index) { }
Iterator (Container& c) : ref (&c), index (0) { }
virtual ~Iterator () { }
virtual bool isEqual (const Object&) const;
virtual void printOn (ostream& = cout) const;
const Object& operator* ();
Iterator& operator= (const Iterator&);
Iterator& operator= (Container&);
Iterator& operator= (const unsigned long);
Iterator& operator++ (int); // prefix
Iterator& operator++ (); // postfix
operator bool ();
bool More ();
};
#endif
578 Fremtidsudsigter A.0

linklist.h
//
// specification på en hægtet liste-klasse
//
// (c) 1991, 1992 Maz Spork
#if !defined _LINKLIST_H
#define _LINKLIST_H
#include "genlist.h"
#include "containr.h"
class LinkedList : public GenericList,
public Container {
public:
DECLARE_TRIVIAL_FUNCTIONS (LinkedList)
LinkedList () : GenericList (), Container () { }
LinkedList (const LinkedList&);
LinkedList& operator= (const LinkedList&);
virtual LinkedList operator+ (const LinkedList&);
virtual ~LinkedList () { };
virtual void printOn (ostream& = cout) const;
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isEqual (const Object&) const;
virtual void Insert (Object*);
virtual Object* Retrieve ();
virtual const Object* getCurrent () const {
Object* o = GenericList::getCurrent ();
return o ? o : &nil;
}
virtual const Object* getFirst () const {
Object* o = GenericList::getFirst ();
return o ? o : &nil;
}
virtual const Object* getNext () const {
Object* o = GenericList::getNext ();
return o ? o : &nil;
}
virtual void goTo (const unsigned long);
virtual const Object& operator[] (unsigned long) const;
virtual const unsigned long Locate(const Object&) const;
virtual const Object* Locate(const unsigned long) const;
};
A.3 Parameteriserede typer 579

#endif
580 Fremtidsudsigter A.0

object.h
//
// specifikaion af rod-klassen Object, fejl-klassen Nil
// samt I/O-klassen ObjectManager
//
// (c) 1991, Maz Spork
#if !defined _OBJECT_H
#define _OBJECT_H
#include
// fremad-referencer til de fire klasser i denne fil
class Nil;
class Object;
class classInfo;
class ObjectManager;
// anvendelige navne for afledte typer
typedef int bool; // boolsk værdi
typedef Object* (*PTOM) (); // pointer til funktion
const TRUE = 1;
const FALSE = 0;
// klassebeskrivelser for ikke-abstrakte klasser
enum Class {
aNil, // fejl-objekt
aLinkedList, // hægtet liste
aSortedList, // sorteret hægtet liste
aStack, // stak (først-ind-sidst-ud-buff)
aQueue, // kø (først-ind-først-ud-buffer)
aDeQueue, // dobbelt-endt kø
aArray, // en lineær liste
aComplex, // komplekst tal
aString, // streng
aIterator, // gennemløb af containere
aAssociation, // en association mellem to obj
aDictionary, // et katalog over associationer
};
// statisk klasse til definition af ind- og udlæselige
// objekter
class ObjectManager {
A.3 Parameteriserede typer 581

static classInfo* classList;
public:
~ObjectManager ();
static Object* readPolymorphicObject (istream& = cin);
static bool Announce (char*, PTOM);
};
// rod-objektet for alle klasser
class Object {
protected:
Object () { };
Object (const Object&) { };
public:
virtual ~Object () { };
virtual void printOn (ostream& = cout) const = 0;
virtual void readFrom (istream& = cin);
virtual void dumpOn (ostream& = cout) const;
virtual bool isEqual (const Object&) const = 0;
virtual Class Type () const = 0;
virtual Object& Copy () const = 0;
virtual const char* Name () const = 0;
};
// det "tomme" objekt - bruges i fejl og termineringer (kun
// én forekomst)
extern Nil nil;
// fejl-klasse: bruges til identifikation af ulovligt
// objekt
class Nil : public Object {
public:
Nil () { }
virtual ~Nil () { }
virtual void printOn (ostream& strm = cout) const {
strm > ws;
}
virtual bool isEqual (const Object& o) const {
return bool (&o);
}
virtual Class Type () const { return aNil; }
virtual Object& Copy () const { return nil; }
582 Fremtidsudsigter A.0

virtual const char* Name () const { return "Nil"; }
};
// globale metoder til sammenligning af objekter
bool operator== (const Object&, const Object&);
bool operator!= (const Object&, const Object&);
// globale metoder til udskrivning og indlæsning af
// objektindhold
ostream& operator> (istream&, const Object&);
// makro til registrering af klasser med I/O-kapabilitet
#define DECLARE_AS_STOREABLE(CLASS) \
static Object* Create ## CLASS () { \
return new CLASS; \
} \
static bool init ## CLASS = ObjectManager::Announce ( \
#CLASS, Create ## CLASS \
);
// makro til erklæring/implementation af trivielle
// medlemsfunktioner
#define DECLARE_TRIVIAL_FUNCTIONS(CLASS) \
virtual Class Type () const; \
virtual Object& Copy () const; \
virtual const char* Name () const;
// makro til implementation af trivielle medlemsfunktioner
#define DEFINE_TRIVIAL_FUNCTIONS(CLASS) \
Class CLASS ## ::Type () const { \
return a ## CLASS; \
} \
Object& CLASS ## ::Copy () const { \
return *new CLASS (*this); } \
const char* CLASS ## ::Name () const { \
return #CLASS ; \
}
#endif
A.3 Parameteriserede typer 583

queue.h
//
// specifikation af en generel enkelthægtet kø
//
// (c) 1991, Maz Spork
#if !defined _QUEUE_H
#define _QUEUE_H
#include "linklist.h"
class Queue : public LinkedList {
public:
DECLARE_TRIVIAL_FUNCTIONS (Queue)
Queue () : LinkedList () { };
Queue (Queue& q) : LinkedList (q) { };
virtual void insertBack (Object* o) {
LinkedList::Insert (o);
}
virtual Object* retrieveFront () {
return Retrieve ();
}
};
#endif
584 Fremtidsudsigter A.0

shared.h
//
// specifikation af deleligt objekt mellem flere
// containerklasser
//
// (c) 1991, Maz Spork
#if !defined _SHARED_H
#define _SHARED_H
#include "object.h"
// et "delt" objekt, opnået gennem delegering og filtrering
// af destruktør
class SharedObject : public Object {
Object* ref;
public:
SharedObject (Object* o) : ref (o) { }
SharedObject (Object& o) : ref (&o) { }
virtual ~SharedObject () { }
virtual void printOn (ostream& s = cout) const {
ref->printOn (s);
}
virtual void readFrom (istream& s = cin) {
ref->readFrom (s);
}
virtual void dumpOn (ostream& s = cout) const {
ref->dumpOn (s);
}
virtual bool isEqual (const Object& o) const {
return ref->isEqual (o);
}
virtual Class Type () const { return ref->Type (); }
virtual Object& Copy () const { return ref->Copy (); }
virtual const char* Name () const {
return ref->Name ();
}
};
#endif
A.3 Parameteriserede typer 585

sortable.h
//
// specifikation på et sortérbart objekt
//
// (c) 1991, Maz Spork
#if !defined _SORTABLE_H
#define _SORTABLE_H
#include "object.h"
class Sortable : public Object {
public:
virtual void dumpOn (ostream& = cout) const;
virtual void readFrom (istream& = cin);
virtual bool isGreater (const Sortable&) const = 0;
};
bool operator> (const Sortable&, const Sortable&);
bool operator< (const Sortable&, const Sortable&);
bool operator>=(const Sortable&, const Sortable&);
bool operator

sortlist.h
//
// specifikation på en sorteret liste
//
// (c) 1991, Maz Spork
#if !defined _SORTLIST_H
#define _SORTLIST_H
#include "linklist.h"
#include "sortable.h"
class SortedList : public LinkedList {
public:
enum SortOrder { // indlejret opremsning
AscendingOrder, DescendingOrder, randomOrder
};
private:
SortOrder order;
public:
DECLARE_TRIVIAL_FUNCTIONS (SortedList)
SortedList (SortOrder o = AscendingOrder)
: order (o) { }
SortedList (SortedList& o)
: LinkedList (o), order (o.order) { }
virtual void Insert (Object*);
};
#endif
A.3 Parameteriserede typer 587

stack.h
//
// specifikation på en generel stak (FILO-buffer)
//
// (c) 1991, Maz Spork
#if !defined _STACK_H
#define _STACK_H
#include "linklist.h"
class Stack : public LinkedList {
public:
DECLARE_TRIVIAL_FUNCTIONS (Stack)
Stack () : LinkedList () { };
Stack (Stack& s) : LinkedList (s) { };
void Push (Object* o) { insertAt (o, NULL); }
Object* Pop () { cursor = head; return Retrieve (); }
virtual void Insert (Object* o) { insertAt (o, head); }
};
#endif
588 Fremtidsudsigter A.0

array.cpp
//
// implementation af statisk allokeret klasse for
// gruppering af objekter.
// Array-klassen indeholder pointere til objekter.
//
// (c) 1991, 1992 Maz Spork
#include "array.h"
DECLARE_AS_STOREABLE (Array)
DEFINE_TRIVIAL_FUNCTIONS (Array)
// konstruér en Array med fast størrelse, angivet som
// tvungen parameter
Array::Array (const unsigned long size)
: Container (size), GenericArray (size) {
elementCount = size;
for (unsigned long i = 0; i < elementCount; i++)
rep [i] = &nil;
}
// kopi-konstrutør: Array til Array
Array::Array (const Array& other)
: Container (other),
GenericArray (other.elementCount) {
for (unsigned i = 0; i < elementCount; i++)
rep [i] = &(other.rep [i]->Copy ());
currentIndex = 0;
}
// læg to Array-objekter sammen
Array Array::operator+ (const Array& other) {
Array ret = *this;
ret += other;
return ret;
}
// destruér Array, deallokerer alle objekter ikke lig nil
Array::~Array () {
for (unsigned i = 0; i < elementCount; i++)
if (*rep [i] != nil) delete rep [i];
}
A.3 Parameteriserede typer 589

indsæt et objekt i et Array på en (eventuelt
/// uspecificeret) position
void Array::Insert (Object* o) {
if (*rep [currentIndex] != nil)
delete rep [currentIndex];
rep [currentIndex] = o;
}
// fjern et objekt fra et Array, klienten har nu objektet
Object* Array::Retrieve () {
if (currentIndex >= elementCount) {
cerr = elementCount) return &nil;
return GenericArray::getCurrent ();
}
// næste objekt
const Object* Array::getNext () const {
if (currentIndex + 1 >= elementCount) return &nil;
return GenericArray::getNext ();
}
// første objekt
const Object* Array::getFirst () const {
if (!elementCount) return &nil;
return GenericArray::getFirst ();
}
// bedre syntaks for getCurrent, returnerer konstant
// pointer
const Object& Array::operator[]
(const unsigned long pos) const {
if (pos < elementCount) return *rep [pos];
cerr

eturn nil;
}
// anden version, returnerer reference til pointer, kan
// bruges som lvalue
Object*& Array::operator[] (const unsigned long pos) {
if (pos < elementCount) return rep [pos];
cerr

assoc.cpp
//
// implementation af en associations-klasse
//
// (c) 1991, Maz Spork
#include "assoc.h"
DECLARE_AS_STOREABLE (Association)
DEFINE_TRIVIAL_FUNCTIONS (Association)
// opret association fra anden association
Association::Association (Association& from) {
Key = &from.Key->Copy ();
Value = &from.Value->Copy ();
}
// sammenlign to associationer
bool Association::isEqual (const Object& other) const {
return ((Association&)other).Key == Key &&
((Association&)other).Value == Value;
}
// udskriv en association
void Association::printOn (ostream& strm) const {
strm dumpOn (strm);
}
// indlæs en association
void Association::readFrom (istream& strm) {
Object::readFrom (strm);
Key = ObjectManager::readPolymorphicObject (strm);
Value = ObjectManager::readPolymorphicObject (strm);
}
592 Fremtidsudsigter A.0

complex.cpp
//
// implementation af en kompleks numerisk klasse
//
// (c) 1991, Maz Spork
#include // matematiske funktioner & konstanter
#include "complex.h"
DECLARE_AS_STOREABLE (Complex)
DEFINE_TRIVIAL_FUNCTIONS (Complex)
// abs() er en friend-funktion for at tillade bedre syntaks
double abs (const Complex& c) {
return sqrt (norm (c));
}
// norm er en friend-funktion for at tillade bedre syntaks
double norm (const Complex& c) {
return c.re * c.re + c.im * c.im;
}
// returnér reel del af det komplekse tal (friend-funktion)
double real (const Complex& c) {
return c.re;
}
// returnér imaginær del af det komplekse tal
// (friend-funktion)
double imag (const Complex& c) {
return c.im;
}
// sammenlign to komplekse tal for størrelsesforhold
bool Complex::isGreater (const Sortable& o) const {
Complex& other = (Complex&) o;
return abs (*this) > abs (other);
}
// sammenlign to komplekse tal for lighed
bool Complex::isEqual (const Object& other) const {
return ((Complex&)other).re == re &&
((Complex&)other).im == im;
}
A.3 Parameteriserede typer 593

følgende fire udfører addition, subtraktion,
// multiplikation og division
Complex operator+ (const Complex& c1, const Complex& c2) {
return Complex (c1.re + c2.re, c1.im + c2.im);
}
Complex operator- (const Complex& c1, const Complex& c2) {
return Complex (c1.re - c2.re, c1.im - c2.im);
}
Complex operator* (const Complex& c1, const Complex& c2) {
return Complex (
c1.re * c2.re - c1.im * c2.im,
c1.re * c2.im + c1.im * c2.re
);
}
Complex operator/ (const Complex& c1, const Complex& c2) {
return Complex (
(c1.re * c2.re + c1.im * c2.im) / norm (c2),
(c1.im * c2.re - c1.re * c2.im) / norm (c2)
);
}
// udskriv et komplekst tal
void Complex::printOn (ostream& strm) const {
strm

containr.cpp
//
// implementation af abstrakt klasse for gruppering af
// objekter
//
// (c) 1991, 1992 Maz Spork
#include "containr.h"
// metode til at lægge to containere sammen
Container& Container::operator+= (const Container& other) {
for (const Object* o = other.getFirst ();
*o != nil; o = other.getNext ()) {
Insert (&o->Copy ());
currentIndex++;
}
return *this;
}
// metode til at udlæse en container - udlæser blot tæller
void Container::dumpOn (ostream& strm) const {
Object::dumpOn (strm);
strm elementCount;
}
A.3 Parameteriserede typer 595

dequeue.cpp
//
// specifikation på en generel dobbelt kø (med hul i
// begge ender)
//
// (c) 1991, Maz Spork
#include "dequeue.h"
DECLARE_AS_STOREABLE (DeQueue)
DEFINE_TRIVIAL_FUNCTIONS (DeQueue)
596 Fremtidsudsigter A.0

dict.cpp
//
// implementation af en katalog-klasse, indeholdende
// associationer
// mellem objekter.
//
// (c) 1991, Maz Spork
#include "dict.h"
DECLARE_AS_STOREABLE (Dictionary)
DEFINE_TRIVIAL_FUNCTIONS (Dictionary)
// tilføj en association: et opslagsobjekt og
// en associeret værdi
void Dictionary::addAssociation (Object& a, Object& b) {
Insert (new Association (a, b));
}
// find en association til en given nøgle
Object* Dictionary::getAssociation (Object& searchKey) {
for (ObjNode* n = head; n; n = n->next) // lineært!
if (*((Association*) n->objptr)->Key == searchKey)
return ((Association*) n->objptr)->Value;
return &nil;
}
A.3 Parameteriserede typer 597

dstring.cpp
//
// implementation af an dynamisk strengklasse
//
// (c) 1991, Maz Spork
#include // strengmanipulationer
#include // is...(), to...() osv.
#include "dstring.h"
DECLARE_AS_STOREABLE (String)
DEFINE_TRIVIAL_FUNCTIONS (String)
// opret en String fra C-streng
String::String (const char* s) {
if (s && *s) {
len = strlen (s);
sptr = new char [len + 1];
strcpy (sptr, s);
}
else sptr = NULL, len = 0;
}
// opret en String fra anden String
String::String (const String& other) : len (other.len) {
sptr = new char [len + 1];
strcpy (sptr, other.sptr);
}
// dealloker en String
String::~String () {
if (len) delete sptr;
}
// sammenlign to strenge for størrelse
bool String::isGreater (const Sortable& o) const {
String& other = (String&) o;
return strcmp (sptr, other.sptr) > 0;
}
// sammenlign to strenge for lighed (*helt* ens)
bool String::isEqual (const Object& o) const {
String& other = (String&) o;
return len == other.len && !strcmp (sptr, other.sptr);
598 Fremtidsudsigter A.0

}
// udskriv en String
void String::printOn (ostream& strm) const {
strm

String String::toUpper () const {
String temp = *this;
strupr (temp.sptr);
return temp;
}
// konvertér til små bogstaver
String String::toLower () const {
String temp = *this;
strlwr (temp.sptr);
return temp;
}
// søg efter substreng (fx. "CD" i "ABCDEF")
bool String::operator () (const String searchFor) const {
return strstr (sptr, searchFor) != NULL;
}
// sæt alle tegn i strengen til bestemt værdi
void String::Set (const char c) {
strnset (sptr, c, len);
}
600 Fremtidsudsigter A.0

iterator.cpp
//
// implementation af en klasse til gennemløb af container
//
// (c) 1991, 1992 Maz Spork
#include "iterator.h"
// metode til optælling af et gennemløbs-objekt (postfix)
Iterator& Iterator::operator++ () {
ref->getNext ();
return *this;
}
// metode til optælling af et gennemløbs-objekt (pretfix)
Iterator& Iterator::operator++ (int) {
ref->getNext ();
return *this;
}
// returnér det aktuelle objekt, som gennemløberen peger på
const Object& Iterator::operator* () {
return *ref->getCurrent ();
}
// returnér en sandhedsværdi afhængig af, om enden er nået
bool Iterator::More () {
return index < ref->Size ();
}
// samme som forrige, men bedre syntaks
Iterator::operator bool () {
return More ();
}
// sammenlign to gennemløbere
bool Iterator::isEqual (const Object& other) const {
return index == ((Iterator&) other).index
&& ref == ((Iterator&) other).ref;
}
// udskriv en gennemløber på den aktuelle position
void Iterator::printOn (ostream& strm) const {
strm operator[] (index)
A.3 Parameteriserede typer 601

}

linklist.cpp
//
// implementation af en hægtet liste klasse
//
// (c) 1991, Maz Spork
#include "linklist.h"
DECLARE_AS_STOREABLE (LinkedList)
DEFINE_TRIVIAL_FUNCTIONS (LinkedList)
// at finde en hægte ved lineær traversering af listen
const Object* LinkedList::Locate
(const unsigned long index) const {
unsigned long i = index;
for (ObjNode* c = head; i-- && c; c = c->next);
return c ? c->objptr : &nil;
}
// læg to LinkedList'er sammen
LinkedList LinkedList::operator+
(const LinkedList& other) {
LinkedList ret = *this;
ret += other;
return ret;
}
// find indekset på en specifik hægte ved en nøgle
const unsigned long LinkedList::Locate
(const Object& toFind) const {
unsigned long i = 0;
for (ObjNode* c = head;
*c->objptr != toFind && c;
c = c->next)
i++;
return i;
}
// gå til hægte nr og lad dette være den aktuelle
void LinkedList::goTo (const unsigned long index) {
unsigned long i = index;
for (ObjNode* c = head; i-- && c; c = c->next);
cursor = c ? c : head;
}
A.3 Parameteriserede typer 603

kopi-konstruktør, genererer en reel kopi af
// eksisterende liste
LinkedList::LinkedList (const LinkedList& from)
: Container (from), GenericList () {
for (ObjNode* c = from.head; c; c = c->next)
Insert (&c->objptr->Copy ());
getFirst (); // nulstil ny liste
}
// tildeling af anden liste
LinkedList& LinkedList::operator=
(const LinkedList& from) {
ObjNode* temp, * cursor = head;
while (cursor) {
temp = cursor->next;
delete cursor->objptr;
delete cursor;
cursor = temp;
}
for (cursor = from.head; cursor; cursor = cursor->next)
Insert (&cursor->objptr->Copy ());
getFirst ();
return *this;
}
// indsættelse af et objekt på listen
void LinkedList::Insert (Object* o) {
GenericList::Insert (o);
}
// at fjerne et objekt på listen
Object* LinkedList::Retrieve () {
if (!Size ()) return &nil;
return GenericList::Retrieve ();
}
// indekseret reference i listen, relativt index
// fra første element
const Object& LinkedList::operator[]
(const unsigned long index) const {
604 Fremtidsudsigter A.0

if (head == NULL || index >= elementCount) return nil;
return *Locate (index);
}
// sammenligning af to lister
bool LinkedList::isEqual (const Object& o) const {
bool result;
for (ObjNode* p = head, *q = ((LinkedList&) o).head; p;
p = p->next, q = q->next)
if (*p->objptr != *q->objptr) return 0;
return 1;
}
// udskrivning af liste på strøm
void LinkedList::printOn (ostream& strm) const {
for (ObjNode* p = head; p; p = p->next)
strm objptr next)
p->objptr->dumpOn (strm);
}
// indlæs en hægtet liste
void LinkedList::readFrom (istream& strm) {
Container::readFrom (strm);
int i = elementCount;
for (elementCount = 0; i; i--)
Insert (ObjectManager::readPolymorphicObject (strm));
}
A.3 Parameteriserede typer 605

object.cpp
//
// implementation af rod-klassen Object, fejl-klassen Nil
// og I/O-klassen ObjectManager.
//
// (c) 1991, Maz Spork
#include "object.h"
#include "string.h"
// initiér statiske data i ObjectManager. Tabellen
// createAddress indeholder adresser på funktioner, som
// explicit allokerer objekter af forskellige typer, og
// returnerer en polymorf reference. Det tillader
// ObjectManger at allokere objekter på basis af en
// klasseidentifikation, og derefter kalde
// indlæsningsmetoder i det pågældende objekt.
classInfo* ObjectManager::classList = NULL;
// følgende erklæring sikrer ordentlig oprydning i globale
// data
static ObjectManager cleanup;
// det globale nil-objekt (det 'tomme' objekt)
Nil nil;
// Annoncer nil-objektet som "gennemsigtigt" udlæseligt
static Object* CreateNil () { return &nil; }
static bool initNil = ObjectManager::Announce
("Nil", CreateNil);
// privat klasse til administration af eksplicit allokering
// af objekter
class classInfo {
friend ObjectManager; // bruges kun herfra !
char* Name; // klassens navn
PTOM allocFunc; // klassens allokator
classInfo* next; // næste klasse...
classInfo (char* s, PTOM f, classInfo* n)
: Name (s), allocFunc (f), next (n) { }
};
606 Fremtidsudsigter A.0

udlæsning af et objekt gennem en ostream (uden
// typeinformation)
ostream& operator> (istream& strm, Object& obj) {
obj.readFrom (strm);
return strm;
}
// udlæsning af et objekt genne en ostream (med
// typeinformation)
void Object::dumpOn (ostream& strm) const {
strm

classList = new classInfo
(className, pointer, classList);
return 1;
}
// læs et objekt fra en istream (statisk metode)
Object* ObjectManager::readPolymorphicObject
(istream& strm) {
char className [0x20];
strm >> className;
for (classInfo* c = classList; c; c = c->next)
if (!strcmp (c->Name, className)) break;
if (!c) return &nil;
Object* empty = (c->allocFunc) ();
empty->readFrom (strm);
return empty;
}
// dealloker alle objekter, der blev allokeret med
// statiske "annonceringer"
ObjectManager::~ObjectManager () {
classInfo* cursor = classList;
while (cursor) {
classInfo* temp = cursor;
cursor = cursor->next;
delete temp;
}
}
608 Fremtidsudsigter A.0

queue.cpp
//
// implementation af en generel enkelthægtet kø
//
// (c) 1991, Maz Spork
#include "queue.h"
DECLARE_AS_STOREABLE (Queue)
DEFINE_TRIVIAL_FUNCTIONS (Queue)
A.3 Parameteriserede typer 609

shared.cpp
//
// implementation af deleligt objekt mellem
// containerklasser
//
// (c) 1991, Maz Spork
#include "shared.h"
610 Fremtidsudsigter A.0

sortable.cpp
//
// implementation af abstrakt sortérbart objekt
//
// (c) 1991, Maz Spork
#include "sortable.h"
// kald den virtuelle isGreater()-metode for at undersøge
// forholdet
bool operator> (const Sortable& a, const Sortable& b) {
return a.isGreater (b);
}
// mindre end er det samme som ej større end og ej ens
bool operator< (const Sortable& a, const Sortable& b) {
return ! (a.isGreater (b) || a.isEqual (b));
}
// større end eller lig med (lige ud ad landevejen)
bool operator>= (const Sortable& a, const Sortable& b) {
return a.isGreater (b) || a.isEqual (b);
}
// mindre end eller lig med er det samme som ej større end
bool operator

sortlist.cpp
//
// implementation af en sorteret liste
//
// (c) 1991, Maz Spork
#include "sortlist.h"
DECLARE_AS_STOREABLE (SortedList)
DEFINE_TRIVIAL_FUNCTIONS (SortedList)
// indsæt objekt i listen på den rette plads
// afhængig af sortering
void SortedList::Insert (Object* obj) {
ObjNode* a = head, *b = 0; // after og before
if (order == AscendingOrder)
while (a && *(Sortable*) obj >
*(Sortable*) a->objptr)
b = a, a = a->next;
else // == DescendingOrder
while (a && *(Sortable*) obj <
*(Sortable*) a->objptr)
b = a, a = a->next;
insertAt (obj, b);
}
612 Fremtidsudsigter A.0

stack.cpp
//
// implementation af en generel stak
//
// (c) 1991, Maz Spork
#include "stack.h"
DECLARE_AS_STOREABLE (Stack)
DEFINE_TRIVIAL_FUNCTIONS (Stack)
A.3 Parameteriserede typer 613

# makefile-eksempel for XCL.
# lib er dit biblioteksprogram, cc er din oversætter.
# -c betyder: oversæt uden at lænke.
xcl.lib: array.obj assoc.obj complex.obj containr.obj \
contbase.obj dequeue.obj dict.obj dstring.obj \
iterator.obj linklist.obj object.obj shared.obj \
sortable.obj sortlist.obj stack.obj queue.obj
.cpp.obj:
lib xcl +array +assoc +complex +containr \
+contbase +dequeue +dict +dstring \
+iterator +linklist +object +shared \
+sortable +sortlist +stack +queue
cc -c {$

Stikordsregister
, 112
, 110
, 27
, 246
, 61
, 237
, 62
#define, 16, 85
#elif, 88
#else, 16, 88
#endif, 88
#error, 89
#if, 16, 88
#ifdef, 88
#ifndef, 88
#include, 84
A
Abstrakte
datatyper design af, 226
datatyper anvendelser for, 247
datatyper, 16
klasser, 337
datatyper og fejlbehandling, 234
Abstraktion
af data, 4
funktionel, 3
Abstraktionsmekanismer, 473
Abstraktionsniveauer, 117
Actor, 599
Ada, 14, 118, 134
A.3 Parameteriserede typer 615

Addition, 39
Adgang, 135
Adgangskontrol, 416
Administrative metoder, 411
Adresse, 28, 90
effektiv, 93
Adresserum, 91
ADT, 16
Afhængighed af implementationen, 134
Afstand, 19
Aggregate klasser, 466
Algol, 7
Algoritmers transparens, 439
Alias, 55
Allokering, 82
af vektor, 83
Analyse, 182, 183
af domæne, 471
Anonyme
datastrukturer, 73
klasser, 142
ANSI C++, ii, 7, 573
ANSI C, 7, 51, 106
Anvendelser for ADT'er, 247
Applikation, 3
Applikationsdomæne, 472
Aritmetisk if/else, 46
Aritmetiske operatorer, 39
Arv, 267, 286
og lageradministration, 445
og genbrug, 476
problemer med, 316
rationale, 396
og tvetydigheder, 301
Arvesystemer, 268
ASCII, 27
ASCIIZ, 94
AssocArray, 250
Associativ liste, 250
Associativitet, 47
Attributter, 390
auto, 81
Automatiske variable, 81
616 Introduktion 1

B
BCPL, 19
Bearbejdende metoder, 412
Beskyttelse, 134
Bestandige objekter, 456
Bestandighed, 455
administration af, 460
implementation af, 457
Betinget oversættelse, 16, 88
Bibliografi, 607
Biblioteker, 119
Big-endian, 22
Bindingstidspunkter, 321
Bitfelter, 72
Bitvis kopiering, 169, 190
Bitvise operatorer, 40
break, 67
Brugerdefineret
manipulatorer, 506
lageradministration, 237
typekonvertering, 204
Burns, Robert 228
C
C, 134
vs.C++, 583
løsning med, 123
ANSI, 7
Call-by-explicit-reference, 57
Call-by-implicit-reference, 57
Call-by-reference, 53, 107
Call-by-value, 53, 54, 107
case, 68
catch, 574
cerr, 111
cfront, 13
char, 26
cin, 111, 492
class, 136
clog, 111
1.6 Organiseringen af denne bog 617

Cobol, 175, 246
CommonView, 468
Containere gennemløb af, 454
Containerklasser, 448
continue, 67
cout, 111, 490
Crash, 83
CustMemMgr, 446
D
Dangling pointer, 83
Data hiding, 119
Datastrukturer, 70
med pointermedlem, 101
fremad-referencer, 78
indlejrede, 74
anonyme, 73
polymorfe, 333
transparens, 439
Datatyper
abstrakte, 16
fundamentale,16
Dataabstraktion definition, 4
Deallokering af vektorer, 175
default, 70
Dekomposition, 425
Delegering, 407, 473
delete, 82
Delhierarkier, 349
Delte objekter, 445
Dereference, 90
og pointere, 91
af pointer, 55
af medlemsdata, 79
Design
af abstrakte datatyper, 226
balance, 473
kompositorisk, 402
Destruktion af afledte objekter, 307
Destruktør, 164
statiske, 172
618 Introduktion 1

i afledte klasser, 308
Differentialprogrammering, 6, 442
Dijkstra, Edsgar, 325
Disk-I/O, 508
Diskriminerende union, 136
Division, 39
Dokumentation, 481
Domæneanalyse, 471
double, 26
Dummy-funktion, 163
Dyadiske operatorer, 39
Dynamisk
lageradministration, 82
binding, 267
binding som indkapslings, 325
strenge, 229
objekter, 174
E
EBCDIC, 27
Effektiv adresse, 93
Eiffel, 597
Eiffel, 468
Ejerforhold i containere, 448
Ekspansion af makroer, 16, 84
Eksplicit typekonvertering, 36, 207
Ekstern lænkning, 80
Eksterne medlemsfunktioner, 129
Ellipsis, 61
Entitetsplanet, 403
enum, 34
Evalueringsrækkefølge, 47, 62
Evolution, 480
Exception handling, 574
extern, 81, 246
F
Fejlbehandling, 574
i abstrakte datatyper, 234
Figur, 278
1.6 Organiseringen af denne bog 619

Figurfortegnelse, xiv
Filbaseret I/O, 112
Filer, 508
Firkant, 278
Flersidet arv, 345
float, 26
Flydende komma, 27
Flytbarhed, 16, 389
for, 66
Formatering af standard-I/O, 496
Fornuft og makroer, 87
Fortegnsoperator, 39
Fortran, 175, 246
Forwarding, 473
Fremad-reference, 51
friend-funktioner, 188
fstream, 507
Funktion, 48
overstyret, 59
kaldte, 50
rekursiv, 59
returværdier fra, 57
pointer til, 99
inline, 62
kald af, 53
kaldende, 50
administrative, 411
som medlemmer, 77
typekonverterende, 206
bearbejdende, 412
status, 412
Funktionider, 443
Funktionsbiblioteker, 388
Funktionskald, 53
Funktionskaldsoperator, 196
overstyring af, 196
G
Garbage collection, 83
Genbrug, 469
vs. software-bjærgning, 470
og granularitet, 477
620 Introduktion 1

vs. software-overlevering, 470
og klasser, 387
og standarder, 469
og arv, 476
Genbrugsmekanismer, 469
Generalitet, 424
Genericitet, 423
rationale, 423
Gennemløb af containere, 454
Globale variable, 82
goto, 67
Granularitet, 477
Grænseflade, 119
dualisme, 435
til klienten, 435
til afledte klasser, 437
rationale, 434
blød, 322
H
Headerfiler, 15
inkludering af, 84
organisering af, 81
Heap, 82
Hello World, 154
Hexadecimale konstanter, 33
Hierarkier, 287
I
Identifikation af entiteter, 478
Idiom, 11
if/else, 63
Implementationsafhængighed, 134
Implementationsdomæne, 472
Implicit typekonvertering, 208
Indeksoperatoren
og lvalues, 195
overstyring af, 193
Indkapslede typeerklæringer, 140
1.6 Organiseringen af denne bog 621

Indkapsling, 133, 267
klassebaseret, 138
klasse- vs. objektbaseret, 138
objektbaseret, 138
typebaseret, 138
eksempel, 133
og dynamisk binding, 325
Indlejring, 75
datastrukturer, 74
klasser, 140
Informationsskjul, 119
Inholdsfortegnelse, iv
Initiering
af referencer, 106
vs. tildeling, 170
af objekter, 154
af multipelt afledte objekter, 363
af polymorfe klasser, 335
af statiske medlemmer, 143
med andet objekt, 169
Initieringslister, 161
Initieringsrækkefølge, 366
Inkludering af headerfiler, 84
Inkremental udvikling, 384
inline-funktioner, 62
Instansplanet, 403
int, 26
Intern lænkning, 80
Interne medlemsfunktioner, 129
ios, 496
Isotrope klasser, 320
Iteration af containere, 454
Iterator, 196
K
Kaldekonventioner, 244
Kanonisk klassestruktur, 415
Kildetekst organisering af, 392
Klassebaseret indkapsling, 138
Klassebegrebet, 127
Klassebiblioteker, 464
Klassehierarkier, 287
622 Introduktion 1

Klasser
skabeloner, 221
og pointere, 216
samspil mellem, 226
indlejrede, 140
som processer, 439
og genericitet, 387
som byggesten, 350
relationer mellem, 403
og egalitet, 285
anonyme, 142
og skop, 136
kongruens, 397
kendetegn, 390
Klassifikationer, 128
Klient, 4, 119
vs. udbyder, 470
løs, 408
Klog pointer, 185
Kommentarer, 18
Komplekse klasser, 410
Kompleksitetsskjul, 385
Kompositorisk design, 402
Konstante
objekter,146
medlemsfunktioner, 148
medlemsfunktioner og overstyring, 150
pointere, 104, 105
Konstanter
literale, 28
symbolske, 33
oktale, 33
hexadecimale, 33
Konstruktion af afledte objekter, 303
Konstruktører, 155
statiske, 172
og konvertering, 208
i afledte klasser, 305
kopiering, 170
Kontrolstrukturer, 63
Konvertering, 206
implicit, 36
eksplicit, 36
Koordinat, 270
1.6 Organiseringen af denne bog 623

Kopi-konstruktør, 170
Kopiering
af objekter, 169, 190
af strukturer, 72
af polymorfe objekter, 343
medlemsvis, 169
problemer med, 170
Kreativitet, 389
Krop, 48
Kvalificerede navne, 141
L
Lageradministration, 80
og arv, 445
brugerdefineret, 237
Lagringsklasser, 81
Leksikalt skop, 142
Levetid af objekter, 456
Lineær
programmering, 2
arv, 288
semafor, 444
Linie, 278
LinkedList, 247
Liskov, Barbara, 476
Liskovs substitutionsprincip, 476
Litteratur, 607
Little-endian, 22
Logiske operatorer, 41
long, 26
Lvalue, 23
Lænker, 14
Lænkning
type-sikker, 246
ekstern, 80
intern, 80
Løs klient, 408
M
624 Introduktion 1

main(), 52
Makroekspansioner, 16, 84
Makroer
og udviklingsmiljøet
og fornuft, 87
Manipulatorer, 500
brugerdefinerede, 506
Medlemmer af strukturer, 71
Medlemmer i funktioner, 77
Medlemsfunktioner, 129
overstyrede, 131
eksterne, 129
private, 138
konstante, 148
interne, 129
Medlemsreferencer, 72
underforståede, 131
Medlemsvariable statiske, 143
Medlemsvis kopiering, 169
Metaklasse, 373
Midlertidige objekter, 192
Mingelering, 60, 245
Modul eksempel 146
Modula-2, 118, 134, 256, 266
Moduler, 15, 139
Modulus, 39
Modulærprogrammering, 4, 388, 442
Monadiske operatorer, 39
MS-DOS, 16, 115
Multipel arv, 345
med relaterede baseklasser, 354
typekonvertering under, 366
med uafhængige baseklasser, 347
tvetydigheder ved, 351
og polymorfi, 369
Målfunktion, 50
N
Navne kvalificerede, 141
Navnemingelering, 245
Nedbrydning
1.6 Organiseringen af denne bog 625

af objekter 154
af multipelt afledte objekter, 363
af polymorfe klasser, 336
Nedtælling, 39
Negation, 40
new, 82
NIHCL, 468
O
Objekt konstant, 146
Objekt-I/O, 242
Objekt-orienterede kendetegn, 265
Objekt-orienteret
rationale, 2
rationale, 265
ordbog, 601
paradigme, 266
terminologi, 268
analyse, 183
indkapsling, 138
Objekter
delte, 445
og ejerforhold, 448
statiske, 172
kopiering af, 169
nedbrydning af, 154
initiering af, 154
midlertidige, 192
vektorer af, 176
kopiering af, 190
levetid, 456
Oktale konstanter, 33
OODBMS, 462
Operator
fortegns, 39
særlig, 45
skift, 40
relationel, 40
, 514
aritmetisk, 39
triadisk, 39
626 Introduktion 1

itvis, 40
tildeling, 42
reference, 42
logisk, 41
dyadiske, 39
monadisk, 39
Operator-funktioner, 179
Operatorer
oversigt over, 39
overstyring af, 178
vs. operanter, 21
præcedensproblemer, 261
Opremsninger, 34
Optælling, 39
Ordbog, 601
Organisering
af lager, 22
af kildetekst, 392
af klasser, 395
OS/2 238, 246
Overstyrede
funktioner, 59
medlemsfunktioner, 131
Overstyring
af funktioner vs.
underforståede parametre, 161
og konstante medlemsfunktioner, 150
problemer med, 205
af new per klasse, 239
af delete, 186
af funktionskaldsoperator, 196
af særlige operatorer, 185
rationale, 180
af relationelle operatorer, 183
af operatorfunktioner, 197
af binære operatorer, 183
i traditionelle sprog, 178
retningslinier for, 186
af new, 186
i klasser, 187
af monadiske operatorer, 182
af fortegnsoperatorer, 182
af indeksoperatoren, 193
af operatorer, 178
1.6 Organiseringen af denne bog 627

af tildelings-operatorer, 184
af dyadiske operatorer, 183
i standardbiblioteket, 198
Oversættelse
betinget, 88
Oversættelsesenheder, 15
P
Parameteriserede typer, 218, 476
Parameterisering, 218
eksempler på, 218
Parametre
underforståede, 132
afledte typer, 53
underforståede, 60
i konstante funktioner, 149
referencetype, 107
Pascal, 86, 118, 175, 246, 256
Per-klasse overstyringer, 239
Permanente objekter, 456
Persistens, 455
Pointer, 90
reference til, 107
og genericitet, 99
typekonvertering af, 103
og vektor, 95
initiering af, 91
til medlemmer, 79
i datastrukturer, 101
dereference af
og void, 103
til konstant lager, 104
advarsler, 100
konstant, 105
til medlemsfunktion, 217
til pointer, 98
og nul, 102
til funktion, 99
til medlemsdata, 216
og dereferencer, 91
og virtuelle funktioner, 322
til objekter, 172
628 Introduktion 1

Pointeraritmetik, 91
Pointertyper, 28
Polymorfe
objekter kopiering af, 343
klasser nedbrydning af, 336
klasser, 319
containere, 449
klasser initiering af, 335
datastrukturer, 333
Polymorfi
og genbrug, 422
programmørkontrolleret, 461
og virtuelle baseklasser, 376
i detaljer, 330
og multipel arv, 369
rationale, 269
Postfix-optælling, 181
Prefix-optælling, 181
private, 134
Private medlemsfunktioner, 138
Problemer
med arv, 316
med virtuelle baseklasser, 378
med switch, 327
Programeksempler, xvii
Programmering
lineært, 2
struktureret, 3
generelt, 14
med containerklasser, 451
differentialt, 6
objekt-orienteret, 6
modulært, 4
protected, 299
Prototyper, 51
Præcedens, 47
Præcision, 27
Præprocessering, 15, 84
public, 134
Punkt, 278
Q
1.6 Organiseringen af denne bog 629

QuickPascal, 596
R
Random, 254
Reference
transparent, 463
Referenceoperator, 42
Referencer, 29, 106
initiering af, 106
til objekter, 172
underforståede, 131
som parametre, 107
til medlemmer, 72
til pointer, 107
register, 27
Regneoperatorer, 39
Rekomposition, 425
Rekursion, 59
Relationelle operatorer, 41
Relationer mellem klasser, 403
Rene virtuelle metoder, 339
Repræsentation af virkeligheden, 385
Reserverede navne, 20
Returværdier, 57
Reverse engineering, 470
Robust kode, 477
Run-time typeidentifikation, 580
Rvalue, 23
S
Samarbejde med andre sprog, 244
Samspil mellem klasser, 226
Semaforstyring, 119
Semantisk katalog, 429
Semantiske udvidelser, 34
Set, 256
short, 26
signed, 27
Sikkerhed, 127
Simple klasser, 410
630 Introduktion 1

Simula, 7
sizeof, 46
Skabeloner, 221
Skalérbare typer, 118
Skifteoperatorer, 40
Skop, 50
og klasser, 136
leksikalt, 142
opløsning, 46
Smalltalk, 14, 266, 597
Softwaredesign definition, 381
Standard-I/O, 16
Standard-input (cin), 112
Standard-output (cout), 111
Standardbiblioteket, 482
static, 81
Statiske
konstruktører, 172
medlemsvariable initiering af, 144
variable, 81
destruktører, 172
objekter, 172
funktioner, 145
medlemsvariable, 143
Statusmetoder, 412
Stream, 110
Stroustrup, Bjarne, 13
strstream, 502
struct, 70, 136
Struktureret programmering, 3
Strøm, 110
Strømme, 16
Strømstatus, 505
Stuktureret analyse, 182
Subtraktion, 39
Svartider, 55
Swift, Johnathan, 22
switch, 68
Særlige operatorer, 45
Sætninger, 21
T
1.6 Organiseringen af denne bog 631

Tabelfortegnelse, xvi
template, 222
Temporære
objekter, 456
forekomster, 193
Terminologi
objekt-orienteret, 268
i denne bog, 9
this, 145, 200
throw, 574
Tildeling vs. initiering, 170
Tildelingsoperator, 42
Tilfældige tal, 254
Tilgang, 135
fra klientkode, 294
Tilgang under arv, 291
Token pasting, 87
Tomme klasser, 410
Top-down analyse, 182
Topologi, 467
Transformation, 270
Translatør, 13
Transparent reference, 463
Triadisk operator, 39
try, 574
Turbo Pascal, 596
Tvetydigheder
under arv, 301
ved multipel arv, 351
Type-cast, 207
Type-sikker lænkning, 246
Type-ækvivalens, 286
Typebaseret indkapsling, 139
typedef, 109
Typeforhold, 141
Typekonvertering, 207
eksplicit, 207
implicit, 208
og konstruktører, 208
i flere led, 209
eksplicit, 36
implicit, 36
brugerdefineret, 204
regler for, 37
632 Introduktion 1

af pointere, 103
under arv, 308
under multipel arv, 366
Typer
fundamentale, 26
parameteriserede, 218
pointere, 28
associationer med, 128
brugerdefinerede, 35
skalérbare, 118
vektorer, 28
forhold mellem, 91
referencer, 28
U
Udbyder, 119
Udtryk, 21
Udvidelsesmuligheder, 125
Udvikling, 479
inkremental, 384
miljø, 14
miljø og makroer, 88
Ulovlige pointerreferencer, 185
Underforståede
parametre i konstruktører, 160
parametre, 60
medlemsreferencer, 131
parametre, 132
værdier i objekter, 211
union, 72, 136
diskriminerende, 136
UNIX, 16, 115
M4, 424
unsigned, 28
V
Variable
automatiske, 81
globale, 82
statiske, 81
Variansdomæne, 472
1.6 Organiseringen af denne bog 633

Vektor, 28
type af, 93
gennemløbning af, 92
indeksering i, 92
gennemløbning af, 92
af char, 94
initiering af, 94
størrelse på, 94
i flere dimensioner, 95
allokering af, 93
deallokering af, 175
og pointer, 95
af objekter, 176
Virkefelt, 50
Virtualitet, 269
Virtuelle
baseklasser og polymorfi, 376
baseklasser, 356
funktioner og klienten, 412
funktioner, 322
funktioner i detaljer, 328
baseklasser problemer med, 378
void, 52
og pointere, 103
W
while/do, 65
X
XCL, 520
kildetekst, 611
udvidelser og tilpasninger, 564
generelle datatyper, 538
værktøjsklasser, 531
containerklasser, 541
abstrakte klasser, 522
634 Introduktion 1

Æ
Ækvivalens, 286
1.6 Organiseringen af denne bog 635

C++, dataabstraktion og objekt-orienteret programmering
Copyright © 1991, 1993 by Maz Spork and Polyteknisk Forlag
1. udgave, 1. oplag 1991
2. udgave, 1. oplag 1993
Omslag: Helle Johnsen
Kopiering fra denne bog kun tilladt i overensstemmelse med overenskomst mellem
Undervisningsministeriet og Copy-Dan.
Bogen er sat, monteret og illustreret af forfatteren og trykt i offset hos AiO Tryk as,
Odense.
Printed in Denmark 1993
ISBN 87-502-0739-3
Polyteknisk Forlag
Anker Engelundsvej 1
DK-2800 Lyngby
42 88 14 88
FAX 42 88 11 67
Polyteknisk Forlag fralægger sig ethvert ansvar for fejl og mangler i bogens
indhold samt følgevirkninger af sådanne fejl og mangler, selvom bogens fulde
indhold er kontrolleret før tryk. Det fulde ansvar for enhver privat og
erhvervsmæssig benyttelse af de i bogen fremlagte oplysninger påhviler derfor
læseren.
636 Introduktion 1