Kurs C++ Od Zera Do Gier Kodera.pdf

Záo*one zmienne

157

RysujPlansze(), do których kompilator nie ma najmniejszych zastrze*e. Czy*by wic
tutaj dopadáa go nagáa amnezja?

Wyjanienie tego, jak by si wydawaáo, doü dziwnego zjawiska jest jednak w miar
logiczne. Otó* g_StanGry zostaáa zadeklarowana wewntrz moduáu game.cpp, wic jej
zasig ogranicza si jedynie do tego* moduáu. Funkcja main(), znajdujca si w pliku
main.cpp, jest poza tym zakresem, zatem dla niej rzeczona zmienna po prostu nie
istnieje. Nic dziwnego, i* kompilator staje si wobec nieznanej nazwy g_StanGry
zupeánie bezradny.
Nasuwa si oczywicie pytanie: jak zaradziü temu problemowi? Co zrobiü, aby nasza
zmienna byáa dostpna wewntrz funkcji main()?… Chyba najszybciej pomyleü mo*na o
przeniesieniu jej deklaracji w obszar wspólny dla obu moduáów game.cpp oraz main.cpp.
Takim wspóádzielonym terenem jest naturalnie plik nagáówkowy game.h. Czy nale*y wic
umieciü tam deklaracj GAMESTATE g_StanGry = GS_NOTSTARTED;?
Niestety, nie jest to poprawne. Musimy bowiem wiedzieü, *e zmienna nie mo*e
rezydowaü wewntrz nagáówka! Jej prawidáowe zdefiniowanie powinno byü zawsze
umieszczone w module kodu. W przeciwnym razie ka*dy moduá, który doáczy plik
nagáówkowy z definicj zmiennej, stworzy swoj wáasn kopi tej*e! U nas znaczyáoby
to, *e zarówno main.cpp, jak i game.cpp posiadaj zmienne o nazwach g_StanGry, ale s
one od siebie caákowicie niezale*ne i „nie wiedz o sobie nawzajem”!

Definicja musi zatem pozostaü na swoim miejscu, ale plik nagáówkowy niewtpliwie nam
si przyda. Mianowicie, wpiszemy do nastpujc linijk:

extern

GAMESTATE g_StanGry;

Jest to tak zwana deklaracja zapowiadajca zmiennej. Jej zadaniem jest
poinformowanie kompilatora, *e gdzie w programie

istnieje zmienna o podanej nazwie

i typie. Deklaracja ta nie tworzy *adnego nowego bytu ani nie rezerwuje dla miejsca w
pamici operacyjnej, lecz jedynie zapowiada (std nazwa), i* czynnoü ta zostanie
wykonana. Obietnica ta mo*e byü speániona podczas kompilacji lub (tak jak u nas)
dopiero w czasie linkowania.
Z praktycznego punktu widzenia deklaracja

extern

(ang. external - zewntrzny) peáni

bardzo podobn rol, co prototyp funkcji. Podaje bowiem jedynie minimum informacji,
potrzebnych do skorzystania z deklarowanego tworu bez marudzenia kompilatora, a
jednoczenie odkáada jego wáaciw definicj w inne miejsce i/lub czas.

Deklaracja zapowiadajca (ang. forward declaration) to czciowe okrelenie jakiego
programistycznego bytu. Nie definiuje dokáadnie wszystkich jego aspektów, ale wystarcza
do skorzystania z niego wewntrz zakresu umieszczenia deklaracji.
Przykáadem mo*e byü prototyp funkcji czy u*ycie sáowa

extern

dla zmiennej.

Umieszczenie powy*szej deklaracji w pliku nagáówkowym game.h udostpnia zatem
zmienn g_StanGry wszystkim moduáom, które doácz wspomniany nagáówek. Tym
samym jest ju* ona znana tak*e funkcji main(), wic ponowna kompilacja powinna
przebiec bez *adnych problemów.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Czujny czytelnik zauwa*yá pewnie, *e doü swobodnie operuj terminami „deklaracja”

oraz „definicja”, u*ywajc ich zamiennie. Niektórzy puryci ka* jednak je rozró*niaü.

Wedáug nich jedynie to, co nazwalimy przed momentem „deklaracja zapowiadajc”,

mo*na nazwaü krótko „deklaracj”. „Definicj” ma byü za to dokáadne sprecyzowanie

cech danego obiektu, oraz, przede wszystkim, przygotowanie dla niego miejsca w

pamici operacyjnej.

Mówic cile: gdzie poza bie*cym zakresem.

Podstawy programowania

158

Zgodnie z tak terminologi instrukcje w rodzaju

int

nX; czy

float

fY; miaáyby byü

„definicjami zmiennych”, natomiast

extern int

nX; oraz

extern float

fY; -

„deklaracjami”. Osobicie twierdz, *e jest to jeden z najjaskrawszych przykáadów

szukania dziury w caáym i prób niezmiernego gmatwania programistycznego sáownika.

Czy ktokolwiek przecie* mówi o „definicjach zmiennych”? Pojcie to brzmi tym bardziej

sztucznie, *e owe „definicje” nie przynosz *adnych dodatkowych informacji w stosunku

do „deklaracji”, a skáadniowo s od nich nawet krótsze!

Jak wic w takiej sytuacji nie nazwaü spierania si o nazewnictwo zwyczajnym

malkontenctwem? :)

Uruchamiamy aplikacj

To niemal*e niewiarygodne, jednak staáo si faktem! Zakoczylimy w kocu
programowanie naszej gry! Wreszcie mo*esz wic u*yü klawisza F5, by cieszyü tym oto
wspaniaáym widokiem:

Screen 30. Gra w „Kóáko i krzy*yk” w akcji

A po kilkunastominutowym, zasáu*onym relaksie przy wáasnorcznie napisanej grze
przejd( do dalszej czci tekstu :)

Wnioski

Stworzyáe wáanie (przy drobnej pomocy :D) swój pierwszy w miar powa*ny program,
w dodatku to, co lubimy najbardziej - czyli gr. Zdobyte przy tej okazji dowiadczenie
jest znacznie cenniejsze od najlepszego nawet, lecz tylko teoretycznego wykáadu.

Warto wic podsumowaü nasz prac, a przy okazji odpowiedzieü na pewne ogólne
pytania, które byü mo*e przyszáy ci na myl podczas realizacji tego projektu.

Dziwaczne projektowanie

Tworzenie naszej gry rozpoczlimy od jej dokáadnego zaprojektowania. Miaáo ono na
celu wykreowanie komputerowego modelu znanej od dziesicioleci gry dwuosobowej i
zaadaptowanie go do potrzeb kodowania w C++.
W tym celu podzielilimy sobie zadanie na trzy czci:

okrelenie struktur danych wykorzystywanych przez aplikacj

sprecyzowanie wykonywanych przez ni czynnoci

stworzenie interfejsu u*ytkownika

Aby zrealizowaü pierwsze dwie, musielimy przyjü doü dziwn i raczej nienaturaln
drog rozumowania. Nale*aáo bowiem zapomnieü o takich „namacalnych” obiektach jak
plansza, gracz czy rozgrywka. Zamiast tego mówilimy o pewnych danych, na których
program miaá wykonywaü jakie operacje.
Te dwa wiaty - statycznych informacji oraz dynamicznych dziaáa - rozdzieliáy nam owe
„naturalne” obiekty zwizane z gr i kazaáy oddzielnie zajmowaü si ich cechami (jak np.
symbole graczy) oraz realizowanymi przeze czynnociami (np. wykonanie ruchu).

Záo*one zmienne

159

Podejcie to, zwane programowaniem strukturalnym, mogáo byü dla ciebie trudne do
zrozumienia i sztuczne. Nie martw si tym, gdy* podobnie uwa*a wikszoü
wspóáczesnych koderów! Czy to znaczy, *e programowanie jest udrk?
Domylasz si pewnie, *e wszystko co niedawno uczynilimy, daáoby si zrobiü bardziej
naturalnie i intuicyjne. Masz w tym caákowit racj! Ju* w nastpnym rozdziale poznamy
znacznie wygodniejsz i przyja(niejsz technik programowania, który zbli*y kodowanie
do ludzkiego sposobu mylenia.

Doü skomplikowane algorytmy

Kiedy ju* uporalimy si z projektowaniem, przyszedá czas na uruchomienie naszego
ulubionego rodowiska programistycznego i wpisanie kodu tworzonej aplikacji.

Jakkolwiek wikszoü u*ytych przy tym konstrukcji jzyka C++ byáa ci znana od dawna,
a du*a czü pozostaáej mniejszoci wprowadzona w tym rozdziale, sam kod nie nale*aá z
pewnoci do elementarnych. Ró*nica midzy poprzednimi, przykáadowymi programami
byáa znaczca i widoczna niemal przez caáy czas.
Na czym ona polegaáa? Po prostu jzyk programowania przestaá tu byü celem, a staá si

rodkiem. Ju* nie tylko pr*yá swe „muskuáy” i prezentowaá szeroki wachlarz mo*liwoci.

Staá si w pokornym sáug, który speániaá nasze wymagania w imi wy*szego d*enia,
którym byáo napisanie dziaáajcej i sensownej aplikacji.

Oczywiste jest wic, i* zaczlimy wymagaü wicej tak*e od siebie. Pisane algorytmy nie
byáy ju* trywialnymi przepisami, wywa*ajcymi otwarte drzwi. Wy*yny w tym wzgldzie
osignlimy chyba przy sprawdzaniu stanu planszy w poszukiwaniu ewentualnych
sekwencji wygrywajcych. Zadanie to byáo swoiste i unikalne dla naszego kodu, dlatego
te* wymagaáo nieszablonowych rozwiza. Takich, z jakimi bdziesz si czsto spotykaá.

Organizacja kodu

Ostatnia uwaga dotyczy porzdku, jaki wprowadzilimy w nasz kod (ródáowy. Zamiast
pojedynczego moduáu zastosowalimy dwa i zintegrowalimy je przy pomocy wáasnego
pliku nagáówkowego.

Nie obyáo si rzecz jasna bez drobnych problemów, ale ogólnie zrobilimy to w caákowicie
poprawny i efektywny sposób. Nie mo*na te* zapominaü o tym, *e jednoczenie
poznalimy kolejny skrawek informacji na temat programowania w C++, tym razem
dotyczcy dyrektywy

#include

, prototypów funkcji oraz modyfikatora

extern

Drogi samodzielny programisto - ty, który dokoczyáe kod gry od momentu, w którym

rozstalimy si nagáówkiem game.h, bez zagldania do dalszej czci tekstu!

Je*eli udaáo ci si dokonaü tego z zachowaniem zaáo*onej funkcjonalnoci programu oraz

podziaáu kodu na trzy odrbne pliki, to naprawd chyl czoáa :) Znaczy to, *e jeste

wrcz idealnym kandydatem na wietnego programist, gdy* sam potrafiáe rozwizaü

postawiony przed tob szereg problemów oraz znalazáe brakujce ci informacje w

odpowiednich (ródáach. Gratulacje!

Aby jednak uniknü ewentualnych káopotów ze zrozumieniem dalszej czci kursu,

doradzam powrót do opuszczonego fragmentu tekstu i przeczytanie chocia* tych

urywków, które dostarczaj wspomnianych nowych informacji z zakresu jzyka C++.

Podsumowanie

Dotarlimy (wreszcie!) do koca tego rozdziaáu. Nabyáe w nim bardzo du*o wiadomoci
na temat modelowania záo*onych struktur danych w C++.

Obiekty

163

W tym okresie stworzone zostaáy znane i u*ywane do dzi jzyki - Pascal, C czy BASIC.
Programowanie staáo si áatwiejsze, bardziej dostpne i popularniejsze - równie* wród
niewielkiej jeszcze grupy u*ytkowników domowych komputerów. Pocignáo to za sob
tak*e rozwój oprogramowania: pojawiáy si systemy operacyjne w rodzaju Unixa, DOSa
czy Windows (wszystkie napisane w C), rosáa te* liczba przeznaczonych dla aplikacji.
Chocia* niekiedy pisano jeszcze drobne fragmenty kodu w asemblerze, ogromna
wikszoü projektów byáa ju* realizowana wedle zasad programowania strukturalnego.

Mo*na w zasadzie powiedzieü, *e z posiadanymi umiejtnociami sytuujemy si wáanie
w tym punkcie historii. Wprawdzie u*ywamy jzyka C++, ale dotychczas korzystalimy
jedynie z tych jego mo*liwoci, które byáy dostpne tak*e w C.
To si oczywicie wkrótce zmieni :)

Skostniaáe standardy

Czasy wietnoci metod programowania strukturalnego trwaáy zaskakujco dáugo, bo a*
kilkanacie lat. Mo*e to si wydawaü dziwne - szczególnie w odniesieniu do,
przywoáywanego ju* niejednokrotnie, wyjtkowo sztucznego projektowania kodu przy
u*yciu tych*e metod. Je*eli dodamy do tego fakt, i* ju* wtedy istniaáa caákiem poka(na
liczba jzyków trzeciej generacji, pozwalajcych na programowanie obiektowe

sytuacja jawi si wrcz niedorzecznie. Dlaczego koderzy nie porzucili swych wysáu*onych
i topornych instrumentów przez tak dáugi okres?…

„Winowajc” jest gáównie jzyk C, który zd*yá przez ten czas urosnü do rangi niemal
jedynego sáusznego jzyka programowania. Jako *e byá on narzdziem, którego u*ywano
nawet do pisania systemów operacyjnych, istniaáo mnóstwo jego kompilatorów oraz
ogromna liczba stworzonych w nim programów. Zmiana tak silnie zakorzenionego
standardu byáa w zasadzie niemo*liwa, tote* przez wiele lat nikt si jej nie podjá.

Obiektów czar

A* tu w 1983 roku duski programista Bjarne Stroustrup zaprezentowaá stworzony przez
siebie jzyk C++. Miaá on niezaprzeczaln zalet (jzyk, nie jego twórca ;D): áczyá
skáadni C (przez co zachowywaá kompatybilnoü z istniejcymi aplikacjami) z
mo*liwociami programowania zorientowanego obiektowo.
Fakt ten sprawiá, *e C++ zaczá powoli wypieraü swego poprzednika, zajmujc czoáowe
miejsce wród u*ywanych jzyków programowania. Zajmuje je zreszt do dzi.

Obiektowych nastpców dorobiáy si te* dwa pozostaáe jzyki strukturalne. Pascal

wyewoluowaá w Object Pascala, który jest podstaw dla popularnego rodowiska Delphi.

BASIC’iem natomiast zaopiekowaá si Microsoft, tworzc z niego Visual Basic; dopiero

jednak ostatnie wersje tego jzyka (oznaczone jako .NET) mo*na nazwaü w peáni

obiektowymi.

Co dalej?

Zaraz, w takim razie programowanie obiektowe i nasz ulubiony jzyk C++ maj ju* z
gór dwadziecia lat - w wiecie komputerów to przecie* caáy eon! Czy zatem technologii
tej nie czeka rycháy schyáek?…

Mo*naby tak przypuszczaü, gdyby istniaáa inna, równorzdna wobec OOPu technika
programowania. Dotychczas jednak nikt nie wynalazá niczego takiego i nie zanosi si na
to w przewidywalnej przyszáoci :) Programowanie obiektowe ma si dzisiaj co najmniej

Byáy to na przykáad LISP albo Smalltalk.

Podstawy programowania

170

Ka*dy obiekt posiada swój wáasny pakiet opisujcych go pól, które rezyduj w pamici
operacyjnej w identyczny sposób jak pola struktur. Metody s natomiast kodem
wspólnym dla caáej klasy, zatem w czasie dziaáania programu istnieje w pamici tylko
jedna ich kopia, wywoáywana w razie potrzeby na rzecz ró*nych obiektów. Jest to, jak
sdz, doü oczywiste: tworzenie odrbnych kopii tych samych przecie* funkcji dla
ka*dego nowego obiektu byáoby niewtpliwie szczytem absurdu.

Dwa etapy okrelania klasy

Skoro dowiedzielimy si dokáadnie, czym s klasy i jak (w teorii) dziaáaj, spójrzmy na
sposoby ich wykorzystania w jzyku C++. Zaczniemy rzecz jasna od wprowadzania do
programu wáasnych typów obiektowych, gdy* bez tego ani rusz :)

Na pocztek warto przypomnieü, i* klasa jest typem (podobnie jak struktura czy

enum

wic wáaciwym dla niej miejscem byáby zawsze plik nagáówkowy. Jednoczenie jednak
zawiera ona kod swoich funkcji skáadowych, czyli metod, co czyni j przynale*n do
jakiego moduáu (bo tylko wewntrz moduáów mo*na umieszczaü funkcje).
Te dwa przeciwstawne stanowiska sprawiaj, *e okrelenie klasy jest najczciej
rozdzielone na dwie czci:

definicj, wstawian w pliku nagáówkowym, w której okrelamy pola klasy oraz
wpisujemy prototypy jej metod

implementacj, umieszczan w module, bdc po prostu kodem wczeniej
zdefiniowanych metod

Ukáad ten nie doü, *e dziaáa nadzwyczaj dobrze, to jeszcze realizuje jeden z postulatów
programowania obiektowego, jakim jest ukrywanie niepotrzebnych szczegóáów.
Tymi szczegóáami bdzie tutaj kod poszczególnych metod, którego znajomoü nie jest
wcale potrzebna do korzystania z klasy.

Co wicej, mo*e on nie byü w ogóle dostpny w postaci pliku .cpp, a jedynie w wersji
skompilowanej! Tak jest chocia*by w przypadku biblioteki DirectX, o czym przekonasz si
za czas jaki.

Domylasz si zatem, *e za chwil skoncentrujemy si na tych dwóch etapach okrelania
klasy, a wic na definicji i implementacji. Jakkolwiek nie brzmi to zbyt odkrywczo, jednak
masz tutaj caákowit sáusznoü :D

Czasem, jeszcze przed definicj klasy musimy poinformowaü kompilator, *e dana nazwa

jest faktycznie klas. Robimy tak na przykáad wtedy, gdy obiekt klasy A odwoáuje si do

klasy B, za B do A. U*ywamy wtedy deklaracji zapowiadajcej, piszc po prostu

class

A; lub

class

B;.

Takie przypadki s dosyü rzadkie, ale warto wiedzieü, jak sobie z nimi radziü. O tym

sposobie wspomnimy zreszt nieco dokáadniej, gdy bdziemy zajmowaü si klasami

zaprzyja(nionymi.

Definicja klasy

Jest to konieczna i czsto pierwsza czynnoü przy wprowadzaniu do programu nowej
klasy. Jej definicja precyzuje bowiem zawarte w niej pola oraz deklaracje metod, którymi
klasa bdzie dysponowaáa.

Informacje te s niezbdne, aby móc utworzyü obiekt danej klasy; dlatego te*
umieszczamy je niemal zawsze w pliku nagáówkowym - miejscu nale*nym wáasnym
typom danych.
Skáadnia definicji klasy wyglda natomiast nastpujco:

class

nazwa_klasy

Obiekty

171

{

[specyfikator_dostpu:]

[pola]

[metody]

};

Nie widaü w niej zbytnich restrykcji, gdy* faktycznie jest ona caákiem swobodna.
Kolejnoü poszczególnych elementów (pól lub metod) nie jest cile ustalona i mo*e byü
w zasadzie dowolnie zmieniana. Najlepiej jednak zachowaü w tym wzgldzie jaki
porzdek, grupujc np. pola i metody w zwarte grupy.
Na razie wszak*e trudno byáoby stosowaü si do tych rad, skoro nie omówilimy
dokáadnie wszystkich czci definicji klasy. Czym prdzej wic naprawiamy ten bád :)

Kontrola dostpu do skáadowych klasy

Fraza oznaczona jako specyfikator_dostpu pewnie nie mówi ci zbyt wiele, chocia*
spotkalimy si ju* z ni w której z przykáadowych klas. Przyjmowaáa ona tam form

private

lub

public

, dzielc caáa definicj na jakby dwie odrbne sekcje. Nietrudno

wywnioskowaü, i* podziaá ten nie ma jedynie charakteru wizualnego, ale powoduje dalej
idce konsekwencje. Jakie?…

Nazwa specyfikator_dostpu, chocia* brzmi mo*e nieco sztucznie (jak zreszt wiele
terminów w programowaniu :)), dobrze oddaje rol, jak ta konstrukcja peáni. Otó*
specyfikuje ona wáanie prawa dostpu do czci skáadowych klasy (czyli pól lub
metod), wyró*niajc ich dwa rodzaje: prywatne (ang. private) oraz publiczne
(ang. public).
Ró*nica midzy nimi jest znaczca i bardzo wa*na, gdy* wpáywa na to, które elementy
klasy s widoczne tylko w ramach jej samej, a które tak*e na zewntrz. Te pierwsze
nazywamy wic prywatnymi, za drugie publicznymi.

Prywatne skáadowe klasy (wpisane po sáowie

private

: w jej definicji) s dostpne

jedynie wewntrz samej klasy, tj. tylko dla jej wáasnych metod.

Publiczne skáadowe klasy (wpisane po sáowie

public

: w jej definicji) widoczne s

zawsze i wszdzie - nie tylko dla samej klasy (jej metod), ale na zewntrz - np. dla jej
obiektów.

Danym specyfikatorem objte s wszystkie nastpujce po nim czci klasy, a* do jej
koca lub… kolejnego specyfikatora :) Ich iloü nie jest bowiem niczym ograniczona.

Nic wic nie stoi na przeszkodzie, aby nie byáo ich wcale! W takiej sytuacji wszystkie

skáadowe bd miaáy domylne reguáy dostpu. W przypadku klas (definiowanych

poprzez

class

) jest to dostp prywatny, natomiast dla typów strukturalnych

(sáówko

struct

) - dostp publiczny.

Trudno uwierzyü, ale w C++ jest to jedyna ró*nica pomidzy klasami a strukturami!

Sáowa

class

struct

s wic niemal synonimami; jest to rzecz niespotykana w innych

jzykach programowania, w których te dwie konstrukcje s zupeánie odrbne.

Dla skuteczniejszego rozwiania z powy*szego opisu mo*liwej mgáy niejasnoci, spójrzmy
na ten oto przykáadowy program i klas:

// DegreesCalc - kalkulator temperatur

// typ wyliczeniowy okrelajcy skal temperatur

A tak*e dla unii, chocia* jak wiemy, funkcjonuj one inaczej ni* struktury i klasy.

Podstawy programowania

174

realizacji sáu* w C++ poznane specyfikatory

private

oraz

public

. W miar nabywania

dowiadczenia w pracy z klasami bdziesz je coraz efektywniej stosowaá w swoim
wáasnym kodzie.

Deklaracje pól

Pola s wáaciw treci ka*dego obiektu klasy, to one stanowi jego reprezentacj w
pamici operacyjnej. Pod tym wzgldem nie ró*ni si niczym od znanych ci ju* pól w
strukturach i s po prostu zwykáymi zmiennymi, zgrupowanymi w jedn, kompleksow
caáoü.

Jako miejsce na przechowywanie wszelkiego rodzaju danych, pola maj kluczowe
znaczenie dla obiektów i dlatego powinny byü chronione przez niepowoáanym dostpem z
zewntrz. Przyjáo si wic, *e w zasadzie wszystkie pola w klasach deklaruje si jako
prywatne; ich nazwy zwykle poprzedza si te* przedrostkiem m_, aby odró*niü je od
zmiennych lokalnych:

class

CFoo

{

private

int

m_nJakasLiczba;

std::string

m_strJakisNapis;

Dostp do danych zawartych w polach musi si zatem odbywaü za pomoc
dedykowanych metod. Rozwizanie to ma wiele rozlicznych zalet: pozwala chocia*by na
tworzenie pól, które mo*na jedynie odczytywaü, daje sposobnoü wykrywania
niedozwolonych wartoci (np. indeksów przekraczajcych rozmiary tablic itp.) czy te*
podejmowania dodatkowych akcji podczas operacji przypisywania.
Rzeczone funkcje mog wygldaü chocia*by tak:

public

int

JakasLiczba()

{

return

m_nJakasLiczba;

}

void

JakasLiczba(

int

nLiczba) { m_nJakasLiczba = nLiczba; }

std::string

JakisNapis()

{

return

m_strJakisNapis;

}

};

Nazwaáem je tu identycznie jak odpowiadajce im pola, pomijajc jedynie przedrostki

Niektórzy stosuj nazwy w rodzaju Pobierz...()/Ustaw...() czy te* z angielskiego -
Get...()/Set...(). Le*y to caákowicie w zakresie upodoba programisty.
U*ycie naszych metod „dostpowych” mo*e za przedstawiaü si na przykáad tak:

CFoo Foo;
Foo.JakasLiczba (

);

// przypisanie 10 do pola m_nJakasLiczba

std::cout << Foo.JakisNapis();

// wywietlenie pola m_strJakisNapis

Zauwa*my przy okazji, *e pole m_strJakisNapis mo*e byü tutaj jedynie odczytane, gdy*
nie przewidzielimy metody do nadania mu jakiej wartoci. Takie postpowanie jest
czsto po*dane, ale zale*y rzecz jasna od konkretnej sytuacji, a tu jest jedynie
przykáadem.

Wielkim mankamentem C++ jest brak wsparcia dla tzw. wáaciwoci (ang. properties),

czyli „nakáadek” na pola klas, imitujcych zmienne i pozwalajcych na u*ycie bardziej

foo oraz bar to takie dziwne nazwy, stosowane przez programistów najczciej w przykáadowych kodach, dla

bli*ej nieokrelonych bytów, nie majcych *adnego praktycznego sensu i sáu*cych jedynie w celach
prezentacyjnych. Maj one t zalet, *e nie mo*na ich pomyliü tak áatwo, jak np. litery A, B, C, D itp.

Sprawia to, *e funkcje odpowiadajce temu samemu polu, a sáu*ce do zapisu i odczytu, s przeci*one.

Obiekty

175

naturalnej skáadni (choüby operatora =) ni* dedykowane metody.

Wiele kompilatorów udostpnia wic tego rodzaju funkcjonalnoü we wáasnym zakresie -

w Visual C++ jest to konstrukcja

__declspec

(

property

(...)), o której mo*esz

przeczytaü w

MSDN

. Nie dorównuje ona jednak podobnym mechanizmom znanym z

Delphi.

Metody i ich prototypy

Metody czyni klasy. To dziki swym funkcjom skáadowym pasywne zbiory danych,
którymi s struktury, staj si aktywnymi obiektami.

Z praktycznego punktu widzenia metody niewiele ró*ni si od zwyczajnych funkcji -
oczywicie poza faktem, i* s deklarowane zawsze wewntrz jakiej klasy:

class

CFoo

{

public

void

Metoda();

int

InnaMetoda(

int

);

itp.

};

Deklaracje te mog mieü form prototypów funkcji, a stworzone w ten sposób metody
wymagaü jeszcze implementacji, czyli wpisania ich kodu. Czynnoci t zajmiemy si
dokáadnie w nastpnym paragrafie.
Warto jednak wiedzieü, *e dopuszczalne jest tak*e wprowadzanie kodu metod
bezporednio wewntrz bloku

class

. Robilimy tak zreszt w przypadku metod

dostpowych do pól, a w podobnych sytuacjach rozwizanie to sprawdza si bardzo
dobrze. Nie nale*y aczkolwiek postpowaü w ten sposób z dáugimi metodami,
zawierajcymi skomplikowane algorytmy, gdy* mo*e to spowodowaü znaczcy wzrost
rozmiaru wynikowego pliku EXE.

Kompilator traktuje bowiem takie funkcje jako inline, tzn. rozwijane w miejscu

wywoáania, i wstawia caáy ich kod przy ka*dym odwoáaniu si do nich. Dla krótkich,

jednolinijkowych metod jest to dobre rozwizanie, przyspieszajce dziaáanie programu.

Dla dáu*szych nie musi wcale takie byü.

Dokáadniejszych informacji na

ten temat

oraz o samych

funkcjach inline

tradycyjnie

mo*na znale(ü w MSDN.

To jeszcze nie koniec zabawy z metodami :) Niektóre z nich mo*na mianowicie uczyniü
staáymi. Zabieg ten sprawia, *e funkcja, na której go zaaplikujemy, nie mo*e
modyfikowaü *adnego z pól klasy

, a tylko je co najwy*ej odczytywaü.

Po co komu takie udziwnienie? Teoretycznie jest to pewna wskazówka dla kompilatora,
który byü mo*e uczyni nam w zamian áask poczynienia jakich optymalizacji.
Praktycznie jest to te* pewien sposób na zabezpieczenie si przed omyákowym
zmodyfikowaniem obiektu w metodzie, która wcale nie miaáa czego takiego robiü.
Jednym sáowem korzyci s piorunujce ;)
Uczynienie jakiej metody staá jest banalnie proste: wystarczy tylko dodaü za list jej
parametrów magiczne sáówko

const

, np.:

class

CFoo

{

private

No mo*e nie caákiem *adnego; istnieje pewien drobny wyjtek od tej reguáy, ale jest on na tyle drobny i na

tyle sproadycznie stosowany, *e nie wyjaniam go bli*ej i odsyáam tylko purystów do stosownego wyjanienia w

MSDN

Podstawy programowania

176

int

m_nPole;

public

int

Pole()

const

{

return

m_nPole; }

};

Funkcja Pole() (bdca de facto obudow dla zmiennej m_nPole) bdzie tutaj sáusznie
metod staá.

Dla szczególnie zainteresowanych polecam

lektur uzupeániajc

o staáych metodach,

znajdujc si w miejscu wiadomym :)

Konstruktory i destruktory

Przebkiwaáem ju* parokrotnie o procesie tworzenia obiektów, podkrelaj przy tym
znaczenie tego procesu. Za chwil wyjani si, dlatego jest to takie wa*ne…

Decydujc si na zastosowanie technik obiektowych w konkretnym programie musimy
mieü na uwadze fakt, i* oznacza to zdefiniowane przynajmniej kilku klas oraz instancji
tych*e. Istot OOPu jest poza tym odpowiednia komunikacja midzy obiektami:
wymiana danych, komunikatów, podejmowanie dziaáa zmierzajcych do realizacji
danego zdania, itp. Aby zapewniü odpowiedni przepáyw informacji, krystalizuje si mniej
lub bardziej rozbudowana hierarchia obiektów, kiedy to jeden obiekt zawiera w sobie
drugi, czyli jest jego wáacicielem. To doü naturalne: wikszoü otaczajcych nas
rzeczy mo*na przecie* rozáo*yü na czci, z których si skáadaj (gorzej mo*e byü z
powtórnym záo*eniem ich w caáoü :D).
Konsekwencje tego stanu rzeczy dla procesu tworzenie (i niszczenia) obiektów s raczej
oczywiste: kreacja obiektu zbiorczego musi pocignü za sob stworzenie jego
skáadników; podobnie jest te* z jego destrukcj. Jasne, mo*na te kwestie zostawiü
kompilatorowi, ale paradoksalnie czyni to kod trudniejszym do zrozumienia, pisania i
konserwacji

C++ oferuje nam na szczcie mo*liwoü podjcia odpowiednich dziaáa zarówno
podczas tworzenia obiektu, jak i jego niszczenia. Korzystamy z niej, wprowadzajc do
naszej klasy dwa specjalne rodzaje metod - s to tytuáowe konstruktory oraz
destruktory.

Konstruktor to specyficzna funkcja skáadowa klasy, wywoáywana zawsze podczas
tworzenia nale*cego do obiektu.

Typowym zadaniem konstruktora jest zainicjowanie pól ich pocztkowymi wartociami,
przydzielenie pamici wykorzystywanej przez obiekt czy te* uzyskanie jakich kluczowych
danych z zewntrz.
Deklaracja konstruktora jest w C++ bardzo prosta. Metoda ta nie zwraca bowiem *adnej
wartoci (nawet

void

!), a jej nazwa odpowiada nazwie zawierajcej j klasy. Wyglda

wic mniej wicej tak:

class

CFoo

{

private

jakie przykáadowe pole...

float

m_fPewnePole;

public

// no i przyszáa pora na konstruktora ;-)

CFoo()

{ m_fPewnePole =

0.0

; }

Wbrew pozorom to racjonalna reguáa: im wicej jest rzeczy, które kompilator robi „za plecami” programisty,

tym bardziej zagmatwany jest kod - choüby nawet byá krótszy.

Obiekty

177

};

Zazwyczaj te* konstruktor nie przyjmuje *adnych parametrów, co nie znaczy jednak, *e
nie mo*e tego czyniü. Czsto s to na przykáad startowe dane przypisywane do pól:

class

CSomeObject

{

private

jaki rodzaj wspóárzdnych

float

m_fX, m_fY;

public

konstruktory

CSomeObject()

{

m_fX

m_fY

0.0

; }

CSomeObject(

float

fX,

float

fY)

{ m_fX = fX; m_fY = fY; }

};

Posiadanie takiego parametryzowanego konstruktora ma pewien wpáyw na sposób
tworzenia obiektów, gdy* musimy wtedy podaü dla odpowiednie wartoci. Dokáadniej
wyjanimy to w nastpnym paragrafie.
Warto te* wiedzieü, *e klasa mo*e posiadaü kilka konstruktorów - tak jak na powy*szym
przykáadzie. Dziaáaj one wtedy podobnie jak funkcje przeci*ane; decyzja, który z nich
faktycznie zostanie wywoáany, zale*y wic od instrukcji tworzcej obiekt.

Z wiadomych wzgldów konstruktory czynimy zawsze metodami publicznymi.

Umieszczenie ich w sekcji

private

daáoby bowiem doü dziwny efekt: taka klasa nie

mogáaby byü normalnie instancjowana, tzn. niemo*liwe byáoby utworzenie z niej obiektu

w zwykáy sposób.

OK, konstruktory maj zatem niebagateln rol, jak jest powoáywania do *ycia nowych
obiektów. Doskonale jednak wiemy, *e nic nie jest wieczne i nawet najdáu*ej dziaáajcy
program kiedy bdzie musiaá byü zakoczony, a jego obiekty zniszczone. T niechlubn
robot zajmuje si kolejny, wyspecjalizawany rodzaj metod - destruktory.

Destruktor jest specjaln metod, przywoáywan podczas niszczenia obiektu
zawierajcej j klasy.

W naszych przykáadowych klasach destruktor nie miaáby wiele do zrobienia - zgoáa nic,
poniewa* *aden z prezentowanych obiektów nie wykonywaá czynnoci, po których
nale*aáoby sprztaü. To si wszak niedáugo zmieni, zatem poznanie destruktorów z
pewnoci nie bdzie szkodliwe :)
Postaü destruktora jest tak*e niezwykle prosta i w dodatku zawsze identyczna. Funkcja ta
nie bierze bowiem *adnych parametrów (bo i jakie miaáaby braü?) i niczego nie zwraca.
Jej nazw jest za nazwa zawierajcej klasy poprzedzona znakiem tyldy (~).

Nazewnictwo destruktorów to jedna z niewielu rzeczy, za które twórcom C++ nale* si
tgie baty :D O co dokáadnie chodzi?
Otóz teoretycznie znak tyldy uzyskujemy za pomoc klawisza Shift oraz tego
znajdujcego si w lewym górnym rogu alfanumerycznej czci klawiatury. Problem
polega na tym, *e po pierwszym jego u*yciu *dany znak nie pojawia si na ekranie.
Dzieje si tak dlatego, i* dawniej za jego pomoc uzyskiwaáo si litery specyficzne dla
pewnych jzyków, z kreseczkami - np. , é czy ó.
Fakt ten mo*naby zignorowaü, jako *e wikszoü liter nie posiada swoich
„kreseczkowych” odpowiedników, wic wcinicie ich klawiszy po znaku tyldy powoduje
pojawienie si zarówno osáawionego szlaczka, jak i samej litery. Do tej grupy nie nale*y
jednak litera C, któr to przyjáo si pisaü na pocztku nazw klas. Zamiast wic *danej
sekwencji ~C uzyskujemy… û!
Jak sobie z tym radziü? Ja nawykáem do dwukrotnego przyciskania klawisza tyldy, a

Podstawy programowania

178

nastpnie usuwania nadmiarowego znaku. Mo*liwe jest te* u*ycie jakiej „neutralnej”
litery w miejsce C, a nastpnie skasowanie jej. Chyba najlepsze jest jednak wciskanie
klawisza tyldy, a nastpnie spacji - wprawdzie to dwa przycinicia, ale w ich wyniku
otrzymujemy sam w*yk.

Klasa wyposa*ona w odpowiedni destruktor mo*e zatem jawiü si nastpujco:

class

CBar

{

public

// konstruktor i destruktor

CBar()

{

/* czynnoci startowe */

}

// konstruktor

~CBar()

{

/* czynnoci koczce */

}

// destruktor

};

Jako *e jego forma jest cile okrelona, jedna klasa mo*e posiadaü tylko jeden
destruktor.

Co jeszcze?

Pola, zwykáe metody oraz konstruktory i destruktory to zdecydowanie najczciej
spotykane i chyba najwa*niejsze elementy klas. Aczkolwiek nie jedyne; w dalszej czci
tego kursu poznamy jeszcze skáadowe statyczne, funkcje przeci*ajce operatory oraz
tzw. deklaracje przyja(ni (naprawd jest co takiego! :D). Poznane tutaj skáadniki klasy
bd jednak zawsze miaáy najwiksze znaczenie.

Mo*na jeszcze wspomnieü, *e wewntrz klasy (a tak*e struktury i unii) mo*emy

zdefiniowaü… kolejn klas! Tak definicj nazywamy wtedy zagnie*d*on. Technika ta

nie jest stosowana zbyt czsto, wic zainteresowani poczytaj o niej w

MSDN

Podobnie zreszt jest z innymi typami, okrelanymi poprzez

enum

czy

typedef

Implementacja metod

Definicja klasy jest zazwyczaj tylko poáow sukcesu i nie stanowie wcale koca jej
okrelania. Dzieje si tak przynajmniej wtedy, gdy umiecimy w niej jakie prototypy
metod, bez podawania ich kodu.

Uzupeánieniem definicji klasy jest wówczas jej implementacja, a dokáadniej owych
prototypowanych funkcji skáadowych. Polega ona rzecz jasna na wprowadzeniu instrukcji
skáadajcych si na kod tych*e metod w jednym z moduáów programu.
Operacj t rozpoczynamy od doáczenia do rzeczonego moduáu pliku nagáówkowego z
definicj naszej klasy, np.:

#include

"klasa.h"

Potem mo*emy ju* zajü si ka*d z niezaimplementowanych metod; postpujemy tutaj
bardzo podobnie, jak w przypadku zwykáych, globalnych funkcji. Skáadnia metody
wyglda bowiem nastpujco:

[typ_wartoci/

void

]

nazwa_klasy::nazwa_metody([parametry]) [

const

]

{

instrukcje

}

Nowym elementem jest w niej nazwa_klasy, do której nale*y dana funkcja. Wpisanie jej
jest konieczne: po pierwsze mówi ona kompilatorowi, *e ma do czynienia z metod klasy,
a nie zwyczajn funkcj; po drugie za pozwala bezbádnie zidentyfikowaü macierzyst
klas danej metody.

Podstawy programowania

198

To w niej wáanie podajemy klasy bazowe, z których chcemy dziedziczyü. Czynimy to,
wpisujc dwukropek po nazwie definiowanej wáanie klasy i podajc dalej list jej klas
bazowych, oddzielonych przecinkami. Zwykle nie bdzie ona zbyt dáuga, gdy* w
wikszoci przypadków wystarczajce jest pojedyncze dziedziczenie, zakáadajce tylko
jedn klas bazow.

Istotne s natomiast kolejne specyfikatory, które opcjonalnie mo*emy umieciü przed
ka*d nazw_klasy_bazowej. Wpáywaj one na proces dziedziczenia, a dokáadniej na
prawa dostpu, na jakich klasa pochodna otrzymuje skáadowe klasy bazowej.
Kiedy za mowa o tych*e prawach, natychmiast przypominamy sobie o sáówkach

private

protected

public

, nieprawda*? ;) Rzeczywicie, specyfikatory

dziedziczenia wystpuj zasadniczo w liczbie trzech sztuk i s identyczne z tymi
wystpujcymi wewntrz bloku klasy. O ile jednak tamte pojawiaj si w prawie ka*dej
sytuacji i klasie, o tyle tutaj specyfikator

public

ma niemal caákowity monopol, a u*ycie

pozostaáych dwóch nale*y do niezmiernie rzadkich wyjtków.
Dlaczego tak jest? Otó* w 99.9% przypadków nie ma najmniejszej potrzeby zmiany praw
dostpu do skáadowych odziedziczonych po klasie bazowej. Je*eli wic które z nich
zostaáy tam zadeklarowane jako

protected

, a inne jako

public

, to prawie zawsze

yczymy sobie, aby w klasie pochodnej zachowaáy te same prawa. Zastosowanie

dziedziczenia

public

czyni zadoü tym *daniom, dlatego wáanie jest ono tak czsto

stosowane.

O pozostaáych dwóch specyfikatorach mo*esz przeczytaü w

MSDN

. Generalnie ich

dziaáanie nie jest specjalnie skomplikowane, gdy* nadaj skáadowym klasy bazowej

prawa dostpu wáaciwe swoim „etykietowym” odpowiednikom. Tak wic dziedziczenie

protected

czyni wszystkie skáadowe klasy bazowej chronionymi w klasie pochodnej, za

private

sprowadza je do dostpu prywatnego.

Formalnie rzecz ujmujc, stosowanie specyfikatorów dziedziczenia jest nieobowizkowe.
W praktyce jednak trudno korzystaü z tego faktu, poniewa* pominicie ich jest
równoznacznie z zastosowaniem specyfikatora

private

- nie za naturalnego

public

Niestety, ale tak wáanie jest i trzeba si z tym pogodziü.

Nie zapominaj wic o specyfikatorze

public

, gdy* jego brak przed nazw klasy bazowej

jest niemal na pewno bádem.

Dziedziczenie pojedyncze

Najprostsz i jednoczenie najczciej wystpujc w dziedziczeniu sytuacj jest ta, w
której mamy do czynienia tylko z jedn klasa bazow. Wszystkie dotychczas pokazane
przykáady reprezentowaáy to zagadnienie; nazywamy je dziedziczeniem pojedynczym
lub jednokrotnym (ang. single inheritance).

Proste przypadki

Najprostsze sytuacje, w których mamy do czynienia z tym rodzajem dziedziczenia, s
czsto spotykane w programach. Polegaj one na tym, i* jedna klasa jest tworzona na
podstawie drugiej poprzez zwyczajne rozszerzenie zbioru pól i metod.
Ilustracj bdzie tu kolejny przykáad geometryczny :)

class

CEllipse

// elipsa, klasa bazowa

{

Zakáadajc, *e mówimy o klasach deklaroanych poprzez sáowo

class

. W przypadku struktur (sáowo

struct

które s w C++ niemal to*same z klasami, to

public

jest domylnym specyfikatorem - zarówno dziedziczenia,

jak i dostpu do skáadowych.