Kurs C++ Od Zera Do Gier Kodera.pdf

Podstawy programowania

202

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mo*na zauwa*yü, ze bazowa klasa CChessPiece nie b dzie tutaj sáu*yü do tworzenia

obiektów, lecz tylko do wyprowadzania z niej kolejnych klas. Sprawia to, *e byáaby ona

dobrym kandydatem na tzw. klas abstrakcyjn. O tym zagadnieniu b dziemy mówiü

przy okazji metod wirtualnych.

Podsumowanie

Myl , *e po takiej iloci przykáadów oraz opisów koncepcja tworzenia klas pochodnych
poprzez dziedziczenie powinna byü ci ju* doskonale znana :) Nie nale*y ona wszak*e do
trudnych; wa*ne jest jednak, by poznaü zwizane z ni niuanse w j zyku C++.

O dziedziczeniu pojedynczym mo*na tak*e poczytaü nieco w

MSDN

Dziedziczenie wielokrotne

Skoro mo*liwe jest dziedziczenie z wykorzystaniem jednej klasy bazowej, to raczej
naturalne jest rozszerzenie tego zjawiska tak*e na przypadki, w której z kilku klas
bazowych tworzymy jedn klas pochodn. Mówimy wtedy o dziedziczeniu
wielokrotnym (ang. multiple inheritance).

C++ jest jednym z niewielu j zyków, które udost pniaj tak mo*liwoü. Nie wiadczy to
jednak o jego niebotycznej wy*szoci nad nimi. Tak naprawd technika dziedziczenia
wielokrotnego nie daje *adnych nadzwyczajnych korzyci, a jej u*ycie jest przy tym doü
skomplikowane. Decydujc si na jej wykorzystanie nale*y wi c posiadaü caákiem spore
dowiadczenie w programowaniu.
Jakkolwiek zatem dziedziczenie wielokrotne bywa czasem przydatnym narz dziem,
stosowanie go (przynajmniej powszechne) w tworzonych aplikacjach nie jest zalecane.
Je*eli pojawia si taka koniecznoü, nale*y wtedy najprawdopodobniej zweryfikowaü swój
projekt; w wi kszoci sytuacji te same, a nawet lepsze efekty mo*na osignü nie
korzystajc z tego wielce wtpliwego rozwizania.

Dla szczególnie zainteresowanych i odwa*nych istnieje oczywicie opis w

MSDN

Puáapki dziedziczenia

Chocia* idea dziedziczenia jest teoretycznie caákiem prosta do zrozumienia, jej
praktyczne zastosowanie mo*e niekiedy nastr czaü pewnych problemów. S one
zazwyczaj specyficzne dla konkretnego j zyka programowania, jako *e wyst puj w tym
wzgl dzie pewne ró*nice mi dzy nimi.

W tym paragrafie zajmiemy si takimi wáanie drobnymi niuansami, które s zwizane z
dziedziczeniem klas w j zyku C++. Sekcja ta ma raczej charakter formalnego
uzupeánienia, dlatego pocztkujcy programici mog j ze spokojem pominü -
szczególnie podczas pierwszego kontaktu z tekstem.

Co nie jest dziedziczone?

Wydawaáoby si , *e klasa pochodna powinna przejmowaü wszystkie skáadowe pochodzce
z klasy bazowej - oczywicie z wyjtkiem tych oznaczonych jako

private

. Tak jednak nie

jest, gdy* w trzech przypadkach nie miaáoby to sensu. Owe trzy „nieprzechodnie”
skáadniki klas to:

konstruktory. Zadaniem konstruktora jest zazwyczaj inicjalizacja pól klasy na ich
pocztkowe wartoci, stworzenie wewn trznych obiektów czy te* alokacja
dodatkowej pami ci. Czynnoci te prawie zawsze wymagaj zatem dost pu do
prywatnych pól klasy. Je*eli wi c konstruktor z klasy bazowej zostaáby „wrzucony”
do klasy pochodnej, to utraciáby z nimi niezb dne poáczenie - wszak „zostaáyby”
one w klasie bazowej! Z tego te* powodu konstruktory nie s dziedziczone.

Podstawy programowania

206

Przedefiniowanie metody wirtualnej

Celem wprowadzenia funkcji wirtualnej Oddychaj() do klasy CAnimal byáo, jak to
zaznaczylimy na pocztku, jej pó(niejsze przedefiniowanie (ang. override) w klasach
pochodnych. Operacji tej dokonujemy prost drog, bowiem zwyczajnie definiujemy
now wersj metody w owych klasach:

class

CFish :

public

CAnimal

{

public

void

Oddychaj()

// redefinicja metody wirtualnej

{ std::cout <<

"Oddycham skrzelami..."

<< std::endl; }

void

Plyn();

};

class

CMammal :

public

CAnimal

{

public

void

Oddychaj()

// jak wy*ej

{ std::cout <<

"Oddycham páucami..."

<< std::endl; }

void

Biegnij();

};

class

CBird :

public

CAnimal

{

public

void

Oddychaj()

// i znowu jak wy*ej :)

{ std::cout <<

"Oddycham páucami..."

<< std::endl; }

void

Lec();

};

Kompilator sam „domyla si ”, *e nasza metody jest tak naprawd redefinicj metody
wirtualnej z klasy bazowej. Mo*emy jednak wyra(nie to zaznaczyü poprzez ponowne
zastosowanie sáowa

virtual

Wedáug mnie jest to maáo szcz liwe rozwizanie skáadniowe, poniewa* mo*e cz sto
powodowaü pomyáki. Nie sposób bowiem odró*niü deklaracji przedefiniowanej metody
wirtualnej od jej pierwotnej wersji (je*eli jeszcze raz u*ylimy

virtual

) lub od zwykáej

funkcji skáadowej (gdy nie skorzystalimy ze wspomnianego sáówka).
Bardziej przejrzycie rozwizano to na przykáad w Delphi, gdzie now wersj metody
wirtualnej trzeba opatrzyü fraz override;.

Nowa wersja metody caákowicie zast puje star, która jest jednak dost pna i w razie
potrzeby mo*emy j wywoáaü. Sáu*y do tego konstrukcja:

nazwa_klasy_bazowej::nazwa_metody([parametry]);

W powy*szym przypadku byáoby to wywoáanie CAnimal::Oddychaj().

W Visual C++ zamiast nazwy_klasy_bazowej mo*liwe jest u*ycie specjalnego sáowa

kluczowego

__super

, opisanego

tutaj

Pojedynek: metody wirtualne przeciwko zwykáym

Czytajc powy*sze objanienie metod wirtualnych, zadawaáe sobie zapewne proste
pytanie o gá bokiej treci, a mianowicie: „Po co mi to?” ;-) Najlepsz odpowiedzi na nie
b dzie wyjanienie ró*nicy pomi dzy zwykáymi oraz wirtualnymi metodami.

Podstawy programowania

210

Czysto wirtualne metody

Wirtualna funkcja skáadowa umieszczona w klasie bazowej jest przygotowana na to, aby
ustpiü miejsca swej bardziej wyspecjalizowanej wersji, zdefiniowanej w klasie
pochodnej. Nie zmienia to jednak faktu, i* musiaáaby ona jako implementowaü
czynnoü, której przebiegu cz sto nie sposób ustaliü na tym etapie.

Posiadamy dobry przykáad, ilustrujcy tak wáanie sytuacj . Chodzi mianowicie o
metod CAnimal::Oddychaj(). Wewntrz klasy bazowej, z której maj dopiero
dziedziczyü konkretne grupy zwierzt, niemo*liwe jest przecie* ustalenie uniwersalnego
sposobu oddychania. Sensowna implementacja tej metody jest wi c w zasadzie
niemo*liwa.
Sprawia to, i* jest ona wywienitym kandydatem na czysto wirtualn funkcj
skáadow.

Metody nazywane czysto wirtualnymi (ang. pure virtual) nie posiadaj *adnej
implementacji i s przeznaczone wyácznie do przedefiniowania w klasach
pochodnych.

Deklaracja takiej metody ma doü osobliw postaü. Oczywicie z racji nie posiadania
*

adnego kodu zb dne staj si nawiasy klamrowe wyznaczajce jej blok, zatem caáoü

przypomina zwykáy prototyp funkcji. Samo oznaczenie, czynice dan metod czysto
wirtualn, jest jednak raczej niecodzienne:

class

CAnimal

{

// (definicja klasy jest skromna z przyczyn oszcz dnociowych :))

public

virtual

void

Oddychaj() =

;

};

Jest nim wyst pujca na kocu fraza =

;. Kojarzy si ona troch z domyln wartoci

funkcji, ale interpretacja taka upada w obliczu niezwracania przez metod Oddychaj()
*

adnego rezultatu. Faktycznie funkcj czysto wirtualn mo*emy w ten sposób uczyniü

ka*d wirtualn metod , niezale*nie od tego, czy zwraca jak wartoü i jakiego jest ona
typu. Sekwencja =

; jest wi c po prostu takim dziwnym oznaczeniem, stosowanym dla

tego rodzaju metod. Trzeba si z nim zwyczajnie pogodziü :)

Twórcy C++ wyra(nie nie chcieli wprowadzaü tutaj dodatkowego sáowa kluczowego, ale w

tym przypadku trudno si z nimi zgodziü. Osobicie uwa*am, *e deklaracja w formie na

przykáad

pure

virtual

void

Oddychaj(); byáaby znacznie bardziej przejrzysta.

Po dokonaniu powy*szej operacji metoda CAnimal::Oddychaj() staje si zatem czysto
wirtualn funkcj skáadow. W tej postaci okrela ju* tylko sam czynnoü, bez
podawania *adnego algorytmu jej wykonania. Zostanie on ustalony dopiero w klasach
dziedziczcych od CAnimal.

Mo*na aczkolwiek podaü implementacj metody czysto wirtualnej, jednak b dzie ona

mogáa byü wykorzystywana tylko w kodzie metod klas pochodnych, które j

przedefiniowuj, w formie klasa_bazowa::nazwa_metody([parametry]).

Abstrakcyjne klasy bazowe

Nie widaü tego na pierwszy, drugi, ani nawet na dziesity rzut oka, ale zadeklarowanie
jakiej metody jako czysto wirtualnej powoduje jeszcze jeden, dodatkowy efekt. Otó*
klasa, w której tak funkcj stworzymy, staje si klas abstrakcyjn.

Programowanie obiektowe

211

Klasa abstrakcyjna zawiera przynajmniej jedn czysto wirtualn metod i z jej powodu
nie jest przeznaczona do instancjowania (tworzenia z niej obiektów), a jedynie do
wyprowadzania ze klas pochodnych.

Ze wzgl du na wy*ej wymienion definicj czysto wirtualne funkcje skáadowe okrela si

niekiedy mianem metod abstrakcyjnych. Nazwa ta jest szczególnie popularna wród

programistów j zyka Object Pascal.

Takie klasy buduj zawsze najwy*sze pi tra w hierarchiach i s podstawami dla bardziej
wyspecjalizowanych typów. W naszym przypadku mamy tylko jedn tak klas , z której
dziedzicz wszystkie inne. Nazywa si CAnimal, jednak dobry zwyczaj programistyczny
nakazuje, aby klasy abstrakcyjne miaáy nazwy zaczynajce si od litery I. Ró*ni si one
bowiem znacznie od pozostaáych klas. Zatem baza w naszej hierarchii b dzie od tej pory
zwaü si IAnimal.

C++ bardzo dosáownie traktuje reguá , i* klasy abstrakcyjne nie s przeznaczone do
instancjowania. Próba utworzenia z nich obiektu zakoczy si bowiem bá dem;
kompilator nie pozwoli na obecnoü czysto wirtualnej metody w klasie tworzonego
obiektu.
Mo*liwe jest natomiast zadeklarowanie wska(nika na obiekt takiej klasy i przypisanie mu
obiektu klasy potomnej, tak wi c poni*szy kod b dzie jak najbardziej poprawny:

IAnimal* pZwierze =

new

CBird;

pZwierze->Oddychaj();

delete

pZwierze;

Wywoáanie metody Oddychaj() jest tu tak*e dozwolone. Wprawdzie w bazowej klasie
IAnimal jest ona czysto wirtualna, jednak w CBird, do obiektu której odwoáuje si nasz
wska(nik, posiada ona odpowiedni implementacj .

Wydawaáoby si , *e C++ reaguje nieco zbyt alergicznie na prób utworzenia obiektu

klasy abstrakcyjnej - w kocu sama kreacja nie jest niczym niepoprawnym. W ten sposób

jednak mamy pewnoü, *e podczas dziaáania programu wszystko b dzie dziaáaü

poprawnie i *e omyákowo nie zostanie wywoáana metoda z nieokrelon implementacj.

Polimorfizm

Gdyby programowanie obiektowe porównaü do wysokiego budynku, to u jego
fundamentów le*aáyby poj cia „klasy” i „obiekty”, rodkowe pi tra budowaáoby
„dziedziczenie” oraz „metody wirtualne”, za u samego szczytu sytuowaáby si
„polimorfizm”. Jest to bowiem najwi ksze osigni cie tej metody programowania.

Z terminem tym spotykalimy si przelotnie ju* par razy, ale teraz wreszcie wyjanimy
sobie wszystko od pocztku do koca. Zacznijmy choüby od samego sáowa: ‘polimorfizm’
pochodzi od greckiego wyrazu polýmorphos, oznaczajcego ‘wieloksztaátny’ lub
‘wielopostaciowy’. W programowaniu b dzie si wi c odnosiü do takich tworów, które
mo*na interpretowaü na ró*ne sposoby - a wi c nale*cych jednoczenie do kilku ró*nych
typów (klas).

Polimorfizm w programowaniu obiektowym oznacza wykorzystanie tego samego kodu
do operowania na obiektach przynale*nych ró*nym klasom, dziedziczcym od siebie.

Zjawisko to jest zatem cile zwizane z klasami i dziedziczeniem, aczkolwiek w C++ nie
dotyczy ono ka*dej klasy, a jedynie okrelonych typów polimorficznych.

Programowanie obiektowe

215

Eureka! Na tym przecie* polega polimorfizm :)

Mo*liwe *e zauwa*yáe, i* *adna z tych przykáadowych klas nie jest tutaj typem

polimorficznym, a jednak podany wy*ej kod dziaáa bez zarzutu. Powodem tego jest jego

wzgl dna prostota. Dokáadniej mówic, nie jest konieczne sprawdzanie poprawnoci

typów podczas dziaáania programu, bo wystarczajca jest zwykáa kontrola, dokonywana

zwyczajowo podczas kompilacji kodu.

Klasy wiedz same, co nale*y robiü

Z poprzednim przykáadem zwizany jest pewien mankament, nietrudno zreszt
zauwa*alny. Niezale*nie od tego, jakie dodatkowe dane o dokumencie zadeklarujemy w
klasach pochodnych, nasza funkcja wywietli tylko i wyácznie te przewidziane w klasie
CDocument. Nie uzyskamy wi c nic ponad autora, tytuá oraz dat stworzenia dokumentu.

Trzeba jednak przyznaü, *e sami niejako jestemy sobie winni. Wyodr bniajc czynnoü
prezentacji obiektu poza sam obiekt postpilimy niezgodnie z ide OOPu, która nakazuje
á

czyü dane i operujcy na nich kod.

Zatem przykáad z poprzedniego paragrafu to zdecydowanie záy przykáad :D

O wiele lepszym rozwizaniem jest dodanie do klasy CDocument odpowiedniej metody,
odpowiedzialnej za czynnoü wypisywania. A ju* caákowitym ideaáem b dzie uczynienie
jej funkcj wirtualn - wtedy klasy dziedziczce od CDocument b d mogáy ustaliü wáasny
sposób prezentacji swoich danych.
Wszystkie te doskonaáe pomysáy praktycznie realizuje poni*szy program przykáadowy:

// Polymorphism - wykorzystanie techniki polimorfizmu

// *** documents.h ***

class

CDocument

{

(wi kszoü skáadowych wyci to z powodu zbyt du*ej obj toci)

public

virtual

void

PokazDane();

};

// (reszty klas nieuwzgl dniono z powodu dziury bud*etowej ;D)
// (za ich implementacje s w pliku documents.cpp)

// *** main.cpp ***

#include

#include

<conio.h>

#include

"documents.h"

void

main()

{

// wska(nik na obiekty dokumentów

CDocument*

pDokument;

// pierwszy dokument - internetowy

std::cout << std::endl <<

"--- 1. pozycja ---"

<< std::endl;

pDokument

new

COnlineDocument(

"Regedit"

"Cyfrowe przetwarzanie tekstu"

Podstawy programowania

218

// zainicjowanie generatora liczb losowych

srand

(

static_cast

unsigned

>(time(NULL)));

// wylosowanie liczby i stworzenie obiektu zwierza

switch

(rand() %

)

{

case

return

new

CFish;

case

return

new

CMammal;

case

return

new

CBird;

case

return

new

CHomeDog;

default

return

NULL;

}
}

Losuje ona liczb i na jej podstawie tworzy obiekt jednej z czterech, zdefiniowanych jaki
czas temu, klas zwierzt. Nast pnie zwraca wska(nik do niego jako wynik swego
dziaáania. Rezultat ten jest rzecz jasna typu IAnimal*, aby mógá „pomieciü” odwoáania
do jakiegokolwiek zwierz cia, dziedziczcego z klasy bazowej IAnimal.

Powy*sza funkcja jest bardzo prostym wariantem tzw. fabryki obiektów (ang. object

factory). Takie fabryki to najcz ciej osobne obiekty, które tworz zale*ne do siebie byty

np. na podstawie staáych wyliczeniowych, przekazywanych swoim metodom. Metody

takie mog wi c zwróciü wiele ró*nych rodzajów obiektów, dlatego deklaruje si je z

u*yciem wska(ników na klasy bazowe - u nas jest to IAnimal*.

Wywoáanie tej funkcji zwraca nam wi c dowolne zwierz i zdawaáoby si , *e nijak nie
potrafimy sprawdziü, do jakiej klasy ono faktycznie nale*y. Z pomoc przychodzi nam
jednak operator

dynamic_cast

, dzi ki któremu mo*mue spróbowaü rzutowania

otrzymanego wska(nika na przykáad do typu CMammal*:

IAnimal* pZwierze = StworzLosoweZwierze();
CMammal* pSsak =

dynamic_cast

<CMammal*>(pZwierze);

Taka próba powiedzie si jednak tylko w rednio poáowie przypadków (dlaczego?

). Co

zatem b dzie, je*eli pZwierze odnosi si do innego rodzaju zwierzt?…
Otó* w takim przypadku otrzymamy prost informacj o bá dzie, mianowicie:

dynamic_cast

zwróci wska(nik pusty (o wartoci NULL), je*eli niemo*liwe b dzie

dokonanie podanego rzutowania.

Aby j wychwyciü potrzebujemy oczywicie dodatkowego warunku, porównujcego
zmienn pSsak z t specjaln wartoci NULL (b dc zreszt de facto zerem):

(pSsak != NULL)

// sprawdzenie, czy rzutowanie powiodáo si

{

// OK - rzeczywicie mamy do czynienia z obiektem klasy CMammal.

// pSsak mo*e byü tu u*yty tak samo, jak ka*dy inny wska(nik

// na obiekt klasy CMammal, na przykáad:

pSsak->Biegnij();
}

Obiekt klasy CMammal jest tworzony zarówno poprzez

new

CMammal, jak i

new

CHomeDog. Klasa CHomeDog

dziedziczy przecie* po klasie CMammal.

Programowanie obiektowe

219

Warunek

(pSsak != NULL) mo*e byü zastpiony przez

(pSsak). Wówczas

kompilator dokona automatycznej zamiany wartoci pSsak na logiczn, co da faász, je*eli
jest ona równa zeru (czyli NULL) oraz prawd w ka*dej innej sytuacji.

Mo*liwe jest nawet wi ksze skondensowanie kodu. Wystarczy wstawiü linijk z

rzutowaniem bezsporednio do warunku

, tzn. zastosowaü instrukcj :

(CMammal* pSsak =

dynamic_cast

<CMammal*>(pZwierzak))

Pojedynczy znak = jest tutaj umieszczony celowo, gdy* w ten sposób caáe przypisanie

reprezentuje wynik rzutowania, który zostaje potem niejawnie przyrównany do zera.

Kontrola otrzymanego wyniku rzutowania jest konieczna; je*eli bowiem spróbowalimy
zastosowaü operator wyáuskania -> do pustego wska(nika, spowodowalibymy bád
ochrony pami ci (access violation).

Nale*y wi c zawsze sprawdzaü, czy rzutowanie

dynamic_cast

powiodáo si , poprzez

porównanie otrzymanego wska(nika z wartoci NULL.

I to jest w zasadzie wszystko, co nale*y wiedzieü o operatorze

dynamic_cast

Incydentalnie trafiaj si sytuacje, w których zastosowanie omawianego operatora

wymaga wáczenia specjalnej opcji kompilatora, uaktywniajcej informacje o typie

podczas dziaáania programu. S to rzadkie przypadki i prawie zawsze dotycz

wielodziedziczenia, niemniej warto wiedzieü, *e takie niespodzianki mog si czasem

przytrafiü.

Sposób wáczenia informacji o typie w czasie dziaáania programu jest opisany w

nast pnym paragrafie.

Bli*szych szczegóáow na temat rzutowania

dynamic_cast

mo*na doszukaü si w

MSDN

typeid

i informacje o typie podczas dziaáania programu

Oprócz

dynamic_cast

- operatora, który pozwala sprawdziü, czy dany wska(nik do klasy

bazowej wskazuje te* na obiekt klasy pochodnej - C++ dysponuje nieco bardziej
zaawansowanymi konstrukcjami, dostarczajcymi wiadomoci o typach obiektów i
wyra*e w programie. S to tak zwane informacje o typie czasu wykonania
(ang. Run-Time Type Information), oznaczane angielskim skrótowcem RTTI.

Znajomoü opisywanej tu cz ci RTTI, czyli operatora

typeid

, generalnie nie jest tak

potrzebna, jak umiej tnoü posáugiwania si operatorami rzutowania, ale daje kilka
bardzo ciekawych mo*liwoci, najcz ciej nieosigalnych inn drog. Mo*esz aczkolwiek
tymczasowo pominü ten paragraf, by wróciü do niego pó(niej.

Skorzystanie z RTTI wymaga podj cia dwóch wst pnych kroków:

wáczenia odpowiedniej opcji kompilatora:

Podstawy programowania

224

prawie zawsze pozostaj staáe - a do nich nale*y tak*e podziaá obiektów skáadowych
aplikacji na trzy fundamentalne grupy.

Podziaá ten jest bardzo ogólny i niezbyt sztywny, ale przez to stosuje si w zasadzie do
ka*dego projektu. B dzie on zreszt punktem wyjcia dla nieco bardziej szczegóáowych
kwestii, opisanych pó(niej.
Pomówmy wi c kolejno o ka*dym rodzaju z owej podstawowej trójki.

Singletony

Wi kszoü obiektów jest przeznaczonych do istnienia w wielu egzemplarzach, ró*nicych
si przechowywanymi danymi, lecz wykonujcych te same dziaáania poprzez metody.
Istniej jednak*e wyjtki od tej reguáy, a nale* do nich wáanie singletony.

Singleton (‘jedynak’) to klasa, której jedyna instancja (obiekt) speánia kluczow rol w
caáym programie.

W danym momencie dziaáania aplikacji istnieje wi c co najwy*ej jeden egzemplarz
klasy, b dcej singletonem.

Obiekty takie s dosáownie jedyne w swoim rodzaju i dlatego zwykle przechowuj one
najwa*niejsze dane programu oraz wykonaj wi kszoü newralgicznych czynnoci.
Najcz ciej s te* „rodzicami” i wáacicielami pozostaáych obiektów.
W jakich sytuacjach przydaj si takie twory? Otó* je*eli podzielilibymy nasz projekt na
jakie skáadowe (sposób podziaáu jest zwykle spraw mocno subiektywn), to dobrymi
kandydatami na singletony byáyby przede wszystkim te skáadniki, które obejmowaáyby
najszerszy zakres funkcji. Mo*e to byü obiekt aplikacji jako takiej albo te*
reprezentacje poszczególnych podsystemów - w grach byáyby to: grafika, d(wi k, sieü,
AI, itd., w edytorach: moduáy obsáugi plików, dokumentów, formatowania itp.

Niekiedy zastosowanie singletonów wymuszaj warunki zewn trzne, np. jakie

dodatkowe biblioteki, u*ywane przez program. Tak jest chocia*by w przypadku funkcji

Windows API odpowiedzialnych za zarzdzanie oknami.

Siá rzeczy singletony stanowi te* „punkty zaczepienia” dla caáego modelu klas, gdy* ich
pola s w wi kszoci odwoáaniami do innych obiektów: niekiedy do wielu drobnych, ale
cz ciej do kilku kolejnych zarzdców, czyli nast pnego, ni*szego poziomu hierarchii
zawierania si obiektów.

O relacji zawierania si (agregacji) b dziemy jeszcze szerzej mówiü.

Przykáady wykorzystania

Najbardziej oczywistym przykáadem singletonu mo*e byü caáociowy obiekt programu,
a wi c klasa w rodzaju CApplication czy CGame. B dzie ona nadrz dnym obiektem
wobec wszystkich innych, a tak*e przechowywaáa b dzie globalne dane dotyczce
aplikacji jako caáoci. To mo*e byü chocia*by cie*ka do jej katalogu, ale tak*e kluczowe
informacje otrzymane od bibliotek Windows API, DirectX czy jakichkolwiek innych.

Je*eli chodzi o inne mo*liwe singletony, to z pewnoci b d to zarzdcy poszczególnych
moduáów; w grach s to obiekty klas o tak wiele mówicych nazwach jak
CGraphicsSystem, CSoundSystem, CNetworkSystem itp., podobne twory mo*na te*
wyró*niü w programach u*ytkowych.
Wszystkie te klasy wyst puj w pojedynczych instancjach, gdy* unikatowa jest ich rola.
Kwesti otwart jest natomiast ich ewentualna podlegáoü najbardziej nadrz dnemu
obiektowi aplikacji - na przykáad w ten sposób:

Programowanie obiektowe

227

// statyczne pole, przechowujce wska(nik na nasz jedyny obiekt

static

CSingleton* ms_pObiekt;

// (tutaj b d dalsze skáadowe klasy)

};

// *** moduá kodu ***
// trzeba rzecz jasna doáczyü tutaj nagáówek z definicj klasy

// inicjujemy pole wartoci zerow (NULL)

CSingleton* CSingleton::ms_pObiekt = NULL;

Deklaracj pola umiecilimy w sekcji

private

, aby chroniü je przed niepowoáan

zmian. W takiej sytuacji potrzebujemy jednak metody dost powej do niego, która
zreszt tak*e b dzie statyczna:

// *** wewntrz klasy CSingleton ***

public

static

CSingleton* Obiekt()

{

// tworzymy obiekt, je*eli jeszcze nie istnieje

// (tzn. jeli wska(nik ms_pObiekt ma pocztkow wartoü NULL)

(ms_pObiekt == NULL) CSingleton();

// zwracamy wska(nik na nasz obiekt

return

ms_pObiekt;

}

Oprócz samego zwracania wska(nika metoda ta sprawdza, czy *dany przez nasz obiekt
faktycznie istnieje; je*eli nie, jest tworzony. Jego kreacja nast puje wi c przy pierwszym
u*yciu.
Odbywa si ona poprzez bezporednie wywoáanie konstruktora… którego na razie nie
mamy (jest domylny)! Czym pr dzej naprawmy zatem to niedopatrzenie, przy okazji
definiujc tak*e destruktor:

// *** wewntrz klasy CSingleton ***

private

CSingleton()

{ ms_pObiekt =

this

; }

public

~CSingleton()

{ ms_pObiekt = NULL; }

Spore zdziwienie mo*e budziü niepublicznoü konstruktora. W ten sposób jednak
zabezpieczamy si przed utworzeniem wi cej ni* jednej kopii naszego singletonu.
Uprawniona do wywoáania prywatnego konstruktora jest bowiem tylko skáadowa klasy,
czyli metoda CSingleton::Obiekt(). Wszelkie zewn trzne próby stworzenia obiektu
klasy CSingleton zakocz si wi c bá dem kompilacji, za jedyny jego egzemplarz
b dzie dost pny wyácznie poprzez wspomnian metod .

Powy*szy sposób jest zatem odpowiedni dla obiektu stojcego na samym szczycie

hierarchii w aplikacji, a wi c dla klas w rodzaju CApplication, CApp czy CGame. Je*eli za

chcemy mieü wygodny dost p do obiektów le*cych ni*ej, zawartych wewntrz innych,

wtedy nie mo*emy oczywicie uczyniü konstruktora prywatnym. Wówczas warto wi c

skorzystaü z innych rozwiza, których jednak nie chciaáem tutaj przedstawiaü ze

Przedrostek s_ wskazuje, *e dana zmienna jest statyczna. Tutaj zostaá on poáczony ze zwyczajowym m_,

dodawanym do nazw prywatnych pól.

Programowanie obiektowe

231

return

vWynik;

}

Te operacje maj zreszt niezliczone zastosowania w programowaniu trójwymiarowych
gier, zatem ich implementacja ma gá boki sens :)

Spokojnie mo*emy w tych funkcjach pobieraü i zwracaü obiekty typu VECTOR3. Koszt
obliczeniowy tych dziaáa b dzie bowiem niemal taki sam, jak dla pojedynczych liczb.

W przypadku parametrów funkcji stosujemy jednak referencje, które optymalizuj kod,

uwalniajc od przekazania nawet tych skromnych kilkunastu bajtów. Zapoznamy si z

nimi w nast pnym rozdziale.

à

acuchy znaków czy wymysáy matematyków to nie s naturalnie wszystkie koncepcje,

które mo*na i trzeba realizowaü jako obiekty narz dziowe. Do innych nale* chocia*by
wszelkie reprezentacje daty i czasu, kolorów, numerów o okrelonym formacie oraz
wszystkie pozostaáe, nieelementarne typy danych.

Szczególnym przypadkiem obiektów pomocniczych s tak zwane inteligentne wska(niki

(ang. smart pointers). Ich zadaniem jest zapewnienie dodatkowej funkcjonalnoci

zwykáym wska(nikom - obejmuje to na przykáad zwolnienie wskazywanej przez nie

pami ci w sytuacjach wyjtkowych czy te* zliczanie odwoáa do „opakowanych” nimi

obiektów.

Definiowanie odpowiednich klas

Tworzenie obiektowego modelu programu przebiega zwykle dwuetapowo. Jednym z
zada jest identyfikacja klas, które b d si na skáadaáy, oraz pól i metod, które zostan
zawarte w ich definicjach. Drugim jest okrelenie zwizków pomi dzy tymi klasami,
dzi ki którym aplikacja mogáaby realizowaü zaplanowane czynnoci.
Przestrzeganie powy*szej kolejnoci nie jest cile konieczne. Oczywicie, majc ju* kilka
zdefiniowanych klas, mo*na pewnie prociej poáczyü je wáaciwymi relacjami. Równie
dobre jest jednak wyjcie od tych*e relacji i korzystanie z nich przy definiowaniu klas.
Obydwa wspomniane procesy cz sto wi c odbywaj si jednoczenie.
Poniewa* jednak lepiej jest opisaü ka*dy z nich osobno, zatem od którego nale*y
zaczü :) Zdecydowaáem tedy, *e najpierw poszukamy wáaciwych klas oraz ich
skáadowych, a dopiero potem zajmiemy si áczeniem ich w odpowiedni model.

Zaprojektowanie kompletnego zbioru klas oznacza koniecznoü dopracowywania dwóch
aspektów ka*dej z nich:

abstrakcji, czyli opisu tego, co dana klasa ma robiü

implementacji, to znaczy okrelenia, jak ma to robiü

Teraz naturalnie zajmiemy si kolejno obydowami kwestiami.

Abstrakcja

Je*eli masz pomysá na gr , aplikacj u*ytkow czy te* jakikolwiek inny produkt
programisty, to chyba najgorsz rzecz, jak mo*esz zrobiü, jest natychmiastowe
rozpocz cie jego kodowania. Sáusznie mówi si , *e co nagle, to po diable; niezb dne jest
wi c stworzenie model abstrakcyjnego zanim przystpi si do wáaciwego
programowania.

Model abstrakcyjny powinien opisywaü zaáo*one dziaáanie programu bez precyzowania
szczegóáów implementacyjnych.

Programowanie obiektowe

233

akapicie byáo jednak tylko pozorne, gdy* „niechccy” znale(limy caákiem prosty i
logiczny sposób, wspomagajcy identyfikacj klas.
Mianowicie, powiedzielimy sobie, *e OOP przesuwa rodek ci *koci programowania z
czasowników na rzeczowniki. Te z kolei s tak*e podstaw j zyka naturalnego,
u*ywanego przez ludzi. Prowadzi to do prostego wniosku i jednoczenie drogi do caákiem
dobrego rozwizania dr czacego nas problemu:

Skuteczn pomoc w poszukiwaniu klas odpowiednich dla tworzonego programu mo*e
byü opis jego funkcjonowania w j zyku naturalnym.

Taki opis stosunkowo áatwo jest sporzdziü, pomaga on te* w uporzdkowaniu pomysáu
na program, czyli klarowanym wyra*eniu, o co nam wáaciwie chodzi :) Przykáad takiego
raportu mo*e wygldaü choüby w ten sposób:

Program Graph jest aplikacj przeznaczon do rysowania wszelkiego rodzaju schematów i diagramów
graficznych. Powinien on udost pniaü szerok palet przykáadowych ksztaátów, u*ywanych w takich
rysunkach: bloków, strzaáek, drzew, etykiet tekstowych, figur geometrycznych itp. Edytowany przez
u*ytkownika dokument powinien byü ponadto zapisywalny do pliku oraz eksportowalny do kilku
formatów plików graficznych.

Nie jest to z pewnoci zbyt szczegóáowa dokumentacja, ale na jej podstawie mo*emy
á

atwo wyró*niü spor iloü klas. Nale* do nich przede wszystkim:

dokument

schemat

ró*ne rodzaje obiektów umieszczanych na schematach

Warto te* zauwa*yü, *e powy*szy opis ukrywa te* nieco informacji o zwizkach mi dzy
klasami, np. to, *e schemat zawiera w sobie umieszczone przez u*ytkownika ksztaáty.

Zbiór ten z pewnoci nie jest kompletny, ale stanowi caákiem dobre osigni cie na
pocztek. Daje te* pewne dalsze wskazówki co do mo*liwych kolejnych klas, jakimi mog
byü poszczególne typy ksztaátów skáadajcych si na schemat.

Tak wi c analiza opisu w j zyku naturalnym jest dosyü efektywnym sposobem na
wyszukiwanie potencjalnych klas, skáadajcych si na program. Skutecznoü tej metody
zale*y rzecz jasna w pewnym stopniu od umiej tnoci twórcy aplikacji, lecz jej
stosowanie szybko przyczynia si tak*e do podniesienia poziomu biegáoci w
projektowaniu programów.

Analizowanie opisu funkcjonalnego programu nie jest oczywicie jedynym sposobem

poszukiwania klas. Do pozostaáych nale*y chocia*by sprawdzanie klasycznej „listy

kontrolnej”, zawierajcej cz sto wyst pujce klasy lub te* próba okrelenia dziaáania

jakiej konkretnej funkcji i wykrycia zwizanych z ni klas.

Abstrakcja klasy

Kiedy ju* w przybli*eniu znamy kilka klas z naszej aplikacji, mo*emy spróbowaü okreliü
je bli*ej. Pami tajmy przy tym, *e definicja klasy skáada si z dwóch koncepcyjnych
cz ci:

publicznego interfejsu, dost pnego dla u*ytkowników klasy

prywatnej implementacji, okrelajcej sposób realizacji zachowa okrelonych w
interfejsie

Caá sztuk w modelowaniu pojedynczej klasy jest skoncentrowanie si na pierwszym z
tych skáadników, b dcym jej abstrakcj. Oznacza to zdefiniowanie roli, speánianej
przez klas , bez dokáadnego wgá biania si w to, jak b dzie ona t rol odgrywaáa.

Podstawy programowania

240

// (dalej definicje obu klas, jak w kodzie wy*ej)

Po tym zabiegu kompilator b dzie ju* wiedziaá, *e CBar jest typem (dokáadnie klas) i
pozwoli na zadeklarowanie odpowiedniego wska(nika jako pola klasy CFoo.

Niektórzy, by uniknü takich sytuacji, od razu deklaruj deklaruj wszystkie klasy przed
ich zdefiniowaniem.

Widzimy wi c, *e zwizki dwukierunkowe, jakkolwiek wygodniejsze ni* jednokierunkowe,
wymagaj nieco wi cej uwagi. S te* zwykle mniej wydajne przy áczeniu nim du*ej
liczby obiektów. Prowadzi to do prostego wniosku:

Nie nale*y stosowaü zwizków dwukierunkowych, je*eli w konkretnym przypadku
wystarcz relacje jednokierunkowe.

***

Projektowanie aplikacji nawet z u*yciem technik obiektowych nie zawsze jest prostym
zadaniem. Ten podrozdziaá powinien jednak stanowiü jak pomoc w tym zakresie. Nie da
si jednak ukryü, *e praktyka jest zawsze najlepszym nauczycielem, dlatego
zdecydowanie nie powiniene jej unikaü :) Samodzielne zaprojektowanie i wykonanie
choüby prostego programu obiektowego b dzie bardziej pouczajce ni* lektura
najobszerniejszych podr czników.

Koczacy si podrozdziaá w wielu miejscach dotykaá zagadnie in*ynierii

oprogramowania. Je*eli chciaáby poszerzyü swoj wiedz na ten temat (a warto), to

zapraszam do Materiaáu Pomocniczego C, Podstawy in*ynierii oprogramowania.

Podsumowanie

Kolejny bardzo dáugi i bardzo wa*ny rozdziaá :) Zawiera on bowiem dokoczenie opisu
techniki programowania obiektowego.

Rozpocz limy od mechanizmu dziedziczenia oraz jego roli w ponownym
wykorzystywaniu kodu. Zobaczylimy te*, jak tworzyü proste i bardziej záo*one hierarchie
klasy.
Dalej byáo nawet ciekawiej: dzi ki metodom wirtualnym i polimorfizmu przekonalimy
si , *e programowanie z u*yciem technik obiektowych jest efektywniejsze i prostsze ni*
dotychczas.
Na koniec zostaáe te* obdarzony spor porcj informacji z zakresu projektowania
aplikacji. Dowiedziaáe si wi c o rodzajach obiektów, sposobach znajdowania wáaciwych
klas oraz zwizkach mi dzy nimi.

W nast pnym rozdziale - ostatnim w podstawowym kursie C++ - przypatrzymy si
wska(nikom jako takim, ju* niekoniecznie w kontekcie OOPu. Pomówimy te* o pami ci,
jej alokowaniu i zwalnianiu.

Pytania i zadania

Na kocu rozdziaáu nie mo*e naturalnie zabraknü odpowiedniego pakietu pyta oraz
ü

wicze :)

Wska(niki

245

cztery rejestry uniwersalne (EAX, EBX, ECX i EDX

). Przy ich pomocy procesor

wykonuje operacje arytmetyczne (dodawanie, odejmowanie, mno*enie i
dzielenie). Niektóre wspomagaj te* wykonywanie programów, np. EAX jest
u*ywany do zwracania wyników funkcji, za ECX jako licznik w p tlach.
Rejestry uniwersalne maj wi c najwi ksze znaczenie dla programistów (gáównie
asemblera), gdy* cz sto s wykorzystywane na potrzeby ich aplikacji. Z
pozostaáych natomiast korzysta prawie wyácznie sam procesor.

Ka*dy z rejestrów uniwersalnych zawiera w sobie mniejsze, 16-bitowe, a te z kolei po

dwa rejestry omiobitowe. Mog one byü modyfikowane niezale*nie do innych, ale trzeba

oczywicie pami taü, *e zmiana kilku bitów pociga za sob pewn zmian caáej wartoci.

rejestry segmentowe pomagaj organizowaü pami ü operacyjn. Dzi ki nim
procesor „wie”, w której cz ci RAMu znajduje si kod aktualnie dziaáajcego
programu, jego dane itp.

rejestry wska(nikowe pokazuj na wa*ne obszary pami ci, jak choüby
aktualnie wykonywana instrukcja programu.

dwa rejestry indeksowe s u*ywane przy kopiowaniu jednego fragmentu
pami ci do drugiego.

Ten podstawowy zestaw mo*e byü oczywicie uzupeániony o inne rejestry, jednak
powy*sze s absolutnie niezb dne do pracy procesora.

Najwa*niejsz cech wszystkich rejestrów jest báyskawiczny czas dost pu. Poniewa*
ulokowane s w samym procesorze, skorzystanie z nich nie zmusza do odbycia
„wycieczki” wgáb pami ci operacyjnej i dlatego odbywa si wr cz ekspresowo. Jest to w
zasadzie najszybszy rodzaj pami ci, jakim dysponuje komputer.
Cen za t szybkoü jest oczywicie znikoma obj toü rejestrów - na pewno nie mo*na w
nich przechowywaü záo*onych danych. Co wi cej, ich panem i wáadc jest tylko i
wyácznie sam procesor, zatem nigdy nie mo*na mieü pewnoci, czy zapisane w nich
informacje nie zostan zastpione innymi. Trzeba te* pami taü, *e nieumiej tne
manipulowanie innymi rejestrami ni* uniwersalne mo*e doprowadziü nawet do
zawieszenia komputera; na tak niskim poziomie nie ma ju* bowiem *adnych
komunikatów o bá dach…

Zmienne przechowywane w rejestrach

Mo*emy jednak odnieü pewne korzyci z istnienia rejestrów procesora i sprawiü, by
zacz áy dziaáaü po naszej stronie. Jako niezwykle szybkie porcje pami ci s idealne do
przechowywania maáych, ale cz sto i intensywnie u*ywanych zmiennych.

Na dodatek nie musimy wcale martwiü si o to, w którym dokáadnie rejestrze mo*emy w
danej chwili zapisaü dane oraz czy pozostan one tam nienaruszone. Czynnoci te mo*na
bowiem zleciü kompilatorowi: wystarczy jedynie u*yü sáowa kluczowego

- na

przykáad:

int

nZmiennaRejestrowa;

Gdy opatrzymy deklaracj zmiennej tym modyfikatorem, to b dzie ona w miar
mo*liwoci przechowywana w którym z rejestrów uniwersalnych procesora. Powinno to
rzecz jasna przyspieszyü dziaáanie caáego programu.

Wszystkie nazwy rejestrów odnosz si do procesorów 32-bitowych.

Podstawy programowania

246

Dost p do rejestrów

Rejestry procesora, jako zwizane cisle ze sprz tem, s rzecz niskopoziomow. C++
jest za j zykiem wysokiego poziomu i szczyci si niezale*noci od platformy
sprz towej.

Powoduje to, i* nie posiada on *adnych specjalnych mechanizmów, pozwalajcych
odczytaü lub zapisywaü dane do rejestrów procesora. Zdecydowaáa o tym nie tylko
przenonoü, ale i bezpieczestwo - „mieszanie” w tak zaawansowanych obszarach
systemu mo*e bowiem przynieü sporo szkody.

Jedynym sposobem na uzyskanie dost pu do rejestrów jest skorzystanie z wstawek

asemblerowych, ujmowanych w bloki

__asm

. Mo*na o nich przeczytaü w

MSDN

; u*ywajc

ich trzeba jednak mieü wiadomoü, w co si pakujemy :)

Pami ü operacyjna

Do sensownego funkcjonowania komputera potrzebne jest miejsce, w którym mógáby on
skáadowaü kod wykonywanych przez siebie programów (obejmuje to tak*e system
operacyjny) oraz przetwarzane przez nie dane. Jest to stosunkowo spora iloü informacji,
wi c wymaga znacznie wi cej miejsca ni* to oferuj rejestry procesora. Ka*dy komputer
posiada wi c osobn pami ü operacyjn, przeznaczon na ten wáanie cel. Nazywamy
j cz sto angielskim skrótem RAM (ang. random access memory - pami ü o dost pie
bezporednim).

Skd si bierze pami ü operacyjna?

Pami ü tego rodzaju uto*samiamy zwykle z jedn lub kilkoma elektronicznymi ukáadami
scalonymi (tzw. koümi), wáo*onymi w odpowiednie miejsca páyty gáównej peceta.

Fotografia 2. Kilka koci RAM typu DIMM

(zdj cie pochodzi z serwisu

Tom’s Hardware Guide

)

Rzeczywicie jest to najwa*niejsza cz ü tej pami ci (sama zwana jest czasem pami ci
fizyczn), ale na pewno nie jedyna. Obecnie wiele podzespoáów komputerowych posiada
wáasne zasoby pami ci operacyjnej, przystosowane do wykonywania bardziej
specyficznych zada.
W szczególnoci dotyczy to kart graficznych i d(wi kowych, zoptymalizowanych do pracy
z wáaciwymi im typami danych. Iloü pami ci, w jak s wyposa*ane, systematycznie
ronie.

Wska(niki

249

Páaski model pami ci

Dzisiejsze systemy operacyjne maj znacznie wygodniejszy sposób organizacji pami ci
RAM. Jest nim wáanie ów páaski model (ang. flat memory model), likwidujcy wiele
mankamentów swego segmentowego poprzednika.

32-bitowe procesory pozwalaj mianowicie, by caáa pami ü byáa jednym segmentem.
Taki segment mo*e mieü rozmiar nawet 4 gigabajtów, wi c z áatwoci zmieszcz si w
nim wszystkie fizyczne i wirtualne zasoby RAMu.
To jednak*e nie wszystko. Otó* páaski model umo*liwia zgrupowanie wszystkich
dost pnych rodzajów pami ci operacyjnej (koci RAM, plik wymiany, pami ü karty
graficznej, itp.) w jeden cigáy obszar, zwany przestrzeni adresow. Programista nie
musi si przy tym martwiü, do jakiego szczególnego typu pami ci odnosi si dany
wska(nik! Na poziomie j zyka programowania znikaj bowiem wszelkie praktyczne
ró*nice mi dzy nimi: oto mamy jeden, wielki segment caáej pami ci operacyjnej i
basta!

Schemat 32. Idea páaskiego modelu pami ci. Adresy skáadaj si tu tylko z offsetów,

przechowywanych jako liczby 32-bitowe. Mog one odnosiü si do jakiegokolwiek rzeczywistego

rodzaju pami ci, na przykáad do takich jak na ilustracji.

W Windows dodatkowo ka*dy proces (program) posiada swoj wáasn przestrze

adresow, niedost pn dla innych. Wymiana danych mo*e wi c zachodzi jedynie poprzez

dedykowane do tego mechanizmy. B dziemy o nich mówiü, gdy ju* przejdziemy do

programowania aplikacji okienkowych.

Przy takim modelu pami ci porównanie jej do ogromnej, jednowymiarowej tablicy staje
si najzupeániej sáuszne. Wska(niki mo*na sobie wtedy caákiem dobrze wyobra*aü jako
indeksy tej tablicy.

Stos i sterta

Na koniec wspomnimy sobie o dwóch wa*nych dla programistów rejonach pami ci
operacyjnych, a wi c wáanie o stosie oraz stercie.

Czym jest stos?

Stos (ang. stack) jest obszarem pami ci, który zostaje automatycznie przydzielony do
wykorzystania dla programu.

Podstawy programowania

250

Na stosie egzystuj wszystkie zmienne zadeklarowane jawnie w kodzie (szczególne te
lokalne w funkcjach), jest on tak*e u*ywany do przekazywania parametrów do funkcji.

Faktycznie wi c mo*na by w ogóle nie wiedzieü o jego istnieniu. Czasem jednak objawia
si ono w doü nieprzyjemny sposób: poprzez bád przepeánienia stosu (ang. stack
overflow). Wyst puje on zwykle wtedy, gdy nastpi zbyt wiele wywoáa funkcji.

O stercie

Reszta pami ci operacyjnej nosi oryginaln nazw sterty.

Sterta (ang. heap) to caáa pami ü dost pna dla programu i mogca byü mu przydzielona
do wykorzystania.

Czytajc oba opisy (stosu i sterty) pewnie trudno jest wychwyciü mi dzy nimi jakie
ró*nice, jednak w rzeczywistoci s one caákiem spore.

Przede wszystkim, rozmiar stosu jest ustalany raz na zawsze podczas kompilacji
programu i nie zmienia si w trakcie jego dziaáania. Wszelkie dane, jakie s na nim
przechowywane, musz wi c mieü staáy rozmiar - jak na przykáad skalarne zmienne,
struktury czy te* statyczne tablice.
Kontrol pami ci sterty zajmuje si natomiast sam programista i dlatego mo*e przyznaü
swojej aplikacji odpowiedni jej iloü w danej chwili, podczas dziaáania programu. Jest
to bardzo dobre rozwizanie, kiedy konieczne jest przetwarzanie zbiorów informacji o
zmiennym rozmiarze.

Terminy ‘stos’ i ‘sterta’ maj w programowaniu jeszcze jedno znaczenie. Tak mianowicie

nazywaj si dwie cz sto wykorzystywane struktury danych. Omówimy je przy okazji

poznawania Biblioteki Standardowej C++.

***

Na tym zakoczymy ten krótki wykáad o samej pami ci operacyjnej. Cz ü tych
wiadomoci byáa niektórym pewnie doskonale znana, ale chyba ka*dy miaá okazj
dowiedzieü si czego nowego :)

Wiedza ta b dzie nam teraz szczególnie przydatna, gdy* rozpoczynamy wreszcie
zasadnicz cz ü tego rozdziaáu, czyli omówienie wska(ników w j zyku C++: najpierw na
zmienne, a potem wska(ników na funkcje.

Wska(niki na zmienne

Trudno zliczyü, ile razy stosowalimy zmienne w swoich programach. Takie statystyki nie
maj zreszt zbytniego sensu - programowanie bez u*ycia zmiennych jest przecie* tym
samym, co prowadzenie samochodu bez korzystania z kierownicy ;D

Wiele razy przypominaáem te*, *e zmienne rezyduj w pami ci operacyjnej. Mechanizm
wska(ników na nie jest wi c zupeánie logiczn konsekwencj tego zjawiska. W tym
podrozdziale zajmiemy si wáanie takimi wska(nikami.

U*ywanie wska(ników na zmienne

Wska(nik jest przede wszystkim liczb - adresem w pami ci, i w takiej te* postaci istnieje
w programie. J zyk C++ ma ponadto cisáe wymagania dotyczce kontroli typów i z tego
powodu ka*dy wska(nik musi mieü dodatkowo okrelony typ, na jaki wskazuje. Innymi