Kurs C++ Od Zera Do Gier Kodera.pdf

Podstawy programowania

202

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Mo*na zauwa*yü, ze bazowa klasa CChessPiece nie bdzie 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 bdziemy 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 jzyku 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 jzyków, które udostpniaj 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 wic posiadaü caákiem spore
dowiadczenie w programowaniu.
Jakkolwiek zatem dziedziczenie wielokrotne bywa czasem przydatnym narzdziem,
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 wikszoci 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 nastrczaü pewnych problemów. S one
zazwyczaj specyficzne dla konkretnego jzyka programowania, jako *e wystpuj w tym
wzgldzie pewne ró*nice midzy nimi.

W tym paragrafie zajmiemy si takimi wáanie drobnymi niuansami, które s zwizane z
dziedziczeniem klas w jzyku 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 wewntrznych obiektów czy te* alokacja
dodatkowej pamici. Czynnoci te prawie zawsze wymagaj zatem dostpu do
prywatnych pól klasy. Je*eli wic konstruktor z klasy bazowej zostaáby „wrzucony”
do klasy pochodnej, to utraciáby z nimi niezbdne 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 szczliwe rozwizanie skáadniowe, poniewa* mo*e czsto
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 zastpuje star, która jest jednak dostpna 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
bdzie wyjanienie ró*nicy pomidzy 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 czsto 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 wic 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 zbdne 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 oszczdnociowych :))

public

virtual

void

Oddychaj() =

;

};

Jest nim wystpujca 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 wic 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 bdzie 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 wzgldu 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 jzyka Object Pascal.

Takie klasy buduj zawsze najwy*sze pitra 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 bdzie 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 wic poni*szy kod bdzie 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 bdzie 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 pojcia „klasy” i „obiekty”, rodkowe pitra budowaáoby
„dziedziczenie” oraz „metody wirtualne”, za u samego szczytu sytuowaáby si
„polimorfizm”. Jest to bowiem najwiksze osignicie 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 bdzie si wic odnosiü do takich tworów, które
mo*na interpretowaü na ró*ne sposoby - a wic 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

wzgldna 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 wic nic ponad autora, tytuá oraz dat stworzenia dokumentu.

Trzeba jednak przyznaü, *e sami niejako jestemy sobie winni. Wyodrbniajc 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 bdzie uczynienie
jej funkcj wirtualn - wtedy klasy dziedziczce od CDocument bd 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

{

(wikszoü skáadowych wycito z powodu zbyt du*ej objtoci)

public

virtual

void

PokazDane();

};

// (reszty klas nieuwzgldniono 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. Nastpnie 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 zwierzcia, dziedziczcego z klasy bazowej IAnimal.

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

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

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

takie mog wic 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 wic 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

, dziki 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 bdzie, 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 bdzie

dokonanie podanego rzutowania.

Aby j wychwyciü potrzebujemy oczywicie dodatkowego warunku, porównujcego
zmienn pSsak z t specjaln wartoci NULL (bdc 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 wiksze 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 pamici (access violation).

Nale*y wic 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

nastpnym 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 czci RTTI, czyli operatora

typeid

, generalnie nie jest tak

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

Skorzystanie z RTTI wymaga podjcia dwóch wstpnych 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. Bdzie on zreszt punktem wyjcia dla nieco bardziej szczegóáowych
kwestii, opisanych pó(niej.
Pomówmy wic kolejno o ka*dym rodzaju z owej podstawowej trójki.

Singletony

Wikszoü 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 wic co najwy*ej jeden egzemplarz
klasy, bdcej singletonem.

Obiekty takie s dosáownie jedyne w swoim rodzaju i dlatego zwykle przechowuj one
najwa*niejsze dane programu oraz wykonaj wikszoü newralgicznych czynnoci.
Najczciej 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(wik, sieü,
AI, itd., w edytorach: moduáy obsáugi plików, dokumentów, formatowania itp.

Niekiedy zastosowanie singletonów wymuszaj warunki zewntrzne, 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 wikszoci odwoáaniami do innych obiektów: niekiedy do wielu drobnych, ale
czciej do kilku kolejnych zarzdców, czyli nastpnego, ni*szego poziomu hierarchii
zawierania si obiektów.

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

Przykáady wykorzystania

Najbardziej oczywistym przykáadem singletonu mo*e byü caáociowy obiekt programu,
a wic klasa w rodzaju CApplication czy CGame. Bdzie ona nadrzdnym obiektem
wobec wszystkich innych, a tak*e przechowywaáa bdzie 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 bd 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 wystpuj w pojedynczych instancjach, gdy* unikatowa jest ich rola.
Kwesti otwart jest natomiast ich ewentualna podlegáoü najbardziej nadrzdnemu
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 bd 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 dostpowej do niego, która
zreszt tak*e bdzie 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 nastpuje wic przy pierwszym
u*yciu.
Odbywa si ona poprzez bezporednie wywoáanie konstruktora… którego na razie nie
mamy (jest domylny)! Czym prdzej 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 wicej ni* jednej kopii naszego singletonu.
Uprawniona do wywoáania prywatnego konstruktora jest bowiem tylko skáadowa klasy,
czyli metoda CSingleton::Obiekt(). Wszelkie zewntrzne próby stworzenia obiektu
klasy CSingleton zakocz si wic bádem kompilacji, za jedyny jego egzemplarz
bdzie dostpny wyácznie poprzez wspomnian metod.

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

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

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

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

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 bdzie 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 nastpnym rozdziale.

à

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

które mo*na i trzeba realizowaü jako obiekty narzdziowe. 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

pamici 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 bd si na skáadaáy, oraz pól i metod, które zostan
zawarte w ich definicjach. Drugim jest okrelenie zwizków pomidzy tymi klasami,
dziki 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 czsto wic 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
rozpoczcie jego kodowania. Sáusznie mówi si, *e co nagle, to po diable; niezbdne jest
wic 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 jzyka naturalnego,
u*ywanego przez ludzi. Prowadzi to do prostego wniosku i jednoczenie drogi do caákiem
dobrego rozwizania drczacego nas problemu:

Skuteczn pomoc w poszukiwaniu klas odpowiednich dla tworzonego programu mo*e
byü opis jego funkcjonowania w jzyku 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 udostpniaü 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 midzy
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 osignicie 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 wic analiza opisu w jzyku 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 umiejtnoci 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 czsto wystpujce 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. Pamitajmy przy tym, *e definicja klasy skáada si z dwóch koncepcyjnych
czci:

publicznego interfejsu, dostpnego 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, bdcym jej abstrakcj. Oznacza to zdefiniowanie roli, speánianej
przez klas, bez dokáadnego wgábiania si w to, jak bdzie ona t rol odgrywaáa.

Podstawy programowania

240

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

Po tym zabiegu kompilator bdzie 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 wic, *e zwizki dwukierunkowe, jakkolwiek wygodniejsze ni* jednokierunkowe,
wymagaj nieco wicej 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 bdzie bardziej pouczajce ni* lektura
najobszerniejszych podrcznikó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.

Rozpoczlimy 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: dziki 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 wic o rodzajach obiektów, sposobach znajdowania wáaciwych
klas oraz zwizkach midzy nimi.

W nastpnym rozdziale - ostatnim w podstawowym kursie C++ - przypatrzymy si
wska(nikom jako takim, ju* niekoniecznie w kontekcie OOPu. Pomówimy te* o pamici,
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 ptlach.
Rejestry uniwersalne maj wic najwiksze znaczenie dla programistów (gáównie
asemblera), gdy* czsto 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 pamitaü, *e zmiana kilku bitów pociga za sob pewn zmian caáej wartoci.

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

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

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

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

Najwa*niejsz cech wszystkich rejestrów jest báyskawiczny czas dostpu. Poniewa*
ulokowane s w samym procesorze, skorzystanie z nich nie zmusza do odbycia
„wycieczki” wgáb pamici operacyjnej i dlatego odbywa si wrcz ekspresowo. Jest to w
zasadzie najszybszy rodzaj pamici, jakim dysponuje komputer.
Cen za t szybkoü jest oczywicie znikoma objtoü rejestrów - na pewno nie mo*na w
nich przechowywaü záo*onych danych. Co wicej, 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* pamitaü, *e nieumiejtne
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 pamici s idealne do
przechowywania maáych, ale czsto 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 bdzie 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

Dostp do rejestrów

Rejestry procesora, jako zwizane cisle ze sprztem, s rzecz niskopoziomow. C++
jest za jzykiem wysokiego poziomu i szczyci si niezale*noci od platformy
sprztowej.

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 dostpu 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,
wic wymaga znacznie wicej miejsca ni* to oferuj rejestry procesora. Ka*dy komputer
posiada wic osobn pamiü operacyjn, przeznaczon na ten wáanie cel. Nazywamy
j czsto angielskim skrótem RAM (ang. random access memory - pamiü o dostpie
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

(zdjcie pochodzi z serwisu

Tom’s Hardware Guide

)

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

Wska(niki

249

Páaski model pamici

Dzisiejsze systemy operacyjne maj znacznie wygodniejszy sposób organizacji pamici
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, wic 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
dostpnych rodzajów pamici 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 pamici odnosi si dany
wska(nik! Na poziomie jzyka programowania znikaj bowiem wszelkie praktyczne
ró*nice midzy nimi: oto mamy jeden, wielki segment caáej pamici operacyjnej i
basta!

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

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

rodzaju pamici, na przykáad do takich jak na ilustracji.

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

adresow, niedostpn dla innych. Wymiana danych mo*e wic zachodzi jedynie poprzez

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

programowania aplikacji okienkowych.

Przy takim modelu pamici 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 pamici
operacyjnych, a wic wáanie o stosie oraz stercie.

Czym jest stos?

Stos (ang. stack) jest obszarem pamici, 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 wic 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). Wystpuje on zwykle wtedy, gdy nastpi zbyt wiele wywoáa funkcji.

O stercie

Reszta pamici operacyjnej nosi oryginaln nazw sterty.

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

Czytajc oba opisy (stosu i sterty) pewnie trudno jest wychwyciü midzy 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 wic mieü staáy rozmiar - jak na przykáad skalarne zmienne,
struktury czy te* statyczne tablice.
Kontrol pamici 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 czsto wykorzystywane struktury danych. Omówimy je przy okazji

poznawania Biblioteki Standardowej C++.

***

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

Wiedza ta bdzie nam teraz szczególnie przydatna, gdy* rozpoczynamy wreszcie
zasadnicz czü tego rozdziaáu, czyli omówienie wska(ników w jzyku 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 pamici operacyjnej. Mechanizm
wska(ników na nie jest wic 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 pamici, i w takiej te* postaci istnieje
w programie. Jzyk 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